This seems to be a good excuse to share this great story:
> At ILC 2002 former Lisp giant now Python advocate Peter Norvig was for some reason allowed to give the keynote address like Martin Luther leading Easter Sunday mass at the Vatican and pitching Protestantism because in his talk Peter bravely repeated his claim that Python is a Lisp.
> When he finished Peter took questions and to my surprise called first on the rumpled old guy who had wandered in just before the talk began and eased himself into a chair just across the aisle from me and a few rows up.
> This guy had wild white hair and a scraggly white beard and looked hopelessly lost as if he had gotten separated from the tour group and wandered in mostly to rest his feet and just a little to see what we were all up to. My first thought was that he would be terribly disappointed by our bizarre topic and my second thought was that he would be about the right age, Stanford is just down the road, I think he is still at Stanford — could it be?
> ‘Yes, John?’ Peter said.
> I won’t pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.
> ‘No, John, it can’t,’ said Peter and nothing more, graciously assenting to the professor’s critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.
BTW, Python can do that [1], it's just not very recommended because the ast is not stable between versions (and maybe even implementations? not sure about that)
- Yes, the original publication year was 2000. I've added that to the file.
- @HelloNurse: You've got the key point. I provided Lisp code to teach AI; but my goal was to teach AI, not Lisp. As more schools and students were familiar with Python and not with Lisp, I needed to make the switch to keep teaching AI effectively.
- @jonathanstrange: Yes, "batteries included" is key to Python; there is some pain in doing any change; this page attempted to alleviate some of the pain.
- @rauhl: "in the silence a thousand words were said". I'm not sure what words are in that silence. But to me, the words are: Lisp and Python are different ecosystems with different customs. The Lisp community likes to solve lots of problems with macros. The Python community doesn't. For 95% of the usages, neither approach is better than the other, they are just different. For example, in Python, `with` is a statement, and you define custom classes for each usage you think of. In Lisp, you define a macro like `with-open-file` for each usage. The end result in usability and efficiency is similar. In Lisp, you often define macros for custom data types, e.g.
(def-tree T1
root (A B C)
A (D E)
B (E F)
...)
In Python you use a combination of built-in data types (like dicts), custom classes, and ad-hoc parsers of text. Again, the approach is different, but readability and efficiency is similar.
It is certainly true that if you want to define, say, a mock Prolog system, it is easier to do it in Lisp with macros than in Python, where you would need to deal with the far messier `ast.parse` module. Is that where the silent words were? For me the words would be "Lisp is a much better choice if your primary goal is defining a full-blown domain specific language. For most other programming tasks, the two languages offer similar functionality in different way."
>The Lisp community likes to solve lots of problems with macros. The Python community doesn't. For 95% of the usages, neither approach is better than the other, they are just different
I'd like to interject for a moment.
As a software engineer with some years of using Python for financial software, and afterwards switching to Common Lisp, i diverge. In my opinion, Lisp macros make all the difference in the world, and I really miss them when using a language that doesn't support them. Sure, anything can be implemented on most languages including Python, but there is a big difference in the maintainability and clearness of the resulting code, as well as in effort.
So, are you abandoning us, Peter? If not nil, i will signal 'tears and no handler-bind will recover me from this condition. (joking of course)
Anyways, thanks for PAIP, it will always be in my heart.
(Note for the uninitiated: PAIP stands for "Paradigms of Artificial Intelligence: Case Studies in Common Unpython", a classic book by Peter Norvig who is part of the big PPP of Lisp literature: Paul (Graham), Peter (Norvig), and Peter (Seibel))
"The Lisp community likes to solve lots of problems with macros" sounds like "Mozart likes to use a lot of notes". I do not like to use macros, I like to hide boilerplate so the semantics stand out. And so I can type less. I do not like typing. But Siri can stuff it. I digress.
I gave this some thought. First, the silence was perfect and it was a privilege to witness that moment between you two. As for the thousand words, they were the hundred moves we do not see in a grandmaster draw after a half dozen moves from a well-understood opening and a handshake. John had by implication stood up for homoiconicity as essential. You conceded Python lacked the quality, leaving intact your equivalence argument built in part on other Python features and in part on missing things not mattering. Nothing more was needed.
But that is just my poor reconstruction of the moment. The silence was better.
I'm just a numerics person but I'd love to hear your input about relational/declarative/Prolog-like programming in Python in the following situation: if the working language doesn't have to be anything resembling Prolog, but can instead be a Python internal DSL(DSL-lite?), and further if, say, one wants to do unification only over (what amounts to) some numeric data, then Python's operator overloading can supply all the heavy lifting one needs - allowing one to build up a representation of the (computational) expression tree via overloading and then "compile" that guy into lists of relational function closures which await environments (design spaces). This is of course a really specific case, but as a "mechanical-type" engineer doing a thesis on automated geometry generation, and needing a pre-processor to quickly pair down my design space to something nice given a design specification on the fly, I've found python + unification + numerics (especially interval arithmetic - where the design space is basically closed...) to be a really useful (and work saving) combination! The end result feels like magic to me anyway. But lots of computing feels like magic to a numerical programmer - that's what makes it so fun to branch out - and Python makes that as easy as possible. (Thanks for all of your writings which help the novice do this kind of thing!)
I should summarize that long winded statement in case anyone tries to read it: eh hem... This one time, for this one specific case, off in a totally unrelated field of engineering, Python made for a pretty fair Prolog substitute for one kid's dissertation.
Was McCarthy even thinking of macros when he locked onto code as data? Or was he thinking code generation in pursuit of AI?Asking, do not know. I know macros are a great example of code=data, but I once had a ball using the AllegroStore CLOS database and a homebrewed DB synch layer to handle remote distribution and update of forms and the code to validate them in a clinical drug trial management context, where forms and their validation code are forever changing. Basically, an intractable software maintenance problem just disappeared. That's always fun. http://smuglispweeny.blogspot.com/2008/03/my-biggest-lisp-pr...
He was not, macro libraries like defmacro and define-syntax were later addition to lisp. Well before formal macro systems were implemented, code-as-data was particularly useful for implementing the eval function in Lisp (the Lisp 1.5 implementation takes up less than a page), which greatly simplified the process of implementing compilers and interpreters.
It's worth noting that one of the main pain points mention of Python was that it was 2-100 times slower (vs 1-2x slower for Lisp). The slowest elements of Python compared to C++ were matrix multiplication (278x slower), array access (141x slower) and heapsort (84x slower). NumPy solves the two slowest, although I can't find an obvious contender for the sorting.
> heapsort (84x slower) […] I can't find an obvious contender for the sorting.
Use the built-in sort instead of hand-rolling your own? The built-in sort is not a heapsort and though I don't know what it was before the 2.3 "timsort" implementation, the essay mentions Python 2.7 so I would assume it's not talking about the old built-in sort either.
+1 - if you ever want macros or syntactic level manipulation in the python world, or just feel like doing something with s-expressions, hy is a great thing.
I like how code in both Python and Lisp can often look similar despite different syntaxes, different conventions, and different philosophies.
Here is a toy example of file I/O in Python 3:
with open('foo.txt', 'w') as f:
print('hello, world', file=f)
with open('foo.txt') as f:
print(f.readline())
Here is a similar example in Common Lisp:
(with-open-file (f "foo.txt" :direction :output :if-exists :supersede)
(format f "hello, world~%"))
(with-open-file (f "foo.txt")
(format t "~a~%" (read-line f)))
This example is a bit contrived to show the similarities. Real and idiomatic code may not look so strikingly similar. But similarities in concepts, constructs, and structure of code emerge in both languages. In fact the article mentions, "Take a Lisp program, indent it properly, and delete the opening parens at the start of lines and their matching close parens, and you end up with something that looks rather like a Python program."
> "Take a Lisp program, indent it properly, and delete the opening parens at the start of lines and their matching close parens, and you end up with something that looks rather like a Python program."
Sure, if you write Python in Lisp, but not if you actually take advantage of Lisp.
Well, technically, same for Python. I mean, you would rather write the Python snippet this way:
with open('foo.txt', 'w') as f:
f.write('hello world\n')
Using print for that doesn't bring much on the table and a newcomer reading the code would wonder why.
Plus really most IRL works just need:
Path('foo.txt').write_text('hello world\n')
Also you never really use readline(), since files are iterable, you generally just loop with for on it.
I don't think that's the point of the author. The point is that they look like enough if you remove the cruft, that you can make helpful associations to learn the one you don't know.
I stopped using python (2.7) a couple years ago once I learned CL. But—if you’re dealing with reading standard input incrementally there are differences between readline() and the interator when it comes to buffering. Or, at least, it was easier for me to get readline to work than it was to figure out how to configure the iterator correctly.
This, the whole Unicode mess and the fact that lisp allows you to write at the same level of abstraction (or greater) without sacrificing performance as much, led me to abandon Python for almost everything.
It depends. I generally use sbcl, unless I'm trying to do something with Cocoa, in which case I use either ccl or Lispworks CAPI. All my projects are open-source (MIT) and some of them are on quicklisp. I actually deploy applications by dumping an image and copying it to the right place.
I use emacs-with-evil mode + SLIME for developing applications... as I say, "the best implementation of vim is written in Emacs Lisp" or "evil-mode is the text editor for the Emacs operating system".
I think you missed /my/ point. What happens when you "remove the cruft" (parentheses) from the following:
(defun example ()
(ascertain that (+ 1 1) is 2)
(ascertain that (+ 1 1) is not zero)
(ascertain that 0 is not zero)
(ascertain that 0 is zero)
(ascertain that (+ 2 2) is 5)
(ascertain that (+ 2 2) is not 5)
(ascertain that (+ 2 2) is = 4.0)
(ascertain that (+ 1 1) is member of '(1 2 3))
(ascertain that 0 is a member of '(1 2 3))
(ascertain that pi is not a member of '(foo bar zot pi))
(ascertain that (error "blah") signals simple-error)
(ascertain that (error "blah") signals a serious-condition)
(ascertain that (error 'unexpected-result) signals an unexpected-result))
That example is not exemplar. If code appearance is the concern, and it is, we need only a single line of "ascertain". So the example cheats by massively repeating a single uninteresting use case. We need branching code, code blocks, function calls with a half dozen parameters...
That said, both will come out fine. What will not be apparent in the final product is that the Lisp version would have been formatted by a Lisp-aware editor, while the Python version will have been formatted by the programmer.
I don't know, I'm not a lisper. But it looks a lot like:
def example ():
assert 1 + 1 is 2
assert 1 + 1 is not zero
...
assert 1 + 1 in (1, 2, 3)
assert 0 in (1, 2, 3)
assert math.pi not in (foo, bar, zot, pi)
...
You've elided some cases, which I'm guessing don't fit Python's assert so well. And what are foo/bar/zot/pi in your translation? Python has "is"/"not"/"in" which retain some of the English-ness, so my example wasn't totally foreign, but...
You should also know that, unlike "assert" in Python, "ascertain" is not something defined by the Common Lisp language. It was defined by a Common Lisp user (me), just some 50-line macro that can be extended at will, to fit whatever clauses I would like it to support, in any way I see fit.
I'm glad that you took a stab at answering my question, but I hope you can see my point more clearly - that in Lisp you can taylor the language to suit your needs, and while sometimes Python may provide similar syntax, other times it may not. In fact many operators already existing in Common Lisp have no direct correspondence. You can also find tons more examples in the code of other people.
Anyway, hope it at least piqued your interest. Have a good day!
> You've elided some cases, which I'm guessing don't fit Python's assert so well.
I didn't get what it meant, so I couldn't really try to translate something I couldn't understand.
> It was defined by a Common Lisp user (me), just some 50-line macro that can be extended at will, to fit whatever clauses I would like it to support, in any way I see fit.
I understood that after looking it up on google and finding nothing. Which is one of the reason I dislike DSL. Usually their specs resides in the head of their dev, with the unit tests.
> I hope you can see my point more clearly
I do, it's just not the point of the author. You can make lisp whatever you want, but the basic syntax has similarities that are helpful for a transition. I don't see why this bother you. Nobody try to limit the quality of lisp.
> Anyway, hope it at least piqued your interest. Have a good day!
Oh it's on my list with Erlang, Haskell and Prolog. Next to the list of books to read, food to try and habits to drop.
Are they really any more similar to each other than to any other random language? E.g. Java:
try(Writer f = new PrintWriter("foo.txt")) {
f.println("hello, world");
}
try(BufferedReader f = new BufferedReader(new FileReader("foo.txt"))) {
println(f.readLine());
}
Lisp as an idea or language family was around in the 60s, Common Lisp not so much.
Common Lisp The Language was published in 1984, CLtL2 in 1990, and the ANSI standard in 1994. I believe the hyperspec (which is not the spec) was published in 1996 or so.
CL is neither as ahead of its time or of another, past time as you might think.
> Do other popular languages support a similar construct? C? C++? Perl?
C? No, though I don't really think of that as an actively maintained language. C++ and Perl achieve the same thing via RAII.
> Not that it takes anything away from Java. I think all languages are gradually trying to or discovering the approach the features and expressiveness of Lisp.
I think language design converges over time, alternating between expressive-but-unmaintainable and structured-but-too-strict but getting closer to the ideal as we advance. In many ways Lisp isn't a complete language design at all - rather macros are there for the user to finish the language themselves.
> The difference here is that you don't need to know the name of the types of all the things, nor write them.
I believe the latest version of Java would allow "var", fwiw.
> Or wrap an object in another object.
True. The java standard library's I/O functionality is quite low-level, perhaps excessively so. In practice there are libraries that give a more lightweight/high-level interface.
I just wish I could get a job writing LISP! I came pretty close with Clojure. I used Clojure on a (albeit throwaway) project that needed some batch processing at one job I had circa 2013. I was on my way! Then interest in Clojure died out. Groovy was #2 for me, but even that is dying out. I am doing Java 8 right now and not really enjoying it. Python would be better for me.
Methinks the enumeration of "Lisp's essential features" a tad short. 1. Coding JS quite a bit these days, I greatly miss every form returning a value. 2. Python's lambda is just sad, and GvR keeps threatening to remove even that. And people, please, once and for all, 3. those parentheses and where we put the operator are absolutely essential to the Lisp experience.
Re 2 - are you bothered by the fact that there is this thing that Python calls lambda, and it would be fine if it was called exprfn or something? Or do you think there is really a big problem with using def in the would-be-lambda's scope to give a temporary name for the function?
Python's lambda was pretty sad last I looked. Has it caught up with Lisp/Clojure's? And has the BDFL stopped trying to eliminate it altogether? I heard he regretted adding it and wanted to yank it at some point. The D in BDFL looks a lot bigger than the B.
Python's lambda is unchanged, and it is still included.
I have the impression that Guido regrets adding it because of the language-design-aesthetic wart - the recurring "why is it called lambda when it can only define single-expression functions?" "you can just use def in the scope just before use, if you need statements" "but then it's not anonymous!" "just use a temp name" dialog loop.
You know, I completely misapprehended your original query. No, it is fine that GvR called it "lambda". Had he called it experfn we would all translate mentally to "lambda" anyway. I am just sorry Mr. Norvig considers it equivalent to Lisp's, or does not consider it essential to Lispy-ness.
The situation is worse: Python doesn't support let. It's so bad that the Hy people aren't able to support let in their Lisp-skin-over-Python.
Python's handling of local variables, whereby assignment and binding are conflated, is perpetrating a harm to the education of neophytes.
It also means that "x = 42" can never be an "assignment to undefined variable x" error in Python, even when in fact it is that error: the programmer thinks there is an existing x being modified, but there isn't. Or more likely, the programmer thinks that an existing y is being modified which does exist, but made a typo and wrote x instead.
One distinction between Lisp and Python's docstrings that he didn't mention is
that in Lisp, you can (and it's normal to) give docstrings to variables; you
can then look these up later with DOCUMENTATION or however else you read
docstrings:
CL-USER> (documentation '*print-readably* 'variable)
"If true, all objects will be printed readably. If readable printing
is impossible, an error will be signalled. This overrides the value of
*PRINT-ESCAPE*."
CL-USER> (documentation '+ 'variable)
"the value of the most recent top level READ"
CL-USER> (defvar *variable* nil "a variable")
*VARIABLE*
CL-USER> (documentation '*variable* 'variable)
"a variable"
I wish all languages were Lisps. Code as data, partial functions, higher order functions, everything is an expression, and recursive evaluation. That's the basis, and I wish more languages had a similar foundation.
Now, the article details Python sharing a lot of features with Common Lisp, often just called Lisp. Which is true, but the foundation is very different.
So many surprising things are to be found on this series of tubes called "the internets", you wouldn't be surprised, not only to find such a baseless claim, but a whole video to support it. That's one of the four noble truths of the internets: "online forum content is always ridiculous."
Of course, I am not going to claim such a thing. I'd be reasonable and claim that Python is a Lisp, because Python actually is the compiler inside CMUCL.
Okay, I certainly don't want to start a language war, so let me be kind. There is one legitimate reason to switch from Lisp to Python: The number of packages and extensions. Python really has more than just batteries included, it's probably the language with the most available libraries after C++.
Still, switching from Lisp to Python is bound to be painful...
- you use softwares that are scriptable in Python (SIG, Blender, etc)
- you write a lot of glue code. That pretty much Python raison de vivre.
- you do a lot of data analysis manually. Pandas is the new excel, and jupyter the new matlab.
- you do a lot of sysadmin. Scripting is just easier in a dynamic language.
- you do a lot of CRUD websites. You just can't beat the frameworks from this language for this kind of things. They do most of the work for you, and do security better than you do.
- you want to integrate new members in your team faster. Python is easier to learn than lisp.
- you are coding a GUI. With kivy you can target desktop and mobile with one code base, and some skins are pretty (https://imgur.com/a/IjM0XGW). With QT you can do powerful things on the desktop. With wx you can do simple GUI simply.
- you have a lot of different kinds of task at hand, and don't want to have too many different languages in your stack. Python is never the best language at anything, but it's a damn good language for most things, so it makes it a versatile toolbox.
> - you want to integrate new members in your team faster. Python is easier to learn than lisp.
Heh, I listed Python in my resume and got this as my first job (after working at my local college) and I learned it on the job (I had used Python before, but nothing major yet) and I gotta say, not only is it easy to pick up if you know other languages, it's fun to experiment with if you do know other languages!
I have only played with Clojure and Racket the most on the other hand, I appreciate them and would love to learn more but I get more done with Python in shorter spans of time.
> - you want to integrate new members in your team faster. Python is easier to learn than lisp.
I'm not so sure on this point.
I've been writing Python for just over a decade now, with a year or so of Ruby thrown in for good measure. At a previous job I was asked to implement an authentication service in Clojure. It took me longer to understand the Clojure ecosystem than to learn to actually write the code. In ~3 weeks I went from having never seen Clojure to having a complete (if minimal) application that authenticated users against third parties via OAuth and issued JWTs.
I'd agree that it would be much easier to onboard junior-level developers to a project that's written in Python (or any similar language), but if you're targeting more senior-level people any modern language isn't really going to be a significant barrier.
That's especially true for lisps - there just isn't a lot of language structure to learn. Python is a "shallow" language in my opinion - there are only a few layers of complexity between a newbie and complete understanding of a language feature. Lisps are shallower still.
One thing I don't understand here why somebody needs to switch to Python and forget other languages? Sometimes I too hack something fast with Python, but still write lots of Rust and Clojure. Then if I need Python, it is very easy to just write some and get things done.
That's not how it happens. Unless it's impossible (ex, you target a credit card), you usually starts with Python because, if you know it, that's the easiest option for a POC. Then you look if for this project, it limited you in some way.
When it does, you use another tech. E.G, you needed something to consume less RAM, or you target the browser, or you want an small APK, you need multi-core AND cheap memory sharing, whatever...
But the thing is, short of some very specific constraints, Python is good enough for a lot of things and so we don't "forget" about other languages, we just end up not needing them more often than not.
That's a picture for my blog (well actually the related twitter account), which essentially deals with Python and porn. I was not going to make a new screen capture just for HN.
I agree - I hadn't looked at it in a couple of years; it looks much more native now. I'll have to spend some time to take a look again soon.
I also had BeeWare hit my radar again this year at PyCon. The last time I looked it was "just" an IDE, which I had no need for. It turns out they've basically written an entire cross-platform GUI framework since then, and based on my brief conversation with their representatives, it looks to be pretty damned handy. In particular, they mentioned that a minimal iOS or Android app ends up being ~5MB - Kivy's big problem when I last looked at it was that the resultant applications were huge.
Somebody is underrating the Common Lisp ecosystem, me thinks. There are much fewer libs than in Python, of course, but, most likely, everything you need you would find in CL, and some of those libs are very high quality.
>There is one legitimate reason to switch from Lisp to Python: The number of packages and extensions. Python really has more than just batteries included
Which you can "steal" by using them from Common Lisp. By using the lisp library called "burgled-batteries".
But still, as pointed below, the Java ecosystem is even bigger, and you can easily leverage by running Common Lisp on the JVM (using Armed Bear Common Lisp).
And then there is Clojure, a lisp-like language that is weaved together with the JVM and thus with very easy ways to interoperate with the JVM.
What if you're the author of a famous textbook and you find that your pseudocode reads more like Python than Lisp and that students on average prefer Python? Is that a legitimate reason? If not, you should probably send a nasty email to Norvig explaining his illegitimacy.
No painful switching is intended; for Norvig's purposes there are Lisp programmers taking an AI course and Python programmers taking an AI course, and both groups should be able to follow examples in a language they know, without stumbling.
Only their teachers need to adjust to the updated code examples in Norvig's updated book, and this summary is a very nice introduction to the main differences between two basically similar languages.
When and whether students should learn Lisp, Python, neither, or both is an entirely different issue.
As with programming languages, natural languages aren't uniform. So you might interpret "one reason" to mean only one or, since "only" wasn't said, give some leeway, assume good faith, and take it as "at least one, and that maybe enough", "primary", or whatever. It's underspecified, as the linguists say.
The statement could have been made more neutral by stating that it was a preference:
> I prefer programming in Lisp, but the packages available for Python makes me a lot more productive. That alone is enough for me to choose Python. I still miss Lisp though.
Language wars are started because people talk about their preferences as an absolute truth (and other people disagree with the presented absolute truth), and you don’t avoid them by starting with “I don’t want to start a language war” while continuing talking in the same way.
If you look at the other replies you see what typically happens: someone mentioned that Lisp does also have libraries, someone mentioned that there are other reasons to choose Python, someone mentioned that the article has a different focus (teaching, not writing). Instead of a comment thread where people talk about their experiences we have a thread where people point back at the OP and loudly complain “no, but see, you are wrong, because of x”. We even have a case where the OP is getting annoyed because someone assumed he didn’t know about Norvig. Seriously, this is exactly what happens when you write in such a style.
This comment alone will make someone annoyed because there are plenty of people who have used both Lisp and Python and (guess what?) prefers Python:
> Still, switching from Lisp to Python is bound to be painful...
Java's library is like Barbie - it has everything. For a standard library, it is insanely complete.
I was going to say that C probably had more complete non-standard libraries than Java. But, on reflection, for the price of writing a JNI wrapper, Java can use all those C libraries, so Java gets the superset - its own plus C's libraries. In that environment, it is obviously impossible for C to win.
There are some libraries I maintain in Python which provide services not available as open-source in Java (or any other free language, as far as my Google searching can tell).
They're related to an archaic file format that is surprisingly popular, though still esoteric.
Just for your info. Norvig wrote the "Paradigms of AI Programming: Case Studies in Common Lisp" book, so I would say that he is pretty knowledgeable about his stuff.
Jesus Christ, could there be more condescending commentaries than yours or that of some other replies? You can safely assume that I know who Peter Norvig is, so keep it civil.
His post illustrates how many programming tasks have gone from problem solving to lego-brick programming, where library is piled upon library and each of them is incomplete and contains piles of bugs. What could possibly be wrong with that approach?
Just like Norvig, I don't claim that Python is bad per se or anything like that. All I've said is that it's painful to go from CL to Python in terms of the general features of the languages (not their tooling). If you have never done this transition, have never programmed sufficiently large programs in CL and Python, please don't comment on it.
>His post illustrates how many programming tasks have gone from problem solving to lego-brick programming, where library is piled upon library and each of them is incomplete and contains piles of bugs. What could possibly be wrong with that approach?
Compared to problem solving which doesn't use "lego bricks" and re-makes the wheel?
Someone must have been going against best practices and remaking the wheel because I see different types of wheels everywhere I look. Shopping carts have a certain type of wheel, skateboards have a certain type of wheel, longboards have a certain type of wheel, rollerblades have a certain type of wheel, bikes have a certain type of wheel, planes have a certain type of wheel, cars, trucks, RC vehicles, toys, etc, etc, etc, etc...
This seems to be a good excuse to share this great story:
> At ILC 2002 former Lisp giant now Python advocate Peter Norvig was for some reason allowed to give the keynote address like Martin Luther leading Easter Sunday mass at the Vatican and pitching Protestantism because in his talk Peter bravely repeated his claim that Python is a Lisp.
> When he finished Peter took questions and to my surprise called first on the rumpled old guy who had wandered in just before the talk began and eased himself into a chair just across the aisle from me and a few rows up.
> This guy had wild white hair and a scraggly white beard and looked hopelessly lost as if he had gotten separated from the tour group and wandered in mostly to rest his feet and just a little to see what we were all up to. My first thought was that he would be terribly disappointed by our bizarre topic and my second thought was that he would be about the right age, Stanford is just down the road, I think he is still at Stanford — could it be?
> ‘Yes, John?’ Peter said.
> I won’t pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.
> ‘No, John, it can’t,’ said Peter and nothing more, graciously assenting to the professor’s critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.
from http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-wh...
Strange that six years into my Lisp-hood I could not recognize the great one. Or the great beard: https://www.independent.co.uk/news/obituaries/john-mccarthy-... It never changed!
>Strange that six years into my Lisp-hood I could not recognize the great one.
God disguises in mysterious ways...
RIP John McCarthy
BTW, Python can do that [1], it's just not very recommended because the ast is not stable between versions (and maybe even implementations? not sure about that)
[1] https://docs.python.org/3.6/library/ast.html
The question said gracefully. Norvig, being intellectually honest and knowing the comparison to Lisp, answered simply no.
Oh, I conveniently skipped over that when reading. I'm definitely not claiming it's graceful of even practical.
Some points:
- Yes, the original publication year was 2000. I've added that to the file.
- @HelloNurse: You've got the key point. I provided Lisp code to teach AI; but my goal was to teach AI, not Lisp. As more schools and students were familiar with Python and not with Lisp, I needed to make the switch to keep teaching AI effectively.
- @jonathanstrange: Yes, "batteries included" is key to Python; there is some pain in doing any change; this page attempted to alleviate some of the pain.
- @rauhl: "in the silence a thousand words were said". I'm not sure what words are in that silence. But to me, the words are: Lisp and Python are different ecosystems with different customs. The Lisp community likes to solve lots of problems with macros. The Python community doesn't. For 95% of the usages, neither approach is better than the other, they are just different. For example, in Python, `with` is a statement, and you define custom classes for each usage you think of. In Lisp, you define a macro like `with-open-file` for each usage. The end result in usability and efficiency is similar. In Lisp, you often define macros for custom data types, e.g.
In Python you use a combination of built-in data types (like dicts), custom classes, and ad-hoc parsers of text. Again, the approach is different, but readability and efficiency is similar.It is certainly true that if you want to define, say, a mock Prolog system, it is easier to do it in Lisp with macros than in Python, where you would need to deal with the far messier `ast.parse` module. Is that where the silent words were? For me the words would be "Lisp is a much better choice if your primary goal is defining a full-blown domain specific language. For most other programming tasks, the two languages offer similar functionality in different way."
>The Lisp community likes to solve lots of problems with macros. The Python community doesn't. For 95% of the usages, neither approach is better than the other, they are just different
I'd like to interject for a moment.
As a software engineer with some years of using Python for financial software, and afterwards switching to Common Lisp, i diverge. In my opinion, Lisp macros make all the difference in the world, and I really miss them when using a language that doesn't support them. Sure, anything can be implemented on most languages including Python, but there is a big difference in the maintainability and clearness of the resulting code, as well as in effort.
So, are you abandoning us, Peter? If not nil, i will signal 'tears and no handler-bind will recover me from this condition. (joking of course)
Anyways, thanks for PAIP, it will always be in my heart.
(Note for the uninitiated: PAIP stands for "Paradigms of Artificial Intelligence: Case Studies in Common Unpython", a classic book by Peter Norvig who is part of the big PPP of Lisp literature: Paul (Graham), Peter (Norvig), and Peter (Seibel))
"The Lisp community likes to solve lots of problems with macros" sounds like "Mozart likes to use a lot of notes". I do not like to use macros, I like to hide boilerplate so the semantics stand out. And so I can type less. I do not like typing. But Siri can stuff it. I digress.
I gave this some thought. First, the silence was perfect and it was a privilege to witness that moment between you two. As for the thousand words, they were the hundred moves we do not see in a grandmaster draw after a half dozen moves from a well-understood opening and a handshake. John had by implication stood up for homoiconicity as essential. You conceded Python lacked the quality, leaving intact your equivalence argument built in part on other Python features and in part on missing things not mattering. Nothing more was needed.
But that is just my poor reconstruction of the moment. The silence was better.
I'm just a numerics person but I'd love to hear your input about relational/declarative/Prolog-like programming in Python in the following situation: if the working language doesn't have to be anything resembling Prolog, but can instead be a Python internal DSL(DSL-lite?), and further if, say, one wants to do unification only over (what amounts to) some numeric data, then Python's operator overloading can supply all the heavy lifting one needs - allowing one to build up a representation of the (computational) expression tree via overloading and then "compile" that guy into lists of relational function closures which await environments (design spaces). This is of course a really specific case, but as a "mechanical-type" engineer doing a thesis on automated geometry generation, and needing a pre-processor to quickly pair down my design space to something nice given a design specification on the fly, I've found python + unification + numerics (especially interval arithmetic - where the design space is basically closed...) to be a really useful (and work saving) combination! The end result feels like magic to me anyway. But lots of computing feels like magic to a numerical programmer - that's what makes it so fun to branch out - and Python makes that as easy as possible. (Thanks for all of your writings which help the novice do this kind of thing!)
I should summarize that long winded statement in case anyone tries to read it: eh hem... This one time, for this one specific case, off in a totally unrelated field of engineering, Python made for a pretty fair Prolog substitute for one kid's dissertation.
Was McCarthy even thinking of macros when he locked onto code as data? Or was he thinking code generation in pursuit of AI?Asking, do not know. I know macros are a great example of code=data, but I once had a ball using the AllegroStore CLOS database and a homebrewed DB synch layer to handle remote distribution and update of forms and the code to validate them in a clinical drug trial management context, where forms and their validation code are forever changing. Basically, an intractable software maintenance problem just disappeared. That's always fun. http://smuglispweeny.blogspot.com/2008/03/my-biggest-lisp-pr...
He was not, macro libraries like defmacro and define-syntax were later addition to lisp. Well before formal macro systems were implemented, code-as-data was particularly useful for implementing the eval function in Lisp (the Lisp 1.5 implementation takes up less than a page), which greatly simplified the process of implementing compilers and interpreters.
It's worth noting that one of the main pain points mention of Python was that it was 2-100 times slower (vs 1-2x slower for Lisp). The slowest elements of Python compared to C++ were matrix multiplication (278x slower), array access (141x slower) and heapsort (84x slower). NumPy solves the two slowest, although I can't find an obvious contender for the sorting.
> heapsort (84x slower) […] I can't find an obvious contender for the sorting.
Use the built-in sort instead of hand-rolling your own? The built-in sort is not a heapsort and though I don't know what it was before the 2.3 "timsort" implementation, the essay mentions Python 2.7 so I would assume it's not talking about the old built-in sort either.
This article predates Python 2.7 by 10 years.
The link to 2.7 was probably added or edited many years later.
Numpy does sorting too.
And what about hylang.org ? I'm surprised it's not even mentioned here : nice lispy syntax with all the python packages = best of both worlds :)
The Norvig’ article is from 2000. (Hy is from 2013.)
+1 - if you ever want macros or syntactic level manipulation in the python world, or just feel like doing something with s-expressions, hy is a great thing.
I like how code in both Python and Lisp can often look similar despite different syntaxes, different conventions, and different philosophies.
Here is a toy example of file I/O in Python 3:
Here is a similar example in Common Lisp: This example is a bit contrived to show the similarities. Real and idiomatic code may not look so strikingly similar. But similarities in concepts, constructs, and structure of code emerge in both languages. In fact the article mentions, "Take a Lisp program, indent it properly, and delete the opening parens at the start of lines and their matching close parens, and you end up with something that looks rather like a Python program."> "Take a Lisp program, indent it properly, and delete the opening parens at the start of lines and their matching close parens, and you end up with something that looks rather like a Python program."
Sure, if you write Python in Lisp, but not if you actually take advantage of Lisp.
Well, technically, same for Python. I mean, you would rather write the Python snippet this way:
Using print for that doesn't bring much on the table and a newcomer reading the code would wonder why.Plus really most IRL works just need:
Also you never really use readline(), since files are iterable, you generally just loop with for on it.I don't think that's the point of the author. The point is that they look like enough if you remove the cruft, that you can make helpful associations to learn the one you don't know.
I stopped using python (2.7) a couple years ago once I learned CL. But—if you’re dealing with reading standard input incrementally there are differences between readline() and the interator when it comes to buffering. Or, at least, it was easier for me to get readline to work than it was to figure out how to configure the iterator correctly.
This, the whole Unicode mess and the fact that lisp allows you to write at the same level of abstraction (or greater) without sacrificing performance as much, led me to abandon Python for almost everything.
What is your preferred CL implementation and development environment?
How do you distribute your programs/applications? As Lisp source code or as a binary generated by dumping core or some such technique?
It depends. I generally use sbcl, unless I'm trying to do something with Cocoa, in which case I use either ccl or Lispworks CAPI. All my projects are open-source (MIT) and some of them are on quicklisp. I actually deploy applications by dumping an image and copying it to the right place.
I use emacs-with-evil mode + SLIME for developing applications... as I say, "the best implementation of vim is written in Emacs Lisp" or "evil-mode is the text editor for the Emacs operating system".
>How do you distribute your programs/applications? As Lisp source code or as a binary generated by dumping core or some such technique?
In any way you like including creating executable files.
What does this have to do with the above comment ?
> Also you never really use readline(), since files are iterable
I think you missed /my/ point. What happens when you "remove the cruft" (parentheses) from the following:
Does it look like Python?That example is not exemplar. If code appearance is the concern, and it is, we need only a single line of "ascertain". So the example cheats by massively repeating a single uninteresting use case. We need branching code, code blocks, function calls with a half dozen parameters...
That said, both will come out fine. What will not be apparent in the final product is that the Lisp version would have been formatted by a Lisp-aware editor, while the Python version will have been formatted by the programmer.
I don't know, I'm not a lisper. But it looks a lot like:
You've elided some cases, which I'm guessing don't fit Python's assert so well. And what are foo/bar/zot/pi in your translation? Python has "is"/"not"/"in" which retain some of the English-ness, so my example wasn't totally foreign, but...
You should also know that, unlike "assert" in Python, "ascertain" is not something defined by the Common Lisp language. It was defined by a Common Lisp user (me), just some 50-line macro that can be extended at will, to fit whatever clauses I would like it to support, in any way I see fit.
I'm glad that you took a stab at answering my question, but I hope you can see my point more clearly - that in Lisp you can taylor the language to suit your needs, and while sometimes Python may provide similar syntax, other times it may not. In fact many operators already existing in Common Lisp have no direct correspondence. You can also find tons more examples in the code of other people.
Anyway, hope it at least piqued your interest. Have a good day!
> You've elided some cases, which I'm guessing don't fit Python's assert so well.
I didn't get what it meant, so I couldn't really try to translate something I couldn't understand.
> It was defined by a Common Lisp user (me), just some 50-line macro that can be extended at will, to fit whatever clauses I would like it to support, in any way I see fit.
I understood that after looking it up on google and finding nothing. Which is one of the reason I dislike DSL. Usually their specs resides in the head of their dev, with the unit tests.
> I hope you can see my point more clearly
I do, it's just not the point of the author. You can make lisp whatever you want, but the basic syntax has similarities that are helpful for a transition. I don't see why this bother you. Nobody try to limit the quality of lisp.
> Anyway, hope it at least piqued your interest. Have a good day!
Oh it's on my list with Erlang, Haskell and Prolog. Next to the list of books to read, food to try and habits to drop.
And you too.
Are they really any more similar to each other than to any other random language? E.g. Java:
Do other popular languages support a similar construct? C? C++? Perl?
The Java try-with-resources was introduced in Java 7 (2011).
The Python with statement was introduced in Python 2.5 (2006).
The Lisp with-open-file has been in Common Lisp Hyperspec for a long time (1960s?).
Not that it takes anything away from Java. I think all languages are gradually converging to the features of Lisp.
Lisp as an idea or language family was around in the 60s, Common Lisp not so much.
Common Lisp The Language was published in 1984, CLtL2 in 1990, and the ANSI standard in 1994. I believe the hyperspec (which is not the spec) was published in 1996 or so.
CL is neither as ahead of its time or of another, past time as you might think.
> Do other popular languages support a similar construct? C? C++? Perl?
C? No, though I don't really think of that as an actively maintained language. C++ and Perl achieve the same thing via RAII.
> Not that it takes anything away from Java. I think all languages are gradually trying to or discovering the approach the features and expressiveness of Lisp.
I think language design converges over time, alternating between expressive-but-unmaintainable and structured-but-too-strict but getting closer to the ideal as we advance. In many ways Lisp isn't a complete language design at all - rather macros are there for the user to finish the language themselves.
> I don't really think of that as an actively maintained language.
Oh, were it only so! It's an actively diddled language.
> C? No, though I don't really think of that as an actively maintained language.
Why would you think that? Work on the C standard is ongoing: http://www.open-std.org/jtc1/sc22/wg14/
Just that I hadn't heard of a new release since 1999, shrug.
C# has the "using" statement, which is effectively the same construct. F# calls it "use".
The difference here is that you don't need to know the name of the types of all the things, nor write them. Or wrap an object in another object.
> The difference here is that you don't need to know the name of the types of all the things, nor write them.
I believe the latest version of Java would allow "var", fwiw.
> Or wrap an object in another object.
True. The java standard library's I/O functionality is quite low-level, perhaps excessively so. In practice there are libraries that give a more lightweight/high-level interface.
> I believe the latest version of Java would allow "var", fwiw.
While Python gained type hinting. It's funny how in the end stuff converge.
LISP is still superior, however.
I just wish I could get a job writing LISP! I came pretty close with Clojure. I used Clojure on a (albeit throwaway) project that needed some batch processing at one job I had circa 2013. I was on my way! Then interest in Clojure died out. Groovy was #2 for me, but even that is dying out. I am doing Java 8 right now and not really enjoying it. Python would be better for me.
Methinks the enumeration of "Lisp's essential features" a tad short. 1. Coding JS quite a bit these days, I greatly miss every form returning a value. 2. Python's lambda is just sad, and GvR keeps threatening to remove even that. And people, please, once and for all, 3. those parentheses and where we put the operator are absolutely essential to the Lisp experience.
Re 2 - are you bothered by the fact that there is this thing that Python calls lambda, and it would be fine if it was called exprfn or something? Or do you think there is really a big problem with using def in the would-be-lambda's scope to give a temporary name for the function?
Python's lambda was pretty sad last I looked. Has it caught up with Lisp/Clojure's? And has the BDFL stopped trying to eliminate it altogether? I heard he regretted adding it and wanted to yank it at some point. The D in BDFL looks a lot bigger than the B.
Python's lambda is unchanged, and it is still included.
I have the impression that Guido regrets adding it because of the language-design-aesthetic wart - the recurring "why is it called lambda when it can only define single-expression functions?" "you can just use def in the scope just before use, if you need statements" "but then it's not anonymous!" "just use a temp name" dialog loop.
You know, I completely misapprehended your original query. No, it is fine that GvR called it "lambda". Had he called it experfn we would all translate mentally to "lambda" anyway. I am just sorry Mr. Norvig considers it equivalent to Lisp's, or does not consider it essential to Lispy-ness.
The situation is worse: Python doesn't support let. It's so bad that the Hy people aren't able to support let in their Lisp-skin-over-Python.
Python's handling of local variables, whereby assignment and binding are conflated, is perpetrating a harm to the education of neophytes.
It also means that "x = 42" can never be an "assignment to undefined variable x" error in Python, even when in fact it is that error: the programmer thinks there is an existing x being modified, but there isn't. Or more likely, the programmer thinks that an existing y is being modified which does exist, but made a typo and wrote x instead.
4. Lisp indents itself. This alone speaks volumes.
That said, credit where due, Python code does look great.
One distinction between Lisp and Python's docstrings that he didn't mention is that in Lisp, you can (and it's normal to) give docstrings to variables; you can then look these up later with DOCUMENTATION or however else you read docstrings:
I wish all languages were Lisps. Code as data, partial functions, higher order functions, everything is an expression, and recursive evaluation. That's the basis, and I wish more languages had a similar foundation.
Now, the article details Python sharing a lot of features with Common Lisp, often just called Lisp. Which is true, but the foundation is very different.
Would appreciate if the reverse (Lisp for python programmer) exists.
Second sentence:
> Although it wasn't my intent, Python programers have told me this page has helped them learn Lisp
obviously the lazy me didnt click through the article. thanks!
Mentioned elsewhere in the thread but take a look at Hy Lang, a lisp that compiles down to Python.
I will consider writing such a guide... not a bad idea, really...
Are we going to discover that Lisp is really a Python?
His Kennyness,
So many surprising things are to be found on this series of tubes called "the internets", you wouldn't be surprised, not only to find such a baseless claim, but a whole video to support it. That's one of the four noble truths of the internets: "online forum content is always ridiculous."
Of course, I am not going to claim such a thing. I'd be reasonable and claim that Python is a Lisp, because Python actually is the compiler inside CMUCL.
I was reading the Lisp code and thinking "why wouldn't this evaluate to (S)?" And, of course, it does.
The invocation of the lisp program should be:
Okay, I certainly don't want to start a language war, so let me be kind. There is one legitimate reason to switch from Lisp to Python: The number of packages and extensions. Python really has more than just batteries included, it's probably the language with the most available libraries after C++.
Still, switching from Lisp to Python is bound to be painful...
Some other reasons:
- you use softwares that are scriptable in Python (SIG, Blender, etc)
- you write a lot of glue code. That pretty much Python raison de vivre.
- you do a lot of data analysis manually. Pandas is the new excel, and jupyter the new matlab.
- you do a lot of sysadmin. Scripting is just easier in a dynamic language.
- you do a lot of CRUD websites. You just can't beat the frameworks from this language for this kind of things. They do most of the work for you, and do security better than you do.
- you want to integrate new members in your team faster. Python is easier to learn than lisp.
- you are coding a GUI. With kivy you can target desktop and mobile with one code base, and some skins are pretty (https://imgur.com/a/IjM0XGW). With QT you can do powerful things on the desktop. With wx you can do simple GUI simply.
- you have a lot of different kinds of task at hand, and don't want to have too many different languages in your stack. Python is never the best language at anything, but it's a damn good language for most things, so it makes it a versatile toolbox.
> - you want to integrate new members in your team faster. Python is easier to learn than lisp.
Heh, I listed Python in my resume and got this as my first job (after working at my local college) and I learned it on the job (I had used Python before, but nothing major yet) and I gotta say, not only is it easy to pick up if you know other languages, it's fun to experiment with if you do know other languages!
I have only played with Clojure and Racket the most on the other hand, I appreciate them and would love to learn more but I get more done with Python in shorter spans of time.
> - you want to integrate new members in your team faster. Python is easier to learn than lisp.
I'm not so sure on this point.
I've been writing Python for just over a decade now, with a year or so of Ruby thrown in for good measure. At a previous job I was asked to implement an authentication service in Clojure. It took me longer to understand the Clojure ecosystem than to learn to actually write the code. In ~3 weeks I went from having never seen Clojure to having a complete (if minimal) application that authenticated users against third parties via OAuth and issued JWTs.
I'd agree that it would be much easier to onboard junior-level developers to a project that's written in Python (or any similar language), but if you're targeting more senior-level people any modern language isn't really going to be a significant barrier.
That's especially true for lisps - there just isn't a lot of language structure to learn. Python is a "shallow" language in my opinion - there are only a few layers of complexity between a newbie and complete understanding of a language feature. Lisps are shallower still.
>
One thing I don't understand here why somebody needs to switch to Python and forget other languages? Sometimes I too hack something fast with Python, but still write lots of Rust and Clojure. Then if I need Python, it is very easy to just write some and get things done.
That's not how it happens. Unless it's impossible (ex, you target a credit card), you usually starts with Python because, if you know it, that's the easiest option for a POC. Then you look if for this project, it limited you in some way.
When it does, you use another tech. E.G, you needed something to consume less RAM, or you target the browser, or you want an small APK, you need multi-core AND cheap memory sharing, whatever...
But the thing is, short of some very specific constraints, Python is good enough for a lot of things and so we don't "forget" about other languages, we just end up not needing them more often than not.
What I don't understand is the necessity of having the video of the naked pirates of the caribbean guy in the corner.
That's a picture for my blog (well actually the related twitter account), which essentially deals with Python and porn. I was not going to make a new screen capture just for HN.
Wow, kivy's material theme improved a LOT since I last saw it a few years ago.
I agree - I hadn't looked at it in a couple of years; it looks much more native now. I'll have to spend some time to take a look again soon.
I also had BeeWare hit my radar again this year at PyCon. The last time I looked it was "just" an IDE, which I had no need for. It turns out they've basically written an entire cross-platform GUI framework since then, and based on my brief conversation with their representatives, it looks to be pretty damned handy. In particular, they mentioned that a minimal iOS or Android app ends up being ~5MB - Kivy's big problem when I last looked at it was that the resultant applications were huge.
Somebody is underrating the Common Lisp ecosystem, me thinks. There are much fewer libs than in Python, of course, but, most likely, everything you need you would find in CL, and some of those libs are very high quality.
>There is one legitimate reason to switch from Lisp to Python: The number of packages and extensions. Python really has more than just batteries included
Which you can "steal" by using them from Common Lisp. By using the lisp library called "burgled-batteries".
But still, as pointed below, the Java ecosystem is even bigger, and you can easily leverage by running Common Lisp on the JVM (using Armed Bear Common Lisp).
And then there is Clojure, a lisp-like language that is weaved together with the JVM and thus with very easy ways to interoperate with the JVM.
I know this comment is rather inane, but rarely have I seen a library name so fitting yet so humorous as "burgled-batteries".
What if you're the author of a famous textbook and you find that your pseudocode reads more like Python than Lisp and that students on average prefer Python? Is that a legitimate reason? If not, you should probably send a nasty email to Norvig explaining his illegitimacy.
No painful switching is intended; for Norvig's purposes there are Lisp programmers taking an AI course and Python programmers taking an AI course, and both groups should be able to follow examples in a language they know, without stumbling.
Only their teachers need to adjust to the updated code examples in Norvig's updated book, and this summary is a very nice introduction to the main differences between two basically similar languages.
When and whether students should learn Lisp, Python, neither, or both is an entirely different issue.
I'm not so sure about that. Clojure is a lisp, and has full access to the Java ecosystem.
Also ABCL lets you Common Lisp over the JVM and have full access to the Java ecosystem.
If you don't want to start a language war, maybe you shouldn't present subjective opinion as facts?
As with programming languages, natural languages aren't uniform. So you might interpret "one reason" to mean only one or, since "only" wasn't said, give some leeway, assume good faith, and take it as "at least one, and that maybe enough", "primary", or whatever. It's underspecified, as the linguists say.
The statement could have been made more neutral by stating that it was a preference:
> I prefer programming in Lisp, but the packages available for Python makes me a lot more productive. That alone is enough for me to choose Python. I still miss Lisp though.
Language wars are started because people talk about their preferences as an absolute truth (and other people disagree with the presented absolute truth), and you don’t avoid them by starting with “I don’t want to start a language war” while continuing talking in the same way.
If you look at the other replies you see what typically happens: someone mentioned that Lisp does also have libraries, someone mentioned that there are other reasons to choose Python, someone mentioned that the article has a different focus (teaching, not writing). Instead of a comment thread where people talk about their experiences we have a thread where people point back at the OP and loudly complain “no, but see, you are wrong, because of x”. We even have a case where the OP is getting annoyed because someone assumed he didn’t know about Norvig. Seriously, this is exactly what happens when you write in such a style.
This comment alone will make someone annoyed because there are plenty of people who have used both Lisp and Python and (guess what?) prefers Python:
> Still, switching from Lisp to Python is bound to be painful...
Java followed by .NET, beats both reagarding available libraries, unless you mean only open source ones.
And JavaScript with their one liner packages probably beats all.
Python still misses having a proper mix of AOT/JIT compilers as standard toolchain, like Lisp does.
Java's library is like Barbie - it has everything. For a standard library, it is insanely complete.
I was going to say that C probably had more complete non-standard libraries than Java. But, on reflection, for the price of writing a JNI wrapper, Java can use all those C libraries, so Java gets the superset - its own plus C's libraries. In that environment, it is obviously impossible for C to win.
There are some libraries I maintain in Python which provide services not available as open-source in Java (or any other free language, as far as my Google searching can tell).
They're related to an archaic file format that is surprisingly popular, though still esoteric.
Lisp can talk to C/C++. And do not forget Clojure. That interops with Java.
Just for your info. Norvig wrote the "Paradigms of AI Programming: Case Studies in Common Lisp" book, so I would say that he is pretty knowledgeable about his stuff.
Jesus Christ, could there be more condescending commentaries than yours or that of some other replies? You can safely assume that I know who Peter Norvig is, so keep it civil.
His post illustrates how many programming tasks have gone from problem solving to lego-brick programming, where library is piled upon library and each of them is incomplete and contains piles of bugs. What could possibly be wrong with that approach?
Just like Norvig, I don't claim that Python is bad per se or anything like that. All I've said is that it's painful to go from CL to Python in terms of the general features of the languages (not their tooling). If you have never done this transition, have never programmed sufficiently large programs in CL and Python, please don't comment on it.
>His post illustrates how many programming tasks have gone from problem solving to lego-brick programming, where library is piled upon library and each of them is incomplete and contains piles of bugs. What could possibly be wrong with that approach?
Compared to problem solving which doesn't use "lego bricks" and re-makes the wheel?
Someone must have been going against best practices and remaking the wheel because I see different types of wheels everywhere I look. Shopping carts have a certain type of wheel, skateboards have a certain type of wheel, longboards have a certain type of wheel, rollerblades have a certain type of wheel, bikes have a certain type of wheel, planes have a certain type of wheel, cars, trucks, RC vehicles, toys, etc, etc, etc, etc...
In programming, the wheel gets remade multiple times for the same category of vehicle (e.g. skateboard).
And instead of a factory making it to recognized standards across that class of vehicle, it's an ad-hoc design for a particular vehicle.
Often it's also square.
Brick-related xkcd: https://xkcd.com/1988/
Haha! The modern developer, right there!
> All I've said is that it's painful to go from CL to Python in terms of the general features of the languages (not their tooling).
As a programmer with full experience in both languages, I agree with this in 200%.
Please don’t swear. Please. There are no victories down this spiral. Only barren soil.
I'm sorry, I honestly didn't realize that this counts as an instance of swearing in certain language communities. My apologies!
Obligatory: "Dude, where's my car?"
Since the Japanese translation was done in 2002, I doubt this article originated in 2008 as is currently mentioned.
[1] http://www.unixuser.org/~euske/doc/python/python-lisp-j.html
https://web.archive.org/web/*/http://norvig.com/python-lisp.... has 2000 so we can go with that.
(2000) Sadly there is no date at all in the article.