Joachim Durchholz wrote:
> Oh, you're trolling for an inter-language flame fest...
I'm stimulating a productive discussion / polemic. That's what they try
to do in classrooms, for example. If you want to engage in a flame-fest,
do not blame anyone but yourself. Also read my post "Cross-posting is good"
regarding this.
>> 3. no multimethods (why? Guido did not know Lisp, so he did not know
>> about them) You now have to suffer from visitor patterns, etc. like
>> lowly Java monkeys.
>
> Multimethods suck.
>
> The longer answer: Multimethods have modularity issues (if whatever
> domain they're dispatching on can be extended by independent developers:
> different developers may extend the dispatch domain of a function in
> different directions, and leave undefined combinations; standard
> dispatch strategies as I've seen in some Lisps just cover up the
> undefined behaviour, with a slightly less than 50% chance of being
> correct).
To me this is like saying "uni-methods are bad because they can be
called on objects that do not have them" or "functions are bad because
they can be given an argument they do not expect". If you disagree and
think that multimethods are a BIGGER problem than uni-methods, please
provide a specific example (in CLOS)
From: Tom Breton
Subject: Re: Python from Wise Guy's Viewpoint
Date:
Message-ID: <m3ptgslp2n.fsf@panix.com>
·······@ziplip.com writes:
> Joachim Durchholz wrote:
>
> > Oh, you're trolling for an inter-language flame fest...
>
> I'm stimulating a productive discussion / polemic. That's what they try
> to do in classrooms, for example. If you want to engage in a flame-fest,
> do not blame anyone but yourself. Also read my post "Cross-posting is good"
> regarding this.
Translation, you're trolling for an inter-language flame fest. Just
like he said.
--
Tom Breton at panix.com, username tehom. http://www.panix.com/~tehom
·······@ziplip.com wrote:
> [...] If you [...] think that multimethods are a BIGGER problem than
> uni-methods, please provide a specific example (in CLOS)
I can't write in CLOS, I'd make all sorts of stupid mistakes since I
never read more than the language specs (and that's several years in the
past).
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).
I might be conflating this with Scheme, though. I looked at both at
about the same time :-)
I'd really like to see a Lisp dialect that valued reliability over raw
expressive power. But I fear this isn't very high on the agenda of the
Lisp community. Besides, it would be difficult to do that - Lisp offers
no protection against peeking at internals and setting up all that
unsafe-but-powerful stuff. In my eyes, Lisp is a valuable
experimentation lab for new language mechanisms, but not fit for
production use.
Let me add a troll-bait disclaimer: Actually I don't see *any* language
that's fit for production use. All languages are just approximations to
that ideal, some are better, some are worse.
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...
Regards,
Jo
Joachim Durchholz <·················@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.
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 systems - with a few lines of code - that would have
required a complete rewrite with more limited languages.
> 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?
> 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.
--
(espen)
Joachim Durchholz <·················@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.
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.
> 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?
> 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.
--
(espen)
Espen Vestre wrote:
> Joachim Durchholz <·················@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
From: Joe Marshall
Subject: Re: Python from Wise Guy's Viewpoint
Date:
Message-ID: <ismkc66s.fsf@ccs.neu.edu>
Joachim Durchholz <·················@web.de> writes:
> 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...
They are. Using a simple super/precursor/whatever call delegates
responsibility to the subclass that rightly belongs to the superclass.
From: james anderson
Subject: Re: Python from Wise Guy's Viewpoint
Date:
Message-ID: <3F93F6DF.252011AC@setf.de>
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
Joachim Durchholz <·················@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)
Espen Vestre wrote:
> Joachim Durchholz <·················@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
Joachim Durchholz <·················@web.de> writes:
> Maybe. I'm pretty sure it wasn't Xerox, but something else.
Perhaps a "Siemens lisp machine"? (which was a Xerox with a Siemens
sticket on it :-))
> > 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.
What a funny comment, I don't think you understand how this works.
Try to do some CLOS programming, maybe you'll like it!
> 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.
Who said anything about a free lunch? And why do you think you need
to welcome me to real life? I know quite a deal about badly organized
companies and how the Dilbert principle works in real life.
> 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).
I have seen programmers adopt very quickly to lisp syntax, I don't
know why you had a problem with it. Maybe you had bad instructors
or a bad programming environment.
> > 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.
No, you can't.
--
(espen)
On Mon, 20 Oct 2003 19:33:32 +0000, Espen Vestre wrote:
> Joachim Durchholz <·················@web.de> writes:
> ...
>> > 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.
>
> No, you can't.
True, for within every substanialy advanced Python program is a lumberjack
trying to get out.
/BA
Espen Vestre wrote:
> Joachim Durchholz <·················@web.de> writes:
>
>> Maybe. I'm pretty sure it wasn't Xerox, but something else.
>
> Perhaps a "Siemens lisp machine"? (which was a Xerox with a Siemens
> sticket on it :-))
No, it had some US label on it - but my recollections are getting quite
dim here, I fear I'm producing random noise instead of information on
that topic.
It's all too long in the past :-)
(Actually, the mainframe that we were working on was a truly
international machine: the outside stickers said "Siemens", the inside
stickers said "Fujitsu", and the manuals said "IBM". That was before
Siemens bought Fujitsu.)
>> 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).
>
> I have seen programmers adopt very quickly to lisp syntax, I don't
> know why you had a problem with it. Maybe you had bad instructors or
> a bad programming environment.
No, your sample is biased: your everyday acquaintances are those who,
sooner or later, made that transition. Those who don't will vanish from
your surroundings, sooner or later.
(Admittedly, I'm guessing here. But this sounds reasonable, at least for
me.)
Anyway. Whether the PHBs' reasoning is valid or not, it will prevent
that Lisp will enter the mainstream in the foreseeable future.
>>> 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.
>
> No, you can't.
Well, I have seen other names in similar quotes...
Regards,
Jo
Joachim Durchholz <·················@web.de> writes:
> No, your sample is biased: your everyday acquaintances are those who,
> sooner or later, made that transition. Those who don't will vanish from
> your surroundings, sooner or later.
> (Admittedly, I'm guessing here. But this sounds reasonable, at least for
> me.)
You guess a lot, and not very educated.
--
(espen)
Espen Vestre wrote:
> Joachim Durchholz <·················@web.de> writes:
>
>
>>No, your sample is biased: your everyday acquaintances are those who,
>>sooner or later, made that transition. Those who don't will vanish from
>>your surroundings, sooner or later.
>>(Admittedly, I'm guessing here. But this sounds reasonable, at least for
>>me.)
>
>
> You guess a lot, and not very educated.
WILL YOU STOP THAT PLEASE?!!!
I hate when people read and quote ONLY what they want to see and quote.
I remind you that JoD answered the following remark:
> I have seen programmers adopt very quickly to lisp syntax, I don't know why
> you had a problem with it. Maybe you had bad instructors or
> a bad programming environment.
I would keep my mouth shut if the author of the citation above was somebody
else, not Espen Vestre Himself. Peculiar context for mentioning the word
"education"...
==
There is a movie where the hero, a little boy tells Bruce Willis that people
with whom he communicates see only things they want to see.
Those people are DEAD.
Be careful Monsieur Espen Vestre.
===========
Anyway, all this proves that cross-newsgroups postings are calamitous. I removed
the Pythonistas from *this one*, they seem innocent, until the next abuse...
Jerzy Karczmarczuk
Jerzy Karczmarczuk <·······@info.unicaen.fr> writes:
> WILL YOU STOP THAT PLEASE?!!!
Will you please stop shouting?
> I hate when people read and quote ONLY what they want to see and quote.
If you followed the whole thread, you would have seen that most of the
discussion was caused by Jochen making completely false claims about
CLOS, which was based on making wrong _guesses_ about the behaviour
from looking at the specs.
My somewhat rude comment must be seen in that context, and I should of
course rather have shut my mouth.
> There is a movie where the hero, a little boy tells Bruce Willis that people
> with whom he communicates see only things they want to see.
>
> Those people are DEAD.
>
> Be careful Monsieur Espen Vestre.
What on earth are you insinuating? This is getting ridiculous.
--
(espen)
Jerzy Karczmarczuk <·······@info.unicaen.fr> writes:
> WILL YOU STOP THAT PLEASE?!!!
Will you please stop shouting?
> I hate when people read and quote ONLY what they want to see and quote.
If you followed the whole thread, you would have seen that most of the
discussion was caused by Joachim making completely false claims about
CLOS, which was based on making wrong _guesses_ about the behaviour
from looking at the specs.
My somewhat rude comment must be seen in that context, and I should of
course rather have shut my mouth.
> There is a movie where the hero, a little boy tells Bruce Willis that people
> with whom he communicates see only things they want to see.
>
> Those people are DEAD.
>
> Be careful Monsieur Espen Vestre.
What on earth are you insinuating? This is getting ridiculous.
--
(espen)
Joachim Durchholz wrote:
> Multimethods, on the other hand, are indeed powerful, but they are also
> dangerous.
Life is dangerous.
> Just like GOTO - you can use it to make code better, but
> often enough it's making it worse.
How often?
> 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.
Is this based on actual experience, or are you just guessing?
> 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.
No, because people are already educated under the assumption that they
are not bright. This assumption is very deeply rooted in our society,
but I don't see any evidence that it has actually improved anything. To
the contrary, it seems to me that people stay "average" _because_ they
are treated this way. IMHO it's very cynical to assume that other people
are less bright than oneself.
Did it ever occur to you that learning a language designed for experts
can make you a better programmer?
Pascal
Pascal Costanza wrote:
> Joachim Durchholz wrote:
>
>> Multimethods, on the other hand, are indeed powerful, but they are
>> also dangerous.
>
> Life is dangerous.
OK - I agree that danger is a factor only if better alternatives are
available.
>> 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.
>
> Is this based on actual experience, or are you just guessing?
Guessing.
Educated guessing though.
I admit that practical experience would be better. But my time budget is
limited, so I have to rely on guesswork. (Like most programmers.)
However, I think that the problems will usually be attributed to the
wrong reasons. Most people don't look past immediate causes of their
software failures (that's why I gave the C buffer overflow problem - not
because C buffers are similar to multimethods, they aren't, but to
demonstrate the mode of thinking that attributes common problems to
other places than their real roots).
Of course, if multimethods are used rarely, the problems will be rare.
>> 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.
>
> No, because people are already educated under the assumption that they
> are not bright. This assumption is very deeply rooted in our society,
> but I don't see any evidence that it has actually improved anything.
No, but there's nothing to improve here.
> To
> the contrary, it seems to me that people stay "average" _because_ they
> are treated this way.
Only in some cases. The majority of people slackens down and refuses to
learn after some point in life. Some do this at an age of 20 years,
others wait until they are 60, and some stay interested and alert for
their entire life - but they are a minority.
Heck, I myself feel the temptation to ease down...
> IMHO it's very cynical to assume that other people
> are less bright than oneself.
It's not brightness. It's willingness to learn.
Besides, I never said I'm brighter than others - I'm most certainly not.
I do have a knack for system design, which is offset by deficits in many
other areas (which are irrelevant to technical newsgroups, so they don't
stick out).
> Did it ever occur to you that learning a language designed for experts
> can make you a better programmer?
Learning /any/ language with a yet-unknown paradigm will make you a
better programmer. Actually I learned a lot from (in chronological
order) Lisp, Prolog, Smalltalk, Eiffel, and Haskell.
This doesn't mean that I think that I'd want to use all these languages.
Regards,
Jo
From: james anderson
Subject: Re: Python from Wise Guy's Viewpoint
Date:
Message-ID: <3F93D20A.B9D0C30D@setf.de>
Joachim Durchholz wrote:
>
> ·······@ziplip.com wrote:
>
> > [...] If you [...] think that multimethods are a BIGGER problem than
> > uni-methods, please provide a specific example (in CLOS)
>
> I can't write in CLOS, I'd make all sorts of stupid mistakes since I
> never read more than the language specs (and that's several years in the
> past).
> 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).
> I might be conflating this with Scheme, though. I looked at both at
> about the same time :-)
how about formulating some examples in some language which is adequate to
express them? perhaps somewhat more concretely than the allusions in your
earlier message, in which you suggest some problem domains and some
amorphously difficult decisions, but despite several rereadings, never
concretly indicate what does not "work".
what does "different directions" mean? "glue code"? "asymmetry"? a "base
class"? a "module"? an "orthogonal extension"?
what is the distinction between "dynamic dispatch" and "parametric polymorphism".
if not in the context of clos, then, well, in english.
>
> I'd really like to see a Lisp dialect that valued reliability over raw
> expressive power. But I fear this isn't very high on the agenda of the
> Lisp community. Besides, it would be difficult to do that - Lisp offers
> no protection against peeking at internals and setting up all that
> unsafe-but-powerful stuff.
what are "internals", what is "protection"?
please at least propose some concrete examples or use cases before making
assertions to which your opening sentence does not lend much authority. it
would be nice to understand better the problem which you appear to want to
discuss, but you will need to be more thorough in your exposition.
...
> In my eyes, Lisp is a valuable
> experimentation lab for new language mechanisms, but not fit for
> production use.
> Let me add a troll-bait disclaimer:
no troll disclaimers necessary, just substance.
...
james anderson wrote:
> Joachim Durchholz wrote:
>
> how about formulating some examples in some language which is adequate to
> express them? perhaps somewhat more concretely than the allusions in your
> earlier message, in which you suggest some problem domains and some
> amorphously difficult decisions, but despite several rereadings, never
> concretly indicate what does not "work".
>
> what does "different directions" mean? "glue code"? "asymmetry"? a "base
> class"? a "module"? an "orthogonal extension"?
>
> what is the distinction between "dynamic dispatch" and "parametric polymorphism".
>
> if not in the context of clos, then, well, in english.
Sorry - this would go beyond the scope of a newsgroup discussion. It
would take me several hours to get this all sorted out, written down,
and worded so that it's generally understandable.
And, frankly, I already have spent too much time on this thread.
I do intend to writ it all up and publish it on a WWW site - in my
copious spare time... :-(
Let me assure you that all these nebulous terms are due to time
constraints, not due to fuzzy reasoning.
Sorry if this all sounds like a lame excuse (actually it is).
And sorry to leave you with lots of fuzzy allusions and no concrete
data. Others may be willing to fill in more details.
>>I'd really like to see a Lisp dialect that valued reliability over raw
>>expressive power. But I fear this isn't very high on the agenda of the
>>Lisp community. Besides, it would be difficult to do that - Lisp offers
>>no protection against peeking at internals and setting up all that
>>unsafe-but-powerful stuff.
>
> what are "internals", what is "protection"?
No way to define an opaque type. AFAIK, modern Lisps allow user-defined
types, but they offer no way to protect them against inspecting their
internals. I'd prefer to have at least a grain of information hiding...
Regards,
Jo
[ Follow-up redirected to comp.lang.lisp ]
Joachim Durchholz <·················@web.de> writes:
> james anderson wrote:
>
> > Joachim Durchholz wrote:
[SNIP]
> >>I'd really like to see a Lisp dialect that valued reliability over raw
> >>expressive power. But I fear this isn't very high on the agenda of the
> >>Lisp community. Besides, it would be difficult to do that - Lisp offers
> >>no protection against peeking at internals and setting up all that
> >>unsafe-but-powerful stuff.
> > what are "internals", what is "protection"?
>
> No way to define an opaque type. AFAIK, modern Lisps allow
> user-defined types, but they offer no way to protect them against
> inspecting their internals. I'd prefer to have at least a grain of
> information hiding...
Well... Using INSPECT one can "look inside" a type, but one has almost
the same (possibly the same) amount of introspection in (say) Python,
using dir() (and very handy it is, not as good as reading
documentation, but for those "I need to check this now" moments, it
can often be sufficient).
One should, as usual, follow one's introspective moments by checking
The Reference(s), to see if what one saw, introspecting, is
"supported" or "unsupported" (if the latter, one can bet things will
break in interesting ways, either "soon" or "on next upgarde"). But,
at times, that can be the only way to use a third-party module taht
*almost* fits one's needs.
I saw a horror-story of someone having to retro-fit third-part C++
modules by clever run-time mangling of things, to get it to work
Right, instead of "it does almost what the documentation says, but not
quite and fixing it is faster than getting a patch or rolling it
ourselves". I think it was in a thread in comp.lang.lisp, a few years
back, regarding why it was a *bad* thing forbidding access to
non-exported sympols from a package. Not exporting something is a good
sign taht one shouldn't touch it and well-behaved programmers
won't. They *may* file a bug saying "this would be handy if it was
supported", but they should, in general, not go ahead and use it.
//Ingvar
--
Coffee: Nectar of gods / Aesir-mead of sysadmins / Elixir of life
From: james anderson
Subject: Re: Python from Wise Guy's Viewpoint
Date:
Message-ID: <3F93F764.3D2D8969@setf.de>
Joachim Durchholz wrote:
>
> james anderson wrote:
>
>
> No way to define an opaque type. AFAIK, modern Lisps allow user-defined
> types, but they offer no way to protect them against inspecting their
> internals. I'd prefer to have at least a grain of information hiding...
unless the writer is willing to me more specific, i suggest that the most
significant term in the above paragraph is "AFAIK".
>
> Regards,
> Jo
Joachim Durchholz <·················@web.de> writes:
> I'd really like to see a Lisp dialect that valued reliability over
> raw expressive power. But I fear this isn't very high on the agenda
> of the Lisp community.
From someone who just sentences ago admitted to having no practical
experience with Common Lisp, this is an amazingly misinformed and
confused statement.
> In other words: Lisp is too powerful and dangerous, [..]
I have never, ever, over the years I've been using lisp myself and
talked to others who are using it, observed any such problem.
If you are afraid of method combination, then just don't use it. I can
guarantee you that it will not jump at you from some dark cave when
you least expect it, ripping your heart out with razor-sharp
claws. Actually, it's more like a well-trained, domesticated dog: When
you tell it to play dead, you won't know it's there until you
explicitly bring it to life. The same goes for most other features you
might find intimidating.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld wrote:
> If you are afraid of method combination, then just don't use it. I can
> guarantee you that it will not jump at you from some dark cave when
> you least expect it, ripping your heart out with razor-sharp
> claws.
Unless you're maintaining code written by others.
I don't know what's the norm in the Lisp community, but I spend about
80% of my time reading and modifying legacy code. If a language offers a
dark corner, I'm sure I'll hit it more often than I want.
The bad thing about such dark corners is: if you try to clean the mess
up, you'll invariably break things. After a few such mishaps, you don't
even try to mess with that code. Avoiding messes will, after a few
maintenance cycles, produce a true mess, until the entire system is
thrown away and rewritten from scratch, in a different language, with
different dark corners. Which means that, in a decade from now, when the
original authors are gone, the same cycle will start.
Not my idea of professional software development. No sir.
> Actually, it's more like a well-trained, domesticated dog: When
> you tell it to play dead, you won't know it's there until you
> explicitly bring it to life. The same goes for most other features you
> might find intimidating.
Hey, that's the first time anybody said I found a concept intimidating!
Regards,
Jo
Joachim Durchholz <·················@web.de> writes:
> Frode Vatvedt Fjeld wrote:
>
> > If you are afraid of method combination, then just don't use it. I can
> > guarantee you that it will not jump at you from some dark cave when
> > you least expect it, ripping your heart out with razor-sharp
> > claws.
>
> Unless you're maintaining code written by others.
> I don't know what's the norm in the Lisp community, but I spend about
> 80% of my time reading and modifying legacy code. If a language offers
> a dark corner, I'm sure I'll hit it more often than I want.
> The bad thing about such dark corners is: if you try to clean the mess
> up, you'll invariably break things. After a few such mishaps, you
> don't even try to mess with that code. Avoiding messes will, after a
> few maintenance cycles, produce a true mess, until the entire system
> is thrown away and rewritten from scratch, in a different language,
> with different dark corners. Which means that, in a decade from now,
> when the original authors are gone, the same cycle will start.
> Not my idea of professional software development. No sir.
You'll find the same problems with any large project in any language.
Maintainable, Complex, Inexpensive
Choose any 2 and the 3rd is where you'll pay for it.
Gregm
Joachim Durchholz <·················@web.de> writes:
> Unless you're maintaining code written by others. I don't know
> what's the norm in the Lisp community, but I spend about 80% of my
> time reading and modifying legacy code. If a language offers a dark
> corner, I'm sure I'll hit it more often than I want. [..]
But this is just like being afraid of the dark! You have made it quite
clear that you know next to nothing about method combination, and that
you have made false assumptions about it, based on which you conclude
that there are "dark corners". There is no dark corner here. Method
combination is a feature that is relatively infrequently used, but can
sometimes provide wonderful, readable and maintainable solutions that
have no parallel in other languages that I know of. Using superficial
aspects of its syntax as a reason to disregard the language, is
downright absurd.
--
Frode Vatvedt Fjeld
Joachim Durchholz wrote:
> I'd really like to see a Lisp dialect that valued reliability over raw
> expressive power. But I fear this isn't very high on the agenda of the
> Lisp community.
Reliability does not have to come from a strait-jacket language. Here is
a C++ Fanatic converted to Python, who gets reliability from test-driven
development: http://www.artima.com/weblogs/viewpost.jsp?thread=4639
> Let me add a troll-bait disclaimer: Actually I don't see *any* language
> that's fit for production use.
I have used CL for a huge application, using CLOS heavily. The first
couple of months had me refactoring quite a bit as I searched for
personal guiding principles, esp. with regards to multiple inheritance.
On a prior substantial app, I worked out my personal prefs with regards
to the model-view thing.
In the end I have my own rules which /limit/ the ways I use CLOS. These
self-imposed constraints tame the potentially wild beast. The only power
lost is the power to tie myself in knots.
OO /is/ a slightly different paradigm, and CLOS does have a ton of
expressive power. It is also approachable, so it is easy to just dive in
and start winging code around. But there is no reason to think one will
not have to train a few neurons to get /fluent/ in something so substantial.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton wrote:
>
> Reliability does not have to come from a strait-jacket language. Here is
> a C++ Fanatic converted to Python, who gets reliability from test-driven
> development: http://www.artima.com/weblogs/viewpost.jsp?thread=4639
Come on, C++ is an underspecified language with loose semantics (for
compatibility and efficiency reasons).
How often do you accidentally introduce ''undefined/unspecified
behaviour'' in your Python programs? How often do you get segfaults in
Python which are caused by your mistake, not a bug in interpreter?
Best regards,
Tom
--
.signature: Too many levels of symbolic links