merits of Lisp vs Python

[David Golden]

Paul Rubin wrote:

Forth was always unreadable to me but I never did much. I thought its
aficionados were silly. Yes if you have a complicated math expression
in Lisp, you have to sit there for a moment rearranging it in infix in
your mind to figure out what it says. The point is that such
expressions aren't all that common in typical Lisp code.

I find Lisp, Forth and classic funny-symbol APL relatively readable
(well, once you've learned the funny symbols in the APL case) That
spans prefix/postfix/infix... The commonality is simple evaluation
order, no damn precedence rules. I can _cope_ with precedence rules,
I'm not a moron, but I prefer languages that don't make heavy use of
them. Well, more accurately, sources that don't, but most coders in
communities of languages-with-lots-of-precedence-rules consider
reliance on those precedence rules in source code idiomatic. And
precedence rules, once you get beyond a few (sometimes rather
misleading) similarities to the ones that most people are made to learn
early on for arithmetic notation, can vary a lot from computer language
to computer language.

 

[hg]

Okay, since everyone ignored the FAQ, I guess I can too...



(Common) Lisp is the only industrial strength language with both pure
compositionality and a real compiler. What Python has is stupid slogans
("It fits your brain." "Only one way to do things.") and an infinite
community of flies that, for some inexplicable reason, believe these
stupid slogns. These flies are, however, quite useful because they
produce infinite numbers of random libraries, some of which end up
being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
is rapidly replacing Perl, and Ruby is simultaneously and even more
rapidly replacing Python. Each is closer to Lisp than the last; the
world is returning to Lisp and is dragging the flies with it.
Eventually the flies will descend upon Lisp itself and will bring with
them their infinite number of random libraries, and then things will be
where they should have been 20 years ago, but got sidetracked by Tcl
and other line noise.

pffffffff !

 

[Ken Tilton]

Such a sweeping generalization. Every person who raves about Lisp is also
accomplished with other languages. Yeah, right. I believe you, even if
millions wouldn't.

Ah, but that is because you are not a careful thinker, you just like
sounding off on Usenet. Me, too!

Think, Steve, think: do you think we pay the rent with /Lisp/ jobs?!

If logic does not work for you, try this:

http://wiki.alu.org/RtL_Highlight_Film

Behind each sound bite is a full survey response, one question being
"what other languages do you use?".

I hit my hand with a hammer once.

Cool, first you use the lame Turing Completeness thing, now you are
arguing by analogy, which does not work because now we have to argue
about how well the analogue maps onto the topic.

When I switched Lisps after several years of Lisp I also had to switch
IDEs (not using Emacs+ILisp). I hated the new IDE. I also told myself to
wait thirty days before worrying about it, since obviously it might just
be a matter of habit. Now when I port things back to the first Lisp I
hate that IDE (except I know a couple of weeks would turn it around).

Now it may be distressing to you that I am talking about something
closer to programming languages than is hammering ones hand, and for
that I apologize in advance.

I didn't keep going until I was an

expert in hitting-own-hand-with-hammer before deciding that hitting my
hand with a hammer was not for me. Did I do the wrong thing? Should I have
kept going until I was an expect at it?

(Of course, writing Lisp isn't precisely like hitting one's hand with a
hammer. With the hammer, the endorphins kick in eventually, and it can
become quite pleasant...)





The sheer arrogance of this claim is astounding.

Actually, this is comp.lang.lisp. It isn't astounding at all.

Exactly, and Usenet. Not the Supreme Court. We can speak casually. We

I don't know, maybe lisp coders actually are more intelligent than
ordinary mortals,

No, it's the Lisp that makes them so effective. I was joking in my
original remark. But not about Lisp programmers being better looking.

but it has been my experience that they have absolutely
no grasp whatsoever of the way most (many? some?) people think. And I'm
not talking about can't-walk-and-think-at-the-same-time people either, I'm
talking about bright, intelligent people who, nevertheless, don't agree
with lisp coders.

As you will soon realize because you are such an open,
intellectually-honest person and will do the reading I recommended, most
of us came to Lisp late in our programming careers, having used and
excelled at (in my case) Apple Integer Basic, Microsoft Basic, 6502
Assembler, COBOL, any DEC Basics, C, Logo, and now Lisp (chosen over the
new C++ because the latter seemed like evry bit the horror it turned out
to be). I have done enough Python to appreciate the cleanliness of the
code and its power, and enough Java... well, after Lisp it is impossible
to find anything in some other language that would tempt one to work
much in it.

My point is that we grasp what you think because we /are/ you, we have
worked alongside you, and we are very good at your language. And we use
Lisp and gloat about it and piss everyone off with our smugness. It
can't be helped--Lisp is that good.

If the parentheses are that meaningless, why do you need them?

Meaningless? Who said that? Did you say that? Someone said that.

I said they disappear. I am not looking at parens, I am looking at the
code structure, as manifested by (you'll like this) the indentation, the
indentation provided automatically when I kerplunk control-shift-P (I
think, my fingers know).

You like analogies. When i tried on my first glasses I said "I can see
the frames!". the glasses guy said, "That is because you are looking for
them." Something like that. With the editor handling the parens 90% of
the time, I do not have to thnk about or look for them.

btw, change all the ()s to []s and I /do/ see them. Possibly they would
go away with time, but I have a hunch that []s might not go away, two
cornery or something.

Funny, when I write code, I try to remove boilerplate, not hide it.

Boilerplate does not mean meaningless. You cannot remove it. It is
absolutely necessary. But it has blanks that must be filled in
differently for each use of the boilerplate. With macros, one supplies
just the fill-ins and the name of the boilerplate, but in a way a
function cannot handle.

The last time we went thru this a Pythonista finally said, Oh, I get it.
These five lines of code I have to write all the time (two setup, one
func call, two cleanup) can be collapsed into one or two. The thread
will be hard to miss in Google groups (two years back?) and the epiphany

Yes. And your point is?

You would love macros if Python had them.

Perhaps you should consider what the term "Turing complete" implies.

I have destroyed this elsewhere, but in case you missed it: HLLs exist
precisely to distance us from having to program Turing machines
directly, and are to be judged precisely on how well they do that, so
this fig leaf offers no cover.

Maybe so. A bulldozer is a lot more powerful than a tack-hammer, but if
somebody suggested using a bulldozer to lay carpet, I'd politely show them
to the door. Sometimes more power isn't better.

I thought we agreed that analogies are useless because they become their
own debate? Again, power means maximizing the ratio between how much
time am I thinking about the problem I am trying to express and how much
time am I thnking about your beloved Turing machine.

Not sure how I would say that in infix.



ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[Ken Tilton]

(message (Hello 'Ken)
(you :wrote n '(Sat, 09 Dec 2006 04:26:02 -0500))
(

KT> keep the Pythonistas from straying. But you have an excuse: Lispniks
KT> always /talk/ about macros giving us the ability to create a DSL. But
KT> no one does.

certainly there's no reason to make a new DSL each day, but sometimes they
are good.
i've recently posted an example of DSL to do queries to RDF data base -- i
find it's very helpful.

That is different. Your very objective /was/ a language. Naturally, you
created one. I am talking about PGs suggestion that the best way to
solve a problem is to create a language for that problem and then use
it. What I think happens more often is the other thing Graham said:
building up CL to be a better language for the problem. So the language
is still predominantly and visibly CL, and here and there are chunks of
macrology hiding a crapload of boilerplate.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[Ken Tilton]

Ken Tilton wrote:




Erm ... because there's an editor for it that indents automatically?
Or did I miss the point?

I think so, but you did not say enough for me to understand /your/
point. It sounded like you were using sarcasm to point out to me exactly
what I had just said.

We might want to punt on this.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[Wade Humeniuk]

This is from the perspective of an aerospace engineer who passed
through python several years ago on the way to lisp. Futhermore, this
is a 2 glass of wine response.

<snip>

Thanks for the comments. I think it is great that you took a "harder
and less travelled way". It may be that some people get to a point
where they are either tired or think they know everything. Or.. their
brains just harden up and they become old dogs.

There seems to be a recurring theme to many of the posts in this thread
about syntax and readability. Some of it is "If I can not instantly
read and understand what the code is doing then something is wrong
with it". As if holding oneself as the standard of what is good and
correct is the only way. If you see something and it
is not readily apparent what it is, then that is a sign than something
interesting may be going on. I got into Lisp because when I
looked at it, I did not understand. I did not think WTF! but thought
that something was going on and maybe I was cheating myself if I
brushed it aside.

There is also some disdain expressed about badly written programs.
Why? They may be that way for some very good reasons, it is folly
to think that programs have to be simple, obvious and elegant. I find
interesting that a programmer got out their comfort zone and attempted
something. Its better than the ones with the big egos who play it safe
so they do not appear to be a fool.

Wade

 

[Steven D'Aprano]

Here, you've basically shot yourself in the ass. Appealing to Turing
completeness when talking about programming language features is about the
dumbest thing you can make. In Turing sense, a program is simply a function that
takes an argument and returns a value. It doesn't say anything about how this
function was implemented. It could be Turing machine, lambda calculus, Markov
chains or whatever else. All these methods produce the same set of programs, but
that doesn't mean you could implement lambda in Turing machine for example.

What exactly are you trying to say here? Is this a comment about the
relative practicality of writing code in a Turing machine versus
high-level languages, or are you implying that lambda calculus is "bigger"
than any Turing-complete language?

If you're talking about practicality, then of course you're correct, not
all languages are equally expressive. Some languages are not expressive
enough. Some languages are too expressive. No language is optimal for all
people for all tasks.

Is is time for someone to read his computer science books again?

Probably. Would you like to borrow mine?

Look, all snarkiness aside, it just isn't true that "stuff like this is
impossible in other languages". If Wolfram Fenske had said "stuff like
this isn't easy in many other languages" he would have been right. And if
he had said "and stuff like this carries risks as well as benefits" he
would have come across as less of a language fanatic.

One of the risks with Python is the ease with which you can modify the
built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
list from 2, 3, and 4, because the built-in list could be redefined.
(In practice, that's not often a real problem, because experienced
Python developers simply learn not to needlessly or confusingly shadow
built-ins. It's not the best system, but it works well enough in
practice.) But at least the basic syntax and keywords of the language are
known to be constant.

With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful." then, no doubt, we'd take you guys more
seriously. But we don't hear that -- we hear Lispers going on and on about
how great it is that they can easily redefine every corner of the
language. Do you blame people for *believing them* and imagining that
reading Lisp code is like following some ghostly will-o-the-wisp across a
swamp, where nothing is what it seems and the landscape is forever
shifting?

Now, if you want to tell me that, despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions, then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?

 

[Ken Tilton]

But Lisp's syntax is so unlike most written natural languages that that it
is a whole different story. Yes, the human brain is amazingly flexible,
and people can learn extremely complex syntax and grammars (especially if
they start young enough) so I'm not surprised that there are thousands,
maybe tens or even hundreds of thousands of Lisp developers who find the
language perfectly readable.

But that isn't to say that the syntax of Lisp is for everybody.

yeah, I think it is. Folks don't vary that much. If every Lisp
programmer also reports parens disappearing at about thirty days, any
given non-Lispnik can pretty much bet on the same experience.

And since no one can produce a witness who worked fulltime on Lisp for
thirty days and gave up on it because it was a great language but they
could not handle the syntax, or a witness who stayed with Lisp because
it is a great language even though to this day they have trouble reading
the synatx...

Far from
it -- I'd be willing to bet that Lisp developers are a self-selected group
of far above average intelligence.

I think the early adopter is distinguished not so much by greater
intelligence as by restlessness and rebelliousness and a little lunacy.
We lack the knack of happiness. Many of the stories on the RtL reveal
folks who sought A Better Way after mastering other languages. And by
Better Way, sorry, we mean "why do I have to forever worry about the
damn paper tape on this Turing machine!". We do not really like
programming, we like thinking about problems and using a computer to
solve them.

That would explain why so many of them
seem to be so much more comfortable with higher-order functions than most
other people -- even intelligent people.

(Looking back, I'm embarrassed about my first reaction to factory
functions all those years ago. Hiss hiss spit. But even with added
familiarity, there comes a time where one has to question the benefit of
sufficiently high-order functions. If you are writing a factory function
that returns factory functions that return factory functions that return
the functions that you needed in the first place, chances are you really
need to rethink your tactics.)

If I'm right, then maybe Lisp is "better" in some absolute sense, *for
those who can use it*. For those who can't, it isn't just a matter of
(say) the syntax being hard to read because it is unfamiliar, but it
being objectively harder to use.

An interesting study would be to track people's eyeballs as they read
code, ...

I spend about 90% of my time thinking and writing code, and read it only
to understand how something works or why it broke. And then I am looking
at parentheses no more than you are looking at the lines of resolution
on a TV when watching Baywatch. I am looking at a mechanism and how it
works.

...or look at how much oxygen their brain uses. Do Lisp coders do more
work to read Lisp than Python coders do to read Python? I suspect they do,
but successful Lisp coders don't notice.

My suspicion goes the other way, and is based not on punctuation, rather
on imperative vs functional. In Lisp every form returns a value, so I do
not have all these local variables around that, in the strecth of an
interesting function, take on a stream of values and transformations to
finally come up with some result, meaning to understand code I have to
jump back and forth thru the code to see the lineage of a value and
figure out its net semantics. Too much like work.

Everybody else does, and
gravitate to languages which might not be "better" but are "good enough".

No, they gravitated to a language that was closer to what they already
knew, C or Java (which also mimicked C to pick up those users). Later
charms of Python were a great community and library support. Lisp simply
does not have the latter, one is forever rolling one's own bindings to C
libs.

(If my post leads to any Lisp developer's already swollen head exploding
from pride, my job here is done *wink*)

They can't get any bigger.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[JShrager]

Okay, since everyone ignored the FAQ, I guess I can too... [snip]
What Python has is stupid slogans
("It fits your brain." "Only one way to do things.") and an infinite
community of flies that, for some inexplicable reason, believe these
stupid slogns.

IOW, you posted the FAQ so you could appear to have highest moral
ground, then you ignore your own advice and promptly head to the very
lowest ground with ad hominem insults.

You're right, in part: My implicitly linking Python's pros or cons with
its stupid marketing hype is, I think, an ad hominem argument. But I
don't see a moral issue here; the purpose of posting the FAQ was merely
to try to stop the fight. It failed.

Regardless, there was some content in my post which you have not
addressed:

To wit:

1. Lisp is the only industrial strength language with pure
compositionality, and that this makes it suprior to Python. We don't
have to debate this because it's being debated elsewhere in this
thread.

2. Ruby, which is closer to Lisp than Python, is beginning to eat
Python's lunch. We don't have to debate this either because George has
kindly gave support to it through posting a survey that made this point
quite nicely; Thanks, George!

BTW, for the record, I don't have anything particularly against Python
aside from its stupid marketing hype and a bit of jealousy over those
flies building libraries which I wish we had in Lisp. I've made the
choice uncountable times between PERL, Python, and Tcl when I didn't
have Lisp as an option, and I have always chosen Python in these cases,
even though I can program in any of these. (Although I'm probably going
to start using Ruby instead of Python in these cases, but I'm not
really expert in it yet.)

(Actually, in many cases I can get away with Emacs keyboard macros
where others would program in PERL or Python, although not always.)

 

[Ken Tilton]

Some languages are too expressive.


Look, all snarkiness aside, it just isn't true that "stuff like this is
impossible in other languages". If Wolfram Fenske had said "stuff like
this isn't easy in many other languages" he would have been right.

Remember, Lisp macros are like being able to run a preprocessor on an
ad-hoc basis. Without Lisp compilers (er, should I say the Lisp
"reader"?) understanding macros and macro functions, not even Lisp could
transform source code this way.

We won't have an intelligent discussion on macros until this gets better
understood. Macros are not about what one can do at run-time, they are
about what happens at compile time. If your compiler/preprocessor/IDE
are not going to cooperate, then embedding a preprocessed language in
Python is so hard as to be unfeasible.

I also would not quibble over "impossible" vs. "incredibly hard". The
bottom line is that at a pretty low level hard becomes "aint gonna happen".

And if
he had said "and stuff like this carries risks as well as benefits" he
would have come across as less of a language fanatic.

One of the risks with Python is the ease with which you can modify the
built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
list from 2, 3, and 4, because the built-in list could be redefined.
(In practice, that's not often a real problem, because experienced
Python developers simply learn not to needlessly or confusingly shadow
built-ins.

Well, duuhhhhh. This the Great Strawman, that Lisp programmers (a) love
having a powerful language (b) so they can produce unreadable code. This
nonsense is an implicit concession that you have no point at all.

It's not the best system, but it works well enough in
practice.) But at least the basic syntax and keywords of the language are
known to be constant.

With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful."

I have to admit you are probably still catching up on what I have
written today.

then, no doubt, we'd take you guys more
seriously. But we don't hear that -- we hear Lispers going on and on about
how great it is that they can easily redefine every corner of the
language.

You have this tendency as your paragraphs grow to get sillier and
sillier and make up more and more hobgoblin crap, I suppose as you sense
the weakness of your case. Can you point to where someone said that? No,
of course not. Get a grip, will you, this could be a useful cultural
exchange, but not with your hysterics.

why do you need
macros then if you are just using them as functions? Why not use functions?

Hint: famous Lisp style rule: never use a macro where a function will do.

Not sure it is worth wasting more time on you at this point or I would
offer examples. Could you calm down a bit and stop making things up?

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[JShrager]

Thankfully folks (including me) seem to be starting to cool off, so
perhaps we can disucss this in somewhat calmer register. I think that
Kenny unintentionally sold macros short by implying that they are
merely window-dressing for boilerplate, and you seem to have a
misunderstanding of macros, which I won't go into too deeply but to
point out that the purpose of macros is not the same as functions.
Functions create new ...uuuhh... functionality, whereas macros create
new programming constructs. These work in very different conceptual
parts of the programming landscape: The former addresses the way that
the functions offered by the programming language fit the parts of the
problem whereas the latter addresses the way that the programming
language itself fits the problem.

So, whereas I will grant that:

"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful."

I don't think that any experience Lisp programming would grant that:

despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions

So, to your point:

then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?

No, they are not functions. We need them because although it is usually
possible to make a given programming language's functionally fit any
given problem, it is often much more convenient, and much cleaner, both
practiaclly and conceptually, to make the programming langauge fit the
problem too.

 

[mystilleef]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

Advantages of Python:

1). More and better mature standard libraries (Languages don't matter,
libraries do).
2). Multiple programming paradigms (including functional style
programming see itertools, functools, operator modules (lambda, map,
filter, reduce, sum etc builtins), higher order functions, list
comprehension, blah, blah)
3). Better OO implementation. (I used to hate OO until I started using
Python)
4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
said. Bindings for almost any lib worth using, at least on *nix)
5). Clearer syntax.
6). Better namespace management. (nobody ever talks about this, but
Python seems to be one of the few languages that gets symbol management
right from a users perspective)
7). Easier packaging and distribution system.
8). Ubiquity! Python is everywhere. Lisp, bleh.
9). Relatively good docs (PHP has better).
10). Fewer perceived community assholes. Large community.
11). Less fragmentation.

