How Python is killing Lisp

http://ynniv.com/blog/2006/11/how-python-is-killing-lisp.html

by pmiller2 • 17 years ago

33 66 17 years ago

Scriptor2• 17 years ago

Personally, it's the double learning curve of having to learn Lisp and Emacs. I understand the basic concepts of Lisp now, but could someone point me to a good introduction to learning Emacs, Slime, and Lisp all at once? Does Practical Common Lisp do that as well?

bugs• 17 years ago

There are certain things that usually just come with practice, emacs and slime usually seem to fit in that category. Once you have gone through the tutorial most of the time you just look up things or figure them out until you remember what to do in a specific situation.

There probably are some screencasts for introduction to emacs, slime might have some available as well.

enum• 17 years ago

You don't have to learn Emacs. Also, Common Lisp isn't the only option. Try Scheme, this one: www.drscheme.org.

Scriptor2• 17 years ago

The thing with Emacs is that I feel like I am missing out on the full potential of developing in CL if I'm not using it. How true is that?

Locke16893• 17 years ago

http://www.plt-scheme.org/ is the new website.

I feel its wrong for me to push this without at least mentioning that one of my professors wrote Dr. Scheme :-/

alecco6• 17 years ago

But ECMAScript is killing Python. The writing is on the wall.

alecco6• 17 years ago

Hello, (former) fellow python fans. ECMAScript, formerly known as JavaScript, is doing very well. So well Python developers started to show their concern for about 2 years. You could read it on PyPy blog and Python mailing lists.

The new ECMAScript VMs are getting faster and already beating Python's. And they are getting faster with plenty of room to improve. The language is cleaning up, with a major milestone reached a few days ago. They have the biggest installed base in the world and there are more developers. The language fits in precisely the same slot as Python.

The writing is on the wall. Down-voting what you don't like doesn't make it go away and it should be very un-HN.

EDIT: Read again the name of the story title if you think my post was flame-bait.

viraptor5• 17 years ago

Well - this comment is quite interesting. The parent one looks like a one-line "meh" comment. I'm quite happy to downvote the original and upvote this one...

But is it really killing python? The language is basically the same (almost-dictionary based, easily extensible types / prototypes, etc.). There's a big difference though: afaik there's no real library for ecmascript that would integrate it with the os. There's simply no way to use ecmascript standalone on a typical system. ecmascript is good in places where you need an embedded scripting language, but lua is not enough. Unfortunately neither of them is useful as a general-purpose language right now. Once someone produces a serious repl-like environment and a set of sys / os / file libraries - it can compete with python.

mcav2• 17 years ago

If Javascript obtains a standard library as comprehensive as Python's, then yes, Python would be in a tough spot.

That is not currently the case.

sreque3• 17 years ago

Neither javascript or python or fast enough to matter. Look at the alioth tests (http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...). V8 is still 25 times slower than C. Does it really matter if you're 25 times slower than C vs 50 or 60 times slower? No, not at all. Using either on the server side you'd have to resort to native code to do the real heavy lifting. Plus, if unladen swallow keeps its promise of doubling CPython's speed, then the gap between the two languages will once again be fairly narrow.

There are more client-side Javascript developers than Python developers, maybe, but not more server-side or general purpose Javascript developers. Google's primary server-side languages are C++, Java, and Python, by the way.

Plus, as a language, Python is superior to Javascript. While the best languages rarely win, hopefully it'll help keep Python in the game for a while longer!

cema5• 17 years ago

If it is ECMAScript, then the writing is mostly "on the browser". Python's writing, however, is everywhere, including the wall. So I would say this killing argument is premature.

alecco6• 17 years ago

> If it is ECMAScript, then the writing is mostly on the browser. Python's writing, however, is everywhere, including the wall.

"The writing is on the wall" is an expression not meant to be taken literally.

> So I would say this killing argument is premature.

Actually many of us are working with ECMAScript outside browsers, often coming from Python and similar languages. Interfacing from C and C++ to V8 is incredibly easy. Have you ever tried to make Python modules?

Also ECMAScript VMs have plenty of security features that come extremely handy, like security. Python security, in particular sandboxing, is almost impossible to achieve and the work-arounds you need kill performance even further.

As a former Python fan, I could go on and on for pages. But I doubt this would change your mind so it's preposterous.

sreque3• 17 years ago

I won't be switching to javascript from python anytime soon. Javascript took about half of the bad ideas from perl and mixed in a few bad ideas of its own into a not very good language.

Invoking a method on a primitive string silently fails and does nothing?

Javascript differentiates between primitive strings and object wrappers such that you have to write ugly code like what's shown here: http://www.planetpdf.com/developer/article.asp?ContentID=tes...?

Forgetting the var keyword makes a variable global?

No module or package system without hacks?

