HN Explorer

Sorry, Lisp. I tried. (ketralnis.com)

10 points by portLAN ↗ HN
"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."

I'm embedding it so it's going to talk to my C wrapper for everything. How are you using it?

Also see: Using Python libraries from Lisp http://common-lisp.net/project/python-on-lisp/

12 comments

[ 408 ms ] story [ 1290 ms ] thread
portLAN
> "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."

I'm embedding it so it's going to talk to my C wrapper for everything. How are you using it?

Also see: Using Python libraries from Lisp http://common-lisp.net/project/python-on-lisp/

From Reddit a comment: "cliki.net/asdf-install and sbcl would have got him just about all he asked. SBCL does posix and threading, cl-sql, cffi for db and ffi, and I am pretty sure sbcl does sockets too."

palish
This is why Arc (or Otter or whatever else) is a great idea. If the implementors can create a system similar to RubyGems where people can write drop-in plugins for things like MySQL access and whatever else then Lisp could become hugely popular.
jamesbritt
How does the PLaneT plugin system for PLT Scheme seem to you?
palish
Sorry, I haven't much looked into Lisp past my first month foray into it, and that was just CL. Between my day job and our startup, simply no time left.

I promise to check it out someday though! Plugin systems are the most important parts of platforms.

jsjenkins168
My experiences with Lisp are similar. Given an infinite amount of time, I would love to write everything I needed in Lisp and have a blast doing it.

But in reality everything is a matter of time, and to build fast and achieve realistic goals I need to build off of established tools as much as possible. But maybe this can change with a wider adoption of better Lisp libraries?

simpleenigma
Several years ago I decided that I wanted to find a language that was more powerful and elegant then anything I had worked with before. Having read much about the benefits of Lisp from Paul Graham, I obviously wanted to give it a try.

I personally found it more difficult to use and the lack of standardization and libraries made it unusable for me. I gave it several weeks and tried to solve the problems I was having using it, but I finally started looking for something that had the power of Lisp, but better libraries.

I ended up using Erlang (http://erlang.org) and I've never been happier. Lisp was part of the inspiration for the language, but the libraries that Erlang has built in was the real selling point for me. In fact I'm still finding gems of undocumented functions in the source code that take days off of my programming time and I've been programming in it for more then two years now.

So if Lisp isn't want you want, give Erlang a try ...

dpapathanasiou
So if Lisp isn't want you want, give Erlang a try ...

I agree, Erlang has some great ideas, especially with respect to messaging and parallel processes.

I'm still more comfortable with CL (by dint of experience), but Armstrong's book (http://www.amazon.com/Programming-Erlang-Software-Concurrent...) has been a great read so far.

simpleenigma
Armstrong's book is the single best source for documentation about Erlang I have found so far. I consider it a must read for anyone who is going to be looking into using Erlang. I had a beta copy of it about two months before it was published and it helped me tremendously by simplifying some of the design patterns I had constructed myself.

Also, if I had to complain about Erlang at all the documentation is the one thing I would complain about. I find so many useful features by reading the source code (which also makes my own code better by reading other peoples code) that are not documented that I often wonder who is choosing what to document and what not to.

For instance, the to_lower() function to make a string lower case is in the http_util module, instead of the string module. Took me six months to find it and I had written my own in the mean time, theirs is much more efficient, but all but undocumented.

ketralnis
(I'm the author.) Yes, Erlang is where I've gone. I'm still learning, but it hasn't taken long to get me up-and-running more than proficiently, and I'm loving it so far
Zak
Common Lisp was designed by committee, and it shows. If Lisp is to become popular, it needs a good, opinionated dialect or three. Arc will probably be one of them. Otter may be another. It would certainly be nice if there were more libraries, but most of the things the author complains about seem to be non-problems:

>database access

Is there a problem with clsql (http://clsql.b9.com/)?

>sockets

Most Lisps (all modern ones?) support sockets. There are libraries to provide a common interface - a quick Google search got me usocket (http://www.cliki.net/usocket)

>threads

Ok, your options are a little more limited here, but CMUCL and SBCL support threads on x86 Linux, as do Lispworks and Allegro if you want to spend money. I suspect this isn't a big problem for most people writing web apps.

>POSIX

I think this is a weak point - CL was developed at a time when there was no clear OS of the future, so it was intended to be OS-agnostic. Today's (and probably tomorrow's) world has Windows, Unix and not much else.

>a portable FFI

CFFI and UFFI both work on all the popular Lisps. What's the problem?

ketralnis
EDIT: Sorry, I misread your comment, and mine agrees with yours rather than argues with it. But I'll leave it here for posterity :)

>> POSIX >I think this is a weak point - CL [...] was intended to be OS-agnostic

I don't think it's a weak point. It's OS-agnostic, which doesn't meet my needs because I need to use operating system features. Just because it wasn't built to meet my needs doesn't mean that it does.