merits of Lisp vs Python

[Paddy]

JShrager at gmail.com wrote:

> Paddy wrote:
> > Python is fun to use.
> > Easy to read.
> > Simple and powerful.
> > Easy to test.
> > Easy to maintain.
> > Fast. Very fast!
>
> Okay, I'm going to commit another rhetorical fallacy here called
> "Argument from Authority": I challenge anyone making psychological
> claims about language X (for any X) being easier to either
> read/learn/use than language Y (for any Y) to come up with any valid
> evidence whatever. Having a PhD in Cognitive Psychology (as well as two
> degrees in computer science) where my subject was how people learn to
> program (among other things), and having extensive experience in this
> field, I am almost certain that no such evidence exists (at least not
> for any real programming language). Now, like any good scientist, I
> could be wrong, but you'd have to convince me, and I very much doubt
> that you could.

Whilst you wait for 'evidence' proving that, for any languages X and Y,
for
example, befunge is easier to grasp than Logo; people who have tried
Python and found it easier to learn than other languages can switch to
Python, (welcome, by the way); and just get things done.
,
>
> While I'm engaging in this particular fallacy, here's another instance:
> Since I'm probably (although I'm not certain) the only person in this
> thread who has made a significant amount of money on either of these
> languages (i.e., via the sale of a startup whose product was tens of
> thousands of lines of Lisp code, and some Tk GUI stuff), and knowing
> both Lisp and Python (although I'm certainly not a Python wizard), I am
> nearly certain that what we did in Lisp COULD NOT HAVE BEEN DONE IN
> PYTHON -- PERIOD. The reason has little to do with macros (although
> they were very helpful, of course, esp. in making Tcl look like a
> reasonable language so that we could use Tk); it has to do with speed,
> which has to do with compilers, which, as it turns out, has to do with
> macros. (See below.)
Maybe for your application, but others think that speed is more to do
with algorithm.  Python has to rely more on using the right algorithm
but
it makes algorithm exploration easier than some languages, embedding
good algorithms for things like sort, and allowing the wrapping of
libraries optimised in other languages.

>
> Now, speaking as a scientist, permit me to make a small practical
> suggestion:
Speaking as an engineer please allow me to make the large practical
suggestions ;-)

> Python -- make parens (or whatever) optionally replace whitespace and
> line breaks as syntax -- and then add a simple macro facility -- macros
> are actually a very simple extension if you have homogenous syntax,
> homogenizing your syntax to the point where macros are possible is the
> hard part -- and just see what happens. One of two general things are
> likely to happen: Either people will not use them, and they will
> languish and die, and then at least you can say; "Been there, done
> that" to the Lisp community. Or, more likely, the some subset of the
> Python community will get it, and will figure out how useful they are,
> although it might take some time. And then you might find yourself with
> a wonderful new tool. You might even get a compiler out of the deal, at
> a pretty low cost, too! If you get macros, and get a compiler, I'm
> pretty sure that you will have no problem winning over the Lisp
> community, who would LOVE to have your extensive libraries, and that
> you will probably be able to maintain and improve your flagging
> position wrt Ruby (which, according to Matz, is more-or-less just Lisp
> w/o macros.)
>
> I'm not saying that this is going to be an easy or quick experiment,
> but it's one that I, and I think most Lispers, would both like to see
> happen, and would benefit from! Moreover, I dare say that some of us in
> the Lisp community would love to HELP -- at least I would, and I'm
> guessing that others would as well.
Talk to these guys:
http://en.wikipedia.org/wiki/PyPy they have an interesting take on
Pythons
interpreter, and their work is being used as part of a Python->C++
flow..

>
> (Unless you guys get a compiler too, you'll always just be a
> scripting language,
Guess what. Scripting Language is not a pejorative term. If you mean
that
python can only be used for 'glue code' then, you'r right, you don't
know
enough about Python.

> but compilers are GREATLY facilitated by having a
> macro facility because (at first blush) all you need to do is to
> macro-expand down to something you know how to turn into code. This
> isn't the only, nor perhaps the best way to get a compiler, but it's
> a step in that direction. Later on you can learn the other great
> features offered by homogeneous syntax, like being able to write code
> walkers, which help improve over the "first blush" compiler. Soon
> enough, I predict, you'll be so far past us and Ruby that...well,
> even Kenny with jump on board! :-)
Code walkers? Do you mean reflection?
Python has this unsung module called doctest that neatly shows some of
the strengths of python:
  http://en.wikipedia.org/wiki/Doctest

- Paddy.