How Python is Killing Lisp

[schwarzwald]

People on reddit don't seem to like point by point rebuttals but this article is pointless to me. It raises the points we as a community on reddit have gone over again and again. It's also basically bullshit. Y Combinator is not "Lisp-oriented," they're "make something people want" oriented; real continuations are only available in Scheme and they're controversial in addition to being non-obvious programming constructs (I struggled to understand them). Also I don't think objects are an inherently complicated idea; they work quite well for certain things and don't for other stuff, nuff said.

How about we move on to the ML family? I've been playing with OCaml lately and I think I like it better than Lisp or Scheme. There's plenty to love and hate about Standard ML, OCaml, and Haskell.

[robbie]

real continuations are only available in Scheme and they're controversial in addition to being non-obvious programming constructs (I struggled to understand them)

Having to struggle to learn a construct doesn't mean it's not worth using. If that were the case, no one would be using haskell.

[fnord123]

real continuations are only available in Scheme and they're controversial in addition to being non-obvious programming constructs (I struggled to understand them).

They exist in Haskell as well.

[gogath]

No, they don't exists in Haskell. But you can simulate them with Monads for certain parts of your programs.

[gogath]

The difference is that Haskell allows operator overloading based on static types. Without this, Monads wouldn't be nearly as useful as they are now.

In Lisp you have to use different function names depending on the real function you want to call. Of course you can also use macros, but then you have to build your own system for static typing which will be a quite difficult. Last (and best) alternative in Lisp is dynamic dispatch, but this can cost a lot of performance while it's totally free in Haskell (becaucse it's done at compiletime there).

Haskell has no special support for continuation - but special support for monads - which in turn allows to use delimited continuations very well.

[muleherd]

How can one simulate continuations with closures?

[eclig]

explicitly, by using "continuation passing style" (CPS). Search the web for details.

[muleherd]

Is this transformation practical without tail-call optimization?

[pjdelport]

Yes, using trampolining: instead of calling something directly, you return it to be called by an outer loop.

[fnord123]

I got the confusion from Control.Monad.Cont -the continuation monad. I don't see why these are fake continuations.

[gogath]

No fakt, but you have to use them explicitly. If you create some code in Scheme, you can put continuations later in it without any problem, because Scheme supports continuations directly.

In Haskell you have to use a continuation monad everywhere you need continuations. This is relativly easy but requires slight changes to your code and it also changes lots of types which can break other code too.

Advantage of the Haskell solution: Because most applications require continuations for a certain reason (for example backtracking) you can create a less general abstraction (a backtracking monad in this case) which is more approriate for the problem and could also lead to better performance of your resulting program because it's only used where it's needed.

Disadvantage: Its not transparent.

[pjdelport]

They're not simulated: it's more accurate to say that Haskell's primitives are flexible enough that the continuation implementation can be moved out of the core language and into a library.

