Re: The fate of Euphoria
- Posted by Patrick Barnes <mrtrick at gmail.com> Nov 06, 2004
- 533 views
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