OpenEuphoria

Expanding Euphoria

• Posted by MAP <ddhinc at ALA.NET> Apr 25, 1998
• 926 views

Okay as I see it, Euphorians seem to be split into two
camps of beliefs when it comes to many of the discussions
concerning expanding the language. Some think that
Euphoria should remain as it is, and that we should all
invent our own methods to code around any problems
that arise. The others believe that a few modifications
could greatly improve Euphoria, and I fall into this group.
Also, forgive me for making a generalization here, but the
division seems to fall along the same lines as those who
view Euphoria as a simple scripting language and those
who think it has the potential to be a pretty powerful
replacement to other languages, even for serious projects.
Perhaps because I'm relatively a late comer to Euphoria I
missed some of the discussions that brought about the
"don't touch the language" sentiment.

I've heard often that Robert doesn't want to change the
language any more than is necessary, and I fully agree
with that. It's because of this that Euphoria is what it is...
a coherant language. Too many languages have expanded
themselves in an awkward manner, throwing in features
upon features to solve small problems incrementally,
rather than finding solutions that make sense for the
language as a whole. The result is an unwieldy language
with, more often than not, a whole host of
counter-intuitive rules that the programmer has to deal
with, causing the resulting program to read more like a
collection of hacks than the pure algorithms that convey
what the program is there to do.

At the other extreme, where some would have Euphoria
stay, oddly enough lies the same problem still. The lack of
a few well chosen features. This leads programmers to
have to code their own solutions to implement them. This
is fine for small programs, but certainly not ideal for more
ambitious ones. I feel that structures are a prime example
of this. I've seen some very inventive methods of doing
these in Euphoria, yet none of them have the pure look
and feel of real structures. They still distort the view of
what is going on in the program, and that is the definition
of a hack. They force the programmer to adopt more a
complex view of the program than simply dealing with what
he or she is there to do.

Yes I do realize that programming isn't, and probably never
will be, about the "purist" ideaology that the academics love
to theorize about in the classroom environments. Real world
programming involves getting your hands dirty occasionally
and facing complex real-world problems that break some
of the rules for the sake of having a more efficient program,
or doing things that the language simply doesn't do... that's
why programmers make the money they do. Yet, in areas
where Euphoria could implement these purist constructs
without sacrificing efficiency and ease of use is where I feel
it should continue to try to grow. The result is an ever more
powerful language in the end. And one where novice and
seasoned programmer alike speak the same language.

Well, If you've read this far I've probably bored you stiff
by now, so I'll try to close up pretty quickly:) I'm simply
saying that I'd like to see Euphoria continue to mature in
those areas that can make the language easier to use. The
language as it is, afterall is about being an "End User" friendly.
And in many cases, features that promote this wind up as
powerful tools in the hands of not-so-novice programmers
as well.

Thanks,
Christopher D. Hickman