How Python is killing Lisp | Hacker News Reader

How Python is killing Lisp

ynniv.com

33 pointspmiller266 comments

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.

> 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?

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

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!

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.

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.

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.

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

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

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

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.

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?

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.

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

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?

I don't think it has to be true, though they do go together well. Not all CL hackers use Emacs. You might consider trying the Lispworks IDE, or the Allegro IDE (on Windows) or the Clozure IDE (on Mac).

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 :-/

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?

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. ;)

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.

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.

Lisp code is almost always written on multiple lines, with an editor that automatically indents everything. Code in a more familiar language (C?) would also look incomprehensible if ten lines were all smushed together on one.

I let Emacs indent that, and it came out like so:

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

You still have to learn the idioms (it's a different language!), but it's not just a jumble of parenthesis.

Prefix notation takes some getting used to for arithmetic, but that's neither here nor there. You probably have a bundle of idiosyncratic operator precedence rules memorized (quick, does 3*4+5 equal 27 or 17?), and Lisp doesn't use those, preferring to consistently use parenthetical nesting for everything.

Paul Graham has a peculiar Lisp style which is NOT mainstream. He is succinct, clever, and usually performance-agnostic. He writes expository code like we write one-liners in the repl to quickly test something out.

That example you linked to is confusing because: 1) You don't know the syntax to read it out like a formula, and 2) he uses the names prod and probs which look the same and strain the mind of a newbie.

The way you read "hard" Lisp code, specially one in Graham's style is to read from the last line upwards. The tell-tale is the deep indentation, btw.

Start at the last line, which is the body of MAPCAR, you know mapcar is MAP which applies its first argument function to successive elements of its second-argument, which should be a list.

  (mapcar #'(lambda (x) 
               (- 1 x)) probs)

Make a mental note about the free variable, probs. You can recognize the function as the usual arithmetic step of converting integers to probability values between 0 and 1. The sharp-quote, #', is an archaic style and unnecessary, so let's wrap up these two lines into a function and change the names to be readable.

  (defun normalize-probabilities (probabilities)
    (mapcar (lambda (x)
              (- 1 x))  probabilities))

Ok.

