OpenEuphoria

Re: Version 2.4 and beyond

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 13, 2002
• 490 views

Derek Parnell writes:
> I, for one, am not 100% sure of what are Euphoria's primary requirements. 
> I suspect that minimulism, speed, size, and platform choice have a part, 
> but what I'd really like, Robert, is to see them clearly stated and published
> under the RDS banner.

I don't have any hard and fast requirements or goals for Euphoria.
I'm an opportunist. All I can do is tell you what I like about Euphoria, 
and what I feel about the current situation.

1. The core language.

I'm content with the size of the core language. I reject the 
notion that it is "incomplete", or must be extended every year
with new features. Sure, there could be some dotting of i's 
and crossing of t's, but any major new extension would have 
to match the power to weight ratio of the current core.
Structures, classes, etc. are tempting, but I've studied them
carefully over the years, and decided not to include them.

When I look at grandiose languages, with 1000-page
manuals describing only the *core* language, I'm appalled.
People seem to be building all sorts of exotic, trendy
features, just so they can one-up the others. I suspect these
features are probably buggy, interact with each other in
unpredictable ways, are rarely used and poorly 
understood by the masses. Python may have a lot of
"features", but if it's 34x slower than the Euphoria *interpreter*,
do you really care? I'm still waiting to see a fast action game
written in Python or Perl.

2. Libraries

One of the great strengths of Euphoria, compared to
Python, Perl, or other interpreted languages, is that
that the standard libraries, and most other 
important add-on libraries, Win32Lib etc., 
are all (heaven forbid!) written in Euphoria.
In Python they have some kludgy API that lets
people write extensions in C, since it's obvious
to everyone that Python itself would be far too slow.

This means that *all* Euphoria users can potentially write
important libraries and tools, where performance matters,
whereas in Python, you need to be a C expert and 
a Python expert, as well as learning the strange API.
This bodes well for the future expansion of cool things
that you can do in Euphoria.

While I think the core should remain small, 
I'll be very happy to see lots of libraries developed.

3. Interpreter Source Code

Releasing the source code was a bit of a two-edged sword.
Although I'm giving away a few secrets, and there will be
several different versions of Euphoria created, I think this
is a powerful way to inject a blast of creativity into the
Euphoria world, and some source holders have
said that they will port to some interesting platforms.
(nothing to announce yet).

Ray Smith writes:
> I also think RDS should have an official documented plan for the 
> future of Euphoria. 

"planning" stifles creativity.
People should not focus so much on what I'm going to do.
My job is to stimulate, and harness the creativity of the 
Euphoria community. I can't predict what's going to happen.
Think of a big pot of boiling, bubbling chemicals and DNA. 
Things will either explode, or else some creature from 
the "X Files" is going to crawl out.  

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com