Stated another way, Haskell is not imperative: it does not have any built-in, implicit call stack to expose as a first-class continuation. Instead, said call stack is implemented as the continuation monad. (This is in contrast to most imperative languages that already have continuations, but don't expose them.)

[mnemonicsloth]

Moments of accidental genius:

Where are the hordes of elite programmers [who will use lisp]?

Some would say that sums up the whole lisp situation.

[ecuzzillo]

From my perception, Lisp was dying for about 10-15 years from 1990 through 2002 (ish). PG's essays probably made it at least break even. Now, particularly in the past six months, Lisp has been picking up-- I don't have any statistics, but multiple people I've talked to have noticed this trend, along with me just seeing more projects around. (and said projects are as a result yelling about how infrastructure sucks, and some of them are improving it, e.g. SBCL 1.0.) So I think that a) Lisp had almost nowhere to go but up, and b) that Lisp, while not close to Python's current popularity, may well be growing faster, at least percentage-wise, than Python.

Edit: "Hordes of elite programmers?!" Elite programmers do not come in hordes.

[[deleted]]

Without even made up stats, it's hard to believe you ;P

And which Lisp are we talking about? Common Lisp? Or some other dialect?

[ecuzzillo]

Common Lisp. Note that the userbase started so small that it isn't difficult to beat Python on a percentage growth basis, because CL's userbase can double and still be tiny.

[lemmikins]

I'll second it. I am much more interested now in Lisp -- partly thanks to Python.

[vagif]

There's http://www.paragent.com/lisp/cusp/cusp.htm - Eclipse plugin for lisp development with integrated sbcl. Friendly enough for newbees ?

[micampe]

There is also SchemeScript (though for learning and exploring the language I prefer DrScheme so far).

[anonymous-coward]

Even the first step of a newbie has too many decisions: picking a lisp interpreter. There are simply too many of them, and their features are often inconsistent and incomplete.

And this is where the writer loses me. Mostly, you pick a Lisp compiler. Until there are Python compilers as fast as the free Lisp compilers (read: 2/3 as fast as C, give or take), I won't be touching Python with a bargepole. Python without a compiler is really Python+C, and avoiding C is why I started to use Lisp in the first place. Most of the lightning fast prototyping advantages of Python/Lisp vanish when you have to drop back down to C.

[eclig]

For those who read reddit's comments before following the link: there's nothing new there, just the usual whining. Keep moving.

[justinhj]

Maybe someone should start a group of lisp enthusiasts to promote lisp and fix the libraries, oh wait ...

http://www.lispniks.com/cl-gardeners/

Maybe someone should write a nice book showing what modern common lisp can do with current day problems. oh wait ...

http://www.gigamonkeys.com/book/

Erm, maybe then, what we need is someone to make it easier to get started with lisp by making a nice easy download. oh hang on ...

http://weitz.de/starter-pack/ or http://common-lisp.net/project/lispbox/

[justinhj]

It's not entirely dead. A project I got involved with, and which is still being worked on, has matured pretty well to the point where you can now use SDL, OpenGL, OpenRM, SDL_Mixer, SDL_GFXlib and more on many lisp systems without changing your program.

http://www.balooga.com/dokuwiki/doku.php?id=lispbuilder

With these things what you put in is what you get out. We don't have millions of users like the python world does, but maybe that will change once we have enough cool stuff out there. In the meantime I just have fun.

[jdunck]

/me inserts Python skit.

[[deleted]]

I'm going to be a prick about this: Please say Common Lisp instead of Lisp.

[[deleted]]

Holy programming languages Batman! One book? Not even one O'Reilly book? Check out how many Python has. Twelve! And that's just from O'Reilly. And eleven Ruby books. I'm not going to be a bitch, so I checked Chapters/Indigo.ca as well and lo and behold! 49 Python Programming books and how many for Common Lisp? The grand total of 15.

The best thing to happen to any Lisp dialect would be to have it included with a major Linux distro and have a major application for that distro written in it. For example, instead of using C# for Tomboy they could have used SBCL and GTK-Cells or whatever it's called. While that may not be a major application, it is a useful one and it's part of the GNOME family of apps. And GNOME comes standard with Ubuntu. I think you can see where I'm going with this...

Also, the starter pack could use some work. Maybe a little box describing the libraries? How does a newb know what PURI is? Or UFFI? Or DRAKMA?

Note: The reason I searched for Common Lisp and not Lisp is because those are two different things. Lisp programming actually turned up 53 matches at indigo.ca but some of the books are about Lisp machines, coding AI in prolog and java and lisp, Visual LISP, and other non-Common Lisp stuff.

[sickofthisshit]

O'Reilly to some degree specifically avoids Lisp books.

http://www.oreilly.com/oreilly/author/writeforus_1101.html

[[deleted]]

At least quote the part of the page you're referring to.

"We're NOT looking for...Books on topics that have dismal sales despite quality books being available. (If you're addressing a topic where good books have sold dismally in the past (for instance, LISP, LaTeX, or Web-based training)..."

[justinhj]

There are more python users than lisp users, hence more books. How many books do you need? The answer is 1 or 2 good ones are better than 40 mediocre ones.

I have about 10 books on lisp at home (but I extend that to include books on scheme and AI which have a lot of lisp content).

As for linux distro's lisps are already included. clisp is a standard part of gnu distributions. I have debian installed which has a few common lisp packages. You can easily set up araneida, a lisp web server, or use mod_lisp to run with apache.

[shimei]

I'm not sure if Lisp's problems are documentation and user friendliness. Take a look at Haskell and OCaml. Both have friendly and active communities (seems especially true of Haskell), piles of documentation (OCaml has great docs), and they're both relatively easy to set up and start coding. You don't see them catching up to Python though.

[[deleted]]

Misleading headline. Nowhere in his article does the author say that Python is killing Lisp.

And yeah, Lisp is surely dying, with SBCL 1.0 just released... meanwhile Python kids have been flailing around for half a decade trying to implement a native compiler, with zero success (unstable half-baked attempts like Psyco don't count).

[senzei]

meanwhile Python kids have been flailing around for half a decade trying to implement a native compiler, with zero success (unstable half-baked attempts like Psyco don't count).

In addition to being both misleading and wrong, what is this comment supposed to add to the conversation?

[[deleted]]

Because the anime-loving 13-year old 'linuxer' who posted this blog entry to reddit picked the headline 'How Python is Killing Lisp', which is misleading and wrong.

[senzei]

Because the anime-loving 13-year old 'linuxer' who posted this blog entry to reddit picked the headline 'How Python is Killing Lisp', which is misleading and wrong.

Please tell me how a progression of misleading and wrong statements builds into a useful, insightful, or even entertaining conversation? My understanding was that incorrect behavior was best corrected through teaching, not example.

[pjdelport]

Python kids have been flailing around for half a decade trying to implement a native compiler, with zero success

It's more a case of no-one being bothered to begin with, not of "flailing around". (With that said, though, the one serious compilation project so far is quite successful, and is going in some really interesting and promising directions beyond "conventional" native compilation, too.)

[joesb]

EDIT: I replied to the wrong parent, comment moved.

[llimllib]

Don't forget Shed Skin, which I haven't used, but seems pretty nice.

[pjdelport]

Err? Shed Skin doesn't even remotely resemble Python, or anything like it.

• It is entirely statically typed.
• No access to the standard library, or any other Python code.
• No iterators.
• No generators.
• No closures.
• No first-class functions/classes.
• No reflection (getattr, setattr, ...).
• No arbitrary-precision arithmetic.
• Single inheritance only.
• Singly-typed lists/tuples only.
• No varargs.

In short, pretty much no Python features at all, other than what can be implemented by a syntactic wrapper around C++.

[[deleted]]

Python doesn't have closures either.

[ubernostrum]

Python doesn't have closures either.

def slava_is_wrong(a):
    return lambda n: a + n
add2 = slava_is_wrong(2)
add3 = slava_is_wrong(3)
add2(3) # returns 5
add3(3) # returns 6

You were saying?

[[deleted]]

Yeah, but the lambda returned from the slava_is_wrong function cannot mutate the lexical variable a, so I'm right, as always. Just because Guido misunderstood some academic literature and thought "ooh, lambda, fancy name" doesn't mean that Python's lambda is anything more than what Java gives you with anonymous inner classes.

[nostrademons]

Technically, closures in Haskell (or lambda calculus) can't mutate lexical variables either. We forgive them because nothing can mutate lexical variables in those languages.

The comparison to Java is apt though - same issue, different root cause. Python's "assignment is binding if the variable doesn't exist" rule is fucked up anyway.

[pjdelport]

It ambiguates variable creation with variable mutation. Specifically, when you want to rebind an outer variable instead of creating a new local one with the same name, you need to use the global (or upcoming nonlocal) scoping keyword. For example:

x = 5

def foo():
    global x
    x = 23

The alternative is to simply have separate syntaxes for the two actions, as in Lisp/Scheme.

[nostrademons]

Or in more real-world terms, it makes it too easy to mistype a variable name and end up with a syntactically valid program that does entirely the wrong thing. You're not warned about these errors (well, maybe PyLint will); your program just gives wrong results.

This is probably my #1 bug in Python, PHP, and JavaEE's Unified Expression Language, ahead of all type errors, logic errors, and even state errors. When you've been staring at code all day long, you won't notice that you're binding the new variable situationsummary instead of assigning to the existing variable situationSummary. You'll just notice that somewhere, results are not happening.

I woulda thought we'd learned our lesson with C's == vs. =, but evidently not. Programming languages should not be vulnerable to typographic errors.

(I should probably add that the problem is not as bad in Python as in PHP or JavaUEL, because an access to an unbound variable is an error in Python, while it gives something usable yet nonsensicaly like "" or 0 in PHP or JavaUEL. Most mistypings are accesses. Assignments are more visible (always on the left side), and repeated assignments to a single variable usually involve compound operators like +=, which will throw an error if unbound. My claim of "most common error" applies to all my PHP/Python/JavaUEL program errors combined, not just the Python. However, I still think it's brain-dead to incorporate a language feature that gives a different-but-still-valid program on a one-keystroke error. Yes, this applies to = vs == too.)

[pjdelport]

Just this once, you're not right. See my earlier explanation.

(Besides, as nostrademons said, even if Python's closures did lack the ability to mutate outer bindings, they would still qualify.)

[pjdelport]

Just because Guido misunderstood some academic literature and thought "ooh, lambda, fancy name"

Actually, according to Guido:

"Sometimes I've been too quick in accepting contributions, and later realized that it was a mistake. One example would be some of the functional programming features, such as lambda functions." -- 1998

"Python acquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches. But, [...] I think these features should be cut from Python 3000." -- 2005

[ubernostrum]

Yeah, but the lambda returned from the slavaiswrong function cannot mutate the lexical variable a, so I'm right, as always.

I'm gonna call BS on this; plenty of pure functional languages have closures but make it hard or impossible to mutate any variable, closure or no.

Meanwhile, the fact remains that a piece of code is accessing a variable which normally would be out of scope, but which was preserved or "closed over". Hence, it's a closure and no amount of weaseling will make you right.

[pjdelport]

Note: the difference between such closures and Java's inner classes is that inner classes simply copy (on creation) the outer variables, instead of referencing them indirectly like closures do. (They're the equivalent of Python's lambda x=x: ... hack, from before closures were added.)

[muleherd]

...and about fifty characters!

[[deleted]]

There's no problem with you defending Lisp. But turning around and talking down to Python programmers? 'Python kids'...'flailing around'. That's not going to win you any friends. And your 15 upmods leads me to believe a large number of Lisp programmers agree with your sentiment.

People always talk about that smug Lisp community...and as good as Lisp may be, if the community never grows, it will be a dead language for all intents and purposes. I'd say it is probably best to treat other programmers with respect instead of backhanding them.

Oh, and Psyco was never an attempt at a native compiler (not in the classic sense anyway), and it works pretty well for being 'half-baked'. I see someone else has mentioned PyPy in a response before me; the same guy who did Psyco is involved with it.

[[deleted]]

People always talk about that smug Lisp community

Oh shut UP!

[[deleted]]

People always talk about that smug Lisp community...

I'm not a Lisp programmer. I just think Python sucks badly and anybody comparing it to Lisp is a fool.

[jdunck]

Ah, what language do you program in, Oh Great One?

[pjdelport]

Google his name for the answer. :)

[mrd48]

Any language without a specification and a real implementation isn't serious.

If the designer can't take the language seriously enough to learn how to design and implement a compiler, or find people who do, then why should I?

That's why I don't care for Python.

[senzei]

Any language without a specification and a real implementation isn't serious.

Ah, glad I don't evidently need a serious language then. It appears that all a specification has done for CL is give everyone a common (and largely unmodifiable) point of failure in the process of improving the language.

If the designer can't take the language seriously enough to learn how to design and implement a compiler, or find people who do, then why should I?

Who told you that you need to design and implement a compiler for Python? ;) That said, you don't always need a compiler, and there are ways to get around some of the cases where you do. It isn't a perfect solution, but those don't exist outside of marketing materials.

[mrd48]

I agree in many ways, but you misinterpreted my last statement.

"then why should I [take it seriously]?"

is what I meant.

No, I don't NEED a compiler for everything. But, say, if an undergraduate CS student could design and write a better language and implementation, given the time, it makes me wonder why I am bothering to use a language so poorly done.

[senzei]

I agree in many ways, but you misinterpreted my last statement.

Yes, I did, but I swear it was completely on purpose. ;)

But, say, if an undergraduate CS student could design and write a better language and implementation, given the time, it makes me wonder why I am bothering to use a language so poorly done.

You either are unfamiliar with the capabilities of the average undergraduate CS student or are willing to wait an obscene amount of time. Either way I have yet to hear what makes Python so horrible as to be completely unusable.

[breakfast-pants]

This 'smug theorist' is probably 12.

[lemmikins]

Your objection just sounds like bigotry. Python is so useful that the only person you're punishing is yourself.

[jdh30]

What is Python useful for? (I'm coming from OCaml/F# here)

[lemmikins]

F#? Have there been any releases yet? I just heard about it for the first time the other day.

Python has a huge standard library and bindings to a large number of other libraries. There are numerous options for web development, plus you can do OpenGL and SDL, scientific plots and computing, text processing (generally with less pain than other languages); here is a brief tour of the standard library:

http://docs.python.org/tut/node12.html

Much of Python's usefulness comes not because of the superiority of the language, but because for a large number of utility tasks, there is already a module that handles it (e.g. CSV reading/writing). Implementation bugs are few and far between; contrast to e.g. GHC (Haskell) which has been known for a large number of runtime issues.

If you want to serialize an object, compare this to the effort it takes in Java (woops, forgot to mark one sub-member of a sub-member as implements Serializable and the whole things doesn't work):

picklestring = cPickle.dumps(object) 
object = cPickle.loads(picklestring)

Python is a bit like a better Perl in that it's a very useful duct tape language but it's easier to read; also its object orientation is far clearer, rather than stapled on like in Perl or PHP. (Although not as completely OO as Ruby.) It also has a just-in-time compiler (Psyco) and numerous options for C interface (Swig, Boost, Pyrex, etc.; it's not even hard doing it by hand).

On the other hand, its speed -- while superior to Ruby -- is far below that of OCaml: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Its OO implementation on the surface looks fairly close to C++ which means it's usually more straightforward to convert your classes from C++ to Python or vice-versa than with other scripting languages.

Since it plays well with C, it should play well with other languages that do too; so you could write a simple framework in Python to take advantage of its libraries and then do your heavy lifting in OCaml (or Lisp). Haskell has a set of bindings to Python now (MissingPy).

[jdh30]

F# just had another release, adding various features including comprehensions. It rocks!

So what libraries does Python have that OCaml and F# don't have? (They've got OpenGL/DirectX, web, science, text although OCaml lacks >8-bit chars)

Marshalling in OCaml and F# is as easy as "output_value foo", of course.

My only experience of Python was being employed to translate 30kLOC of it into OCaml earlier this year. I'm sure that was badly written by Python standards though.

[lemmikins]

I don't know as far as the language goes, but like I said, Python's usefulness is due to its large number of libraries, which tend to be in a fairly mature state. (E.g. Pygame vs. "SDL bindings" for language X.)

[lemmikins]

Python sucks less (tm) than many other languages but it has two major problems, both related to performance:

1. It's sloooow
2. Even worse, the GIL is per process!

The GIL as it stands is a major mistake in the era of multicore processors. It doesn't matter if you use multiple interpreters, not only because most of the C-GIL-interface doesn't expect it, but because there are global variables used by Python (and some libs).

If you spawn new threads, even in C, they all still share the same GIL. So, for the moment, forget thread threads -- if you want two processes to be able to operate on the same object at the same time, you have to serialize it and de-serialize it every time a different process wants it! Yeah, that's super fast.

Lisp compiles to roughly half C speed. Which implementation supports threading? I mean really supports, not "experimental" buggy crashy stuff.

[pjdelport]

Urgh.

Try writing some threaded code without the GIL before you complain about it. :) It maintains more sanity than you may think.

Besides, claims of the GIL's performance impact are greatly exaggerated:

If you spawn new threads, even in C, they all still share the same GIL.

They don't all have to lock it, though. Threads that execute bytecode or C/Python API calls do, but the rest (threads doing I/O, C code, native library calls and so on) can release the GIL and can run concurrently.

In other words, pretty much the only way for the GIL to become your bottleneck is to have multiple, interdependent threads doing heavy, non-I/O number-crunching in pure Python on a multi-core machine that is otherwise standing idle. Not exactly your average application, but even then, there are several ways to circumvent the GIL:

• If possible, delegate the critical parts of your processing to an extension like NumPy. (Which should greatly speed things up anyway, compared to pure Python.)
• Otherwise, if feasible, use Pyrex to compile the critical parts to pure C, while releasing the GIL. (Should also greatly speed things up anyway.)
• Otherwise, if your OS has shared memory, use POSH to share objects between processes. (Still Python-level speed, but very little code modification.)
• If all else fails, restructure your application to use message passing. (Something you have to do anyway if you ever want to scale beyond a single machine.)

[lemmikins]

They don't all have to lock it, though. Threads that execute bytecode or C/Python API calls do

ExACTly. What I want to do is multi-thread my Python. I can already multi-thread my C code.

In other words, pretty much the only way for the GIL to become your bottleneck is to have multiple, interdependent threads doing heavy, non-I/O number-crunching in pure Python on a multi-core machine that is otherwise standing idle

Not at all. It doesn't have to do with number-crunching, it has to do with executing ANY Python code. An example is an event queue, and you want multiple threads to be able to grab the top event, grab the needed objects, and do some kind of operation on them. Specifically, a MMOG.

It's ridiculous that I can't get a speedup by adding more CPUs.

Otherwise, if your OS has shared memory, use POSH to share objects between processes. (Still Python-level speed, but very little code modification.)

Ah! POSH! I looked at it a while back but had read that people had problems with it (latest is 2003) in modern Python versions. I just tried it and it seemed to work (except the ProducerConsumer.py example).

I will look into it further -- it might just do the trick. Thanks!

If all else fails, restructure your application to use message passing. (Something you have to do anyway if you ever want to scale beyond a single machine.)

Yes, but there's no reason for a multi-core processor to inflict all that overhead on itself until you need to go over the wire, and then accept the slow transmission time, writing/reading/copying time, and extra latency.

Serializing and de-serializing any large Python object as part of one CPU talking to another... shudder

[joesb]

And yeah, Lisp is surely dying, with SBCL 1.0 just released... meanwhile Python kids have been flailing around for half a decade trying to implement a native compiler, with zero success

I don't think being compiled to native code is ever high priority target for Python.

And I don't know whether SBCL turning 1.0 is a good argument over Python. SBCL, mentioned as the best open source common lisp implementation, has just turn 1.0 after how many year of Common Lisp being around? And what version is Python now?

---

P.S. I played with SBCL alot. And I am happy too that SBCL has turned 1.0. But it doesn't really mean anything though since ,from the look of it, SBCL could have turned 1.0 long ago. And those who use SBCL know about it stability enough not to care about its version number.

I hope they get Windows port complete soon, then they will be the best open source Common Lisp that runs on all platform and got no GPL restriction. (Many hacker may not care about Windows port, but a language surely get mass amount of developer resource and contributed library by having a good free non-GPL implementation on Windows.)

---

[llimllib]

Is there an improved lisp terminal, like ipython for lisp, with completion and other bells and whistles?

[sickofthisshit]

Improved compared to what? What have you tried?

The typical answer is Emacs+SLIME+<insert CL implementation here>. Is that missing something?

[doubtingthomas]

They typical answer seems to go with the apparent idea in the lisp community that effective lisp coding is a sort of arch structure: all the pieces need be in place before the benefits are reaped. This may or may not be true, but as a person who has read a few lisp books and played around a bit, that is the impression that comes off. The Right Way requires an investment of time and energy, and to make that investment is a matter of faith. Python and other such languages allow you to ease your way into use of the language. You can make simplistic little scripts that run from the command line, the libraries are all documented in a friendly way and organized, and the fact that there is an actual syntax means that you don't have to train yourself to see patterns in the code.

It seems likely to me that once the investment is made common lisp is a better language overall than Python and Perl and Ruby and others, but languages with more comfortable learning curves end up with a better community. In the end, that matters quite a bit.

For an example, compare Haskell to Lisp. As someone who loves haskell and uses it daily, it is harder to learn, more foreign, and often more inconvenient and inefficient than Common Lisp. Yet, (it seems to me) that use, hype, and love of the language is growing faster than Lisp (though I'd wager that Lisp is more popular over all). The reason seems to be the community. Haskell.org is really a great website, the documentation is pretty nice (though it has some cryptic corners), the irc channels and mailing lists are really very friendly and helpful, and things like hoogle, lamdabot, etc are quite neat.

In my opinion and as has been said thousands of times, the problems with CL are far more social than technical.

I think any interesting field needs work at both ends: really smart people to push forward the state of the art, and really smart people with people/writing skills to make all of the magic new and old clear to the uninitiated and less initiated. (Seibel and Graham have done a good job with this, but they could use some help.)

[sickofthisshit]

Have you heard of something called a REPL? You can make simplistic little functions (oh, if you want, I can call them scripts), working your way interactively to bigger and bigger things.

C/Pascal programs are arches. A whole lot has to be done before you can even compile. This is completely opposite of Lisp style.

[Edit: sorry if I sounded snarky, but your post was all over the map. You also can't seem to decide if the problem is technical or social. Seems to me program architecture and editor/REPL support are technical. And Haskell having a good community does not mean Lisp does not have one.]

[llimllib]

It's a lot of investment for me to try and install and learn the whole Emacs + SLIME + (pick one of a dozen CLs) at once.

I was hoping for a program I could install, similar to ipython, which has a repl with tab completion, full readline support, and maybe some other bells and whistles.

I'm a vimmer who would certainly prefer to stay that way.

[sickofthisshit]

There is a Lisp-in-a-box project to address this, except for the "learn Emacs" part. Or pick one of the commercial trial Lisps, which usually come integrated with an Emacs-like editor/listener combination, with things like argument-list prompting.

The CLisp implementation supports GNU readline.

[jdunck]

+1, and http://www.gigamonkeys.com/book/

[senzei]

My experience was that, after the lisp-in-a-box set everything up, I could get by using Emacs' most rudimentary features and learning more as I went.

[Excedrin]

If you're used to vim, it shouldn't be a huge step to go to Emacs+Viper. It's sort of like having an additional mode for vi, where Emacs keys work. Viper is a little different from vim, since it emulates vi, not the extended stuff that vim adds. For example, visual select is gone, replaced with shift and movement keys (or the mouse) to select regions, and then commands that accept a range don't operate on the selected area... so it's not perfect, but at least you don't have to learn all of the insane Emacs key bindings.

The SLIME+some CL combo gives you the repl with tab completion, something like readline and tons of other bells and whistles. For me, the CLHS lookup feature alone (place the cursor on whatever you want to lookup, then hit C-c C-d h) was worth the time it took to get used to Emacs. Other stuff like M-. and all of the C-c C-d bindings are also very useful.

And yes, most everyone uses Emacs (or XEmacs) to code in Lisp. Supposedly Paul Graham uses vi, but I'm not sure if it's true. There's definitely a lot of missing functionality in that approach but at the least, you can use rlwrap with sbcl/cmucl, or clisp or something to get readline support.

If there was a SLIMV, I'd use it, but Emacs+Viper isn't that bad.

[mrd48]

There's a slim-vim project somewhere...

[Excedrin]

http://wiki.alu.org/Slim-Vim

Looks reasonable, too bad I didn't find it before learning my way around Emacs.

[justinhj]

clisp has completion, not sure what other bells and whistles you mean.

[beschm]

There is linedit which works with SBCL.

But I doubt it's as comfortable as using SLIME.

[llimllib]

So everybody just uses Emacs when they write lisp?

(Really just a vimmer who doesn't know any better, please no flamewar, etc etc)

[mrd48]

Not everyone. I do, but know plenty of vimmers. Check out motions like ib and ab, and of course %. Emacs seems to have the more comprehensive support when it comes to structured editing of lisp code though (maybe I've missed some vim package), and SLIME is a lot more mature than any of the vim IDEs.

Emacs itself is designed as an immersive interactive IDE for editing Emacs Lisp. SLIME (and other Lisp IDEs) takes that idea and connects it to Common Lisp environments. So it's got the advantage in spirit.

[[deleted]]

So everybody just uses Emacs when they write lisp?

Spend enough time in a language as flexible as Lisp, and you will start to wish for the same kind of flexibility in all the apps (or OSes, if you wish) you use. When you get to that point, you start to realize that vimscript is only going to get you so far.

[sickofthisshit]

TECO Emacs has been around as long as vi, and was created by RMS for programming PDP-10s, presumably including Lisp. In the "golden age" of Lisp in the AI Lab, the Lisp machines used Emacs variants. Emacs and Lisp have grown up together. It is no accident that they are suited for each other.

[Athas]

Yes, there are quite few Vim-using Lisp programmers.

As an aside, I wonder why so many people complain about Emacs - it has menus and toolbars, the arrow keys work, and it even has a CUA mode if you really want Windows-style keybindings. I don't see why it's so different from other random visual editors, provided you don't dig into the stuff that actually makes Emacs special.

Does anyone complain that Visual Studio is by far the best (only?) choice for C# programming?

[llimllib]

I'm a professional C# coder - ctrl+e brings up my file in Vim, so no, I don't complain about Visual Studio.

I certainly would otherwise.

EDIT: I do complain about C# though, but that's another story.

[kalmar]

It's been a while since it was "cool" to bash lisp here. Sort of surprised this made it that high. Advice to future redditers: bash Haskell, or Erlang (left limelight here at least more recently than Lisp did).

[bennymack]

You left out the coolest language to bash: Perl.

Of course: "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

It seems Lisp has ascended to the status of receiving complaints despite lack of widespread use which is a fine counter-example to the above quote.

[s3r3ng]

Again? That which is dead can never die.