Advantages of Lisp:

Learning a functional language can improve your programming range and
depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
when there's mind bending Haskell. I'd go as far as saying I believe
Haskell has a better fate than Lisp.

On Lisp Macros:

I think they are overrated, and in general cause more harm than good.
It's the reason I find Lisp-like programs difficult to grok, maintain
and extend. Cos every smart ass wants to needlessly write his own mini
language to the point of absolute obfuscation. Naturally, I'm supposed
to be awed by his mischievous cleverness.

Conclusion:

The semantics or features of a language is almost irrelevant today.
Developers want to put the lego pieces together, they don't want to
make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
was popular in the 70s, but it's boring and expensive today. Today,
when a developer needs to solve a problem, the question they ask is,
"Is there a library for that?". If the answer is no, they a more likely
to switch to a language that provides a library that solves their
problem. The challenge for developers today is software architecture,
robustness and scalability, not language purity or semantics. The Lisp,
and to an extent Haskell, community will never ever ever grok this.
They'll continue to wonder why an "inferior" language like Python keeps
getting popular. It will always escape them that it might be because
Python is actually easier to use for most people to write "real world"
applications. It has good usability.

 

[Timofei Shatrov]

What exactly are you trying to say here? Is this a comment about the
relative practicality of writing code in a Turing machine versus
high-level languages, or are you implying that lambda calculus is "bigger"
than any Turing-complete language?

