What is good about Prothon?

[Mark Hahn]

In AS, a, b, and c are all equivalent and independent; any changes
made to one do not affect the others. It's a no-brainer to use, and
quite safe. In Prothon, b and c derive state and behaviour from a
unless/until it's modified locally (ie on b or c). Changes made to one
may or may not show up in another depending on the derived
relationship and subsequent changes*,

I told you before that we had a Self-like copy and asked you then if using
that would make you happy. You never answered that question. Now you've
posted an example that ignores the Prothon copy (yes, it is spelled exactly
like the AS copy

Will you only be happy with Prothon if I rip out everything that is not like
AS or Self? Isn't having Prothon capable of doing everything AS and Self
can do, in the same way they do it, good enough for you? I know for a fact
that it can do everything they can do because there are months left in the
design and if you just got rid of that chip on your shoulder and pitched in
and helped, it could work well for people who want to use it like you do.

You should be aware that we are discussing right now the possibility of
putting the whole "class-mimicing" structure on an object that is a
descendent of a pure Self-like root object. Lenard is doing a pretty good
job of explaing to me why we sometimes need objects without the "class-like"
methods __new__ and __init__. Here is his response to my question about
that ("Object" is the "pure" object and "buildable" would have __new__ and
__init__):

------ Beginning of Lenard Lindstrom's post ------

This is all very logical and I have no problem with it, but can you give me
a usage example of an object that would inherit directly from Object instead
of Buildable?

I do not know about a specific usage example, but knowledge bases in
artificial
intelligence comes to mind as a general case:

object ClydeLike(Object):
$colour = "grey"
$legcount = 4
$mass = 2500

object Clyde(ClydeLike): # Lieberman got it wrong. I can explain in a
separate posting.
pass

object Fred(ClydeLike):
$mass = 2400

Probably anything whose attributes are initialized to contants, that is, no
calculations
are required. Then specific initial attribute values for an extension object
are set
with the object statement.

If descriptors are implemented in Prothon then value checks and special
computations
can be done on a per attribute bases, removing one more need for an _init_
function.
The Buildable prototype would come into play for immutables and objects that
convert
several input values into a different internal representation at creation
time.

---------- End of Lenard Lindstrom's post ------------

Lenard even said "Lieberman got it wrong." See! If you come over and help
out there are other like-minded people to work with you

By the way, the above code samples are from current builds of Prothon. The
object keyword was added recently.

 

[Mark Hahn]

Eh, I'll see what I can do. Here's a short example to get you started:

This is plenty. I'm getting a good idea of what is going on here.

In AS, every compiled script is itself a script object. Scripts can be
loaded into other scripts using the 'load script' command; this
provides the foundation for library-based design.

I see no difference from a Prothon module so far (which is good).

Script objects can
also be declared within other script objects and handlers (aka
procedures) using the 'script [identifier]...end script' block. This,
along with their support for delegation via the 'parent' property,
allows you to do prototype-based OOP.

Oh, so the script is also the function. That is a bit limiting, not having
functions within a script.

Incidentally, because script
objects have first-class syntactic support, they also support modular
design within a single file, sectioning off parts as separate
namespaces without having to move code off into separate files as
you'd do in Python;

This I REALLY like. I'll put this on the list of ideas to "steal" for
Prothon.

Thus a single, very generic type (script) can perform all the roles
that it takes Python several specialised and largely
non-interchangeable types (classobj, instance, module) to do.

Prothon is the same. Using a module as a prototype is a trick that recently
paid off. We have no structure or rules making one object unable to play
the role of another. As we slowly unwind our brains from class-thinking
(not an easy task) I expect the benefits to pour forth.

Other nice stuff: while AS allows only a single delegate per object,
the ability to compose object behaviour at runtime makes it much more
powerful than class-based single inheritance, and less of a PITA to
use than MI. Just create and delegate-chain together the objects you
want as and when you need them.

You don't have to convince me that dynamic delegation is good.

[* Python shouldn't feel too smug, however, seeing as I had no better
luck trying to dynamically attach property objects to class instances,
and had to resort to sticking nodes into a private dict accessed via
__getattr__ and __setattr__.]

We'll make sure Prothon can feel smug in this regard.

Good programmers know how to add features;
great ones know how NOT to.

I will be sure to remember that after Prothon is designed. Right now we are
not adding features to Prothon, we are designing version 0.1. You have to
add features when you start with zero features. Even you must admit a
language with zero features is unintresting

 

[has]

You've mistranslated your example.

Not at all. I was arguing these issues long before Prothon got its
copy() method. I'm aware of its recent addition, but it doesn't
really change anything: the canonical Prothon way to create new
objects is still b = a(), not b = a.copy().

[FWIW, at least Prothon's not as confusing as Io, whose misleadingly
named "clone()" doesn't in fact clone at all, but does the
make-new-empty-object-that-delegates-to-the-existing-one thing that
Prothon's __call__ does.]


Anyway, this leads me to my next question: how many ways should one
need to create new objects? I now count three in Prothon, which is
certainly one too many. And what's it going to do about it?

The art of great software design isn't adding features, it's getting
rid of them.

 

[has]

I told you before that we had a Self-like copy and asked you then if using
that would make you happy. You never answered that question. Now you've
posted an example that ignores the Prothon copy (yes, it is spelled exactly
like the AS copy

See my other post for the reason why I did this (yes, it was quite
intentional).


But to answer your question directly: no, simply adding a copy()
operation (the "trying to please everybody, and ultimately pleasing
no-one" strategy) won't make me happy; I have no use for another C++.


You might think I'm merely being obtuse; trying to give you a bad day
just for jollies. But no; and perhaps a little digression will help
explain why...

Right now you should be sketching out lots of rough ideas quickly and
in the large, critiquing them, throwing some away, experimenting
further with others, critiquing the results of those tests, revising,
reviewing, refactoring those ideas, compacting and simplifying them,
stripping them down as hard as you can to see just how far you can
simplify them, reversing direction and changing tack; and not letting
yourself get blocked in to a single developmental rat-run where you
can only proceed forward on a single, predetermined path.

Or, in short, for every feature added: 1. justify its addition; and 2.
find at least one other feature - preferably more - that can't
adequately justify theirs and strip them right back out again.

This is another lesson I learnt in art school, btw: when working in
clay, one should always build up. Add a bit of clay, step back,
analyse the result. If you add too much or put it in the wrong place,
don't try to carve it flat or smear it into position; instead, cut the
whole lot right back 'to the bone' and start building it up again.

For me, who learnt this lesson very quickly, it was rather depressing
watching the rest of the class, who didn't, plod away day after day,
fighting a losing battle for hours on end with a material they just
couldn't seem to understand as it turned into a buttery caricature
instead of a portrait head.

Meantime, I'm scooting around the room like a madman, never standing
more than a minute or two in front of my piece before stepping back,
or walking away, or going to get drinks from the vending machine. And
each morning I came in, I'd take a long look with fresh eyes at where
I'd got to the previous day, and if I didn't like it, out came the big
knife as I'd chop great gobs off and throw them back in the clay bin.

I think by the end of that class I'd produced two pretty decent busts,
and had already made a start on the third. The better of the two I
completed within three afternoons too, with the bulk of it done in two
and the third spend mostly idling around and occasionally diving in to
tweak a feature here or there.


Now, wood and stone carving I suck at. You get one chance to get it
right, and if you screw up just once you have to start all over again.
Such fear of failure made me nervous and timid - which, considering
the price of each fresh bit of stone, maybe wasn't entirely
unsurprising - and the results were insipid and flat and utterly,
utterly boring.

But clay I love. It rewards excitement and adventure, and encourages
risk-taking and experimentation; the more bold and daring you are, the
more it becomes alive. If you screw up along the way there's no
permanent loss, and the valuable lessons you gain from doing so _far_
outweigh the cost of any time spent. So you work fast and loose, try
lots of different ideas quickly to see where they might go, screw up
often and learn as much by your mistakes as your successes.


Code is like clay. It's so frustrating for me to see programmers treat
it like stone. If you were in my art class I'd hand you a pile of
newsprint and box of charcoal and have you do 30-second sketches for
an hour. Then another hour doing five-minute drawings. And I can
guarantee the if I then set you to do a finished drawing in the
remaining hour the final result would be far, far better than if I'd
given you a whole day - or even week - to work on it.

--

I'll see if I can get around to answering some of your other questions
later. Meantime, I hope you can find a little time to spend pondering
the above. Who knows, maybe even put what implementation you've done
aside for a bit, and go stroll round the room for a while... maybe
catch some fresh perspective - even surprise yourself.


(p.s. My new favourite phrase for the week: "Premature implementation
is the root of all evil." Hope nobody minds!;-)

 

[Mark Hahn]

But to answer your question directly: no, simply adding a copy()
operation (the "trying to please everybody, and ultimately pleasing
no-one" strategy) won't make me happy; I have no use for another C++.

You have a very warped mind. To say that having Python two-tier object
construction and Self-like constructs in the same language is C++ is
ludicrous.

You have finally answered a question I have asked several times. Having
anything but AS or Self in the language will keep you from being happy. Now
that I know where you stand I can quit wasting my time trying to get you to
help out.

You keep pitching that you are such a creative artist, but if you were you'd
be helping find a way to solve the conundrum of merging the Python and Self
worlds and making positive contributions instead of just throwing stones.

 

[Donn Cave]

You have a very warped mind. To say that having Python two-tier object
construction and Self-like constructs in the same language is C++ is
ludicrous.

He's saying `language that tries to please everybody [by adding
features like copy instead of doing it right in the first place] == C++'
He could have a point. (Is there going to be an optional __copy__
method?)

You have finally answered a question I have asked several times. Having
anything but AS or Self in the language will keep you from being happy. Now
that I know where you stand I can quit wasting my time trying to get you to
help out.

You keep pitching that you are such a creative artist, but if you were you'd
be helping find a way to solve the conundrum of merging the Python and Self
worlds and making positive contributions instead of just throwing stones.

He probably thought they were pearls of wisdom. Guess you don't
want any more, anyway.

Donn Cave, (e-mail address removed)

 

[Mark Hahn]

He's saying `language that tries to please everybody [by adding
features like copy instead of doing it right in the first place] ==
C++' He could have a point. (Is there going to be an optional
__copy__ method?)

Yes, there already is a copy method. It solves the problem he posted of AS
versus Prothon. Adding copy is apparently turning Prothon into C++. I've
never thought of something as simple as copy as being an evil thing. (The
funny thing is I added copy as part of porting Python's methods. It has
nothing to do with Self or AS, but it happens to match his needs).

He probably thought they were pearls of wisdom.

He and I have been going in circles for weeks. I keep trying to get him to
identify what would really make him happy in Prothon and apparently having
anything that resembles the two-tiers of object creation of Python is an
anathema to him and has to be removed. If it stays and there is anything
else in there that he'd like then it would be C++.

Guess you don't want any more, anyway.

Depends on what you mean by pearls of wisdom. I've been getting a lot of
great ideas from both Prothon and Python mailing lists. I've been spending
a lot of time arguing with Has (we started on the Prothon lists) because he
has knowledge of AS and Self and would love to have him contribute. So far
he will only tell me that Prothon sucks because of the two tiers and his
only recommendation is to treat my code like clay and tear it down and start
over.

 

[has]

He's saying `language that tries to please everybody [by adding
features like copy instead of doing it right in the first place] ==
C++' He could have a point. (Is there going to be an optional
__copy__ method?)

Yes, there already is a copy method. It solves the problem he posted of AS
versus Prothon.

One: No, it does not. But it does prove _just how little_ of what I've
said you have actually understood.

Two: BTW, learn to differentiate between "ludicrous" and "hyperbole".
They are _not_ the same.

Three: You I was just giving you a hard time for the sake of it? I
wasn't; you asked for criticism, and I gave it. It just wasn't the
criticism you wanted. You want to hear what I say when asked to
critique something I think is a piece of piss but simply don't care
about enough to say? "Yes, that looks very nice/interesting. I'll be
very curious/interested to see how where it goes."

Four: You think it's just you? Obviously you've never seen me chewing
AppleScript a new one; it's such a fundamentally flawed language that
I'm now actually working actively against it. (MacPython-to-AEM
bridge, more hours spent critiquing and reading and learning than I
can shake a stick in, mystery language project in development; hey,
you do the math.)