Passing in the wrong number of arguments into a function is normal behavior that doesn't cause an error? At least you have nice syntax to bind arguments to variables, which perl doesn't.

People think ECMAScript's implementation of prototype based programming is a good idea? I could do the same thing in python easily by only instantiating objects and adding functions and properties to them manually, and the syntax wouldn't be much worse than in javascript, but I don't, and neither does anyone else.

It's been a while since I've studied javascript so my memory of dumb things about the language has grown dim, but I honestly don't get how people think it is a good language, or should be used anywhere else than where we are forced to use it: in the browser.

natrius• 17 years ago

Most of the issues you mentioned are solved in ECMAScript 5 with "use strict".

chromatic• 17 years ago

> At least you have nice syntax to bind arguments to variables, which perl doesn't.

Perl 5 and 6 both have this.

m0th873• 17 years ago

As a non-lisp programmer, what scares me away is the syntax. I don't think I could ever wrap my head around the (admittedly succinct) examples I see online, because it takes so much effort for me to figure out what's going on in even a few lines of code. Comparatively, I was able to understand what was going on in most python scripts before I knew the language. Is this something that just takes a while to get down? Or are some people just naturally prone to the syntax?

PieSquared3• 17 years ago

The reason this syntax scares you is simple: it's different.

At the very root, Python syntax is nearly identical to Java, C, etc.

The syntax of Haskell, OCaml, etc, is a deviation from that of Python, Java, etc, but not an incredibly significant one. Perhaps you may find that the syntax of these languages scares you but you think you could probably learn it after a bit of mind-wrangling.

Lisp, on the other hand, is old. It was developed over 10 years before even C came to being! So the syntax is completely different, and requires you to actually learn it instead of just assuming that your knowledge of other programming languages will pull you through.

In summary, it's not a fault in you. It's just that you are used to C-derived and influenced syntaxes, but not to Lisp; and the syntax of Lisp is different enough that you need to actually learn it.

