What is good about Prothon?

[Mark Hahn]

has wrote:

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