Prothon should not borrow Python strings!

[Roger Binns]

Mark Hahn wrote:
> Roger Binns wrote:
>
> > In addition to all the excellent notes from Paul, I would recommend
> > you consult with someone familiar with the locale and encoding
> > issues for Hebrew, Arabic and various oriental languages such
> > as Japanese, Korean, Vietnamese and Tibetan.  Bonus points for
> > Tamil :-)
>
> I sure hope you are kidding.  If not you are scaring me away from doing
> anything.

You can get the design done right early, and worry about the implementation
later.

[ external string resource files ]
> Do you mean for the interpreter or some enabling tool for the Prothon
> programs?  Doing this for the interpreter is on the to-do list.

I mean for user programs and making it a fundamental part of the
language (ie you must use it).

The current model of print statements compatible with 1950's teletypes
is old and busted.

How about inspiration from 1960's era mainframes (or the more recent AS/400)?

The AS/400 is actually an excellent example of an alternate approach.
Your programs have a seperate resource that defines "screens" (think
of a full display on a terminal).  The resource is rich in that it
can be longer than a screenfull (ie you need page down), and it
defines both output fields and input fields, including validation
information and type information for the fields.

When the web arrived, they could instantly web enable the applications
with zero changes to the application code.  Similarly you could build
a gui for the apps automatically as well.

Taking a step back to what that could inspire in Prothon, how about making
I/O richer.  Instead of teletype style print, make the resource files
richer.

I should be able to run someones program and have it output
to a teletype, a GUI, HTML, XML or whatever else becomes popular in
the next ten years, without changing a line of code of the application.
(Bonus points for encapsulating the command line arguments that way :-)

Now you could do all this through libraries (ie as an optional part
of the libraries rather than part of the language design) but the
moment you do that, a lot of code won't use it, and a scheme like the
above is only useful if all code uses it.

Additionally the current schemes available in languages like Python
is a royal pain in the butt.  The language makes it hard to do.

Try the following steps:

 - Start with a program that says "Hello, World"
 - Then change it to say the it in English and French
 - Then make it take a command line argument that accepts a
   name, and have it say Hello, Name (or Name, Hello depending
   on the locale)
 - Ok, now make it output HTML, XML, teletype and a gui

If the language/library design is done well, each of those should
add one line of code.  Every language I am aware of the moment
makes it take way way more than that, which leads people not to
bother, which means that code randomly doesn't work with other
libraries, and everything is still stuck at the lowest common
denominator (printing to a teletype).

Roger