Python from Wise Guy's Viewpoint

[Espen Vestre]

Joachim Durchholz <joachim.durchholz at web.de> writes:

> Actually, my experiences with Lisp come from several pre-Scheme
> encounters. They include a rather poor (by today's standards) dialect
> called Interlisp, which worked OK but was a little restricted, and a
> Lisp machine that offered no protection whatsoever for the system
> internals and, consequently, crashed in ways that make even Windows ME
> look like the incarnation of stability.

Probably, you have tried, as I did, to use Xerox Lisp Machines in
standalone mode. They were much more stable when run with a server (I
tried that too, at Xerox PARC). Their standalone user base wasn't
really big enough, and the developers used them with a server (this
isn't something I'm just guessing, a PARC guy admitted having similar
problems on his standalone 1100-series machine at home).

(Anyway, even using them standalone was better than Windows ME wrt.
 stability)

> before/after/around don't offer anything that a simple call to an
> ancestor method wouldn't offer, and with less linguistic
> requirements. 

Yes they do. E.g. :around-methods wrap _around_ the primary method.
If you want the most specific method to be called first, you can
always use ordinary ancestor methods (call-next-method).

> And, maybe, because you're not working in a team of a dozen or more
> people, so you know exactly what combinations of types are safe to use
> with a multimethod, and which aren't? 

Not a dozen, but 5 people are still maintaining and expanding the
system I was the main author of 5 years ago (and I left them almost
2 years ago).

I agree that multimethods must be used with care. But so must many
constructs, even in languages that try hard to put a straight jacket
on their users. 

> stupid coding error, and you simply fix the problem? (C programmers
> don't see C as a dangerous language, they just consider race
> conditions and buffer overruns as stupid programming mistakes as
> well... deficits of a language are easier to see if you take an
> outside perspective.)

Sorry, but I don't think the multimethod/buffer overrun analogy is a
fair one (except if you can come up with at least one real life
example of multi-method-hell at work).

> In practice, most programmers aren't great, they are average. Assuming
> a halfways sane distribution, 50% of all programmers are even /below/
> average - and their services are still very much in need.
> How should they get their work done?
> Educating them isn't an option - if that were a possibility, it would
> have long been done.

The problem with this attitude, is that below-average programmers
usually advance, through the Dilbert Principle, to pointy-haired
positions, and if there is this idea that "everybody must use the same
programming language, and it must be a simple one" floating around as
a principle, you can be sure that they grab it.

Another point: Do you have any _substantial_ reasons for claiming that
mediocre (or worse) programmers _really_ work better with any of the
more mainstream languages than they would do with Common Lisp (if we
for a moment disregard the most simple 'library-assembling-
programming' in VB or java where CL obviously currently has a drawback
by supporting fewer libraries)?

Yet another point: Inside every substantially advanced program,
there's a lisp trying to get out. _My_ idea (this is just guessing, I
admit), is that large CL systems are _easier_ to maintain, even for
Joe Notsobright, than large complicated systems written in other
languages, where all the fancy mechanisms have been reinvented (had to
be reinvented!) in much more obscures way to make the program work.
-- 
  (espen)