Python from Wise Guy's Viewpoint

[Joachim Durchholz]

Espen Vestre wrote:

> 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 not Xerox, but something similar.
That was about the late 1980ies, I think - Lisp machines being on or
slightly after the peak of their hype.
It might indeed have been a server thing though - there was some backup
server in the background. I still found it unacceptable if I could bring
the machine down on its knees by inadvertently changing some system
function...
Well, that's long past. The real issues are different.

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

Maybe. I'm pretty sure it wasn't Xerox, but something else.
I tried to forget the whole unwholesome episode as quickly as possible :-)

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

No, I just want to use the implementation that happens to be useful for
my subclass.

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

Hey, straightjackets aren't enough, you need ball and chains! ;-)

Seriously, I see that multimethods can solve problems. It's just that I
have seen so many constructs that were later replaced by slightly less
powerful and much safer constructs.

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

Too detailed for now.

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

Hey, but that's sensible. The less languages you have in shop, the less
problems you have reassigning people between tasks. And every constraint
removed if making life easier - there are already enough constraints to
keep satisfied.

I don't pretend I'm happy with that. I just mean that I can understand
the PHB reasoning at work, and I don't know any good alternatives.
Welcome to real life - TANSTAAFL.

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

They certainly would work better with a language with a "more standard"
syntax ("Lots of Irritating Superfluous Parentheses" and all).
I know it's something that people learn to "see through", but it's
certainly massively irritating getting used to it.

I did some programming in Lisp, but I never fully got rid of that
parenthesis paranoia... maybe a full year of part-time Lisp programming
isn't enough.
Though that's already too long for a commercial project. Job
satisfaction is an important factor, and forcing developers to adopt to
many parentheses is just a needless irritation (from a boss's
perspective, Lispers will do fine with them of course).

> Yet another point: Inside every substantially advanced program, 
> there's a lisp trying to get out.

I agree with that, though one could replace "Lisp" with other language
names.

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

I have seen similar claims for almost any language "with a mission",
such as Smalltalk and Eiffel. Which happens to be the languages that I
dug into well enough to see such statements - I'm pretty sure that many
other languages claim this as well.

I'd be interested in any hard facts about such issues. (I know that they
are difficult if not impossible to come by. I'm just thinking wishfully,
and aloud...)

Regards,
Jo