Python from Wise Guy's Viewpoint

[Joachim Durchholz]

Espen Vestre wrote:

> Joachim Durchholz <joachim.durchholz at web.de> writes:
> 
>>Anyway, I lost interest in CLOS when I saw those clumsy BEFORE and AFTER
>>keywords, and that priorization machinery for multimethods. Too
>>complicated, too liberal (allowing lots of powerful things and lots of
>>subtle bugs).
> 
> If you come to such a decision without even trying it out, it doesn't
> mean CLOS has a problem, but rather that you have an attitude problem. 

Well, if you come to such a decision without even knowing me personally, 
I think it's your attitude problem as well ;-)

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