merits of Lisp vs Python

[Steven D'Aprano]

On Sun, 10 Dec 2006 02:12:29 -0500, Bill Atkins wrote:

> Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:
> 
>> Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
>> that hypothetical anything-goes language than is healthy. Maybe that's a
> 
> Wrongly.  

That's your opinion, and as an experienced Lisp coder, it is an opinion
worth treating seriously. Nevertheless, a mere denial doesn't constitute
evidence, let alone proof.

> And do they?  To paraphrase Brian Griffin: "Are you sure it
> was people?  Are you sure it wasn't...nothing?"

You know, I'm really starting to think that you Lispers -- and I hate to
generalise, but in this case I feel I'm forced to -- have a real problem
here. On the one hand, I keep reading how unfair it is that the rest of
the programming world won't give Lisp a fair go, that all these other
programmers are spreading FUD over Lisp, especially over the macros and
parentheses. And then you come along and imply that nobody is concerned
about Lisp macros.

So which is it? If Lisp is so self-evidently better than every other
language, and if nobody has any fears or concerns with Lisp, why is Lisp a
fringe language? Not as fringe as it was ten years ago, and maybe growing
in popularity, and it is beyond all doubt that Lisp has a lot of influence
amongst language designers, but outside of a few niche areas, its still a
fringe language.


 
>> My point isn't whether or not their claims are correct (a "couple" of
>> macros? really?) but that things like this feed the perception that Lisp
>> is close to that hypothetical language where anything could be anything.
>> If anything could be anything, do you really know what (+ 1 2) means
>> without reading every line of code?
> 
> Jesus H Christ.  Didn't you just get through talking about how easily
> someone can redefine built-ins in Python?

Yes. But you can't redefine 1+2 in Python, at least not without hacking
the interpreter. Can you redefine (+ 1 2) in Lisp? 

 
>> Even something simple like file I/O can be abused. Example: I've seen
> 
> Agreed.  This is why I've always argued that I/O should never have
> been included in programming languages.  Too dangerous.  And, let's
> face it, pretty old-fashioned these days.

Ha ha, I love good sarcasm!

Unfortunately, that isn't good sarcasm. 


>> (This is an interesting demonstration that any language that allows file
>> I/O and importing of external program files can always treat functions
>> as data, even if the language doesn't directly support it. An alternative
>> would be to keep the strings in memory instead of writing to a module,
>> then use exec on them instead of importing the module.)
> 
> No, it treats code as text.  See the difference?

Text is data.

What is the point of your comment? You don't have to argue about every
thing I say, even the ones we agree on. Look again at what I wrote. Is
there anything that gave you the impression that I think that having the
ability to write text to a file and import it is better than actually
supporting functional programming directly?

[snip]

>> Is that an argument against factory functions? Damn straight it is:
>> they are a powerful tool, and in the hands of morons, they can be
>> dangerous. Does that mean that languages shouldn't permit higher-order
>> functions? Not necessarily: all programming tools can be misused, but some
>> can be misused more easily than others. Power and risk is often a
>> trade-off, and language designers can't eliminate all risk of stupid
>> behaviour, but they can design the language to allow whatever level of
>> risk they believe is acceptable. (E.g. there is no doubt that C's raw
>> pointers are powerful, but many languages deliberately don't use them.)
> 
> Could you please calm down?

Huh? 

>> The risk of stupid factory functions is small compared to the benefit, but
>> maybe there is some domain somewhere where the ideal solution is a
>> language that DOESN'T treat functions as first class objects, deliberately
>> weakening the language so that a particular class of errors (or stupid
>> behaviour) just cannot happen. But that language isn't Python.
> 
> Could you calm down?

Okay, once was funny. Twice is worrying. What exactly is giving you the
idea I need to calm down? Was it the use of reasoning and logic?
Perhaps it was the attempt to be reasonable and moderate and find some
middle ground that we could agree on, or if not agree, at least say "Well,
I disagree with you, but at least I understand where you are coming from"?


>> When it comes to Lisp's macros, the perception is that the power is
> 
> NB: here, "the" means "Steven D'Aprano's" (the number of meanings
> "the" can assume in different contexts is quite surprising).




> 
>> correspondingly greater, and the risk of abuse even more so. The safe
> 
> Don't you get tired of making the same arguments?  Because I'm getting
> tired of making the same counterpoints.