1. Re: What's Holding Euphoria Back
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.
[Primarily DOS]
Euphoria is still primarily a DOS application, despite efforts to graft the
Win32 API on. This limits it to a DOS hobbyist base.
<<Insert plug for built in cross-platform API support here>>
[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.
[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.
-- David Cuny