Unne wrote:The JVM is heavy and it takes a while to start, and it's an enormous memory hog, but once it's running it goes fast. In my (limited) experience QtJambi apps run about as fast as native Qt apps once they're up and running. In practice this isn't that much of an issue, because Clojure like any other Lisp is meant to be started once in a blue moon, and then you play at the REPL.
Yes, it takes a while to start, which means you can't create desktop programs with it, for instance. Maybe an Internet Browser, but it can't do too much initialization. A solution is to create a server and let it keep running (waiting) in the background, but it would be difficult to do such a thing if the user don't like the idea of having one hundred megabytes of RAM gone forever.
I guess the same idea can be done with SBCL, or Common Lisp in general - let a small C program try to communicate with CL through a socket (or DBUS), and make the implementation run some code or load some file in a separated thread. I'll try to do this on my machine in a near future.
It'd be cool to have Qt4 bindings for Common Lisp, that's something I've wanted for a while before I jumped ship for Clojure. Supposedly it's not too hard to do nowadays if you use Smoke
. There are even PHP bindings for Qt4. Surely Common Lisp can beat PHP.
Nice! Understanding Smoke and maybe use it to create an interface is added to my WISH-TO-DO list (now that's a big list...
). I wonder if MOP can help doing such a binding. Specializing the function slot-value-using-class to access the foreign code as if it where a slot in a CL class, specialize compute-class-precedence-list, creating subclasses of Qt classes as if they where CLOS classes...