Qt and Lisp...a great opportunity?

[Unne]

I've used QtJambi in Clojure to good effect. Very easy to get up and running quickly. Worked cross-platform with no problems. Very well-documented. It's sad to hear QtJambi is losing official support and going "community", but at least version 4.5 is there to use.

As for Clojure, it looks good but is probably a no-go in my specific case for performance reasons. Yeah, I know about premature optimization, but there are some things in 3D graphics that just -have- to be fast (vector and matrix math, iterating over image data, etc). My understanding is that Common Lisp will let me put in type declarations, turn off safety, and so on in order to optimize specific sections of code. Being able program at a high level in general but retain the ability to really tune specific code paths would be a huge benefit to us.

You can have type declarations and primitive unchecked integer/floating point arithmetic in Clojure if you want it. http://clojure.org/java_interop#toc36 Clojure can be just about as fast as Java. Not sure if that's fast enough but it might be worth a try.

[August]

You can have type declarations and primitive unchecked integer/floating point arithmetic in Clojure if you want it. http://clojure.org/java_interop#toc36 Clojure can be just about as fast as Java. Not sure if that's fast enough but it might be worth a try.

Thanks much for the info! I will definitely do some performance testing with Clojure as part of my Lisp research. The thing I like about Common Lisp is that you can easily get a look at the disassembly. In my particular case, we would likely have a couple of code paths where we would want to get the "as fast as C/C++" claims working

[gugamilare]

I've used QtJambi in Clojure to good effect. Very easy to get up and running quickly. Worked cross-platform with no problems. Very well-documented. It's sad to hear QtJambi is losing official support and going "community", but at least version 4.5 is there to use.

Well, it is more or less ok, I heard Nokia will support it for one year. On the other hand, about the community keeping Qt Jambi up to date, well...

You can have type declarations and primitive unchecked integer/floating point arithmetic in Clojure if you want it. http://clojure.org/java_interop#toc36 Clojure can be just about as fast as Java. Not sure if that's fast enough but it might be worth a try.

Well, I didn't know that, this seems good news. I have a bad feeling about java, though - it looks like that it's too heavy, you can't write small and reasonably fast applications. I can be wrong right know, I'm saying that because I already have used Eclipse (with cusp, it is a good option for beginners like I was back then - but you have to open it once and keep it open, because opening it frequently is frustrating) and I also downloaded Jubbler once (a VERY SLOW program to edit subtitles).

Anyway, not saying anything against Clojure itself, it looks to have nice features (which I envy - although I didn't try it).

[Unne]

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.

The other bad thing about QtJambi is that there are issues with memory leaks due to the way Qt disposes of objects, and the separate garbage collector in the JVM not playing nicely together. (See e.g. here.) I imagine that would be a problem for any other garbage-collected language too though. You can easily work around this but it's a pain.

On the other hand QtJambi works pretty well from the Clojure REPL, you can fiddle with Qt objects and re-compile event handlers while your app is running and other such fun. It integrates well with native Java threads too, which Clojure can put to good use.

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.

[gugamilare]

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...

[dmitry_vk]

The other bad thing about QtJambi is that there are issues with memory leaks due to the way Qt disposes of objects, and the separate garbage collector in the JVM not playing nicely together.

That's bad. For Gtk, memory management is better — it is easy to use it in garbage-collected language and not have memory leaks or prematurely destroyed objects.

[nuntius]

The other bad thing about QtJambi is that there are issues with memory leaks due to the way Qt disposes of objects, and the separate garbage collector in the JVM not playing nicely together.

That's bad. For Gtk, memory management is better — it is easy to use it in garbage-collected language and not have memory leaks or prematurely destroyed objects.

Qt's memory management is quite good. I suspect the problems relate to the binding, not the library. The only difficulty I've had with Qt is the need to sometimes call deleteLater() rather than delete().

[AlexPaes]

Just today as i browsed through Hacker News i found this link, a Common Lisp binding to the smoke interface to QT. I thought this should interest some of the people following this thread.

CommonQT

[gugamilare]

Wow, nice! This is a great new.