I'm trying to say that the ability to read is a very useful skill in a Usenet
discussion. Your posts, like the two quoted above, seem to indicate the lack of
it.

 

[tayssir.john]

With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful." then, no doubt, we'd take you guys more
seriously.

Who are "we"? I was a heavy Python and Java user before being aware of
Lisp. I knew even then that there was something wrong with the
programming world, because there were too many programming patterns I
could not automate away within the language. It's ironic to be a
programmer who can't automate her own work.

I told people that programming was just "glorified accounting." I
shrugged when reading about how complexity was exploding, because that
was the language designers' job to manage it.

Upon hearing of Lisp, I taught it to myself alone, because it was
important. Despite all the FUD, despite all the people who presumed
that a language designer was smarter than his users. I came to realize
that the programming world was full of users who repeated "conventional
wisdom" based on generalities they heard from a friend of a friend of
an evangelist of a corporation -- and worse yet, I was part of that
culture and picked up those poor habits.

Now, if you want to tell me that, despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions, then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?

You may wish to read the following:
<http://www.defmacro.org/ramblings/lisp.html>

Perhaps Lisp becomes clearer once you see its syntactic similarity with
a very mainstream language -- XML. (But sexps are far more lucid than
XML.) Then we can seriously talk about the real-world engineering
implications of macros, and other powerful features which aren't so
hyped as macros.


