Re:Sorry, Lisp. I tried.
by Zak on Monday December 03, 2007 @12:01PM
(#85642)
Without database access, sockets, threads, POSIX, or a portable FFI (which I could at least use to write many of those features), my programs can't talk to the outside world, and that makes them basically useless.
Is this a troll, or did the author simply not do very much research?
CLSQL can talk to MySQL, PostgreSQL, SQLite, Oracle and (through ODBC) MS SQL. What database does dking want to access?
I'm pretty sure all the major Lisps provide a socket interface. Usocket standardizes it.
I think the commercial Lisps provide threads. SBCL and CMUCL have threads on certain platforms, especially x86 Linux.
POSIX is available through the FFI, but some Lisps provide their own POSIX package. I think there's some work being done on a more portable library.
CFFI and UFFI are both good FFIs portable between all the major Lisps.
Everything the author asks for is easy to find. Many of these libraries are the first hit for a reasonable google search (e.g. "lisp sql"). I've had issues finding good Lisp libraries on occasion, but the situation is much better than the author suggests.
Re:Sorry, Lisp. I tried.
by ketralnis on Monday December 03, 2007 @02:29PM
(#85674)
> Is this a troll, or did the author simply not do very much research?
It's not a troll, and I did do some research. I wrote this a few months ago (this is its second round on news.yc, and I'd make some addenda to it if it weren't actively linked to at the moment). My biggest problem was that I was insisting on portability across implementations, because that's something that I got for free in languages like Ruby that I didn't want to give up. Reading around, it looks like most Lisp users didn't have such a requirement, and mine was largely engineered because of bias given to me by the implementations of the other languages I was using.
When it comes down to it, I needed an implementation with those things that would work with FreeBSD, OS X, and Linux, and maybe sometimes Windows, and support threads, WebDAV, and some other stuff. While I still can't find a WebDAV client library, it looks like my requirements for portability across implementations may have been unfounded.
Since then I've gotten into Erlang, but if I were to try Lisp again it would probably be a Scheme after reading around.
Re:Sorry, Lisp. I tried.
by Zak on Monday December 03, 2007 @02:49PM
(#85680)
Portability between implementations is a bit of a red herring (as you seem to have discovered); most libraries you'd actually want to use run on most implementations you'd actually want to use. Ruby and Python don't give you this either, but they do give you a standard implementation. I suspect a lot of Ruby code you might want to run doesn't work with JRuby or IronRuby.
Portability between operating systems is a more serious problem. I think ECL is the only free implementation that does this well, and most libraries don't seem to be tested on it.
Re:Sorry, Lisp. I tried.
by mrtron on Monday December 03, 2007 @04:25PM
(#85704)
>When it comes down to it, I needed an implementation with those things that would work with FreeBSD, OS X, and Linux, and maybe sometimes Windows, and support threads, WebDAV, and some other stuff. While I still can't find a WebDAV client library, it looks like my requirements for portability across implementations may have been unfounded.
That kind of support is basically only provided by the JVM...unless I am mistaken.
Re:Sorry, Lisp. I tried.
by tlrobinson on Monday December 03, 2007 @05:29PM
(#85720)
The problem is, yes, there are libraries available for these things, but as far as I can tell they're not usually included or standardized. When I fire up Ruby or Python or whatever I know that most of the things I need are already there, and I don't usually have to go hunting down libraries all over the net.
There are just too many options for dialects, libraries, etc. I want one standard Lisp that has all the "expected" things built in so I can focus on programming.
Re:Sorry, Lisp. I tried.
by vikram on Tuesday December 04, 2007 @06:44AM
(#85901)
I had similar issues. But I find that the simplest way to get around them is to use VMWare or Parallels, depending on what your emacs is running on. Run Lisp inside the OS of your choice and connect to it using Slime.
If you don't use Slime+Emacs+Tramp, I don't think it's worth getting into CL at all. Slime absolutely rocks my world. I have 8 SBCL instances running on multiple machines (virtual and dedicated) on my network and the internet, and I don't have problems doing any lisp development.
My advice would be to pick the OS/Lisp implementation based on what you think you might need.
Re:Sorry, Lisp. I tried.
by vikram on Tuesday December 04, 2007 @06:17PM
(#86146)
2 actually, running behind pound. I had a few more running on a couple of virtual slices on slicehost. But I recently got rid of them as SBCL has some issues with Xen.
About SQL, for example, I'm using Submarine (ORM) with Postmodern and it's running like a charm. For Web development, there are Hunchentoot, AllegroServe and interesting frameworks like UCW or Weblocks (each one I'm using right now).
Maybe the guy didn't tried enough, more 5 min. at google would be enough ;-)
Re:Sorry, Lisp. I tried.
by henning on Monday December 03, 2007 @01:37PM
(#85662)
Lush is great for numerical prototyping, much better than MATLAB/Octave. Its matrix/tensor engine is one of the most awesome (as in being in awe) pieces of software I've ever come across. It is definitely mature and well-tested in that niche. It was created by leading neural network researchers.
Re:Sorry, Lisp. I tried.
by viergroupie on Tuesday December 04, 2007 @04:11AM
(#85876)
I don't quite get the faith Lush seems to inspire in some of its users. It's terribly documented, has antiquated semantics (no closures), and isn't even type safe (you can segfault if you pass an object of the wrong type). I might consider using Lush when performance was absolutely critical, but otherwise I don't think it holds a candle to Matlab for prototyping.
Re:Sorry, Lisp. I tried.
by jey on Monday December 03, 2007 @02:47PM
(#85678)
Why? So you have access to the Python libraries from Lisp? That would probably be better accomplished by writing a layer that used the Python/C API to fbnd the functions into Lisp, rather than compiling the whole program to run on the (slow) python interpreter.
Re:Sorry, Lisp. I tried.
by hhm on Tuesday December 04, 2007 @10:32PM
(#86200)
No, I just was thinking in some Lisp implementation that didn't require to install the JVM, but that could use the bytecode of a lighter language, like Python. Also because I suppose if a Lisp implementation is generating code for a specific platform, its documentation will refer to such platform, and I'd prefer to read about Python bytecode than about JVM.
But maybe I'm wrong and it's just useless prejudice of my part.
Re:Sorry, Lisp. I tried.
by dpapathanasiou on Monday December 03, 2007 @10:07AM
(#85608)
I was thinking the same thing -- there's also a Lisp for the JVM called Clojure (http://clojure.sourceforge.net/) which he might have found interesting.
Re:Sorry, Lisp. I tried.
by ketralnis on Monday December 03, 2007 @02:09PM
(#85668)
I've been looking at that one, as well as Armed Bear Common Lisp. Shortly after writing that article I started reading up a lot on Erlang which I've come to like and now have some projects in it (notably wrotit.com, where the submitter probably found this article, since that's the domain on which this was submitted to reddit a few hours ago). I didn't discover ABCL or Closure until after I started using Erlang, so both are a bit of a back-burner educational thing at this point.
Re:Sorry, Lisp. I tried.
by henning on Monday December 03, 2007 @03:24PM
(#85688)
Lisp the Platonic ideal is powerful and important. Particular dialects like Common Lisp and particular implementations are akward because the ANSI standard is intentionally silent about common network, I/O, etc. stuff.
Re:Sorry, Lisp. I tried.
by ketralnis on Monday December 03, 2007 @02:10PM
(#85669)
Submitter: thanks for submitting the (original) ketralnis.com article. The same article was submitted under my experimental domain wrotit.com to reddit, and I'd much prefer to reduce the incoming links to that domain until I've made final decisions about the link and URL structure over there :)
Is this a troll, or did the author simply not do very much research?
CLSQL can talk to MySQL, PostgreSQL, SQLite, Oracle and (through ODBC) MS SQL. What database does dking want to access?
I'm pretty sure all the major Lisps provide a socket interface. Usocket standardizes it.
I think the commercial Lisps provide threads. SBCL and CMUCL have threads on certain platforms, especially x86 Linux.
POSIX is available through the FFI, but some Lisps provide their own POSIX package. I think there's some work being done on a more portable library.
CFFI and UFFI are both good FFIs portable between all the major Lisps.
Everything the author asks for is easy to find. Many of these libraries are the first hit for a reasonable google search (e.g. "lisp sql"). I've had issues finding good Lisp libraries on occasion, but the situation is much better than the author suggests.
It's not a troll, and I did do some research. I wrote this a few months ago (this is its second round on news.yc, and I'd make some addenda to it if it weren't actively linked to at the moment). My biggest problem was that I was insisting on portability across implementations, because that's something that I got for free in languages like Ruby that I didn't want to give up. Reading around, it looks like most Lisp users didn't have such a requirement, and mine was largely engineered because of bias given to me by the implementations of the other languages I was using.
When it comes down to it, I needed an implementation with those things that would work with FreeBSD, OS X, and Linux, and maybe sometimes Windows, and support threads, WebDAV, and some other stuff. While I still can't find a WebDAV client library, it looks like my requirements for portability across implementations may have been unfounded.
Since then I've gotten into Erlang, but if I were to try Lisp again it would probably be a Scheme after reading around.
Portability between operating systems is a more serious problem. I think ECL is the only free implementation that does this well, and most libraries don't seem to be tested on it.
Not likely. Rails runs fine on jruby at least, and it does every dirty trick under the sun.
That kind of support is basically only provided by the JVM...unless I am mistaken.
If you want support on another OS platform, run linux in a virtual machine of some sort.
There are just too many options for dialects, libraries, etc. I want one standard Lisp that has all the "expected" things built in so I can focus on programming.
If you don't use Slime+Emacs+Tramp, I don't think it's worth getting into CL at all. Slime absolutely rocks my world. I have 8 SBCL instances running on multiple machines (virtual and dedicated) on my network and the internet, and I don't have problems doing any lisp development.
My advice would be to pick the OS/Lisp implementation based on what you think you might need.
About SQL, for example, I'm using Submarine (ORM) with Postmodern and it's running like a charm. For Web development, there are Hunchentoot, AllegroServe and interesting frameworks like UCW or Weblocks (each one I'm using right now).
Maybe the guy didn't tried enough, more 5 min. at google would be enough ;-)
Rather than a Lisp that runs on the JVM, I'd be very interested in knowing a Lisp that somehow runs as Python bytecode. Does such a monster exist?
Outside of its niche, it's pretty useless.
But maybe I'm wrong and it's just useless prejudice of my part.
Old news.