merits of Lisp vs Python

[Bill Atkins]

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.  And do they?  To paraphrase Brian Griffin: "Are you sure it
was people?  Are you sure it wasn't...nothing?"

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

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

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

> Honest to god, the code really was like that! 

Holy cow!  How incredible!

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

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

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