Michael Fair : I am looking for a team of people willing to explore a
different approach to what we are currently doing.

Alain : Nothing is carved in stone. We are very open-minded.

Michael Fair : Here would be my initial plan of attack. Take the Python
(www.python.org) interpreter and revamp the syntax to be as xTalk like
as possible. This would be the heart of the LGPL Embeddable interpreter
and become the base code. Next port wxPython
(http://alldunn.com/wxPython/) to use the new syntax and throw some Mac
programmers on the wxWindows project. Begin programming the object
hierarchical message passing infrastructure and "stack" library in the
new OpenTalk language.  This gives us our familiar stack based card
metaphor of objects and commands and gives the xTalk languages a new
reputation for procedural programming. Finally add the ability to
create executables that know how to load and run their own stacks and
call it version 1.0. Start going public everywhere I can touting how we
used already existing packages and can run on Windows, Mac, and Linux,
generate interest in porting many of the other Python modules like Com
and ActiveX, the Distributed Networking stuff, all the multimedia
libraries, the LDAP stuff.

Alain : Are you quite familiar with Python? Are there many more like
you?

Michael Fair : This approach yields a very high ROI.  Because it uses
the python interpreter as the underlying engine we can leverage
anything that it can do.  We would have to begin addressing issues
about how to load and store class code in the GUI product, possibly by
adding a "library" object as well as a "stack" object, but it could be
done.

Alain : The leveraging principle is definitely a good one.

Michael Fair : I don't think this approach any easier or harder than
rolling our own like we are doing now, it's just different. 

Alain : If your approach is no easier, then why not roll-our-own
instead. We would no doubt end up with something that would precisely
address our needs, given that we are its designers. 

Michael Fair : It solves some critical problems easily, but creates
others. However it is the method that I think is the superior one.

Alain : In what way is it superior?

Michael Fair : Any other opinions, thoughts, ideas, or warnings?

Uli : Michael, I don't think this'll work out. Python is much more
structured than HyperTalk is. Hacking a very formal type of language to
be as informal
as HyperTalk would result in a slowdown, or in a huge amount of
rewrite. What you'd be able to use from the Python code would very
likely be about as
much as Anthony has already finished. I'd rather suggest you get into
BISON and help Anthony with implementing Interpreter.

Alain : Python is an interpreted language that is quite similar to
Perl, right?

Michael Fair : ... and throw some Mac programmers on the wxWindows
project.

Uli : I'm fine with that. I'm already helping out from time to time
(though I haven't yet been able to download the new beta). This would
provide both your wxPython project as well as the current branch, which
is why I don't have any objections at all.

Alain : We do both?

Michael Fair : Begin programming the object hierarchical message
passing infrastructure and "stack" library in the new OpenTalk
language.  This gives us our familiar stack based card metaphor of
objects and commands and gives the xTalk languages a new reputation for
procedural programming.

Uli : You mean we should essentially duplicate Serf? 

Alain : Is Serf open source?  Why aren�t we pooling our efforts?

Uli : Well, if Interpreter or your HyperCardized Python would be that
fast, I don't mind. But so far I think we'd gain more speed in the
long-term run if we did like MetaCard and tried to do as much as
possible with as few scripting lines as necessary. 

Alain : We should at least give MetaCard a try, I think.

Uli : Whatever may happen in the future, at the moment compiled code
still *is* faster.

Alain : Yes, compiled code still is faster, but interpreted code will
always be more flexible. It�s a tradeoff.

Michael Fair : I am looking for a team of people willing to explore a
different approach to what we are currently doing. Here would be my
initial plan of attack. Take the Python (www.python.org) interpreter
and revamp the syntax to be as xTalk like as possible. This would be
the heart of the LGPL Embeddable interpreter and become the base code.

Anthony : If you took the Perl one instead, you'd also get the Perl
compiler, the MacPerl port, the Windows Perl ports, and the Unix
versions. It's also under a much more liberal licence, the Perl
Artistic.

Alain : Perl is indeed much more popular than Python.

Michael Fair : Next port wxPython (http://alldunn.com/wxPython/) to use
the new syntax and throw some Mac programmers on the wxWindows project.

Anthony : Perl would need to be expanded to support wxWindows, but that
is not too hard: It's already been expanded, in the MacPerl port, to
support the toolbox.

Alain : So Perl is an option, after all?  Do you remember the
discussions we had several months ago concerning the pros and cons of
programming with Perl versus programming with C/C++ ?  I was promoting
the Perl option earnestly but I was drowned out by the chorus for
C/C++. I�m not upset about it at all. I�m just bemused by the fact that
Perl is re-surfacing now. For the record, I welcome Perl as a
programming language for OC, because I am sufficiently familiar with
Perl that I could participate in the coding, while now I am limited to
the collaborative aspects. No problem here either, though. I am mainly
in it for the collaborative aspects. But, in addition to coding, the
use of Perl would undoubtedly help me better understand what is going
on and, thus, help me provide the group with better support for our
collaboration.

Michael Fair : Finally add the ability to create executables that know
how to load and run their own stacks and call it version 1.0. Start
going public everywhere I can touting how we used already existing
packages and can run on Windows, Mac, and Linux, generate interest in
porting many of the other Python modules like Com and ActiveX, the
Distributed Networking stuff, all the multimedia libraries, the LDAP
stuff.

Anthony : Plenty of stuff for Perl, too. Plus you get some very nice
regexp support :)

Alain : Perl has a huge following. My guess is that there is much more
stuff coded in Perl than in Python.

Anthony : An egcs frontend would be nice while we're at it :)

Alain : What is a �egcs frontend�?  Is it Perl or Python or C?

Michael Fair : Ok, I'll go towards Perl. However, there should be a
little more discussion as to whether or not this approach merits an
attempt.

Alain : Yes, we should discuss this further.

Michael Fair : I'm just as clueless as most people are, I'm just trying
to find the path of least resistance for the most gain.

Alain : Ditto!

Uli : I have a feeling that Hypercard is much more structured than we
think... 

Alain : �HyperCard 2.2 the Book� contains the formal syntax
specification of HyperTalk in one of its annexes.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Reply via email to