Look up further and notice the result of this function call, a list, is being reduced to an integer. APPLY applies its first argument, a function, to its second argument, a list. For example, (apply #'+ (list 1 2 3 4)) means sum of the first four digits. C programmers should find this familiar: (apply #'main argv)

Where MAPCAR returns a list, apply returns whatever its function argument is supposed to return. We know the function #'* takes a list of numbers and returns their product. So, the snippet is just multiplying the list of probabilities, or reducing to a scalar.

  (apply #'* (normalize-probabilities probs))

Then:

  (+ prod (apply #'* (normalize-probabilities probs)))

And here something called prod is being added to our scalar. Hmmm.

Look up a bit and see where that's coming from. The nearest binding form for prod is in the LET body on top. Looks very similar to something we have seen before. Another application of multiplication to the list named probs. This is not a Lisp issue, it's a Bayesian statistics or perhaps a PG issues. You continue reading the paper and discover his formula in English prose. Aha! :-)

You can move code around, tuck it into functions and do whatever you want with it. See if you recognize the code snippet now:

  (defun normalize-probabilities (probabilities)
    (mapcar (lambda (x)
  	    (- 1 x))  probabilities))

  (defun pg-foo-fomula (product)
    (/ product (+ product
  		(apply #'* (normalize-probabilities probs)))))

  (defun main ()
    (loop
     (let ((probabilities (eval (read))))
       (when (listp probabilities)
	     (print (pg-foo-formula (apply #'* probabilities))))
       (princ "OK > "))))

Typically you don't do that; you don't make silly repls and you never ever write a MAIN or any other program entry function. You write libraries, that you use in other libraries, and you orchestrate them all via interactive use and deploy in a custom image.

You should write a book on practical lisp. I'd buy it!

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.

You have a point; your basic statement is something I agree with. However, it depends on what variant of Lisp. Common Lisp, it's true, does have a lot of remnants from the past which make it ugly. (After all, why should I have to say 'aref' when it would be so much nicer just to say [] for array references...)

However, other Lisps exist. Take a look at Scheme or Clojure. Scheme is prettier, and Clojure more practical.

(On a side note: these different variants of Lisp certainly don't help create one "Lisp community".)

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.

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.

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.

Lisp macros make it possible to DSLs that make sense.

The syntax also helps with code generation.

> 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?

Because I can do easy prototyping in lisp; safe, functional code in lisp; serious multiprocessing in lisp; fast tight-loops in c; nice oo in either lisp, lisp or lisp.

If you find a problem that needs a new paradigm, you either need a new language, or you need lisp.

> Python right now is basically lisp + community from what I can see.

Python is a great language. It supports a lot of the most useful and powerful paradigms that lispers use, so many lispers like it and use it.

But python is not "basically lisp", simply because it lacks the property I mentioned earlier.

By "safe" I meant "static type-safe" - sorry for the confusion. And no - can't do that in lisp.

What do you mean by serious multiprocessing in lisp? Does it have a distributed database included? Or a node registration and message passing framework? Or a process control framework? Can it run my 10000 processes? Does it have portable networking and thread implementation where nothing ever blocks... Or did you mean that I can have for example the sbcl threading http://www.sbcl.org/manual/Threading.html and can build all of that on my own? I could do the same in c... but I won't - erlang is better for that.

I'd also argue with "nice oo in lisp"... for some values of "nice" :) For big projects I want a code browser / ide. I want types in my OO. I want the code to be structured in a way that makes the methods belong to classes. I don't want old-style message passing OO (not saying that it's bad... it's just not what is used these days in big projects). I want new-style enterprise-level OO with interfaces and self-commenting code where you write what you want to do, because every single person in your 100-person team has to understand it without any comments when you're not around.

So everything that's left imho is easy prototyping. We can shoehorn every paradigm into any language - sure. But then you get something that can do everything and isn't good for anything in particular. If I learned lisp before python, I'd probably say the same thing about python... it's just not worth the additional attention, because they're both easy-prototyping languages, where you can promote the code into production when your first design is "good enough".

Someone correct me if I'm wrong, but I think Common Lisp provides the ability to declare types of variables, and do type-checking on it. This allows you to make CL type-safe if you want to. It also allows a major speed up.

The real problem I see with Lisp is that it lacks a vibrant community like Ruby and Python has, and is in some cases quite ugly. (Why, why use names like 'progn'? Why not the shorter, clearer 'do'? etc.) Clojure addresses that, but I get the feeling that Clojure is just an addon to Java and that you must use the Java lib in order to use Clojure; the integration between them seems to be to be a bit ugly, if easy to use.

However, due to the size of the JVM base, Clojure is very good for production code - but strikes me as lacking the hack-hack quality you can get with CL. And only has one implementation. Aurgh! If only they didn't standardize CL. (Except, then it wouldn't exist at all right now, I bet.)

> We can shoehorn every paradigm into any language - sure. But then you get something that can do everything and isn't good for anything in particular

That doesn't necessarily follow, but it might very well be true.

In addition to features, languages need speakers. Java is rarely regarded for its feature set, but it is certainly a "good" language in that it is good at something.

The rest of your comment is largely drivel, compounded by the fact you simply don't know lisp well enough to think in lisp, and consequently have a meaningful conversation about what that means. Nevertheless, you somehow got the impression that I thought you should switch to lisp, and I sincerely apologize for that; I never meant that at all- only to express how knowing lisp is valuable.

However, there was one thing in particular:

> I don't want old-style message passing OO

Most lisp programmers prefer CLOS-style OO which uses generic functions, and not message passing.

Feel free to correct me - I hope to learn something new if you say exactly why you think my points are incorrect. Especially - why would you choose lisp over a specialised solution - static type safety, multiprocessing, oo being the main areas discussed. I don't claim to be an expert in lisp, as I mentioned before. What I wrote is based more on what I see, rather than what I work with every day and I appreciate other views even if don't agree :)

> Feel free to correct me - I hope to learn something new if you say exactly why you think my points are incorrect

They aren't necessarily incorrect, they're just meaningless: I don't start a program and say what this program needs is static type safety, multiprocessing and object oriented designs. I start at a much higher level than that: What should the program ultimately do?

A number of years ago, I made survey kiosks that ran on OpenMCL on G3 macs. They had to ask some prearranged questions, with some potential branching and "please specify" type answers, and they could give different questions based on previous answers. On the way, a number of interesting things happened:

1. The original plan was to use xulrunner and aserve on top of an X server (no WM). xulrunner was simply too slow, so with only two weeks left it was ripped out and replaced with checkboxes, buttons, images, "textareas" and radio buttons on SDL. All of the generic functions which used to emit html, now tracked dynamic variables for a "cursor" and made a drawlist.

2. The survey stations updated their code using multicast pings. Basically they had a directory of source files, and a version tag that would automatically be pushed to any nearby station. When I decided I needed a database, I simply stored the answers in that directory, using the mac address of the ethernet device as the file "name", and the contents simply as lisp forms. The result was that all the answers collected by a machine were shared with every other nearby station. On two occasions a machine died in the field, but no questions were lost. They also shared their source code similarly, so I could push out updates very easily.

3. I was out of the state at a wedding on their first deployment, and there was a problem: One of the machines was acting really funky. Using two cell phones, emacs and slime, I was able to connect into the machine remotely and repair it on the live system. Once it was repaired, I saved the file and it automatically copied all over the campus.

4. One of the major focuses was media awareness. The user was asked to enter in all of the advertisements they were aware of. This was completely freeform, but we needed to collect the results, correct misspellings, cluster them, and make graphs in real time as the event proceeded. These reports were used in justification to the event promoters.

5. At our second install, they had no ethernet deployment. Instead they promised someone could walk a USB key between the machines. A udev rule to detect insert copied all the database files from that synchronization directory to the usb stick, and a trigger replaced any local files if they were newer.

From prototype to delivery was about two months, and we used multiprocessing, a distributed system, and object oriented programming.

Could it have been done in Python? Sure, but had I used python I probably would've used one of the web frameworks, and once I decided I needed to draw the screen myself, things would've gotten pretty messy.

Could it have been done in Erlang? Sure (I can use the process dictionary for dynamic variables), but when I build the database synchronization system using Erlang primitives, I lose the ability to add the easy USB support.

Could it have been done in Haskell? Absolutely, but only if I got it right the first time: I wouldn't have been able to update the code while I was at a wedding.

Ultimately, had I a clear idea of what was needed before I started, any one of those languages could've been made to work, and they all have lots of library code I could've lifted, which is your point.

However my point is that I didn't have a clear idea what was needed, and replacing the libraries would've required either a significant shift in complexity, or a paradigm that the "best" language simply didn't have.

I don't always use lisp, because the practical access to libraries and efforts is important, however there are times where not having access to libraries and efforts is more important: When I don't know what a program will need, locking myself into a module or a framework is the last thing I want to do.

Lisp does not, at the moment, have any truly practical implementation of multiprocessing. It also doesn't gather any of the lazy benefits of Haskell. It is worthless for prototyping as its modules haven't been up to date in 20 years.

Edit: Gruseom is right, I was very critical without providing any support. Lisp is still very useful in certain cases. The instances which I find trouble with it are detailed in my second response.

Lisp does not, at the moment, have any truly practical implementation of multiprocessing.

That would explain why there aren't any Lisp web servers.

It is worthless for prototyping as its modules haven't been up to date in 20 years.

Tell that to the people who are using it. Oh wait, I'm one of them. What you're saying here is such a crock that I have to wonder what your purpose is.

Fair, I was overly critical. For me, I find that it is far easier to find modules for Python than for Lisp. For example, the other day I was looking for a module to read and write ID3 tags. The only thing I could find for lisp was http://www.google.com/search?hl=en&client=safari&rls..., which is buggy and incomplete. It didn't take very long to find a suitable Python module.

As to multithreading, first since when is a web server the be-all-end-all of multiprocessing? Hell, you don't even need multithreading to do a webserver, just use Unix processes. My issue with Lisp is that there is no standard for multi-threaded Lisp; the ANSI spec doesn't consider threading at all. The Lisp community seems to be increasingly fractured over the years, which is too bad because I'm not insulting Lisp because I hate it -- it has just become too difficult to use as my generic do-everything language.

Sorry for impugning your motivations. I lumped your comment in with the anti-CL canards that people keep repeating.

Your ID3 tag library is a good example of the kind of thing one doesn't find much of in the CL world.

On multithreading, though, I think you're off base. Modern CLs all support it, it works great, end of story. That it's not in the standard is a red herring; you simply look up what you need in the documentation for your Lisp instead of in the Hyperspec. Big deal. If you want to run on more than one Lisp, it's trivial:

  (defun spawn (name fn)
    #+ccl  (ccl:process-run-function name fn)
    #+lispworks (mp:process-run-function name nil fn)
    #+sbcl (sb-thread:make-thread fn :name name))

I wouldn't use CL as a do-everything language either, but it's typically a superb place to be if you're trying to do anything complex.

To respond to a specific point, Practical Common Lisp has a complete implementation of a program to read MP3 and build an online index from the information there. It is a thing of beauty.

> 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.

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 :)

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).

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.

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

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.

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.

> 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...

The original title is a stupid flame-bait and the funny thing is it's a dated argument. [That was my point, turning the flame back.]

> 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.

What are you talking about? There have been people working with Spidermonkey for ages. Now there are so many V8-based projects it feels almost like a crazy fad. The hello world example of V8 is a shell showing trivial OS integration.

> Once someone produces a serious repl-like environment and a set of sys / os / file libraries - it can compete with python.

There are plenty of libraries in the making, perhaps the criticism could be there are too many. The thing is, since it's trivial to interface it with C and C++, at the moment most (?) of us are just exploiting the much, much larger library base of those languages.

Use whatever language you feel like. In a few years, remember this. I might be wrong, or Python might get its act together, we don't really know. But the writing...

Well... I think I'll refer to what you wrote as lisp/perl6 syndrome :)

There is no lisp and there is no perl6. There is no ecmascript. There is some v8, rakudo, drscheme and others... It cannot compete with python, ruby and the rest. If you tell me that "ecmascript can be a standalone scripting tool", people will expect that you can run `ecmascript somefile` and make it just work. I heard about spidermonkey in mozilla and v8 in chrome of course - never heard that they can run standalone - it might be surprising to people involved in the project, but others?...

I meant the sys / os / file library, not some collection. If it's external to the language itself... sorry - but that's not good enough for "general purpose". If you say there are too many system libraries, then maybe you're right. C has stdlib, python has standard modules, ruby has standard modules, java has standard runtime environment - I see a trend here. If it's not obvious which ecmascript am I supposed to use and I cannot just download it and open a file with 1 line of code... sorry - it's not general purpose enough for most of my needs.

The community itself is kind of closed too. http://www.ecmascript.org/ doesn't lead anywhere interesting. Even the community page / wiki doesn't give me any interesting information. "This is a wiki for the ongoing specification work of Ecma TC39...." - thank you, but that's not what I'm looking for. We're "safe" from ecmascript for some time - at least until the people involved figure out how to introduce new people to the language.

I agree with the library argument and the GPL argument. And I agree that it is unfortunate these two languages (Lua and ECMAScript) do not have a complete standalone environment at this point.

I disagree with the downmod argument: the one-liner did not feel as a "meh" argument but a succinct reference to an easily (re)constructed (but more verbose) argument regarding ECMASCript versus Python similar to the original argument of Python versus Lisp. I think such succinct arguments are fine here (in fact, I have upmodded it to compensate for what I considered the undeserved negative score).

In what sense does Lua not have a standalone environment? That's news to me.

   $ lua
   Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
   >

Same for javascript... I use the js console all the time. Thank you, spidermonkey.

> but lua is not enough. Unfortunately neither of them is useful as a general-purpose language right now.

I emphatically disagree. Lua is a great language, it just expects you to be comfortable with more than one language (ideally including C). It's a scripting language, in a more literal sense than, say, Python - you use it to glue together libraries in several other languages and give them a simple repl and scripting interface.

It also seems to be a lot less "opinionated" than Python (let alone Haskell) -- since the whole design of the language is skewed towards being embedded in something else, it's quite happy to be used in just the parts where it's the best tool for the job, and otherwise stay out of the way, and it doesn't come with its own heavy style requirements.

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.

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!

My point was that Python isn't killing Lisp any more than ECMAScript is killing Python.

About the rest, I answered in other parts of this thread.

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.

> 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.

Oh, I agree that ECMASCript is a wonderful language which is widely misunderstood and underestimated (not in this community, but in the industry in general). However, there is more to a successful language than just the "linguistic" quality, or else Lisp would not be where it is now.

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

I think that was satire.

I tried to take it that way but since the meaning of the expression is godly written messages of upcoming doom it didn't make any sense. For satire to be funny it has to [follow], or at least mirror, in some way the original meaning. I picked he isn't familiar with the expression to the alternative, that he failed at being witty.

When you tried sandboxing python, did you look at http://wiki.python.org/moin/How%20can%20I%20run%20an%20untru...? There's multiple sandboxing options listed there.

Also, Python has SWIG, SIP, and Boost to help integrate native code. I haven't yet integrated python and C, but I have integrated Ruby and C. A quick google for V8's C/C++ interface is not leading me to anything useful. Is it really that much easier? If so, that's an advantage of the V8 runtime, not of ECMAScript the language itself. Both Python and Ruby have multiple implementations for which native code interface can work differently. Pypy, for example, claims to have a simple libffi interface.

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.

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

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

Perl 5 and 6 both have this.

Reply on news.ycombinator.com