Python from Wise Guy's Viewpoint

[james anderson]

Joachim Durchholz wrote:
> 
> mike420 at 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.

...