Five: You think I don't give my own work this treatment? Obviously you
have never seen me spend weeks or months working at something, only to
throw it out the moment I've uncovered a flaw too deep or uneconomic
to fix, or simply discover a new and much simpler way to solve the
same problem, and take all that blood-sweat-and-tears effort and
postmortem then shitcan the lot of it without a second thought. So if
your only reaction to hard criticism is to run away or barricade your
mind to it, if you're not willing to make such sacrifices in the name
of the greater good, if you're not willing to at least entertain the
possibility that You Might Be Wrong Too; then I'm sorry to say but you
really have chosen the wrong line of work to get into, and I can find
much better things to devote all my attention to.

Six: As for what will make me happy? That I never again hear that
bloody Lieberman name used to deflect every criticism I offer. Because
that is so intellectually lazy of you it's actually insulting mine. I
have provided you with plenty of answers throughout; you simply choose
not to notice or accept them. And that is something I absolutely
_cannot_ help you on.


Therefore, I am finally willing to state: "Prothon looks very
nice/interesting. I'll be very curious/interested to see how where it
goes." May you find some fulfillment in that.

has

 

[has]

He probably thought they were pearls of wisdom. Guess you don't
want any more, anyway.

Yeah, well I'd personally be the first to acknowledge that every other
"pearl" I throw is more commonly a lump of shit. So I actually
appreciate it when folk take a sniff and tell me it's a turd. It's
when they blat every single toss straight into the rough then promptly
ask for another one that I eventually get a bit peeved.

