Re: The fate of Euphoria

new topic     » goto parent     » topic index » view thread      » older message » newer message

On Sat, 06 Nov 2004 18:39:58 +1100, David Jarvis <davidj at ultrasmart.org>
wrote:
> **From one viewpoint**
> My only interest in Eu's fate is whether the investment in time I
> have taken to learn and use it, and the fee I paid for the Private Ed
> of the interpreter v 2.4 will be "lost" if it "dies" tomorrow.

That is correct - we are not dependent from Rob, the 2.4 euphoria
package doesn't require 'activation', or anything similarly repugnant.


> If Eu died tomorrow - it would owe me nothing. And I would probably
> continue to use if for a number of years.
> I suspect many others also find Eu *currently* a very useful tool
> which is very good value (in terms of fee, ease of use, power). So I
> suspect it will keep going for a while yet.

Yes, that also is true. I suspect that Rob is happy with the number of
users Euphoria has at the moment, and has no particular desire to make
it expand. Then again, I may be wrong - but no matter.

I suppose the question appears - why *aren't* there more people who
use Euphoria, considering it's been around longer than PHP...?
There's not a simple answer, and I think the perceived weaknesses of
Euphoria aren't going to deter new users - they won't even be aware of
those weaknesses until they've used it for a longer period of time.

> **Could it be better?**
> For whom? Making it better for you may mean it is no longer as useful
> to me (eg harder for me to learn because of the extra feature you
> wanted).

There are two ways to write a language. 
The way that Euphoria seems to be taking is the first - for each
function of the language, there are 1 or 2 ways to accomplish that
task. An approach I think is *largely* sensible.

However, those few choices may not be ideal for the task - one example
- multiple subscripts of a sequence:
--( e = {5,10} )
my_sequence[e[1]][e[2]] --finds the element at my_sequence[5][10]

Okay, fair enough. It would be easier for some tasks though, to be
able to do this:
--( e = {5,10} )
my_sequence[ e ] --finds the element at my_sequence[5][10]

So, you have a dilemma. One the one hand, it's easier to write, it may
well be faster, and it allows custom levels of subscripting. On the
other, it's not as easy to understand.

The second approach to take is like that of Perl. There are many many
many ways to accomplish a task. The downside is that it can be very
difficult to understand. If you implement too many ways of doing
something, the syntax becomes unclear, as anyone who's seen Perl Golf
can tell you.

A balance needs to be struck, which *may* (although I wish he'd
out-and-say-it) be a cause of Rob's hesitance in implementing anything
new. If unchecked, 'improvements' could quickly cause the language to
become unclear.

> In contrast to what a number of members seem to be implying, RDS
> probably have quite a lot at stake in making Eu "better".

Here, I disagree.
Rob's job is selling Euphoria, and a few other things, like
ListFilter. (As far as I know, Rob feel free to correct me)

All Euphorians *use* Euphoria, some of us for our job. If Euphoria
needs a small enhancement for it be useful for a particular task, that
user has a large stake in that enhancement being implemented. As was
mentioned, variable_id() could make a large difference in the
suitability of Euphoria - a GOOD difference.

Rob on the other hand, sells Euphoria. Once a person has used Euphoria
a little, they'll usually want to get a registered version so that
they can continue making more complex projects. Once they've paid, Rob
doesn't have to listen to them. If there's a request for an
enhancement, there's no real benefit to Rob implementing it in an
upcoming version - that user will probably get the new one anyway -
either because by buying the previous version, they're entitled to it,
or they'll upgrade anyway, just to get the bug fixes. I dare say he
has no incentive to even think about whether a new feature should be
added to the language - unless it's a simple thing, and doesn't take
much effort, and benefits him, what's the point? He'll be paid anyway.

 
> Many of the posts I have read seem to be from people who work in or
> understand the software industry and who *care* about Eu and it's
> future. They seem to be from people who can see that Eu has a great
> future and may miss out on it because of lack of certain features, or
> lack of pace in its evolution.

Indeed. One thing is, you never have trouble finding information about
C or C++. It's gone past a critical mass point, where there are so
many people using the language that there is an incentive for new
users to learn the language, and increase the number of people using
the language. So, the mere fact that lots of people use the language
helps, because if you have a problem there are many sources of
information to solve that problem.
Euphoria is nowhere near this point. However, it's still a good idea
to attract more people - I'm glad I never have to figure out the
windows API myself, and I don't have to, because fellow Euphorians
have already done it. Numbers are important.

 
> I'm not sure why they *care* about Eu - perhaps they have put in much
> more to the development of Eu than I have - eg via contributed code
> into the archive. However, I suspect RDS may do well listening to
> these people.
See above. And yes, I think RDS would be better off if he listened to
us. Who knows, perhaps ListFilter deletes all these messages before
they even reach his pristine ears?

-- 
MrTrick

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu