Bob Rogers wrote: > I was once told (by a fellow Lisp refugee) that Python is the > favorite "new" language of Lisp programmers because it has similar > semantics.
Sure, Paul Graham compares Python to Lisp in several of his essays. http://paulgraham.com/icad.html If you look at these languages in order, Java, Perl, Python, you notice an interesting pattern. At least, you notice this pattern if you are a Lisp hacker. Each one is progressively more like Lisp. Python copies even features that many Lisp hackers consider to be mistakes. You could translate simple Lisp programs into Python line for line. It's 2002, and programming languages have almost caught up with 1958. He doesn't seem to be bothered by the conflict you point out, but does admit: As an illustration of what I mean about the relative power of programming languages, consider the following problem. ... If you try to translate the Lisp/Perl/Smalltalk/Javascript code into Python you run into some limitations. Because Python doesn't fully support lexical variables, you have to create a data structure to hold the value of n. And although Python does have a function data type, there is no literal representation for one (unless the body is only a single expression) so you need to create a named function to return. He then speculates that Python might one day evolve to support a more elegant form, but... Ben Tilly wrote: > Ironically Guido has very much NOT drunk of the functional programming > wine. To be specific, he dislikes anonymous functions and closures, > which is one of the reasons that Python's support for them is not > great. (And he removed some of the support they have.) Right, he mentions that in the podcast, so it seems unlike Python will go in that direction. Paul Graham concludes his point with: In the rivalry between Perl and Python, the claim of the Python hackers seems to be that that Python is a more elegant alternative to Perl, but what this case shows is that power is the ultimate elegance: the Perl program is simpler (has fewer elements), even if the syntax is a bit uglier. In another essay he addresses my original question: http://paulgraham.com/pypar.html essentially confirming my conclusion. (I'd read this essay a year ago, but forgot the specifics.) A friend of mine who knows nearly all the widely used languages uses Python for most of his projects. He says the main reason is that he likes the way source code looks. That may seem a frivolous reason to choose one language over another. But it is not so frivolous as it sounds: when you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor. At the mention of ugly source code, people will of course think of Perl. But the superficial ugliness of Perl is not the sort I mean. Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts. Perl may look like a cartoon character swearing, but there are cases where it surpasses Python conceptually. (More on "Python's readability" in: http://www.paulgraham.com/power.html ) As I joked in the prior message I still think the right way to address this problem is by adding a language pragma, just like "use strict," that enforces greater conformity. Just as many Perl shops mandate use of "use strict" they could mandate use of "use Enterprise" or whatever its called. Perl seems to get penalized for its history (sys admin glue) and the current wide dynamic range of problems it is capable of addressing efficiently (one liners, small scripts, 10K+ line applications). If you're writing a large application, the coding style should obviously be different from a one-page script, and using a pragma to have the compiler enforce that seems reasonable. Although unlike "use strict" this pragma isn't going to help you avoid things that will affect the functionality of your program. At some point you just have to rely on the programmer's ability to follow the coding standards established on your project. What I don't get is why the industry seem to favor having the compiler be the enforcer...or more specifically, why it isn't obvious that a simple add-on to an established language could offer the equivalent. But maybe this explains it... In another essay where Paul examines the assertion that "Python's goal is regularity and readability, not succinctness," he says: http://www.paulgraham.com/power.html I'm not as sure that readability is directly proportionate to succinctness as I am that power is, but certainly succinctness is a factor...in readability. So it may not even be meaningful to say that the goal of a language is readability, not succinctness; it could be like saying the goal was readability, not readability. What readability-per-line does mean, to the user encountering the language for the first time, is that source code will look unthreatening. So readability-per-line could be a good marketing decision, even if it is a bad design decision. Ah, good marketing... -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
