Re: Euphoria's Future
This comparison with Python brings up a few interesting points.
I think Euphoria is a *great* language, with a lot of potential. But I =
think that there are a couple of key things that will, IMHO, forever =
hinder it (at least as it exists now). Comparing E with Python seems to =
have helped clarify that.
First seems to be E's lack of diversity. For all it's strengths, it's =
bound to the Wintel platform (and DOS). Granted, if you must choose one =
platform to be on that might well be the one to choose, but I have =
difficulty believing a language will grow in acceptance--or =
publicity--unless it's ported to as many platforms as possible. Most Mac =
users (who I think would be the most enthusiastic about E, incidentally) =
aren't likely to know about the language simply because no material =
relevant to them exists. They won't read about it in Mac Weekly. They =
won't download it from a Mac shareware site. Chances are they'll only =
hear of it from a Wintel user. Repeat the scenario for other platforms =
and I think it becomes clear that it is a hinderance.
The second major roadblock to the language, ironically, seems to be it's =
strong points. Run-time index checking. Not allowing initialized =
variables to be used. All the nice, interpreter-based trappings that =
make programming in Euphoria euphoric. All of this is great; but what =
happens when the attempt to port to another platform IS made? We're =
going to have to mold another system environment so that it checks =
everything Euphoria currently checks, returning the same (or at least =
corresponding) error messages, and in many cases doing things the same =
way. What I'm saying is, it seems as if most of Euphoria's strong points =
are not *language specifications*, but rather, specific to this =
particular implementation. (Hold on, here come the comparisons...)
Take for example C. Does C stop you from using uninitialized variables? =
Most implementations probably don't, but in theory it very well could. =
Since variables must be declared before use, couldn't a C compiler check =
for just such a situation and flag it as an error, refusing to compile =
until corrected? And why couldn't extra code be automatically included =
before every index access in a COBOL program so that illegal subscripts =
are caught and the program safely aborts? For that matter, making a =
COBOL interpreter would make it easier to include a lot of other checks =
along with that one, yes? My point is: other languages could have a lot =
of the same things as Euphoria. The declare-before-use and syntax =
elements could easily be made part of a Euphoria specification, but =
could run-time index checking? Or other such built-in nicities? After =
all, if my program's logically sound, it'll run on any =
syntactically-correct E interpreter (or compiler), regardless of whether =
the index accesses are checked. All of which leads to what I think could =
be the biggest hinderance...
Control. The fact that Euphoria isn't a specification of syntax, =
operation and language elements, but a specific implementation of an =
idea, officially the property of a single company (or man). Even if =
"Euphoria" isn't itself trademarked as a programming language name, I =
don't know how Rob feels about others making unauthorized, modified, =
possibly incompatible, =
we'll-implement-it-how-we-want-and-to-heck-with-the-run-time-checks =
variants of his brainchild. Don't get me wrong, I'm NOT saying he should =
"let go" of the language, release a specification and encourage others =
to create their own interpreters or even compilers (taking either a =
Java-like or Linux-like stance). But I think if widespread usage is the =
goal, that is what's going to have to happen--either with Rob's blessing =
or against his wishes. I don't think C would have the widespread =
popularity it enjoys if even the mighty Microsoft were the only one who =
sold a compiler, dictating every minute detail of implementation.
Euphoria might eventually become well-known, but if so I don't think it =
will be the same Euphoria that we all know and love. I like it the way =
it is now; I don't think it needs to change. While I'd like to see other =
platforms supported (but only if at the core identical to the plain DOS =
version), I don't think some of the compromises that might need to be =
made to achieve stardom are worth it.
Just my few cents...
Rod Jackson
----------
From: Arlie Codina[SMTP:web.master at FLASHMAIL.COM]
Sent: Tuesday, February 23, 1999 6:21 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Euphoria's Future
Hi Everyone,
There's been a lot of talk about the future of Euphoria. Just yesterday
I visited the web site of Python and and even downloaded a copy. From
this I learn that Python is free including the source code. You can even
modify it and resell it if you like. It's only 3 years older than =
Euphoria
and it has now become commercially viable. Companies are now writting =
commercial
software in Python. It has support/library for data base connectivity =
both
commercial & non-commercial.
Somebody mentioned writting a browser in Euphoria. They did it in =
Python. My
point exactly is for us take a look at Python as an example. There is a =
lot
of stuffs going for it now. Let's get excited and contribute more stuffs =
so
that in no time Euphoria well get to where Python is now.
I would like to invite RDS to download a copy of Python including source
code and take a look at it. I really like the interactive prompt of =
Python. Perhaps we can have it in Euphoria. It's really helpful in =
testing code
fragment specially to beginners like me.
On top of this I still like Euphoria's simplicity. I was too overwhelmed =
with
all of Python's features. Before anyone comments on this kindly visit =
first
http://www.python.com to get an accurate picture on what I'm talking
about and more.
Regards,
Arlie Codina
web.master at flashmail.com
|
Not Categorized, Please Help
|
|
