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]

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]

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]

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]

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]

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]

[snip reply]

Excellent reply, Mark. Thank you.


-Peter

 

[Mark Hahn]

[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]

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]

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

 

[Michele Simionato]

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

I don't know about the silent majority, but you certainly channel me,
including the point about "being pragmatic". Whether Prothon will grow
to satisfy the expectations is still to be seem, but I would certainly use
another language if I found one better than Python for the task I have to
accomplish.

Michele Simionato

 

[David MacQuigg]

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.

I for one, welcome any discussion of alternatives to Python,
particularly comparing languages like Ruby and Prothon that are
derived from Python and have the benefit of hindsight. For those who
are annoyed, just set your filter to kill [Prothon] in the subject
line.

For those with an open mind, I highly recommend looking at both Ruby
and Prothon. I don't see these as a practical alternative for what I
need, but as an eye-opener on how many of the problems in Python could
be solved more elegantly (or at least differently).

I don't see Python as the ultimate programming language, but it is
close enough that it is not worth the cost of switching to a perfect
language. The outcome I would most like to see is that Python 3
adopts some of the changes we see in Prothon (and a few from Ruby).

-- Dave

************************************************************* *
* David MacQuigg, PhD * email: (e-mail address removed) * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *

 

[Mark Hahn]

I don't see Python as the ultimate programming language, but it is
close enough that it is not worth the cost of switching to a perfect
language. The outcome I would most like to see is that Python 3
adopts some of the changes we see in Prothon (and a few from Ruby).

David, long time no read. Have you noticed that Prothon is ending up with a
lot of the things you wanted? The with statement now works your way plus a
number of other things.

 

[David MacQuigg]

David, long time no read. Have you noticed that Prothon is ending up with a
lot of the things you wanted? The with statement now works your way plus a
number of other things.

Yes, I am very pleased by the changes in the last few months. The
explicit binding syntax is excellent. That removes the objection I
had to making the language classless. I also like the greatly
simplified scope rules.

My big problem remains all the "non-language" defiencies - libraries,
textbooks, support community, etc. For this to happen it has to be an
easy jump for Python programmers. The benefits of removing a bunch of
minor flaws in Python will have to exceed the cost of migration.

Maybe your approach is right -- go for the perfect syntax first, build
a core of strong supporters, then in the second release decide how
much compromise you are willing to make to bring in the larger Python
community. Even at that point it will be easier for Prothon to make
radical changes. And you won't have to waste time on arguments about
whether something is syntactically impossible.

I just updated my language popularity table, showing the number of
projects in each language on SourceForge:

Date C++ Java Perl Python Ruby Prothon
------ ------ ------ ------ ------ ------ ------
11/25/2002 4026 1994
4/3/2004 13148 11660 5441 3120 289
7/10/2004 13261 12137 5317 3236 303

What'even more interesting is the growth rate (percent per year):
Days
495 25.9% 41.6%
98 3.2% 15.2% -8.5% 13.8% 18.0%

Looks like Ruby, Java, and Python are growing the fastest, although
the numbers on Ruby are too small to put a lot of faith in the stats.
Python's growth is starting to level off. C++ is stationary, and Perl
is in decline!!

If I were you, I would think about where Prothon should be in this
matrix five years from now, and maybe modify your mission statement to
address the issues that will make it happen. Ruby has been out for
nine years now, and in spite of the high growth rate, and the pride of
all Japan, it just doesn't seem to be going anywhere. They can't even
get their Windows installer to share the machine with Python. The
"critical mass" for a language seems to be somewhere between Ruby and
Python. Anything less, and eventually it will die.

-- Dave

 

[Mark Hahn]

Yes, I am very pleased by the changes in the last few months. The
explicit binding syntax is excellent. That removes the objection I
had to making the language classless. I also like the greatly
simplified scope rules.

It is amazing how hard it was to come up with a consistent syntax that
allowed all that simplicity. It seems contradictory that it requires so
much hard work (and so much arguing) to create something simple.

Lately we have been working hard to add some complexity back in to it on top
of the simplicity. After all this we will have a class keyword and
Python-like directed method calls like you wanted!!! The new complexity
will be optional and only for people that want it. See:
http://prothon.org/wiki?pagename=DesignByContractClass

My big problem remains all the "non-language" defiencies - libraries,
textbooks, support community, etc. For this to happen it has to be an
easy jump for Python programmers. The benefits of removing a bunch of
minor flaws in Python will have to exceed the cost of migration.

That will come with time. You have to have a good new language first before
you can expect people to help you add support to it.

Maybe your approach is right -- go for the perfect syntax first, build
a core of strong supporters, then in the second release decide how
much compromise you are willing to make to bring in the larger Python
community.

I don't plan on compromising. I think Prothon 1.0 will make 90% of users
happy the way it is, once support and libraries are available.

Even at that point it will be easier for Prothon to make
radical changes. And you won't have to waste time on arguments about
whether something is syntactically impossible.

I'm hoping the users will be able to use Prothon the way it is and do
radical things with it. Time will tell.

 

[Ben]

That will come with time. You have to have a good new language first
before you can expect people to help you add support to it.

As a user of Python who is very interested in Prothon this point is very
important to me. Thinking about this, does Prothon have a mechanism similar
to Pythons import hooks, so in a Prothon program you could do somthing like

import python

and then be able to import python modules natively. (With automatic
translation of the builtin types). e.g

import python
import urllib2
....


This would greatly increase the uptake and people would be able to play
around with prothon using libraries that already have and understand?

Ben
---

 

[Oliver Fromme]

> [...]
> 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).

Will the type-checking be performed at compile-time or at
run-time?

Best regards
Oliver

 

[Mark Hahn]

As a user of Python who is very interested in Prothon this point is
very important to me. Thinking about this, does Prothon have a
mechanism similar to Pythons import hooks, so in a Prothon program
you could do somthing like

import python

and then be able to import python modules natively. (With automatic
translation of the builtin types). e.g

import python
import urllib2
...


This would greatly increase the uptake and people would be able to
play around with prothon using libraries that already have and
understand?

Unfortunately Prothon objects are very different than Python's internally so
automatic translation of libraries will probably never be possible. Prothon
was never intended to be compatible with Python. Prothon "steals" most of
Python but is not compatible, just like Python 3 will not be.

There will probably be library equivalents that are close enough to make
porting quite easy though. The current re library is a good example. It is
compatible. Also the Prothon sqlite library uses the Python db protocol.

 

[Mark Hahn]

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

Will the type-checking be performed at compile-time or at
run-time?

The current plan is run-time. This is still a work-in-progress though.

 

[Ben]

Unfortunately Prothon objects are very different than Python's internally
so
automatic translation of libraries will probably never be possible.
Prothon
was never intended to be compatible with Python. Prothon "steals" most of
Python but is not compatible, just like Python 3 will not be.

There will probably be library equivalents that are close enough to make
porting quite easy though. The current re library is a good example. It
is
compatible. Also the Prothon sqlite library uses the Python db protocol.

Could it not be done in a similar manner to LunaticPython
(https://moin.conectiva.com.br/LunaticPython), only slightly more
integrated, so that method calls on prothon objects are simply forwarded to
the equivalent python calls? It should be possible to write a forwarding
proxy, I was just wondering about the import hooks part, so that if a .py
file is found instead of a .pr, the proxying can be invoked.

Anyway, its not that important. Just a suggestion I had.

Cheers,

Ben
---