Re: Major change proposal

Mark Hahn wrote:
> I looked seriously at using Parrot for an interpreter and almost
> everything wrong with Parrot is right with .net and mono.  It is
> stable and working. It has the library ready to use.

Mono is missing a major part of the library, namely doing a GUI.
The Windows.Forms package is not ready, and it may be this
time next year before it is.  They recently decided to drop
Wine and re-implement the Windows interface themselves.
This is the page for Windows.Forms on mono, although it
hasn't been updated to reflect them dropping Wine:

  http://www.go-mono.com/winforms.html

I guess you need to decide on one unique thing for Prothon.
Currently you are trying to do two, namely an improved
language and an improved interpretter.

If you think both are crucial to the success of Prothon
then you will need to continue to do both.  If only one is
then drop the other part and concentrate on the part that
matters.

Just to give you an idea of how far there is to go, my major
Python program talks to cellphones over a data cable.  It
runs on Windows, Linux and Mac as a gui.  This is what I
need to deliver it from the Python side:

Python        Programming language and numerous modules
wxPython      GUI
win32all      Access to more windows api and COM (Outlook)
pyserial      Access to serial ports
python-dsv    Parsing of CSV files.  (It has extra functionality
              over the Python csv module such as being able to
              guess the seperators.)
SWIG          I need to generate Python wrappers from the C libary
              libusb and some custom code for the Windows Address
              Book.  I also use mingw/gcc to compile the wrappers.
paramiko      Python implementation of SSH2 protocol
pycrypto      Used by paramiko for the crypt stuff
py2exe        Wrap up Python program on Windows
cxFreeze      ... on Linux
bundlebuilder ... on Mac

This is the list of modules from Python I use:

 HTMLParser, Queue, SimpleXMLRPCServer, StringIO, base64, cStringIO,
 codecs, copy, datetime, difflib, fnmatch, getopt, getpass, glob,
 imp, logging, os, quopri, random, re, sha, shutil, socket, string,
 struct, sys, threading, thread, time, tokenize, traceback,
 weakref, webbrowser, xmlrpclib, zipfile, zlib

If you think the secret sauce is in the language then compile it
down to very high level bytecode, and have seperate translators
into Python bytecode, Java bytecode, CLR and even C.

If the secret sauce is the interpretter then I would recommend
abandoning the language and write a better intrepretter for
Python.  (I have yet to be convinced that Prothon is an order
of magnitude better than Python).

If it is the language and the interpretter then continue with
both.  I would however recommend writing as much of the interpretter
as possible in the language itself just as the PyPy folks are
trying to do.

Roger