SBCL and Lispworks. A short while ago, I shipped a project which was implemented using those two Lisp implementations.
- Windows GUI for someone who needs to select things quickly and usably. The users are nontechnical and may even be nervous with the computer, so they need extra usability support. Essentially a webapp with a rich-client GUI instead of a browser, so it's constantly communicating with a server.
Lispworks' GUI system is pretty excellent. You're given a simple declarative language, much like DEFCLASS. But to start out, there's a handy graphical tool which lets you build a simple tree respresentation of a GUI, auto-generating its code. I found that it started to suck once the GUI gets more complex; at which point you'll want to make changes to the DEFCLASS-like output. (Maybe it's come to scale better since I checked.) The documentation certainly isn't Java-level, but it's fine, I think.
I'm staying at a minor version lower than the current version, because I'm not sure how to get the new one working well with Emacs/Slime
I find Emacs very useful, even if maybe the debugging facilities in Lispworks' IDE is far superior.
The users opine that the GUI looks attractive. I'm glad that I don't need some bulky installer; it's all in one .exe, though I need to package a few DLLs for older Windows installations.
Pretty crossplatform. I remember building a Windows GUI, which ran on MacOS without needing to alter a line of code. I mean, I'm sure I'd have to change the menu items around to conform to the Mac's UI guidelines, but that's not a big deal.
- website (which contains video as well as continuously-updated meeting info)
- controls a video editor (displays text and graphics under a speaker's face) and streams video to TV station
- coordinates these various parts, sending serialized objects all over the place
Looking at the poll results, most of us are familiar with SBCL. On the live server, I have a screen session with 3 Emacs/Slime sessions, and one screen devoted to displaying whether video is being transmitted to the SBCL-controlled video editor.
There's 3 technical weak links:
- VLC (an opensource video server) -- I simply don't trust it. The project's constraints seemed to force the use of it. However, now those constraints are greatly loosened.
- Networking. This is largely a human problem. Who knows when someone decides to change some resource's address, or decides to stop sticking our webpages into the main site? Also, pulling video from the multicast server requires a voodoo hack. (The one part I didn't write in Lisp was a Java proxy which forwarded multicast packets to the Lisp-controlled VLC instances. It probably could've been written in Lisp; I merely wrote it in Java to eliminate Lisp as a potential culprit while solving my multicast problem.)
- Elephant/Postmodern is pleasant and simple, though I have a nagging concern about it occasionally complaining about DB connections. (Doesn't seem to lose data AFAIK; just complains.) Definitely need to fix that.
It's actually been programmed almost exclusively by one person, under suboptimal conditions.
- Fancy video features (Flash, etc), and radical decrease in the app's dependence on VLC.
- Significant usability improvement -- instead of selecting items from a list (with the help of an interactive search box), users will be able to select 2D dots positioned like the room layout.
- In a main chamber, cameras and mics will do the user's job, for the most part, so the user can lounge around.