Python from Wise Guy's Viewpoint

[james anderson]

that was a bizarre post.

the author begins by describing problematic experiences with a dialect of lisp
which, by his own qualification was "poor (by today's standards)," then he
continues with a characterization of the behaviour of method qualification,
which characterization he then deprecates in the next sentence. then, after
having indicated that he may well not have acquaited himself with the language
documentation, he proceeds to express skepticism about how much one can infer
from immediate method definitions.

it is evident that he does have direct experience with these issues in broader
terms, which makes it a shame that he perfers to conjecture about the
performance of the lower 50% rather than to state the issues concretely.

...

Joachim Durchholz wrote:
> 
> ...
> 
> 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.
> When I looked at Scheme and CLOS, I found lots of new added mechanism,
> but no attempts at fixing the old problems. (Which, probably, wasn't
> even on the agenda. Maybe it's just me who sees problems.)
> 
> > Multimethods and before/after/around-methods are among the things
> > that make me really happy as a lisp programmer, and with them I've
> > done things to systems - with a few lines of code - that would have
> > required a complete rewrite with more limited languages.
> 
> before/after/around don't offer anything that a simple call to an
> ancestor method wouldn't offer, and with less linguistic requirements.
> It looks as if somebody reimplemented Simula features without thinking
> about available improvements.
> Unless, of course, Lisp before/after/around semantics is different than
> a simple super/precursor/whatever call; in which case a more visible
> warning in the descriptions of before/after/around semantics would have
> been in order...
> 
> Multimethods, on the other hand, are indeed powerful, but they are also
> dangerous. Just like GOTO - you can use it to make code better, but
> often enough it's making it worse. Multimethods are just a case where
> problems disguise themselves as coding errors - looking at the
> sophisticated user-definable machinery for selecting the right method
> during multimethod dispatch, it seems like these problems indeed showed
> up, and were "solved" by adding further baroqueness to the language. To
> the point that reading the source code of a function will not reveal
> what's actually happening, because some quirk in multimethod resolution
> strategy may select entirely different subfunctions than those that the
> reader would have expected.
>  From a software maintenance perspective, this is pure disaster.
> 
> >>unsafe-but-powerful stuff. In my eyes, Lisp is a valuable
> >>experimentation lab for new language mechanisms, but not fit for
> >>production use.
> >
> > Hmm. I wonder why my CLOS-infested server software keep running for
> > MONTHS?
> 
> Maybe because you're one of those above-average bright guys?
> 
> 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? And if a problem indeed shows up,
> you don't attribute this to multimethods per se, but to some 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.)
> 
> >>In other words: Lisp is too powerful and dangerous, C++ is too tricky, C
> >>is too low-level, Java is too slow (even when compiled) and slightly too
> >>restricted, [add your favourite language and its deficits here] - choose
> >>your evil...
> >
> > But of all evils, Common Lisp is the least, since it gives you the
> > most reliable code (yes it DOES!), gives good programmmers the
> > opportunity to write wonderfully readable code, is wonderfully
> > expressive and is Great Fun to work with.
> 
> 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.
> 
> Regards,
> Jo