prototypes in Python [was: what is good in Prothon]

[has]

michele.simionato at poste.it (Michele Simionato) wrote in message news:<95aa1afa.0405012134.2b43ad6f at posting.google.com>...

> Actually, I do NOT support the idea of making prototypes part of the
> core language.

Ditto. [To paraphrase:] There should be one, and preferably only one,
way of doing things. Including OOP.


> If I was writing a new language, I would do Python with prefix notation ;)

You sick disturbed Lisp lover, you... ;p
 

> Seriously, I think that everybody interested in language design should
> first study the existing languages and see what has already been
> tried in the last fifty years: then probably 99% of "new" proposal
> would be dismissed.

Amen. (I figure in another ten or fifteen years somebody will finally
get round to successfully re-inventing Lisp as the Next Big Thing, and
then things can actually start moving forward again...)


> I have not studied prototypes, so I may be wrong, 
> but I have a gut feeling that they are not such a good idea. 

I have a gut feeling you should study them first, before asking your
gut for its opinion. A gut's gotta have something solid to chew on. ;)


> One thing I like about classes is that they are self-documenting: when you 
> see a class, you know which methods are in it.

<cough>Dylan</cough>

(And Dylan is one of those languages that makes me tear up at the
thought of it. Perhaps someday its prince will come? One can but
hope...)


> Of course, you can add 
> methods at run-time, but this is not good style: it is good to have the 
> ability, but you should not abuse it. OTOH, in prototype languages you 
> dynamically add methods all the time and the definitions are scattared in 
> different places, so it is not obvious to know what an object is doing 
> unless you read all the program (including imported modules). 

I would say proto-OO philosophy is a bit closer to Lisp philosophy
than Java philosophy. However, I think you'll find good proto-OO
programmers have no more problems staying disciplined than good
class-based programmers.

Now, whether mediocre programmers would manage to screw up any worse
in proto-OO than class-OO is a separate question; but then, spaghetti
is spaghetti whatever the language. Sure you can spread object
behaviour from one end of the source to the other if you want to, but
you can also write 1000-line procedures in C - and it's not like you
can blame C's object model for that because it doesn't even have one.


So perhaps the solution isn't creating a more restrictive, less
flexible language (and then retroactively slapping all sorts of mad
complexity on top to cater for the competent users who quickly object
to the limitations it indiscriminately imposes upon them); but
creating a simple, open language that can scale extremely well as-is,
and providing training wheels to the more thoughtless, naive users
till they learn some responsibility for themselves.

Of course, that leaves you with the political problem that no l33t
hAx0r would ever admit to needing training wheels and will insist on
taking the biggest baddest Ferrari regardless of whether they're
competent to handle it or not. But then, it's not my responsibility to
keep them from wrapping their dumb selves round the first lamppost
they meet if that's what they'll insist on doing. Plus it's one less
doofus to be getting in my road later.;)


> This is already a problem with regular inheritance, prototype inheritance
> would worsen the situation, at least ISTM and IMHO.

Feel free to check out any of my proto-OO programming efforts, and
critique away. <g>

You might also check out my HTMLTemplate Python module, which although
it uses MI for behavioural composition retains many other aspects of
its original proto-OO design and philosophy. In a field dominated by
vast, lumbering PHP-copycats and wannabes, I think it rather makes for
one of those "breaths of fresh air" somebody mentioned earlier. ;)