Clojure Lisp and a modern GUI
briancarper.net
briancarper.net
There are very good reasons why this combination hasn't been particularly popular. C++ with a few libs like MFC or WTL continues to rule on Windows being slowly replaced by .NET stack, Obj-C keeps rocking on OSX and C/C++ with Qt/GTK doing their job on Linux/BSD. Why is that? I suspect because of 3 reasons: very weak JVM penetration on the desktop, JVM is too heavy for most applications and because JDK-based UI feels foreign on every platform.
Developing a desktop application on JDK means that your users will have to deal with 100MB+ downloads followed by quirky installation process that rewards the with less then stellar UI experience at the end, especially the slow startup time.
Startup time is more important than most developers think: majority of desktop apps absolutely need it: imagine 5-second delay every time you wanted to launch Apple's "Quick View" to glance at a file, or imagine 5+ JVM-based apps load&initialize after reboot. Most desktop software I worked on was small-to-medium size and we just couldn't afford to add those 5+ seconds on JVM initialization. JVM I guess will work OK for projects like Ecilpse or a big Office suite or something like Photoshop. Microsoft understands this very well, this is why C#/.NET is so carefully optimized around loading time and comes with precompilation tools that essentially turn your C# code (including .NET itself) into native Win32 modules.
One project I want to do for myself is a usable Del.icio.us client for OSX. I can't see how I can use JVM-based tools for that... I want instant start-up by a hotkey when I need to search for links or add one. Moreover, I want users to be able to download and try it under 20 seconds.
The only JDKUI apps I'v ever used were development tools for Java itself plus numerous crap for the enterprise. And, of course, every once in a while I get "Java. Please wait..." splash screen on a new cellphone, followed by a prompt "Cancel/Go Back" keypress: that pretty much sums up my JVM-based UI experience. Which is sad: Clojure is going to be locked up on the server just like Java has been for years.
> ..users will have to deal with 100MB+ downloads
I've never seen a JRE download that big. At most it's around 25Mb, although in practice you can get it a lot smaller than that (sub 10Mb for the minimal install afaik).
> ..One project I want to do for myself is a usable Del.icio.us client for OSX.
Java is already shipped on every copy of OS X - so zero download in that case. The startup time seems just fine. I'm using Apache JMeter right now and the startup time seems about the same as any other app I use.
Veryyy slowly... but I think its the same issue with it.
>100MB+ downloads
When is that ever the case? Certainly not the VM or even a "odd" toolkit like SWT.
>Startup time is more important than most developers think
Agree. Any app its more important them people think.
The bottom line is if you want maximum responsiveness, minimum size, you have to eliminate layers, not add them. And Obj-C + cocoa is a fairly productive environment. however, it isn't necessarily small or fast to startup - have you downloaded or tried to create a cocoa app lately? 30 + meg is common for the most basic things. And they are anything but instant to start up. Sounds like you want quicksilver like performance - which means pre loading - or just use quicksilver (probably already is a del.icio.us thing in existence).
Sizes, INSTALLED, not from the compressed DMG:
An entire quicken-like 100% cocoa app: 6 megabytes,
Seashore, a streamlined graphics editor based on the gimp: 8.4mb
And for a "truly small" example, the "wakeup your computer and play an itunes song" alarm clock I first wrote to learn Cocoa years ago: 500k.
"quicken-like" - well that means nothing unless it replicates the girth of horrible accounting rules that quicken has to adhere to - if its a "quicken like" accounting app, I guess it would not, so I don't think that really is a useful measure.
The startup time can be a problem, and Clojure offering only JIT compilation doesn't improve things.
I had some experience with using Swing and Clojure, and was able to easily wire up GUIs laid out in NetBeans to Clojure code.
This included subclassing elements such as table view headers to customize appearance, cross-platform on OS X and XP.
Note also that Clojure can be hinted to eliminate type reflection, bringing performance to a par with Java.
I make an argument for Swing as the best Ruby GUI option here: http://www.ibm.com/developerworks/library/j-monkeybars/index...
I imagine something akin to Monkeybars could be developed for Clojure whereby developers can exploit the fluidity of the language while getting the benefit of Swing development tools.
It's interesting that Qt places itself as "a better Java". Regarding the UI and API parts, many coders knowing both Java and Qt seem to agree.
Every time I use Inkscape on Windows I'm happy about the Gtk toolkit, because there was no chance at all of the software being ported to Win32 otherwise.
This is 2008, jesus christ.
http://code.google.com/android/devel/ui/xml.html http://en.wikipedia.org/wiki/Extensible_Application_Markup_L...
Lots of OSX apps (the ones which most people think of as being friendly, usable and pretty) are done mostly programmatically, even with the interface builder stuff available...
From what I understand, it only complicates development even more without providing any real improvement.
Also, most of the XML-presentation libraries offer multiple language bindings, so there's less of a requirement for your language to provide its own GUI toolkit, and it's easier to convert your app from one language to another (e.g. injecting Python into a legacy C app) without losing any of the details from the original interface.