Re: Euphoria's identity/philosophy -- Where is the focus?
- Posted by Spock Nov 03, 2014
- 3223 views
Irv,
I remember reading some of your posts on the old forum, and your frustration with the lack of some features and Rob's refusal to implement them, so I'm happy for you that you eventually got what you wanted.
But what do you mean by "modern"? It seems to me that 4.x went more the way of C, which can hardly be called "modern". In my opinion, adding a bunch of built-ins and control structures only served to distract from Euphoria's distinctive USP, which is the sequence.
Let me give just 1 example: years ago, I wrote business apps in Euphoria. It was easy to use, and Eu code is clear enough that some other programmer could, if necessary, maintain the apps if I were no longer available. Several of these programs are still in daily use.
Then someone wanted to connect to that new internet thingy, and I had to buy books on internet protocols and write my own low-level code to connect. It worked - but was incomplete, since I had other things to do besides developing a complete net library *and* properly documenting it.
Other people contributed more or less complete net libraries to RDS archives, but I was never really able to use these, either because of some missing feature, minimal documentation, or coding styles that left me puzzled. IOW, it often took more time to figure out how to use a contributed library that it took to write my own from scratch.
To me, a "modern" programming language should be able to download web pages without the programmer having to learn low-level protocols and spending days (for me, weeks) writing and testing code.
That's just one of dozens of things that have been added to Eu 4x - call 'em convieniences, if you wish - that make life easier for programmers who prefer to "build a car" rather than "reinvent the wheel".
Hi Irv,
The issues you describe above with the old Euphoria are _exactly_ what I encounter with the new Euphoria, ironically. I write and maintain business apps on a daily basis. I just can't use the new std lib routines for the tasks I require.
Eg, a fundamental process underpinning just about any non-trivial business task is the sorting of lists of data. The sort has to be stable and capable of sorting by column. Performance is also another consideration. The std sort routines just dont' cut it. The code is also bloated and ugly. Whoever created std\sort.e hasn't done a good job at all:
sort() - NOT stable
custom_sort() - NOT stable
sort_columns() - NOT stable, in fact, worthless for business apps or anything where the correctness of the end data is paramount.
insertion_sort - STABLE but has bad performance for large data sets, also no column sorting
I've written my own sorting routines. There is one interface, sort(), and a few extra optional params to get whatever specialisation I require (column, index, custom, arbitrary). The sort is always stable, capable of column sorting, and very fast.
Another example: The Hash Table in map.e - Although this probably has correctness, it is extremely bloated and has terrible performance. I would consider this implementation to be the HT equivalent of BubbleSort. Of course I've written my own with a much simpler interface and much better performance.
A future example will be network access. So far my apps have operated as standalone entities but I can see that to be even more useful they will require client/server interactions. Now I could just try and use some of the std code but that would not be very responsible. The demo sock_server.ex has these intriguing lines:
- what do we do if we want to shut down the server?
- do we have to use Ctrl+Break?! Is there no other way?
These seem to hint at an underlying deficiency somewhere, perhaps in socket.e, that I could never tolerate in my programs. So I am thinking that to educate myself and just for my own peace of mind it would be a good idea if I rewrite this stuff from scratch. And make it bullet-proof.
I find your statement about "convieniences.. that make life easier for programmers.." rather underwhelming.
Spock
