What is good about Prothon?

[has]

"Mark Hahn" <mark at prothon.org> wrote in message news:<ZHXjc.17225$Qy.13377 at fed1read04>...

> My position (which is basicly in agreement with Lieberman's paper) is that
> having multiple tiers is inherent in all programming and is a natural result
> of factoring the problem of making many copies of the same thing.

And my position is that:

1. Anyone can find pieces of paper to prop up an existing position. It
doesn't really prove anything. It's finding pieces of paper that
actively contradict your position and being able to A. convincingly
refute their arguments or, if that fails, B. acknowlege that they're
right and you're wrong, and revise your position accordingly.

2. There's a world of difference between the user imposing their own
tiers upon an environment, and having the environment impose its
choice of tiers upon them. Tiers can add convenience, which is what
makes them tempting in the first place, but they also add
restrictions. Adding tiers is easy; it's removing them that's hard.

3. Factoring's supposed to add simplicity, not complexity. Programmers
are far too tolerant - sometimes even welcoming - of the latter. An
attitude I think goes a long way to explaining why so much software is
so damned complicated: there's simply not enough lazy, intolerant,
impatient folk in software development. (Note: being lazy, intolerant
and impatient, as well as somewhat slow-witted, I shall no doubt be
doing my bit to redress this in future.;)


<SIDENOTE>
For benefit of viewers who've just tuned in, here's a practical
illustration of how Prothon freaks me out: let's say I want to create
three objects; a, b and c. In AppleScript, I would do this:


-- Create object 'a'
script a
	property x : 1
end script

-- Create objects 'b' and 'c'
copy a to b
copy a to c

log {a's x, b's x, c's x} --> {1, 1, 1}

set b's x to 4
log {a's x, b's x, c's x} --> {1, 4, 1}

set a's x to 9
log {a's x, b's x, c's x} --> {9, 4, 1}


[note: AS's 'copy' command performs a deep copy; unlike Python's,
which is shallow]

Whereas Prothon does this:


# Create object 'a'
a = Object()
a.x = 1

# Create objects 'b' and 'c'
b = a()
c = a()

print a.x, b.x, c.x # --> 1 1 1

b.x = 4
print a.x, b.x, c.x # --> 1 4 1

a.x = 9
print a.x, b.x, c.x # --> 9 4 9


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*, and it's up to the user to keep
track of all this - IMO a great way for all sorts of unpleasant,
unwanted interaction bugs to crop up in non-trivial code unless you're
very, very careful. (And hey, I've already got C pointer arithmetic
any time I feel like living dangerously.;)

(* In class-based OO you've also got the potential to do this kind of
data sharing, but there the difference between sharers - i.e. classes
- and sharees - i.e. instances - is explicit, so casual mix-ups are
much less likely to happen.)

</SIDENOTE>


> We will continue to agree to disagree.

Think I'll just continue to disagree, if it's all the same.


> I have learned a lot in my arguing
> with you though and do appreciate the time you've spent wearing out your
> keyboard.

Well I'm glad it wasn't completely wasted. And hey, who knows; you may
always change your mind. (And I have some neat thoughts on how to set
up a nice modules system if you ever tempt me back...;)