Here's a crash course:

  (f a b c) is the same as f(a,b,c).
  '(a b c) is kind of like ["a", "b", "c"].
  '(1 2 3) is just like [1,2,3]
  (defun x (a b c ...) ...) defines a function x(a,b,c).
  (+ 1 2 3) is just like +(1,2,3) = 1 + 2 + 3
  (setf x 5) is just like x = 5
  '(a b ,c) is just like ["a", "b", c]
  if L is equal to '(1 2 3), then
    `(10 20 ,@L) is like [10, 20, 1, 2, 3]

Now, to be honest, I just showed you nearly 100% of the 'syntax' Lisp has. The rest is already understanding the language (knowing how to def. functions, how to do loops, etc).

By the way, what you might find interesting is that I once showed this to a friend of mine who knew nothing about programming. I showed him how to write a basic program in Java (with a few subroutines and a loop), then how to do it in Lisp. He exclaimed, "Argh! If I can do it like this, then why do I need all those fancy weird words like public and void and what not and braces and... eugh!"

Sorry for that longish post, I hope you found it at least a bit informative. ;)

tel• 17 years ago

Also:

Until you start getting into the most complex (and powerful) aspects of lisp, the last two lines of syntax are rarely used. You get get a very long way without understanding them, but once you do lisp will become one of your favorite languages.

m0th873• 17 years ago

Very useful! I suppose I was wrong to say the syntax is confusing, because lisp is so syntactically minimalistic. But when I look through lisp code, I can't determine anything with respect to scope. Take, for example, the code in pg's A Plan for Spam: http://www.paulgraham.com/spam.html

(let ((prod (apply #'* probs))) (/ prod (+ prod (apply #'* (mapcar #'(lambda (x) (- 1 x)) probs)))))

It took me several minutes to weed through this code. Part of that is because I didn't know what, say, apply did, and had to look it up. That's not an issue because you have to do that when learning any new language. But I had to carefully inspect the source bottom-up and break it apart because I couldn't tell what the arguments are on each function call. An IDE that does block highlighting would help a lot, but even then it feels overwhelming, because it only helps me inspect the block that my mouse cursor is currently on.

I guess what I'm saying is, I feel as if the syntactical constructs in other languages are necessary for me to be able to quickly parse a language.

ezy• 17 years ago

I'm not sure this is quite correct. My own (admittedly controversial) opinion is that lisp is old, and it's "syntax" is broken because it's nonexistent. Python has it's own problems, but it is less broken. :-)

The raw basic "syntax" in terms of the parens is a bear to read (and write), but you get used to it. It may be different, but that isn't really the problem. Anyone can figure out nested parentheses and escaping. Just as someone else pointed out -- this isn't alien territory .. nested parens/brackets/whatever and literal escaping are common in complex/terse code in any of the popular languages. Possibly Haskell is different, but I find it's terse syntax of juxtaposition more inscrutable than lisp, for the most part.

The problem is that in practical terms, the lisp syntax is not just nested parens and various forms of quoting and basic function invocation. The syntax includes the positions of arguments to various standard macros and special forms. Are they are sublists or inline? what are the keywords? And most importantly, are they evaluated or not? From an academic point of few, this technically could be considered semantics of a programming language, but I think that's false -- we don't consider human sentence structure semantics. This is totally syntax. And in lisp, it's highly irregular from form to form. It's just something you have to "know" based on the form, and the lack of syntax other than parens and quotes certainly doesn't help you at all here.

Compared to something like python, it's unreadable and confusing.

lsb• 17 years ago

Everyone says that the parens melt away, and it's true.

However, using the language means the syntax, semantics, std lib, and community. So it's ultimately a very personal choice.

megaduck• 17 years ago

Disclaimer: I'm still a total lisp newbie, take all of this with a grain of salt.

As I see it, the biggest hurdle to learning LISP isn't the syntax per se. Lisp's syntax is so simple, it's easily learned in a matter of minutes. The whole language basically boils down to lists and dotted pairs, and lists can be boiled down to dotted pairs if you squint at them the right way.

The real obstacle for newcomers is that you have to completely rewire your brain. The vast majority of us were taught programming with BASIC, C, Java, or something similar. With those languages, programming is like following a recipe. Do step a, then do step b, etc. Moreover, imperative languages use a familiar "verb" and "noun" paradigm. That's natural and intuitive to most of us.

With lisp, everything gets turned on its head. Everything happens at once. Code is data. There's no syntactic sugar because there's no syntax. You have to completely relearn how to look at computers and programming, and start over as a child. It's incredibly rewarding once you start having those "aha!" moments, but there is a decent-sized conceptual hurdle for people that are used to procedural programming languages.

It seems that the majority of the lisp community suffers from the curse of knowledge. For experienced lisp people, lisp is so natural and intuitive that it's hard to understand why other people have such trouble with it. The OP is correct, lisp could really use more resources to bridge the gap between lispers and the outside world.

viraptor5• 17 years ago

I see it a bit differently. I had to learn enough lisp to port some small application I needed to python. The result is basically this:

I don't have any problem learning the syntax - I didn't have anything against ml-s, haskell and others either, even though I started with pascal. But what do I gain by using lisp seriously? I can do easy prototyping in python; safe, functional code in haskell; serious multiprocessing in erlang; fast tight-loops in c; nice oo in either python, c# or java, etc. etc. Why exactly should I spend more time with lisp? What does it help me achieve? Python right now is basically lisp + community from what I can see. Sytax doesn't even matter that much.

If I need to rewire my brain to feel natural with a language that doesn't give me any new possibilities... then what's the point? I need those wires to understand haskell, sorry ;) I just need some balance - I can change the way I write my code, but tell me what do I get in exchange... and then tell me how is it better than doing the same in any other language.

geocar4• 17 years ago

> Is this something that just takes a while to get down?

Yes. You can practice in python reading this:

    [f,b,(),q,[1,7,q],[q],[q,r,6,1]]

> Or are some people just naturally prone to the syntax?

Lisp "code" is just a data structure (largely: nested lists). It's not the syntax that bothers you, it's dealing with complex data structures. You can see for yourself that they bother you no matter the actual syntax because the above form is python, and it bothers you as well.

People who seem to pick up lisp quickly, simply have a better- rather, a more compatible background. If they lack your particular impetus, they might already be comfortable with complex data structures.

Yes: People can be predisposed to "getting" lisp, but I doubt it is a genetic thing.

> it takes so much effort for me to figure out what's going on

There's nothing going on. In python, there's an invisible stratum between the code you write and the code the computer executes. You don't usually see the substrate, and if you aren't paying real close attention, you might often forget that it is there. Lisp simply lacks that invisible layer.

If you can't get past the complex data structures bit, there are other languages that lack that stratum that use very simple data structures: Forth, for example.

mark_l_watson4• 17 years ago

I wrote 2 Springer-Verlag Lisp books in ancient times, and have about 25 years of Lisp experience.

That said, Ruby has mostly replaced Lisp in my toolbox. When I do use a Lisp family language, it is most often Gambit-C Scheme to build small standalone executables - and sometimes Franz or SBCL Common Lisp.

BTW, I consider Python and Ruby to be fairly interchangable - use whichever you like best. Both are great languages with great libraries and supporting open source projects.

garnet7• 17 years ago

> Ruby has mostly replaced Lisp in my toolbox.

Wow. Would love to hear why. Could you list some of your weighted plusses and minuses for Lisp and Ruby?

mark_l_watson4• 17 years ago

I used to worry more about good runtime performance. Now I prefer to use a language that is easier and faster to use in development.

re: pluses and minuses:

Lisp:

+ better interactive development style; I'll keep a Lisp repla open most of the day. For Ruby, irb is not something that I live in.

+ really great runtime perfromance

- not as many libraries for web frameworks, database, etc.

Ruby:

+ very concise and fun to develop with

+ many great libraries and frameworks

- poor runtime performance

mahmud2• 17 years ago

Mark, you're a polyglot. I would say for the last 20 years you have been a C++, then Java author more than a Lisp programmer.

The first C++ book I ever owned was yours, the one about artificial agents that had a sculpture on the cover, and that must have been 15 years ago.

If you're in the business of education, your "toolbox" is essentially whatever people need to learn. You wouldn't hear an English teacher in Korea with 25 years of experience saying she is done teaching English, because teaching Spanish is so much more easier. That doesn't make any sense. At the time you wrote the published Lisp books, it was the height of AI-bubble and people needed to learn Lisp and Prolog. Then you wrote an Smalltalk book (IIRC.) then C++, Java .. all dictated by what the public needed.

Btw, you still have the literary and expository prowess to teach today's hot technologies as well. But that doesn't say anything about Lisp, Prolog, Smalltalk, C++, or Java except that you are no longer in the business of teaching them.

And I mightly thank you for the Agents book, btw. I didn't know what I was doing and just typed in the code into Borland C++ 4.5. The diskette was missing when I bought it, and I am sure I tried to download the source code from the Addison-Wesley ftp site (it could have been a Prentice Hall book as well)

Cheers!

mark_l_watson4• 17 years ago

I must admit that I usually think that whatever projects that I happen to be working on are: most fun, most interesting, etc. Same comment applies to programming languages, tools, and frameworks. This is a reflection of a simple fact of life: whatever we think hard about and generally mull over, becomes very interesting.

mark_l_watson4• 17 years ago

That said, I am likely to be using Lisp a lot next year: I have a partially written book on Franz AllegroGraph that the people at Franz suggested that I put on hold until their new version 4 is released. The free version of AllegroGraph is awesome (supports 50 million RDF triples, and easily used from Lisp, Java, Ruby, Python, etc. clients). The $$ version scales very well to huge data sets.

whyenot• 17 years ago

Python also wins because it's a living language, still changing, adapting and updating itself while Common Lisp died the day the ANSI standard was published and today is a zombie, even if it still smells fairly nice.

Now that comp.lang.lisp is utter crap, there isn't much of a community either except for #lisp, which as an outsider I find kind of intimidating and not a good place to ask for help. Actually, what lisp really needs is for Conrad Barski to clone himself 10x :)

cema5• 17 years ago

Well, there is always Clojure, as another commenter mentioned. Its community is different (friendly and helpful) and so is the language (vibrant, modern and evolving).

mnemonicsloth2• 17 years ago

Three years old.

When this was written, there was no such thing as Clojure [1], and a number of now-essential CL libraries were just getting started.

Providing no new information, this article just invites needless soapboxing.

[1] Clojure is fast, free, trendy, inherently parallel, and fits seamlessly into the Java ecosystem. It's just an anecdote, but I notice less complaining about parentheses, too.

cema5• 17 years ago

You are correct. Still I think it offers useful historical perspective.

mnemonicsloth2• 17 years ago

Lisp already has too much historical perspective. That's one of the things people like about Clojure.

camccann• 17 years ago

It's just an anecdote, but I notice less complaining about parentheses, too.

I still like the idea of "Lisp with syntactic whitespace". A few simple transformation rules to add implicit parentheses based on indentation would make it a lot more readable for people who aren't already veteran Smug Lisp Weenies.

There was even a specification written for adding it to Scheme: http://srfi.schemers.org/srfi-49/srfi-49.html

ynniv• 17 years ago

It didn't feel needless when I wrote it. The lisp community was sitting on their haunches (their laurels had long rotted away), and silly new languages were stealing lisp's thunder. Today, I would probably have written about how clojure will soon be "killing" python, so maybe I'm just a soapboxer.

kristianp• 17 years ago

I started learning scheme recently, and enjoyed it for a while, then went back to ruby. (I have been programming in Ruby for a few years now.)

If I want to prototype something quickly, I will use ruby. I think the modular way you can program in an oo language is another factor. It is easy to write a demo, and then add the class to a rails project. I tried to read about using modules, such as those used by gambit-c, but the mailing list replies were dense with jargon, which I found more of a barrier than the parentheses.

I found the scheme environment too fragmented and lacked a decent equivalent of rubygems. The lack of a non-emacs editor with nice indenting was a contributing influence.

Replace ruby with python and scheme with lisp above, to see the relevance.

How Python is killing Lisp

Related Stories