Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several students claimed that they had a hard time mapping from the pseudocode in my AI textbook to the Lisp code that Russell and I had online. So I looked for the language that was most like our pseudocode, and found that Python was the best match. Then I had to teach myself enough Python to implement the examples from the textbook. I found that Python was very nice for certain types of small problems, and had the libraries I needed to integrate with lots of other stuff, at Google and elsewhere on the net.
I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se.
In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.
In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.
Thank you, Peter. This is how I have felt for years, but could never find words that describe it as well as you just did.
Someone should write a program that automatically posts this paragraph at the top of every language war thread. I think they should write that program in php :-)
What makes it possible to launch 10% faster? Is it familiarity with the language, tools, libraries, and frameworks? Is it that the language is more dynamic and requires less to accomplish task X? I would say yes to both questions.
Now with the first question, familiarity with the language, lets discuss Python. Python is my language of choice. I know it, I use it, I pay attention to what is happening with the language, the community, etc. I organize a Python User Group. If I were to work on a new project, I would choose Python. I believe I could launch 10% if not 50% faster with Python than with Ruby. Does that make Python a better language? No. Just that I don't know Ruby, Rails, Sinatra, etc.
I think the second question about how dynamic the language is plays into this as well. Java is not very dynamic. Some tasks in Java are downright ugly to work with. If you want to prototype fast and spit out a product fast, you might not want to use Java. At that point, there are several great languages to choose from like Python, Ruby, Groovy, Scala, Lisp, Smalltalk, Javascript, Closure, etc. The list just goes on. You could also argue that .net is more dynamic. But Java has some good points to it as well. You have less risk of bugs due to it being statically and strictly typed. You can build off some great libraries. You get the benefit of the JVM and JIT, which are amazing. Maybe you can't launch faster with Java, but maybe you can launch with a more robust stable product. First doesn't mean best; remember the article about Wasabi and Mint?
The way I read Peter's comment was you don't want to spend you time finding the best language. Instead you want to just grab the most convenient language and spend your time creating the best product. Think through your architecture, work on your design, test the hell product, study the market, your competitors, work on your marketing, and on and on. The list of things to do never end, and if you were still debating about which language to choose, you won't launch.
I agree. Language choice is definitely not the most important factor in success, but it's not as unimportant as some think it is.
Some languages make it easier to become familiar with the libraries. Compare the standard libraries of Ruby and Python with PHP. Even though I programmed in PHP for several years I always had to look up argument order, or whether the names of functions contained underscores between words or not.
Also, the language choice might lead one to a slippery slide of platform choice which easily slips into trapping you in an architecture you really did not want.
I've had a similar experience, lately while writing and editing pieces for Code Quarterly--I've written the same basic algorithms in Javascript, Python, and Common Lisp to play around with them. I find the Python the best vehicle for conveying the algorithms despite being more fluent in Common Lisp.
But I've also been astounded at how slow CPython is compared to SBCL (the Common Lisp implementation I use) when I have to do long runs to gather data. (For the things I've been playing around with, my Common Lisp implementations have been something like 5 to 20 times faster.)
that's bad assembly-style pseudo-code and thinking. Lisp favors higher-level, functional pseudo-code that readily runs as is!
like in scheme:
(write
(let for ((i 0) (s 0))
(if (> i 100) s
(for (+ 1 i) (+ i s)))))
why would you care for those a, b, or s variables in the first place when all you want is the sum? The above expression writes the sum as computed by a recursive approach using lexical bindings.
you may of course abstract it away into a function:
(define (for from to doit result)
(if (> from to) result
(for (+ 1 from) to doit (doit from result))))
and use it:
(write
(let ((a 0)
(b 100))
(for a b + 0)))
Then, why no one still not made such eDSL? As I understand, the only reason to choose Python for Peter Norvig was the similarity of Python to pseudo-code. I think that such great hacker as Peter Norvig could easily develop pseudo-code eDSL on top of Lisp macro-system.
As school teacher on programming I'm limited in choice of programming languages. The only language which I can study is Pascal (a lot of other reasons on it). The problem is that Pascal have not any libraries (GUI, 2D/3D, Game Development Engines, programming micro-controllers, ...). Students can write only simple console applications. So, it was be ideal to have subset of Pascal as eDSL on top of Common Lisp or Clojure. In that way I can easily extend original Pascal to access some real world libraries.
I think also on top of Common Lisp we can develop some simpler eDSL as pseudo-code for beginner students.
>The problem is that Pascal have not any libraries (GUI, 2D/3D, Game Development Engines, programming micro-controllers, ...).
It's not true. Lazarus (http://www.lazarus.freepascal.org/) gives pretty much everything Delphi has.
Currently I develop OpenGL 2D analytical tool. Again GUI is on par with Delphi.
There are such DSLs on top of Common Lisp. But usually not on the scope of a full programming language like Pascal. It is not that typical anymore, but there are examples in that direction.
LOOP shows some of the practical problem. For example for LOOP one needs a custom highlighter in the IDE, because it has its own complex syntax, which does not follow the basic Lisp model.
Same for indentation / code formatting. There maybe other problems.
There is another Iteration facility as a library for Common Lisp called ITERATE. It is very similar to LOOP, but the syntax is a bit more oriented towards Lisp.
There are such DSLs on top of Common Lisp. But usually not on the scope of a full programming language like Pascal. It is not that typical anymore, but there are examples in that direction.
The advantage of doing a "language X to CL" translator is that it's going to be much simpler than doing it in another language (the number of features offered by CL is a huge superset of that available in any other language; the only exception is continuations), the result will be faster (the example Ruby translator is faster than Ruby, cl-javascript is faster than SpiderMonkey, etc, mostly due to SBCL being a reasonably good compiler), and you will have access to really good debugging tools (Clozure is really good at this - see http://openmcl.clozure.com/ccl-documentation.html#watched-ob... for example).
Usually these languages like Python are implemented on top of Lisp using a special parser. Of that there are many, from C, Python to special research languages. Then there are a lot of languages with lispy syntax. Typical examples were Prolog dialects with Lisp syntax (and optional Prolog syntax). The example that languages are embedded into a single s-expression (like in the LOOP macro) is also possible, but different. It would not make sense to use Python that way, since the low level syntax of Python is different from what Lisp s-expressions provide. For example s-expressions are not preserving any textual layout (indentation) when read - something that a language that uses indentation in its syntax would need, but would not get from being embedded in a single s-expression.
I came to conclusion that it is easier to do external DSL, not embedded. Parse source code on Pascal and then translate it into S-expressions. Am I right?
Btw, if I'm gonna write external DSL, I can do that in any language for example on Python. So, what's the difference?
Once again the YC community surprises me in both it's depth and it's breadth. From someone who has found your (and Russell's) text invaluable, I say - thank you, sir.
And thank you PG/YC for giving me the opportunity to do so.
Just wanted to chime in briefly here and say thank-you for your example Lisp interpreter in Python. Made some things much clearer for me and because of it I now have the knowledge to be implementing R5RS over the top of Ruby! Thanks again!
> But Python has the edge (with a large number of students) when the main goal is communication, not programming per se.
Communication is increasingly the more important part of programming. Engineering is only really useful if its well communicated, or in a binary you trust.
Yeah, there'll come a time when to build systems all you need is a bunch of people talking to reach a consensus: how much to pay for a third party to write it for them.
Peter, you imply that Python is better for, or more like, pseudo-code, but why is it better? In my opinion, it is better for most people because they were taught syntaxes more like that of Python than that of Lisp. An important factor in easy-of-understanding is to be similar to something you are already familiar with. To the extent that this is the reason, it's not implicit in Lisp vs. Python, but rather more a question of which style of syntax is better-known.
> Peter, you imply that Python is better for, or more like, pseudo-code, but why is it better?
Well from what he writes, he seems to say Python looks much closer to their actual pseudo-code, and it's therefore easier for students to translate pseudocode to Python than to Lisp.
> In my opinion, it is better for most people because they were taught syntaxes
Such as english. One of the original goals of Python (inherited from ABC[0]) was to be a good teaching language. I'd expect that when Peter talks about his students, he's mostly talking about students with low-to-no knowledge in programming. Those who are already knowledgeable probably don't have a hard time adapting.
When I took an AI class at my university with AI: A Modern Approach (the book was good, if a little difficult to understand at times), we had a couple projects that we had to write in lisp.
First project:
Problem Solving Agent for Traveling Salesman Problem. 1. Depth First Search (function argument- DFS)
2. Iterative Depth First Search (function argument- IDFS)
3. A* - Heuristic: Path Cost Incurred (function argument- PATH)
4. A* - Heuristic: Minimum Spanning Tree heuristic (function argument- MST)
5. (Extra Credit 25 points ) Create and implement a heuristic equal to or better than MST
Second project:
In this project we implement a decision tree induction algorithm in Lisp.
I had played around with lisp before this point and found it fascinating. I approached these projects with excitement. But even with 8 years of serious programming experience, I could not for the life of me solve these problems in lisp. My problems included:
1. Knowing exactly what methods I wanted to call and use and either
a. Not being able to find them in any reference I found online, or
b. Finding out that they don't exist, and you have to write them yourself, or
c. Finding them and shaking my head at how ridiculously they were named.
2. Not being able to read the code I had just written.
3. Not being able to debug.
4. Finding that manipulating common data structures like hash tables is a total chore.
Eventually I gave up. I had spent about two hours trying to implement the project I had already solved in my head into common lisp and was making little or no progress. So I fired up another vim terminal, solved the project in Python in about 30 minutes, including debugging, and then manually translated the code into lisp.
When project 2 rolled around, I decided to give it another go, but I quickly became frustrated again. Maybe my mind just isn't able to grok lisp? Maybe I'm just not smart enough?
All I'm claiming is that I am an example of a student who was already very knowledgeable about programming and completely unable to adapt to lisp.
Do you also find your pseudocode (and therefore python) clearer, or was it entirely pedagogical?
Redesigning a data format to match how I notate and think about it, to minimize my cognitive load, has been very helpful to me.
The long-term trend in computers seems to be to trade performance for helping the developer.
> when the main goal is communication, not programming per se
This reminds me of debates about the scientific method. Some say that you can test hypotheses etc alone without publishing and you are doing science; but others define science as a community activity, and so without publishing, it is not 'science'. While I love the idea of the lone researcher, and clever insights definitely come from individuals, without a community there is no SOTSOG.
Robert M. Lefkowitz's 2007 PyCon Keynote discusses the "main goal is communication, not programming" in great detail. Wish there was a text I could cite.
I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se.
In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.