Re: Euphoria's identity/philosophy -- Where is the focus?

new topic     » goto parent     » topic index » view thread      » older message » newer message
Spock said...

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).

Spock said...

Eg, a fundamental process underpinning just about any non-trivial business task is the sorting of lists of data.


Spock said...

Performance is also another consideration.


Spock said...

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.

Spock said...

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.

Spock said...

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.

Spock said...

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).

Spock said...

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.


Spock said...

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:

However, if you look at the latest version of the demo at 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.

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


Quick Links

User menu

Not signed in.

Misc Menu