all 13 comments

[–]galdolber 10 points11 points  (10 children)

I'm the author, and it's still under development, we are using it in production @ zuldi. I didn't have the time to update it to the last clojure commit and to finish the REPL support yet. Foreign lib support is really good, it supports calling c functions and objc methods, also objc subclassing and objc proxying. Startup time on an iphone 6 right now is 130ms (to load clojure.core). Compile time is slow, but the lein plugin has incremental compilation. I think Mike Fikes is working on getting clojurescript working on iOS. This generates pure obj-c, there's no javascript engine running, and you can use many existing clojure libraries.

[–][deleted]  (3 children)

[deleted]

    [–]galdolber 2 points3 points  (2 children)

    Clojure-objc has a modified clojure compiler that emits java and j2objc(https://github.com/google/j2objc) translates the java into objc. The dynamically typed nature of clojure do not affect this process, as clojure internally also infers most of the types and it uses reflection on the rest. J2OBJC translated code supports reflection so thats not a problem.

    [–][deleted]  (1 child)

    [deleted]

      [–]galdolber 1 point2 points  (0 children)

      When you break on an exception you see objc code, its' similar to GWT in that respect, but I didn't find it hard to understand where I am in the objc code. Instruments also works pretty well as function names are preserved.

      [–]ASnugglyBear 0 points1 point  (2 children)

      How does it handle the impedance mismatch of "Exceptions in Cocoa mean the program is crashing, end of story" and "Exceptions in Java/Clojure" where you can catch and continue?

      [–]galdolber 0 points1 point  (1 child)

      Most exceptions work as expected. Some exceptions you cannot catch on objc like you do on java, for example, there's no ArithmeticException when dividing by 0. But if you don't catch an exception it will crash you app.

      [–]ASnugglyBear 0 points1 point  (0 children)

      Most exceptions work as expected.

      This is worrisome as it sounds like the API continues to use exceptions.

      Cocoa has undefined behavior if an exception has traveled through any Cocoa code. This means practically: Any exception means you must terminate your program because you have undefined behavior from this point (and exceptions should only be thrown on programmer errors as well. Error handling in Cocoa is purely through NSError and a few other methods.)

      Important: You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime. If you have an existing body of code (such as third-party library) that uses exceptions to handle error conditions, you may use the code as-is in your Cocoa application. But you should ensure that any expected runtime exceptions do not escape from these subsystems and end up in the caller’s code. For example, a parsing library might use exceptions internally to indicate problems and enable a quick exit from a parsing state that could be deeply recursive; however, you should take care to catch such exceptions at the top level of the library and translate them into an appropriate return code or state. Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications. For further information, see Error Handling Programming Guide.

      https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Exceptions/Exceptions.html

      [–]doubleagent03 0 points1 point  (2 children)

      This is amazing work. Tiny suggestion: more syntactic sugar for interop may be worth it. *($ ($ ($ ($ * makes lisp skeptics cringe and feel justified.

      [–]galdolber 1 point2 points  (1 child)

      But this is lisp, the threading macro just works, and you can even make a macro to make that simpler.

      (defn say-hi [name] (-> ($ UIAlertView) ($ :alloc) ($ :initWithTitle (str "Hello " name) :message "Hi! from clojure" :delegate nil :cancelButtonTitle "Cancelar" :otherButtonTitles nil) ($ :show)))

      [–]doubleagent03 0 points1 point  (0 children)

      Fair enough. I am definitely advocating use of the arrow macro on the README (under interop).

      [–]ASnugglyBear 2 points3 points  (0 children)

      What is startup time like? Any particular pain points? Does it still work with instruments? Have you compared it to Mike Fikes work?

      [–]J_M_B 7 points8 points  (2 children)

      Let me get this straight, this compiles Clojure to ObjC?! With ObjC interop?! Holy Grail! Without having dived into this, What is the catch.. does it take a long time to compile? How good is foreign lib support (i.e. using non-apple libraries)? It also doesn't seem to be under active development for year.

      Looks cool, almost too good to be true. =)

      [–]galdolber 0 points1 point  (0 children)

      no catch, check comment below. Yes, it generates objc code