merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:

> 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

You feel you're forced to generalize about an entire group of language
users based on what a handful of people have posted on a newsgroup?

> 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.

I'd like to know the answer.  But the problem most people cite is the
parentheses, not the fear that someone will abuse macros.  I have
certainly never seen anyone as worried about macros as you seem to be.

>>> 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? 

Yes.  Can't you redefine standard functions in Python?

Frank Buss correctly points out that you can shadow the + symbol and
make it whatever you'd like it to be.  This is true, but now someone
has to intentionally and specifically import the package containing
that shadowed + into their own package.  You are never unwittingly
using a different + than the standard CL one, although you really seem
to want this to be the case.

>>> (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?

Well, text is not code.  Text is a syntaxful representation of the
actual code, which is an AST.  If I have a string full of text, I
can't do very much meaningful work with it.  On the other hand, if I
have an AST, I can transform it or analyze it however I choose.

>> 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"?

Where I'm coming from?  Dude, you're writing paragraph upon paragraph
about the same thing, multiple times per day.  You're terrified of
worst-case scenarios that everyone else is telling you are not
realistic.