On Jan 17, 11:51 pm, Mark Allerton wrote:
> Hi all,
>
> I've been hacking on a bridge between Clojure and Cocoa, and have been
> prompted to break cover by recent discussion of the subject of Objective-C
> interfacing here on this list.
This is fantastic! In you README.md, you provide the reasons why this
is better than a Java-to-Cocoa bridge.
Apple's Java-Cocoa bridge was a failure - and in hindsight it's not
that hard to see why. Despite being an Ahead-of-Time compiled language
based on C, Objective-C's runtime is in fact quite a bit more dynamic
than Java's - and this left Java developers at a disadvantage, being
made to write more code to work around the impedance mismatch.
So why might Clojure be a better match? As a dynamic language it may
be a better fit for the dynamic aspects of the Objective-C runtime. In
addition, as a lisp, Clojure has few ties between programming paradigm
and syntax, making it easier to adopt Objective-C's paradigms directly
in Clojure code.
I think this is spot on. This is one reason why I have never had much
interest in working with Apple's Java Cocoa bridge. The code always
felt clumsy and awkward compared to the Objective-C version. I'm
certain that, as you say, that the dynamic nature of Clojure is a
better fit with Objective-C than Java. Indeed, this is why LispWorks
has an Objective-C bridge for Cocoa, and why so many Scheme projects
also have Objective-C bridges.
As for "Why is this a terrible idea?":
There are some other reasons Java was a bad fit for Cocoa, and Clojure
doesn't fix these - namely the memory overhead of the JVM, startup
time and lack of application responsiveness due to JIT compilation and
garbage collection.
-
I think the relatively long start-up time can be tolerated, especially
if the programmer provides some fancy splash screen to distract the
user while the rest of the application loads. The lack of
responsiveness is a more difficult issue to overcome, but if prior
experience with Apple's Java bridge is any guide, the mushy (rather
than crisp) UI responsiveness is tolerable if not ideal.
In the end, I don't think this is a "terrible idea" by any means. It
provides a great entry point to Clojure integration with Cocoa,
providing a pathway to building superior UIs for Clojure
applications. Any lingering problems, I'm sure, can be overcome or
remedied in the long-term.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