Tayssir

 

[Bill Atkins]

I've read all the arguments against significant indents/whitespace, or
in favour of braces, and while there are a few minor good points they
make, a few edge cases where Python's significant indentation is
sub-optimal, overall I believe that the famous reaction of programmers to
Python and whitespace is simply them being more like cats than usual:

"It's different, anything different is frightening, I don't like it, hiss
hiss spit!!!"

What about "It's wrong, it's wrong, hiss hiss spit!" ?

I want to be able to change my code and let the editor indent the
result; if I make extensive changes to a section of Python code, I
have to review it afterward and make sure I haven't introduced any
subtle indentation mistakes. Compare

(let ((x 'blah))
(if (eql x 'foo)
(print "blah")
(print "bloo"))))

This could quite conceivably be the result of a lot of refactoring
of (admittedly silly) code. But now I just press C-M-q and, pow:

(let ((x 'blah))
(if (eql x 'foo)
(print "blah")
(print "bloo")))

All happily-indented. And mistakes in nesting show up as mistakes in
indenting. Who could ask for anything more? Python requires me to
review the structure of the code to make sure I haven't inadvertantly
broken it. Why?

Why do I need Python to enforce my indentation (potentially leading to
bugs) when my editor can indent my code perfectly because the syntax
of Lisp is so free of special cases?

But Lisp's syntax is so unlike most written natural languages that that it
is a whole different story. Yes, the human brain is amazingly flexible,
and people can learn extremely complex syntax and grammars (especially if
they start young enough) so I'm not surprised that there are thousands,
maybe tens or even hundreds of thousands of Lisp developers who find the
language perfectly readable.

Most programming languages are nothing like natural languages
(thankfully - ever heard of something called COBOL?). Lisp's syntax
is trivial to lean, and its semantics are very precise.

But that isn't to say that the syntax of Lisp is for everybody. Far from
it -- I'd be willing to bet that Lisp developers are a self-selected group
of far above average intelligence. That would explain why so many of them
seem to be so much more comfortable with higher-order functions than most
other people -- even intelligent people.

(Looking back, I'm embarrassed about my first reaction to factory
functions all those years ago. Hiss hiss spit. But even with added
familiarity, there comes a time where one has to question the benefit of
sufficiently high-order functions. If you are writing a factory function
that returns factory functions that return factory functions that return
the functions that you needed in the first place, chances are you really
need to rethink your tactics.)

If I'm right, then maybe Lisp is "better" in some absolute sense, *for
those who can use it*. For those who can't, it isn't just a matter of
(say) the syntax being hard to read because it is unfamiliar, but it
being objectively harder to use.

An interesting study would be to track people's eyeballs as they read
code, or look at how much oxygen their brain uses. Do Lisp coders do more
work to read Lisp than Python coders do to read Python? I suspect they do,
but successful Lisp coders don't notice. Everybody else does, and
gravitate to languages which might not be "better" but are "good enough".

(If my post leads to any Lisp developer's already swollen head exploding
from pride, my job here is done *wink*)

I'm afraid you're on the wrong track. Any programmer can pick up Lisp
and be productive in it these days. Please don't try to make Lisp
seem more mysterious or elitist than it really is. It's just a
programming language, and anyone can learn it:

http://www.gigamonkeys.com/book

 

[Bill Atkins]

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

Of course, but you have to realize that Turing-completeness is a
useless concept when comparing languages. C and Python are both
Turing-complete. So: write me some code in each that reads in a line
of text, splits it on spaces and stores the result in an array. Which
would you rather write? Which will be shorter and more easily changed
and straightforwardly grasped in the future?

QED. Turing-completeness is irrelevant when comparing languages.
Take it as a given.

 

[Bill Atkins]

Advantages of Python:

1). More and better mature standard libraries (Languages don't matter,
libraries do).
2). Multiple programming paradigms (including functional style
programming see itertools, functools, operator modules (lambda, map,
filter, reduce, sum etc builtins), higher order functions, list
comprehension, blah, blah)
3). Better OO implementation. (I used to hate OO until I started using
Python)
4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
said. Bindings for almost any lib worth using, at least on *nix)
5). Clearer syntax.
6). Better namespace management. (nobody ever talks about this, but
Python seems to be one of the few languages that gets symbol management
right from a users perspective)
7). Easier packaging and distribution system.
8). Ubiquity! Python is everywhere. Lisp, bleh.
9). Relatively good docs (PHP has better).
10). Fewer perceived community assholes. Large community.
11). Less fragmentation.

