Home Original page

merits of Lisp vs Python

Bill Atkins atkinw at rpi.edu
Sun Dec 10 02:12:29 EST 2006 
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.
More information about the Python-list mailing list