To be honest, however, I've got nobody to blame but myself for this
particular outbreak. I unsubscribed from the prothon mailing list
because I'd already recognised I wasn't getting anywhere and my
continued presence would only waste my own time and energy and
everybody else's. And I should _really_ have known better than to get
re-involved over here. So I apologise to the rest of the
comp.lang.python group - as friendly and civilised an online group as
I've ever been in - for any disturbance caused, and now return you to
your regular program. Let Mark have the last word; just for surviving
me this far I think he deserves it.

Mr Intensity

 

[Greg Ewing]

Not at all. I was arguing these issues long before Prothon got its
copy() method. I'm aware of its recent addition, but it doesn't
really change anything: the canonical Prothon way to create new
objects is still b = a(), not b = a.copy().

In that case you're not arguing about what the language
provides, but about the preferred style of using what the
language provides.

 

[has]

In that case you're not arguing about what the language
provides, but about the preferred style of using what the
language provides.

At which point we more or less come full circle, as we're back to the
"all approaches are equally valid, so all criticisms are equally
worthless" argument, then I point out that this sort of relativist
fallacy is the same attitude that makes C++ what it is today, and then
I get told that such statements are "ludicrious" (they're not; they're
hyperbole) and "Lieberman said I could do it this way so that makes it
okay", and then I completely waste another week of my time rehashing
the same arguments I gave last time as to why such attitudes doom any
such projects they touch to a lifetime of mediocrity as they
perversely persist in reinventing every flaw and misfeature that
better minds already solved donkeys years ago, and all with no more
success than before.

So I'm going to stop right there, because I've already said all I
usefully can and have more useful things to be doing with my time, and
what you do with yours is not any problem of mine, and everyone else
on comp.lang.python are feeling their brains dribble out their ears.

has