So a few years back I wrote my M.Sc. thesis as a part of which I implemented an engine for Polish interactive fiction (a.k.a. text adventure) games (which is a very different problem from English interactive fiction because of inflection and the fact that in Polish the order of words in a sentence is not as rigid as in English.) The example game I made using this engine was a remake of the classic "Hobbit." All the code was in Common Lisp and it was a console game at that point but I wanted to add some graphics to make it look more like the original.
I looked into several options, starting from cl-sdl, but (at least at the time) none of them worked on Linux and Windows with the Common Lisp implementation I used (which was clisp.) I don't remember the details but I spent a good week pounding my head against the wall. clisp has a very good ffi mechanism but you can't use ffi to call into SDL because SDL (on some platforms at least) needs to use its own main() function, so once you're running your Lisp code it's too late.
In the end I decided to implement the graphics part in C and just talk to the Common Lisp backend over a pipe. If you speak Polish you can check out the results on http://www.jfedor.org/pfedor/hobbit.html
Note that this method would not have been possible for anything much more complex, like say an arcade game, and also that in other languages it would typically be trivial (say using pygame in Python.)
It was generally library problems, but then I was trying to use sbcl on windows the last time I attempted CL development (this was over a year ago, before I found out about clojure) so even the libraries that DID exist were painful to deal with.
Maybe things have changed but I could not make much headway with ASDF so even when I did find the libraries... yeah. And yes I did have cygwin installed which is why I got past some of the problems.
Maybe I'd have made real headway if I were full on in Linux land where sbcl and everything else has much better support, since it's built around the *nix tool chain.
I develop on Windows and deploy on Unix. Library problems are something we have to face on every platform and programming language, as programmers, but we learn to work around them.
This morning I needed HTML to PDF generation; my first instinct was to use something from Lisp, I found xhtml to pdf generation stuff in CL-TYPESETTING's contrib but it didn't work for me, so I went out and mocked up the application with a web service .. just to find out the remote server shut me down. Next try was to download Perl modules, PDF::FromHTML was broken for me and I didn't know how to fix it (I am not a good perl programmer, btw.) I tend tried the PHP HTML_ToPDF, and it too was too problematic for my tastes. A few hours later, I retooled the app to use a shell pipe:
I then played with that for a bit and found it too fickle. Took a second look at the CL-TYPESETTING stuff, my application was now working but still I wasn't confident with it, however, since 7AM this morning, I have had so much exposure to HTML to PDF converters that I knew how they were supposed to function. It took me about 10 minutes to find the problem in the CL-TYPESETTING package (Windows didn't have truetype font it was referencing and the sample usage was buried in a comment at the bottom of the xml-xform.lisp file.)
It would have been very convenient for me to bitch about Perl and its broken PDF::FromHTML module, even though any competent Perl programmer would have told me how to fix it in a jiffy. And the PHP package. It was also convenient to bitch about the web service that blocked me, but I found out they were charging an access fee for the API and I shouldn't have scraped their web page and abused their servers.
Truth is, all languages, tools and platforms suck in small user-dependent ways (they are not DWIM-enabled.) You could waste a life time complaining about them, so the productive thing to do is weigh the language's pros against its cons, and if it's mostly good, then you better learn it well and use it to its full potential.
This is very topical for me. With Lisp, if you have a marginally obscure problem, there is often no answer presumably because no one else has encountered that issue before. With Python, there are 1,000 people who ran into the same thing.
My current problem: Using CL+SSL apparently has a bug which makes it not possible to make an SSL connection with it. So I guess no one using Lisp is using CL+SSL to make an SSL connection. Frustrating.
Right, but I felt the productivity gains once I got past those problems compared to the ease of getting python running with what I needed (my language of choice at the time) and it's own level of power simply didn't create the right situation to warrant continuing to fight with it after I spent something like 4 evenings just trying to get my environment working how I wanted with ability to download packages I needed via ASDF.
Python is an excellent language in the hands of a competent pythonista: your programming career will thank you if you stuck with one language and learned its ins and outs over 3-4 years.
Libraries are add-ons and most can be ported and rewritten in your favorite language with more natural idioms. SWIG is nowadays the equalizer; it makes the entire C world callable from your favorite pet language. Stuff like LLVM will take you even further, once you know what you're really doing. In the mean time, use foreign functions and web service to bridge the gap where it exists.
My advice to Clojure programmers is to learn Lisp and mine its rich heritage for beautiful designs. A few months spent on a full CMUCL installation will make you a much better programmer for the rest of your lives: I was a Win32/COM guy writing GUIs for a living. When I discovered CMUCL I saw stuff I couldn't imagine. I was able to put buttons in the Unix shell and attach callbacks to all underlined text in an editor buffer. Stuff like that prepared me for DOM scripting with jquery. Look at Smalltalk and SML too.
A personal note to Clojure web framework guys, specially people using Compojure: take a look at Hunchentoot and copy all its good parts. I develop on Hunchentoot and everyday I discover an engineering decision made by its author that just humbles me. Good code makes you respect its author.
I've not looked at it in a long time but Hunchentoot is certainly an excellent piece of engineering, and one of the things I was certainly interested in using at the time I was attempting to get into SBCL development.
I should go back and look at it's code again, and see what new ideas I can get out of it now that I've come back to lisp style syntax, though obviously w/o CLOS and the MoP.
Comments
When was the last time you gave up your Lisp project for the lack of libraries, and what were those libraries?
So a few years back I wrote my M.Sc. thesis as a part of which I implemented an engine for Polish interactive fiction (a.k.a. text adventure) games (which is a very different problem from English interactive fiction because of inflection and the fact that in Polish the order of words in a sentence is not as rigid as in English.) The example game I made using this engine was a remake of the classic "Hobbit." All the code was in Common Lisp and it was a console game at that point but I wanted to add some graphics to make it look more like the original.
I looked into several options, starting from cl-sdl, but (at least at the time) none of them worked on Linux and Windows with the Common Lisp implementation I used (which was clisp.) I don't remember the details but I spent a good week pounding my head against the wall. clisp has a very good ffi mechanism but you can't use ffi to call into SDL because SDL (on some platforms at least) needs to use its own main() function, so once you're running your Lisp code it's too late.
In the end I decided to implement the graphics part in C and just talk to the Common Lisp backend over a pipe. If you speak Polish you can check out the results on http://www.jfedor.org/pfedor/hobbit.html
Note that this method would not have been possible for anything much more complex, like say an arcade game, and also that in other languages it would typically be trivial (say using pygame in Python.)
It was generally library problems, but then I was trying to use sbcl on windows the last time I attempted CL development (this was over a year ago, before I found out about clojure) so even the libraries that DID exist were painful to deal with.
Maybe things have changed but I could not make much headway with ASDF so even when I did find the libraries... yeah. And yes I did have cygwin installed which is why I got past some of the problems.
Maybe I'd have made real headway if I were full on in Linux land where sbcl and everything else has much better support, since it's built around the *nix tool chain.
I develop on Windows and deploy on Unix. Library problems are something we have to face on every platform and programming language, as programmers, but we learn to work around them.
This morning I needed HTML to PDF generation; my first instinct was to use something from Lisp, I found xhtml to pdf generation stuff in CL-TYPESETTING's contrib but it didn't work for me, so I went out and mocked up the application with a web service .. just to find out the remote server shut me down. Next try was to download Perl modules, PDF::FromHTML was broken for me and I didn't know how to fix it (I am not a good perl programmer, btw.) I tend tried the PHP HTML_ToPDF, and it too was too problematic for my tastes. A few hours later, I retooled the app to use a shell pipe:
Ugly but worked.I then played with that for a bit and found it too fickle. Took a second look at the CL-TYPESETTING stuff, my application was now working but still I wasn't confident with it, however, since 7AM this morning, I have had so much exposure to HTML to PDF converters that I knew how they were supposed to function. It took me about 10 minutes to find the problem in the CL-TYPESETTING package (Windows didn't have truetype font it was referencing and the sample usage was buried in a comment at the bottom of the xml-xform.lisp file.)
It would have been very convenient for me to bitch about Perl and its broken PDF::FromHTML module, even though any competent Perl programmer would have told me how to fix it in a jiffy. And the PHP package. It was also convenient to bitch about the web service that blocked me, but I found out they were charging an access fee for the API and I shouldn't have scraped their web page and abused their servers.
Truth is, all languages, tools and platforms suck in small user-dependent ways (they are not DWIM-enabled.) You could waste a life time complaining about them, so the productive thing to do is weigh the language's pros against its cons, and if it's mostly good, then you better learn it well and use it to its full potential.
This is very topical for me. With Lisp, if you have a marginally obscure problem, there is often no answer presumably because no one else has encountered that issue before. With Python, there are 1,000 people who ran into the same thing.
My current problem: Using CL+SSL apparently has a bug which makes it not possible to make an SSL connection with it. So I guess no one using Lisp is using CL+SSL to make an SSL connection. Frustrating.
Right, but I felt the productivity gains once I got past those problems compared to the ease of getting python running with what I needed (my language of choice at the time) and it's own level of power simply didn't create the right situation to warrant continuing to fight with it after I spent something like 4 evenings just trying to get my environment working how I wanted with ability to download packages I needed via ASDF.
Python is an excellent language in the hands of a competent pythonista: your programming career will thank you if you stuck with one language and learned its ins and outs over 3-4 years.
Libraries are add-ons and most can be ported and rewritten in your favorite language with more natural idioms. SWIG is nowadays the equalizer; it makes the entire C world callable from your favorite pet language. Stuff like LLVM will take you even further, once you know what you're really doing. In the mean time, use foreign functions and web service to bridge the gap where it exists.
My advice to Clojure programmers is to learn Lisp and mine its rich heritage for beautiful designs. A few months spent on a full CMUCL installation will make you a much better programmer for the rest of your lives: I was a Win32/COM guy writing GUIs for a living. When I discovered CMUCL I saw stuff I couldn't imagine. I was able to put buttons in the Unix shell and attach callbacks to all underlined text in an editor buffer. Stuff like that prepared me for DOM scripting with jquery. Look at Smalltalk and SML too.
A personal note to Clojure web framework guys, specially people using Compojure: take a look at Hunchentoot and copy all its good parts. I develop on Hunchentoot and everyday I discover an engineering decision made by its author that just humbles me. Good code makes you respect its author.
I've not looked at it in a long time but Hunchentoot is certainly an excellent piece of engineering, and one of the things I was certainly interested in using at the time I was attempting to get into SBCL development.
I should go back and look at it's code again, and see what new ideas I can get out of it now that I've come back to lisp style syntax, though obviously w/o CLOS and the MoP.