Prothon 0.1.2 is getting close to Alpha [Prothon]

[Mark Hahn]

Prothon is pleased to announce another major release of the language,
version 0.1.2, build 710 at http://prothon.org.

This release adds many new features and demonstrates the level of maturity
that Prothon has reached. The next release after this one in approximately
a month will be the first release to incorporate the final set of frozen
Prothon 1.0 language features and will be the Alpha release. You can see
the set of features still under discussion for 1.0 at the new Prothon WIKI
at: http://prothon.org/wiki.

This list is not only long but the changes are mostly major features.

Changes in version 0.1.2....

- print is now a function, not a keyword
- function-as-command feature allows print to be used without parens
- Added prop keyword and properties feature with wildcards
- Changed del_ to final_ so properties could use get_, set_, & del_
- a += b type assignments now always do a = a + b
- New in-place modify operators a +! b, a -! b, a *! b, etc.
- Formal parameter default values now evaluated at call time
- String now stored with native 24-bit ordinal values
- Split String type into seperate String and Bytes (binary) types
- Split File into File and TextFile
- Replaced String % operator with String.fmt()
- Added cmp_ and eq_? for strings of length 1 and Ints
- Added object-oriented Directory object and methods
- Added TempDir and TempFile (deleted at shutdown)
- Added basic DateTime object
- Added WeakRef object with callback feature on obj modification
- Added Slice object
- getItem_, setItem_, and delItem_ now allow any object indexing
- Finalization now called on shutdown
- Added built-in range() generator (not list function)
- Added List(iter_) constructor
- Octal constant format changed from 0377 to 0o377
- Octal esc sequence changed from \0377 to \o377
- except keyword no longer allowed alone, must use "except Exception"
- except syntax changed from "except exc, var" to "except exc as var"
- Function formal params now introspectable via simple attribute
- *args param local variable in func is now a tuple, not a list
- Added immutable check to dictionary function key parameter
- Added Dict.len_ and Dict.bool_?
- Moved File from extension module to built-in
- Changed File.stdxxx to sys.stdIn, sys.stdOut, and sys.stdErr
- changed Len, Cmp, len, cmp, chr, ord to
len, cmp, len_, cmp_, chr_, ord_
- changed Sys to sys, changed sys.ps1, sys.ps2 to sys.cons.ps1,
sys.cons.ps2
- Changed SQLite to sqlite, OS to os, Re to re
- Change symbol prefix from backtick (`var) to dollar-sign ($var)
- Changed console prompt from >>> to O>>
- Added many new *.pr test files
- Fixed raise keyword so second arg is doc_ attribute of first
- Fixed crash on printing recursive containers, now prints ...
- Fixed assignment from sequences to arg lists and for statements
- Fixed import in console
- Fixed bug in Func constructor
- Fixed bug in string.rstrip, string.strip, and string.find
Prothon is an interpreted dynamic language that takes much from Python but
is not compatible with Python as it uses the simpler prototypes instead of
classes. Prothon is an industrial strength language that uses native OS
threads and 64-bit architecture. For a description of Prothon see the
tutorial at
http://prothon.org/wiki?pagename=TutorialHomePage.

Mark Hahn
email: mark at prothon.org

[Peter Hansen]

Mark Hahn wrote:

Prothon is an industrial strength language that uses native OS
threads and 64-bit architecture.

Mark, as someone with an "industry" perspective, I interpret
the phrase "industrial strength" as meaning two things**, primarily:
power and reliability.

Does Prothon already have enough users and runtime to justify a
claim that it is highly reliable? I believe Python can make this
claim fairly easily at this point, though even a few years ago
I'm not sure that was the case.

What do _you_ mean by "industrial strength"?

-Peter

** That is, when I don't think it's just a marketroid talking.
I know Mark isn't a marketroid, in spite of the similarity
in the names. ;-)

[Mark Hahn]

Peter Hansen wrote:

Mark Hahn wrote:

Prothon is an industrial strength language that uses native OS
threads and 64-bit architecture.

Mark, as someone with an "industry" perspective, I interpret
the phrase "industrial strength" as meaning two things**, primarily:
power and reliability.

Does Prothon already have enough users and runtime to justify a
claim that it is highly reliable? I believe Python can make this
claim fairly easily at this point, though even a few years ago
I'm not sure that was the case.

What do _you_ mean by "industrial strength"?

I understand your concern.

I meant it is designed to be industrial strength when it is finished. The
architecture/foundation is built from the ground up with that in mind. I'm
also making a bit of a comment that it will be more industrial strength than
Python.

And yes, I am a marketing force of one. :-)

I'm sure everyone can tell marketing claims like this from technical points
made elsewhere. I make it clear that it is pre-alpha. I made its status
clear at the top of the announcement and the marketing blurb at the
traditional place at the end. I actually tried to think of some sub-heading
to put before the marketing blurb but I couldn't think of what it should
say.

In the last announcement I forgot the standard blurb and several people
emailed me and gave me flack for announcing something and not telling what
it was in the announcement. I'm not very good at this marketing stuff. :-(

[Peter Hansen]

Mark Hahn wrote:

Peter Hansen wrote:

What do _you_ mean by "industrial strength"?

I meant it is designed to be industrial strength when it is finished. The
architecture/foundation is built from the ground up with that in mind. I'm
also making a bit of a comment that it will be more industrial strength than
Python.

That claim interests me a lot. I've found recent versions of
Python to be *very* robust. I'd trust them with almost anything
at this point, more than I could say of most code in other
languages I've used. Why do you think you can improve on that,
(or even be on par with it if you're writing the interpreter
from scratch)?

-Peter

[Paul Rubin]

Peter Hansen <pe***@engcorp. com> writes:

I meant it is designed to be industrial strength when it is
finished. The architecture/foundation is built from the ground up
with that in mind. I'm also making a bit of a comment that it
will be more industrial strength than Python.

That claim interests me a lot. I've found recent versions of
Python to be *very* robust. I'd trust them with almost anything
at this point, more than I could say of most code in other
languages I've used. Why do you think you can improve on that,
(or even be on par with it if you're writing the interpreter
from scratch)?

Python has all kinds of annoying little limitations and misfeatures
that make me think an "industrial strength" version could do some
things differently. Yes, you can write reasonably reliable programs
in Python if you're careful about the different traps, but maybe
Python tries to accomplish too many things at once. So it will be
interesting to see how Prothon comes along.

[Mark Hahn]

"Peter Hansen" <pe***@engcorp. com> wrote

That claim interests me a lot. I've found recent versions of
Python to be *very* robust. I'd trust them with almost anything
at this point, more than I could say of most code in other
languages I've used. Why do you think you can improve on that,
(or even be on par with it if you're writing the interpreter
from scratch)?

The claim starts with getting rid of the GIL of course. OS native threads
allowing pre-emption in C code and blocked IO is considered mandatory by
most for an industrial-strength server serving hundred of users
simultaneously.

Secondly we are putting optional design-by-contract features into the
language that have kept many organizations and projects away from Python.
These range from type-checking variables and functions (using interfaces
actually, not types) to classes (for contractual purposes only). Yes,
Prothon will have classes available optionally.

Thirdly we have what we believe will be a usable security model. Python's
is broken and virtually non-existant.

Fourthly a Psyco-like jit will be our standard interpreter. Python could do
this also of course.

Also we have fixed many Guido regrets and what we think Guido should have
regretted :-) Any time the language is friendlier, more expressive,
intuitive, and powerful, it is more industrial-strength.

Of course you will have to take a look at the design and judge for yourself
since we don't have a finished language like Python is. That of course is
our big advantage also. We could promise anti-gravity right now :-)

[Peter Hansen]

Mark Hahn wrote:

"Peter Hansen" <pe***@engcorp. com> wrote

Why do you think you can improve on that,
(or even be on par with it if you're writing the interpreter
from scratch)?

[snip reply]

Excellent reply, Mark. Thank you.
-Peter

[Mark Hahn]

Peter Hansen wrote:

Mark Hahn wrote:

"Peter Hansen" <pe***@engcorp. com> wrote

Why do you think you can improve on that,
(or even be on par with it if you're writing the interpreter
from scratch)?

[snip reply]

Excellent reply, Mark. Thank you.

You're no fun. I was trolling for a rip-roaring flame-war :-)

Seriously though I know those topics aren't of great interest to c.l.p. or
people here wouldn't be using Python. They are of interest to some small
niche markets though and we'll take what we can get. Thanks for asking and
being so polite.

[Peter Hansen]

Mark Hahn wrote:

Peter Hansen wrote:

Excellent reply, Mark. Thank you.

You're no fun. I was trolling for a rip-roaring flame-war :-)

Seriously though I know those topics aren't of great interest to c.l.p. or
people here wouldn't be using Python.

Here I think you underestimate the community, and a large number
of people in it. I think Python programmers, more than many many
other groups out there, are keenly interested in issues such as
reliability, security, and such. As but one example, the fact
that so many of us choose Python over other languages is in part
because of the greater security found in avoiding buffer overruns
and memory allocation bugs, and the reliability of knowing our
code will pretty much *never* crash the entire computer, and
that tracebacks will point us more quickly to the cause of bugs
so we can fix them. Okay, three or four examples...

My real point, though, is that Python programmers are perhaps
above all else *pragmatic*. We'll keep using Python as long as
it is so effective, even with its warts, while we either
eagerly or casually (depending on our own nature) observe
idealists like you who have the time and inclination to try
to improve things. If and when you succeed, many will probably
explore the possibility of making a shift to the new offshoot,
and the Great Tree of Computer Languages will have expanded
by one more generation. So don't assume that there isn't
interest here.

But, in the meantime, we have work to do, and Python is pretty
damn good at getting out of our way and letting us do it. (And
for the same reason, we appreciate the fact that most of the
Prothon discussion is in its own mailing list, if I can channel
the silent majority for a moment. :-)

-Peter

[Jeff Shannon]

Peter Hansen wrote:

As but one example, the fact
that so many of us choose Python over other languages is in part
because of the greater security found in avoiding buffer overruns
and memory allocation bugs, and the reliability of knowing our
code will pretty much *never* crash the entire computer, and
that tracebacks will point us more quickly to the cause of bugs
so we can fix them. Okay, three or four examples...

Our three chief weapons are readability, security, practicality... . and
an almost fanatical devotion to the Pope! ;)

Jeff Shannon
Technician/Programmer
Credit International