Re: Euphoria's identity/philosophy -- Where is the focus?
- Posted by jimcbrown (admin) Nov 04, 2014
- 3034 views
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.
Irv complained about routines that did not exist under the old version of Euphoria. Your own example however is about routines that do in fact exist under the new version of Euphoria (but not all of which existed under the old one).
Eg, a fundamental process underpinning just about any non-trivial business task is the sorting of lists of data.
Agreed.
Performance is also another consideration.
Agreed.
The sort has to be stable
sort() - NOT stable
custom_sort() - NOT stable
What do you mean by stable?
Certainly, if there are problems with these routines that can be repeatably demonstrated with test code, then either the problems should be fixed or else the routines replaced with better versions that don't share those problems.
sort_columns() - NOT stable, in fact, worthless for business apps or anything where the correctness of the end data is paramount.
Can you give examples where the end data is incorrect? You probably found a bug (or several), and these need to be fixed.
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:
My 2 cents: if the code works well and performs well, but happens to be ugly, that's a reasonable trade off. Of course, you're claiming failure on all three standards...
What exactly do you mean by bloated? The dictionary definition of bloated refers to swelling, which doesn't seen applicable here.
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.
I see no reason why these routines can't be added to the stdlib directly (after an appropriate and purely pro forma code review of course).
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.
Ditto.
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.
Actually, you're wrong. There is no underlying deficiency anywhere.
That's a comment that should have been cleaned up and removed. It refers to a much older version of the demo, where this was a problem: http://scm.openeuphoria.org/hg/euphoria/rev/287ce495bda9
However, if you look at the latest version of the demo at http://scm.openeuphoria.org/hg/euphoria/file/f0054b3a8f8b/demo/net/sock_server.ex you'll see that, even though the comment is still present (and thus incorrect), the issue itself has been fixed. To quit the sock_server demo, simply just have a sock_client send the quit command to the server.
