1. Re: What's Holding Euphoria Back
"Cuny, David" <David.Cuny at DSS.CA.GOV> wrote:
>My 2 cents on what I think make Euphoria difficult to "sell":
>
>[The Name "Euphoria"]
>
>"Euphoria" is a name that makes people giggle. I've put together a number
of
>small programs in Euphoria at work; when people ask what they are coded in,
>the answer is now a "non-standard language". I don't expect the name to
>change (there's too much invested in it at this point), but it *is* as
>issue.
After I discovered Euphoria -- and once I finally understood the nature of
sequences -- I breathlessly described to friends and family alike all the
wonderful features of this "revolutionary programming language" I'd
discovered. They all listened seriously at first, and seemed impressed with
the ideas of sequences, run-time checking, and the other excellent features.
But the moment I told them the actual name of this "revolutionary
programming language", the unanimous response was laughter -- either
outright, or stifled. At first I didn't realize it, but I've come to realize
just how much the name prevents people from taking the language seriously. I
personally think it's an awesome name, but Dave's right -- it *is* an issue.
Also, there's another issue somewhat related to this that just struck me.
Let's say that someone out there *is* thinking seriously about backing
Euphoria, despite the name. They've heard some of the details about it from
programmers, and they want to check it out. So they go to the official
Euphoria programming page -- and are greeted with *garish* colors, and the
following welcome message:
"This page provides the latest info on Euphoria - a nifty new programming
language for your PC. Euphoria is fast, flexible and fun; simple, safe, and
sexy!"
This doesn't exactly encourage anyone to take the language seriously.
<snip>
>[Forward References]
>
>People coming from other languages are used to using forward references -
>but it's *painful* to do in Euphoria, and there is the overhead of having
to
>create a sequence to hold the arguments:
>
> -- create a holder for the forward reference
> integer foo_id
>
> -- define a prototype for the function
> function foo( integer x, integer y )
> call_func( foo_id, {x, y} )
> end function
>
> -- define the "real" function
> function forward_foo( integer x, integer y )
> -- code goes here
> end function
>
> -- resolve the reference
> foo_id = routine_id("forward_foo")
>
>That's a lot of work that could *easily* be done by the interpreter - just
>allow the prototypes:
>
> -- qbasic syntax, perhaps "forward" is a better keyword
> declare function foo( integer, integer )
>
>that are resolved later:
>
> -- define the "real" function:
> function foo( integer x, integer y )
> -- code goes here
> end function
>
>Since the interpreter knows what the proc looks like, it could resolve the
>call *efficiently*, instead with all the overhead of the current method.
I must disagree here. When I was first learning Euphoria, I was impressed
with how it "forced" you to structure your program routines. When searching
for a function or procedure, you *always* knew you could find its definition
*before* any place where it was used. The old QuickBasic "declare" syntax
would seem like a step backwards to me, either requiring the programmer to
write the declares themselves (which I would *hate* to do), or requiring
some utility to automatically scan the source code and create the "declare"
statements at the top or the source code. Either way, the beginning of our
Euphoria source code would be cluttered with all these "declare" statements!
I suppose we could just have the interpreter make *two* passes through the
source code -- once to get all the routine declarations, then its usual pass
-- thereby avoiding the need for any "declare" statements at all. But then
it shoots down the whole beauty of Euphoria's initial design, requiring only
*one* pass through the source.
I was somewhat upset with the introduction of routine_id() at first, but
obviously this was a necessity for programming in a Windows environment. My
feeling is that the current way routines are defined in Euphoria is the best
way, forcing you to organize your code logically. The "pain" involved in
creating "forward references" in Euphoria should probably be considered a
deterrent -- use them only if you really, *really* need to.
I suppose programmers coming in from other languages will complain about how
Euphoria "forces" you to do this. Actually, Euphoria forces you to do a lot
of things -- initialize your variables, use valid subscripts, pass valid
parameters and so on -- which *greatly* helps reduce the number of dumb
errors in a program. If programmers want the "freedom" to deal with
uninitialized variables, invalid subscripts, invalid parameters and so
forth, there are already many other programming languages available to meet
those needs.
>[Namespace]
>
>I think there is general agreement, especially by those who have tried
using
>multiple libraries. The problem even occurs with using named indexes in
>sequences:
>
> window[POSITION]
> political[POSITION]
>
>This whole namespace problem seems to beg for implementing classes. After
>all, we're trying to use the same names to accomplish different results -
>the very definition polymorphism.
>
>Obviously, there is no trivial fix for this. I had investigated putting
>together a pre-processor for structures some time back, but dropped it when
>it became apparent that because of their recursive nature, it would be
>impossible to resolve structures until run time.
I agree totally and wholeheartedly with both points made here. Namespace
issues are a major headache for any Euphoria programmer. The whole reverse()
fiasco -- involving Euphoria 2.1 alpha and old versions of Win32Lib -- is
only the most recent example of this. I think we should be allowed to
redefine *any* routine, not just the built-in ones -- the interpreter can
generate warning messages for this, very much like the existing warnings for
the redefinition of built-ins.
And I obviously agree with Dave's remarks about structures. I won't go into
this again, since I believe I've already made my views on this point clear.
(Do I hear strains of the "Hallelujah Chorus"?) :)
Gabriel Boehme