Are any of these not subjective?

Advantages of Lisp:

Learning a functional language can improve your programming range and

Lisp is much more than a functional language.

depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
when there's mind bending Haskell. I'd go as far as saying I believe
Haskell has a better fate than Lisp.

Yeah, that's pretty far.

On Lisp Macros:

I think they are overrated, and in general cause more harm than good.
It's the reason I find Lisp-like programs difficult to grok, maintain
and extend. Cos every smart ass wants to needlessly write his own mini
language to the point of absolute obfuscation. Naturally, I'm supposed
to be awed by his mischievous cleverness.

Uh huh. Can you cite examples of this? Sounds like you're just
making stuff up here. Contrary to popular belief, writing a Lisp
macro that warps your mind and introduces a totally un-CL-like
semantics is extremely difficult. Most of the people who are good
enough at CL to do it (I'm certainly not one of them) are also
experienced enough to know when it's the right choice.

And Lisp environments all support getting the macroexpansion,
documentation, and source of any unfamiliar macro you might happen
upon, so really this is not as much of a problem as you might
fantasize it to be.

Conclusion:

The semantics or features of a language is almost irrelevant today.
Developers want to put the lego pieces together, they don't want to
make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
was popular in the 70s, but it's boring and expensive today. Today,
when a developer needs to solve a problem, the question they ask is,
"Is there a library for that?". If the answer is no, they a more likely
to switch to a language that provides a library that solves their
problem. The challenge for developers today is software architecture,
robustness and scalability, not language purity or semantics. The Lisp,
and to an extent Haskell, community will never ever ever grok this.
They'll continue to wonder why an "inferior" language like Python keeps
getting popular. It will always escape them that it might be because
Python is actually easier to use for most people to write "real world"
applications. It has good usability.

I don't agree with a lot of what you say in this paragraph, but I
you're right that libraries are crucial. That's why I wish there were
more people writing Lisp libraries instead of being scared away by
sheer fabrications like the stuff that's appearing in this thread.

 

[Bill Atkins]

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

"Can you imagine if carpenters were like computer scientists? Some of
them would argue that it's not necessary to own a hammer because the
butt of a screwdriver is naildriver-complete."
-- Barry Margolin in comp.lang.lisp

 

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote n '(09 Dec 2006 01:01:14 -0800))
(

PR> If Common Lisp didn't have lexically scoped variables (most Lisp
PR> dialects before Scheme didn't have them) then it would be very
PR> difficult to add that with macros.

i think there's some way to hack that. for example, make defun a macro that
will collect all lexically scoped variable and mangle them. for example:

(defun foo () (let ((i 1)) (print i)))

will be transformed to

(defun foo () (let ((i_foo 1)) (print i_foo)))

(or just some random suffix). this way variables in different functions will
never collide. maybe there's a catch somewhere, but that should look very
close to lexical variables.

PR> Do you seriously think lexical scoping is the last word in language
PR> features and that there's now nothing left in other languages that
PR> can't straightforwardly be done in CL? Hint:
PR> call-with-current-continuation (also known as call/cc).

there's nothing impossible
we even have a lib for nondeterministic calculations -- Screamer, that's
much much more cool than that call/cc..

(defun pythagorean-triples (n)
(all-values
(let ((a (an-integer-between 1 n))
(b (an-integer-between 1 n))
(c (an-integer-between 1 n)))
(unless (= (+ (* a a) (* b b)) (* c c)) (fail))
(list a b c))))

you define ranges for variables, define constraints (in a form very close to
normal lisp code) and then just say -- all-values, or solutions (first thing
that satisfies constaints).

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")

 

[Bill Atkins]

There is just not that much boilerplate in Python code, so there's
not so much need to hide it.

Well, of course there is. There are always going to be patterns in
the code you write that could be collapsed. Language has nothing to
do with it; Lisp without macros would still be susceptible to
boilerplate.

Here's a concrete example:

(let ((control-code (read-next-control-code connection)))
(ecase control-code
(+break+
(kill-connection connection)
(throw :broken-by-client))
(+status+
(send-status-summary connection))
((+noop+ +keep-alive+))))
;; +X+ indicates a constant

The standard ECASE macro encapsulates this pattern: Compare the
variable control-code to +break+. If the two are EQL, then run the
code provided in the +break+ clause. Likewise for +status+. In the
last clause, the test-form is a list, so the generated code will
compare control-code to either +noop+ or +keep-alive+. If it is EQL
to either, it runs the body of that clause, which happens to be blank
here. The E in ECASE stands for "error," so if control-code doesn't
match any of these choices, the generated code will signal an error
with the following text "CONTROL-CODE fell through ECASE expression;
was not one of: +BREAK+, +STATUS+, +NOOP+, +KEEP-ALIVE+". All of that
boilerplate is handled by the macro. In Python, I would need to do
something like:

control_code = connection.read_next_control_code()
if control_code == +break+:
connection.kill()
throw blah
else if control_code == +status+:
connection.send_status_summary()
else if control_code == +noop+ || control_code == +keep_alive+:
else:
error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"

To change what control codes you want to check for, you need to add
conditionals for them and keep the error text relevant. The reality
is that a computer could be doing this for you, leaving your code
simpler and more easily changed.

Now someone will complain that the ECASE code means nothing until I
understand ECASE. Yep. But once you understand ECASE, you can look
at that code and, *at a glance*, see how control flows through it. In
the equivalent Python code, I need to walk through each conditional
and make sure they're all following the same pattern. If you're not
convinced, extend the example to 12 different control codes.

Note also that ECASE is just expanding to the COND conditional. There
is nothing mind-bending (or even mind-twisty) going on inside of it.
It's simply a way of expressing a common syntactic pattern in
higher-level terms. To prove that macros are not the frightening
beasts you guys are making them out to be:

CL-USER 13 > (let ((*print-case* :downcase))
(pprint (macroexpand '(ecase control-code
(+break+
(kill-connection connection)
(throw :broken-by-client))
(+status+
(send-status-summary connection))
((+noop+ +keep-alive+))))))

(let ((#:g17558 control-code))
(case #:g17558
(+break+ (kill-connection connection) (throw :broken-by-client))
(+status+ (send-status-summary connection))
((+noop+ +keep-alive+))
(otherwise (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ +keep-alive+))))))

If you treat the #:G17548 as just a weirdly-named variable, you can
see that the code is just expanding into the standard CASE macro. I
can in turn expand this CASE to:

CL-USER 14 > (let ((*print-case* :downcase))
(pprint (macroexpand '(case #:g17558
(+break+
(kill-connection connection) (throw :broken-by-client))
(+status+
(send-status-summary connection))
((+noop+ +keep-alive+))
(otherwise (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ +keep-alive+))))))))

(let ((#:g17559 #:g17558))
(cond ((eql '+break+ #:g17559) (kill-connection connection) (throw :broken-by-client))
((eql '+status+ #:g17559) (send-status-summary connection))
((or (eql '+noop+ #:g17559) (eql '+keep-alive+ #:g17559)) nil)
(t (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ +keep-alive+))))))

COND is the Lisp conditional form.

As you can see, ECASE does not blow your mind, but simply names and
standardizes a common pattern of code. It expands into standard
macros. And ECASE is so easy to write that most Lisp programmers have
extended versions of it in their personal libraries. And most of
these are named GENERIC-CASE or STRING-CASE, etc. and most expand into
standard COND, CASE or ECASE macros. We are not going crazy and
definining new langauges; we are simply extending Lisp to meet our
needs, by creating macros that abstract common patterns. In many
cases, the macros resemble standard, well-known Lisp macros even down
to their names.

(In the real world, I might use CLOS's eql-specifiers to define
handlers for each kind of control code. But Python doesn't have
anything analagous to that, so I'll be polite and pretend I have to
use ECASE).