1. Euphoria's identity/philosophy -- Where is the focus?

slacker said...

Rob's vision was "Just Say no to complicated programming languages", but in my view, it seems that the devs lost sight of that imperative.

Yep, the "not being complicated" aspect was probably what the other thread's OP had in mind when he was asking about Eu's minimalism.

MatthewMacGregor said...

I believe that to be effective and successful, most languages need to figure out their identity.

To me, what's most valuable about Euphoria is that it's elegant, readable, easy. In this regard, the recent versions have remained faithful to these principles. However, as for the language's "identity" (or, if you will, "philosophy") there is certainly scope for discussion, especially considering that it is not something set in stone, or even explicitly defined for that matter. But it's worth exploring it, hence this thread. From what I understand minimalism as such is no more a guiding principle (perhaps it never was), but the anti-bloat guidelines remain in place, as well as the readability requirements. That, along with elegance, is what I like best about Euphoria. Yet there a few syntax changes (proposed by various users in the past, but alas, mostly ignored - ahem, developers please take notice) that would be much welcome, in order to improve things in the way of readability and *simplification* (to mention but one: the comparison of sequences with the = operator). The principle of least surprise is an important guideline to keep in view, and I believe it should be central to Euphoria's philosophy: the programmer should always get what he expects, or at least his "surprise" should be minimized. Consequently, the language syntax and semantics should be made as intuitive as possible. Again, getting an error message when you are trying to compare sequences with = is not very nice... For the sake of user friendliness it would be worth making the effort to change the syntax to accommodate the expectations of the newbie programmers and thus eliminating unnecessary glitches.

MatthewMacGregor said...

Development should be focused on making sure it continues to solve the problems it's uniquely positioned to solve well.

I think a comparison with Python might be in order here, because I believe that Python is probably the closest contender to what we may call Euphoria's "area of excellence" (i.e. what grants it a unique positioning), especially in terms of readability, elegance, intuitiveness, etc. Of course Python is much more developed than Euphoria, but for this very reason it has become bloated and very slow. So Euphoria is waaaaay better in this regard. Nonetheless, we must recognize that in terms of friendliness, ease of use and intuitiveness Python really shines (I would place it on a par with Euphoria). The point I am trying to make, taking hint from Matthew's remark, is that the best thing to do is to concentrate on Euphoria's best strengths, which for me are simplicity, readability, intuitiveness, etc. They are undisputably Euphoria's forte. In other words, the primary focus should not be on adding new features (we don't need another Python...), but on improving the Euphoria's programming experience through syntactic sugar and the like. I am insisting on this because I believe that this is truly Euphoria's area of excellence today, so it should be made a priority. Of course, other people may have different views as to what constitutes Euphoria's "core identity" or as to what its primary strengths are, and they are welcome to express them.

Regards to all Euphorians,

GreenEuphorian

new topic     » topic index » view message » categorize

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

I think EUPHORIA's core identity is the following:

  1. to have only one kind of data: objects which are an atom or a sequence of objects
  2. to have pass by value for *everything*. Not only atoms but sequences as well.
  3. in contrast to the famous expression "Garbage In, Garbage Out". Euphoria is Garbage In, Error Out.


There is a bit of a compromise with poke and peek. We have what in C are void* pointers. This violates the first principle (they are atoms that you can get other information from), yet Euphoria would be very limited if you couldn't do this kind of thing. A wrapper library is supposed to hide these routines.

Euphoria sequences are most like arrays in other languages. A number is a number. There is no concept of 5 the complex number vs. 5 the floating point number vs. 5 the integer. Any library that works with very large numbers violates this idea. For the sake of argument I implemented 320 bit big endian integers using sequenes in the namespace bignum. Because now we have 5 vs. bignum:new("5") which are different but the same, we no longer have 5 is just 5 anymore. Such objects are useful, however.

It would be nice if we could reconcile the later in such a way that 5 == bignum:new("5") would return 1. The only way I can see to do this is to allow arbitrarily long integer and floating point sizes to be used by default and to have an 'approx' function that could be used to crunch them back into 64-bit double floats again. As an optimization approx( 10 / 3 ) would simply be division by double floats.

Other languages pass by reference and value. Euphoria has pass by value or it looks like that from the user's prospective. The fact that it copies on write is an implementation detail on how it implements pass by value. There are ways around that though. Like the std/map.e library which uses false pointers. This has caused some confusion among some users who save the map to a disk, (really only a handle) and find the map doesn't exist when another process tries to use the same handle. That's the cost of using false or real pointers. The win is you get pass-by reference semantics with std/map. If it were pass-by-value, each routine would need to return a new map in order to modify an existing one. Some deem always returning the modified structure to be a less attractive way of doing things.

Finally, garbage in, error out. The user is supposed to know a value should attain a certain value, run-time type checking catches this error, assigning to an index out of bounds is an error, etc. If possible, don't let the user shoot himself in the foot.

I think that often the last principle is in conflict with the first. Having distinct types prevent all kinds of errors from happening. As mentioned before, pointers in Euphoria are essentially void*, for they are simply just numbers (principle 1) and they do not have the structure type information that you get with C in int* and so on. The coder has to determine the type on each access (against principle 3). The EUPHORIA parser cannot check for this.

The three-principles are in order of importance, except that principle two and one are at par with each other.

Shawn Pringle

new topic     » goto parent     » topic index » view message » categorize

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

SDPringle said...

Like the std/map.e library which uses false pointers. This has caused some confusion among some users who save the map to a disk, (really only a handle) and find the map doesn't exist when another process tries to use the same handle. That's the cost of using false or real pointers. The win is you get pass-by reference semantics with std/map. If it were pass-by-value, each routine would need to return a new map in order to modify an existing one.

FYI, both the Map and Stack libraries use Pseudo Memory (std/eumem.e) library for these "false pointers" to provide pass-by-reference functionality. The Pseudo Memory library has the potential for a variety of uses based on its "pointer" semantics.

SDPringle said...

I think that often the last principle is in conflict with the first. Having distinct types prevent all kinds of errors from happening. As mentioned before, pointers in Euphoria are essentially void*, for they are simply just numbers (principle 1) and they do not have the structure type information that you get with C in int* and so on. The coder has to determine the type on each access (against principle 3). The EUPHORIA parser cannot check for this.

I think that when you start to cross over into other languages (e.g. working with a C library) then most of the rules go out the window. However, I believe that the author of a C library wrapper should do his best to preserve the nature of Euphoria within that wrapper to the benefit of his users (other Euphoria programmers). The same concepts, I believe, will hold true when (if?) the struct branch goes full-time: typical Euphoria programmers won't need to use built-in structures, but library authors can use them to ease the burden of wrapping a structure through peek()/poke() calls.

-Greg

new topic     » goto parent     » topic index » view message » categorize

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

SDPringle said...

I think EUPHORIA's core identity is the following:

  1. to have only one kind of data: objects which are an atom or a sequence of objects
  2. to have pass by value for *everything*. Not only atoms but sequences as well.
  3. in contrast to the famous expression "Garbage In, Garbage Out". Euphoria is Garbage In, Error Out.


I think your short list nails it for 80%-90% of the identity of Euphoria, despite the caveats in the rest of your post.

One thing that I would add is that Euphoria code is readable, more than any other language I've studied. It's neither overly terse nor overly verbose, but it seems to hit a sweet spot. Just my opinion.

new topic     » goto parent     » topic index » view message » categorize

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

jaygade said...
SDPringle said...

I think EUPHORIA's core identity is the following:

  1. to have only one kind of data: objects which are an atom or a sequence of objects
  2. to have pass by value for *everything*. Not only atoms but sequences as well.
  3. in contrast to the famous expression "Garbage In, Garbage Out". Euphoria is Garbage In, Error Out.


I think your short list nails it for 80%-90% of the identity of Euphoria, despite the caveats in the rest of your post.

One thing that I would add is that Euphoria code is readable, more than any other language I've studied. It's neither overly terse nor overly verbose, but it seems to hit a sweet spot. Just my opinion.

Adding features has been run away race in all directions trying to emulate every other

computer language with no single leader like Rob.

The original idea of the design of Euphoria :

1: A core of necessary functions and procedures to create and run a Program.

2: The ability to write and added a library to expand the capabilities of Euphoria.

3: A translator to combine the core and your libraries into a fast single program.

Just look at the programs in the archive that were written before 4.00 !

There are hundreds of programs in the archive that worked and solved problems.

What happen to creativity and the challenge to solve a problem ?

I keep seeing new users come to the language and saying why isn't feature xyz

in Euphoria like the abc language ?

It seems that users think that every feature has to be a built-in feature.

That is my opinion.

bernie

new topic     » goto parent     » topic index » view message » categorize

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

Bernie,

That's pretty much what I think. I didn't say anything at the time all this development was going on because it would have made no difference (I'm just a "Joe User", not a skilled C programmer who could have contributed), and besides, it surely would have come across as churlish.

I paid for Euphoria updates for years and was happy to do it. Not knocking open source, and of course it was Rob's decision, but IMO it would have been better if he could have stayed on as a "benevolent dictator". Design by committee doesn't really work very well.

Anyway, I'm not complaining. Eu 3 suits my needs perfectly and I'll be sticking with it. It's a pity it's not being maintained any more, although I doubt there are many bugs (I haven't found any yet).

Regarding Euphoria's niche, there still seems to be very little consensus on what it is.

new topic     » goto parent     » topic index » view message » categorize

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

Slacker said...

That's pretty much what I think. I didn't say anything at the time all this development was going on because it would have made no difference (I'm just a "Joe User", not a skilled C programmer who could have contributed), and besides, it surely would have come across as churlish.

Actually, I think it would have been better for you to have spoken up back then.If everybody felt that way, but no one was willing to speak up, how could we have known about it? I've expressed my disappointment about this before: http://openeuphoria.org/forum/m/119572.wc

The way it looks to me is this:

Most users don't bother to respond at all, and it's unclear what their opinions are (or even if they have decided upon one).

Of those who do wish to speak up, a bare majority seem to generally agree with most changes, a very large minority disagree, and a much smaller minority have no opinion.

For an example, see: http://openeuphoria.org/forum/m/119566.wc

Slacker said...

I paid for Euphoria updates for years and was happy to do it. Not knocking open source, and of course it was Rob's decision, but IMO it would have been better if he could have stayed on as a "benevolent dictator". Design by committee doesn't really work very well.

You might be interested in this project then: http://openeuphoria.org/forum/m/122732.wc

Slacker said...

Anyway, I'm not complaining. Eu 3 suits my needs perfectly and I'll be sticking with it. It's a pity it's not being maintained any more, although I doubt there are many bugs (I haven't found any yet).

Again, I'm surprised. As I've stated before, it definitely does have known bugs: http://openeuphoria.org/forum/m/122733.wc

new topic     » goto parent     » topic index » view message » categorize

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

Here is was what my opinion was about open-source Euphoria 8 years ago.


Posted by Bernie Ryan <xotron at bluefrog.com> Sep 20, 2006
104 views

Rob:

In my opinion making Euphoria open-source is a BIG mistake.

I think that Euphoria full source code should be made available
without restriction for a FEE that allows a purchaser to develop
it or sell it in any way that the purchaser desires. The only
requirement being that the purchaser sign a non-discloser agreement
and that RDS be given credit for it's work somewhere in the about box.
RDS would still keep a public domain version available for the
general hobbiest or users that don't have the ability to modify
the code. I'am sure that some developer's would be willing to share
some of their ideas with RDS to add to public domain version which
would take the pressure off RDS to add this feature and that feature
because a user could purchase a version developed by another user.

This would keep Euphoria from becoming a run away train.
It protects the users that already have time invested in Euphoria.
It allows Euphoria development to proceed in an orderly way.

A far as I'am concern I don't think anyone should be able to vote
on any direction of Euphoria that hasn't purchased it.

Bernie


Posted by Bernie Ryan <xotron at bluefrog.com> Sep 26, 2006
91 views
Last edited Sep 27, 2006

I keep reading on this list about how you are going to need
version control and all these developers are going to do
this and that.

My question is who are all these developers and where are they
going to come from.

I only know of maybe 3 or 4 users on this list that have the skills
to modify and incorporate changes into the source that would make
Euphoria improvements.

I think that this open-source rush to judgement is blinding a lot
of ordinary users into beleving that something magic is going
to happen to Euphoria and 100 new developers are going suddenly
to appear at RDS door demanding a copy of the source so they can improve it.

How many times has someone said "I'am going to develop a open-source
version of Euphoria" and it died on the vine ?

Euphoria has to be found and accepted by many more users then
it presently has. Mean while you wait for the developers to show up
you are going to lose all the users that develop libraries because
the incentive for developing the libriares will disappear; ie
micro-bucks.

Bernie

new topic     » goto parent     » topic index » view message » categorize

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

Those of us who have a better memory would probably say that "design by committee" is working much better than the "benevolent dictator" version, simply because Rob was extremely reluctant to add anything to Euphoria, no matter how many requests were made. He had the right to do that, of course, but the lack of 'modern' features probably turned off a lot of would-be Eu programmers.

Now, of course, the opposite situation exists - there are more features than I generally need. Just because I don't need them at the moment doesn't mean no one else needs them, or that I won't need them in the future.

Just because it was (usually) possible to extent Eu 3 with your own code to do whatever it was you needed done, does not mean that I also prefer to waste time writing my version of the same functions. Functions which would probably be incompatible with everyone elses' versions.

new topic     » goto parent     » topic index » view message » categorize

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

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.

There is the issue of knowledge representation and how the structure and syntax of the language, to certain degree, dictates the way you tackle the problem. So someone who is used to programming in BASIC tends to think in terms of numbers, strings, arrays, for loops etc, whereas someone using Lisp thinks in terms of lists and functional programming, and the target demographic is quite different for these languages.

So I guess it comes back to Euphoria's intended niche, and what that is, or should be. If it's supposed to be a general-purpose language that's powerful AND easy to learn and use, you can't go on adding stuff and expect the niche to stay the same, because more choice comes at the cost of less easy to learn and use.

new topic     » goto parent     » topic index » view message » categorize

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

Slacker said...

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.

Were you distracted? Have you evidence that anyone at all has been distracted? And how has this distraction manifested itself? Can you fill in the logical progression from "adding a bunch of built-ins and control structures" to "distract from ... the sequence", because I've been thinking about what you are saying here and I'm finding it hard to see the connections.

Slacker said...

... comes back to Euphoria's intended niche, and what that is, or should be.

I'm pretty sure that Euphoria doesn't have an intended niche because that would imply a coherent and guiding agency that is driving the development and future of the language. And that doesn't exist. It is just a language to be used for whatever purpose(s) you as a developer want to use it for.

Slacker said...

If it's supposed to be a general-purpose language that's powerful AND easy to learn and use, you can't go on adding stuff and expect the niche to stay the same, because more choice comes at the cost of less easy to learn and use.

Just a few comments for now on this aspect...

  • Yes, in the general case, there is a tipping point in which any given structure (eg. a programming language) can be expanded beyond its usefulness. In Euphoria's case, I'm of the opinion that that stage has not been reached, and is in fact still some way off. Of course you are entitled to differing opinions.
  • Euphoria is a general purpose language and one that allows multiple coding styles. It is expected that a developer would only use Euphoria's capabilities in a manner that they felt comfortable with, unless one has to abide by some corporate rules. In other words, if you don't want to use the added aspects of the language, then don't. Euphoria and the OpenEuphoria team don't care how you use the language.
  • The problem of source code using language features that one is not desirous of, is really only applicable when reading or maintaining someone else's code. And if you are doing that, then it might be that one also has to expand their education in the language. I'm not so sure that that is such a bad thing.
new topic     » goto parent     » topic index » view message » categorize

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

Slacker said...

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

new topic     » goto parent     » topic index » view message » categorize

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

irv said...
Slacker said...

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

new topic     » goto parent     » topic index » view message » categorize

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

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.

Agreed.

Spock said...

Performance is also another consideration.

Agreed.

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.

Ditto.

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

new topic     » goto parent     » topic index » view message » categorize

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

Spock said...

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.

Spock

The std/sort.e routines date back to at least E2.5 which have always used the shell sort algorithm.

A stable sort is "one which retains the original order of items while sorting." That is when two items of equal value are sorted the do not change relative positions if the sort is stable but may or may not change if the sort is unstable.

The old docs tell you a shell sort is unstable but do not define "stable."

The cure for a better sort algorithm is if you, Spock, could contribute the code you have developed and already tested to the standard library. We would all be grateful.

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.

The same goes for alternative Hash algorithms and interface.

_tom

new topic     » goto parent     » topic index » view message » categorize

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

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.

And you have posted these routines to RDS's code sharing archives?

You can do this without getting approval from Rob or the current developers, so that the rest of us can benefit from the improvements.

If not, please do so - I will be happy to use them.

new topic     » goto parent     » topic index » view message » categorize

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

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


NO. Irv said "..people contributed more or less complete net libraries to RDS archives, but I was never really able to use these, either because .."

This is my issue as well. The only difference between the 2 code sets is that the latter have been incorporated into the Eu bundle. So, my point remains.

jimcbrown said...
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.

Jim, are you making a joke here? I think you know what stability in sort algos means. The solution has always been around: Merge Sort - but not the one that was in the old Eu demos. Rob made a mistake in the code and the sort was not stable unless you change the comparison:

if compare(a[1], b[1]) < 0 then -- wrong, not stable  
if compare(a[1], b[1]) <= 0 then -- good, stable since the first element is placed sooner in the sequence when compared to an equal second element 

What I did was to enhance insertion_sort() and call that inside merge_sort() for sequences of less than 100 items. The result is pretty good.

jimcbrown said...
Spock said...

sort_columns() - NOT stable..

Can you give examples where the end data is incorrect? You probably found a bug (or several), and these need to be fixed.

sort_columns() calls custom_sort() which use the unstable shell sort. Unless I'm mistaken the end result is that the data is not guaranteed to be in the intended order.

jimcbrown said...
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.

The cores inside merge() and insertion_sort() have duplicated sequences (for ascend/descend). And the core of sort() is pretty much the same as custom_sort().

Spock

new topic     » goto parent     » topic index » view message » categorize

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

_tom said...

The old docs tell you a shell sort is unstable but do not define "stable."

The cure for a better sort algorithm is if you, Spock, could contribute the code you have developed and already tested to the standard library. We would all be grateful.

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.

The same goes for alternative Hash algorithms and interface.

_tom

Hi Tom,

When I tested the HT in map.e on an image to try and count the number of unique colors in a bitmap I got a performance difference of some ridiculous factor, in favor of my code. I would have repeated that test right now except.. I can't get map.e to work!

I'll post something later when I can figure it out.. which is the whole point of what I am saying. Why should I have to do extra work to cover someone else's mistake? Whether that's a code lib or programming language, same thing.

Spock

new topic     » goto parent     » topic index » view message » categorize

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

Spock said...
_tom said...

The old docs tell you a shell sort is unstable but do not define "stable."

The cure for a better sort algorithm is if you, Spock, could contribute the code you have developed and already tested to the standard library. We would all be grateful.

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.

The same goes for alternative Hash algorithms and interface.

_tom

Hi Tom,

When I tested the HT in map.e on an image to try and count the number of unique colors in a bitmap I got a performance difference of some ridiculous factor, in favor of my code. I would have repeated that test right now except.. I can't get map.e to work!

I'll post something later when I can figure it out.. which is the whole point of what I am saying. Why should I have to do extra work to cover someone else's mistake? Whether that's a code lib or programming language, same thing.

Spock

Ok. I am going to make a retraction on the hash table in map.e - the performance is (finally) now not too bad. My original test (see below) was based on the Oct 2012 release. The latest one has corrected the poor algorithm used. However, the interface and unnecessary bloat are still disgusting. The original criticsm was valid, just 2 years too late.

-- Original test 
 
include std/console.e  
include std/map.e  
 
procedure test() 
	atom t 
	t = time() 
	object m = map:new() -- Create a new map 
 
	for i = 1 to 100000 do 
		map:put(m, i, i) 
		map:has(m, i) 
	end for 
 
	? time() - t 
 
	? 9/0 
end procedure 
 
test() 
 
-- map.e 2.5 s 
-- my hash.e .202 s, 12 times faster 
 
new topic     » goto parent     » topic index » view message » categorize

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

Spock said...

Ok. I am going to make a retraction on the hash table in map.e - the performance is (finally) now not too bad. My original test (see below) was based on the Oct 2012 release. The latest one has corrected the poor algorithm used. However, the interface and unnecessary bloat are still disgusting.

"Disgusting"?!? It's a bit of a strong word you used here...

new topic     » goto parent     » topic index » view message » categorize

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

Spock said...
jimcbrown said...
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).


NO. Irv said "..people contributed more or less complete net libraries to RDS archives, but I was never really able to use these, either because .."

Ok, I understand now. I believe he meant both, hence the confusion.

Spock said...

This is my issue as well. The only difference between the 2 code sets is that the latter have been incorporated into the Eu bundle. So, my point remains.

In this specific example, the socket interface in v4 has been written from scratch, rather being incorporated from a library from the archive.

Spock said...

Jim, are you making a joke here?

No.

Spock said...

I think you know what stability in sort algos means.

I didn't until _tom's clarification.

Spock said...

The solution has always been around: Merge Sort - but not the one that was in the old Eu demos. Rob made a mistake in the code and the sort was not stable unless you change the comparison:

if compare(a[1], b[1]) < 0 then -- wrong, not stable  
if compare(a[1], b[1]) <= 0 then -- good, stable since the first element is placed sooner in the sequence when compared to an equal second element 

What I did was to enhance insertion_sort() and call that inside merge_sort() for sequences of less than 100 items. The result is pretty good.

Sounds good to me. I don't see any hurdle to getting this change into trunk.

Spock said...
jimcbrown said...
Spock said...

sort_columns() - NOT stable..

Can you give examples where the end data is incorrect? You probably found a bug (or several), and these need to be fixed.

sort_columns() calls custom_sort() which use the unstable shell sort. Unless I'm mistaken the end result is that the data is not guaranteed to be in the intended order.

Hmm. Could we modify custom_sort() to call the enhanced insertion_sort()+merge_sort() (with your fix in it) to make it (and thus sort_columns() ) stable as well?

Spock said...
jimcbrown said...
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.

The cores inside merge() and insertion_sort() have duplicated sequences (for ascend/descend). And the core of sort() is pretty much the same as custom_sort().

Spock

Ah, ok, I understand now. Most of that is from the Rob Craig days .. but it would definitely be nice to get it cleaned up.

new topic     » goto parent     » topic index » view message » categorize

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

Spock said...

Ok. I am going to make a retraction on the hash table in map.e - the performance is (finally) now not too bad. My original test (see below) was based on the Oct 2012 release. The latest one has corrected the poor algorithm used. However, the interface and unnecessary bloat are still disgusting. The original criticsm was valid, just 2 years too late.

Actually, you're not the first to point this out.

There's a ticket that covers part of this, http://openeuphoria.org/ticket/893.wc - and I think Derek was working on a complete rewrite. See http://openeuphoria.org/forum/m/124691.wc and http://openeuphoria.org/forum/m/124274.wc

A complete rewrite is a major task, hence the long period of time... if you already have a superior library, I defnitely think it makes sense for the devs to take a look at it to see if we can get an improved map or HT library into the stdlib that much faster.

new topic     » goto parent     » topic index » view message » categorize

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

GreenEuphorian said...
Spock said...

Ok. I am going to make a retraction on the hash table in map.e - the performance is (finally) now not too bad. My original test (see below) was based on the Oct 2012 release. The latest one has corrected the poor algorithm used. However, the interface and unnecessary bloat are still disgusting.

"Disgusting"?!? It's a bit of a strong word you used here...

Everything bloated is disgusting. Don't you read fashion magazines?

new topic     » goto parent     » topic index » view message » categorize

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

jimcbrown said...
Spock said...

Ok. I am going to make a retraction on the hash table in map.e - the performance is (finally) now not too bad. My original test (see below) was based on the Oct 2012 release. The latest one has corrected the poor algorithm used. However, the interface and unnecessary bloat are still disgusting. The original criticsm was valid, just 2 years too late.

Actually, you're not the first to point this out.

There's a ticket that covers part of this, http://openeuphoria.org/ticket/893.wc - and I think Derek was working on a complete rewrite. See http://openeuphoria.org/forum/m/124691.wc and http://openeuphoria.org/forum/m/124274.wc

A complete rewrite is a major task, hence the long period of time... if you already have a superior library, I defnitely think it makes sense for the devs to take a look at it to see if we can get an improved map or HT library into the stdlib that much faster.

Sorry Jim, the 2 libs are too different (a bit like comparing Superman's Fortress of Solitude to the city in Bladerunner..) to fit, one to the other. I thought mine had superior performance but as I discovered yesterday they're on a par (now) [that state is not going to last for very long, though]. I'm also planning a major paradigm change to my compiler which suits the minimalistic interface I have [ more or less: init(), find(), add(), get() ].

I don't think the Eu Devs need my help on this one.

Spock

new topic     » goto parent     » topic index » view message » categorize

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

Spock said...
jimcbrown said...
Spock said...

Ok. I am going to make a retraction on the hash table in map.e - the performance is (finally) now not too bad. My original test (see below) was based on the Oct 2012 release. The latest one has corrected the poor algorithm used. However, the interface and unnecessary bloat are still disgusting. The original criticsm was valid, just 2 years too late.

Actually, you're not the first to point this out.

There's a ticket that covers part of this, http://openeuphoria.org/ticket/893.wc - and I think Derek was working on a complete rewrite. See http://openeuphoria.org/forum/m/124691.wc and http://openeuphoria.org/forum/m/124274.wc

A complete rewrite is a major task, hence the long period of time... if you already have a superior library, I defnitely think it makes sense for the devs to take a look at it to see if we can get an improved map or HT library into the stdlib that much faster.

Sorry Jim, the 2 libs are too different (a bit like comparing Superman's Fortress of Solitude to the city in Bladerunner..) to fit, one to the other. I thought mine had superior performance but as I discovered yesterday they're on a par (now) [that state is not going to last for very long, though]. I'm also planning a major paradigm change to my compiler which suits the minimalistic interface I have [ more or less: init(), find(), add(), get() ].

I don't think the Eu Devs need my help on this one.

Spock

If it's not a replacement for the std/map.e library, would it still make sense to include your HT library in the stdlib as a new, standard HT library? Not as a replacement or an alternative, but just as a brand new feature. You clearly get a lot of use out of it, and it's quite likely imvho that many others would as well.

new topic     » goto parent     » topic index » view message » categorize

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

irv said...
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.

And you have posted these routines to RDS's code sharing archives?

You can do this without getting approval from Rob or the current developers, so that the rest of us can benefit from the improvements.

If not, please do so - I will be happy to use them.

I will post it to the contributions page in about a week. Anyone can then take whatever they might need. It won't matter to me if it doesn't make it into std\ since I never use that anyway. I should mention that it does differ from std\sort.e in that there is no ascend/descend distinction (but that is easily implemented by adding a reverse() at the end, if needed) and it sorts by single rather than multiple columns (but this would be easy to incorporate too). Overall speed is about the same as std\sort.e

Spock

new topic     » goto parent     » topic index » view message » categorize

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

jimcbrown said...
Spock said...

The solution has always been around: Merge Sort - but not the one that was in the old Eu demos. Rob made a mistake in the code and the sort was not stable unless you change the comparison:

if compare(a[1], b[1]) < 0 then -- wrong, not stable  
if compare(a[1], b[1]) <= 0 then -- good, stable since the first element is placed sooner in the sequence when compared to an equal second element 

Sounds good to me. I don't see any hurdle to getting this change into trunk.

Don't let me stop you, but I have to point out that such a change is almost completely pointless. If I sort {2,1,2,3} and get {1,2,2,3} or {1,2,2,3}, it matters not one jot. Ever.

ERM..., unless those 2's are the subject of different delete_routine()s, but that is a bit baroque, to say the least, and if I hadn't mentioned it you probably wouldn't have thought of it, right?

Given that delete_routine() did not exist at the time it was written, the statement "Rob made a mistake in the code and the sort was not stable" is utterly wrong, on all counts.

Hee hee. Look Ma, I too can troll. But in this case at least, I am right.

Of course if you had a custom_merge_sort() based on the merge_sort() of the old Eu demo, then it would indeed make a more obvious and significant difference, and on that basis (alone) it is a good change to make.

Regards,
Pete

new topic     » goto parent     » topic index » view message » categorize

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

jimcbrown said...
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? ..

 
sequence testdata = 
{ {1,1}, 
  {2,1}, 
  {2,2}, 
  {1,2}, 
  {3,1}, 
  {2,3}, 
  {2,4}, 
  {1,3}, 
  {2,5}, 
  {3,2} } 
 
? sort_columns(testdata, {1}) 
 
 
-- Result: 
 
{ {1,1}, 
  {1,2}, 
  {1,3}, 
  {2,2}, -- 1 
  {2,4}, -- 2 
  {2,1}, -- 3 
  {2,5}, -- 4 
  {2,3}, -- 5 
  {3,1}, 
  {3,2} } 
 

The elements for the middle block are completely jumbled up. The commented numbers show what should have been in the 2nd column, if the sort were stable.

I wonder why nobody picked this up sooner? Of course, it did give me a chance to have a good rant..

Spock

new topic     » goto parent     » topic index » view message » categorize

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

Spock said...

I wonder why nobody picked this up sooner? Of course, it did give me a chance to have a good rant..

Spock

include std/sort.e 
 
sequence testdata = 
{ {1,1}, 
  {2,1}, 
  {2,2}, 
  {1,2}, 
  {3,1}, 
  {2,3}, 
  {2,4}, 
  {1,3}, 
  {2,5}, 
  {3,2} } 
 
? sort(testdata) 
/* 

{ 
  {1,1}, 
  {1,2}, 
  {1,3}, 
  {2,1}, 
  {2,2}, 
  {2,3}, 
  {2,4}, 
  {2,5}, 
  {3,1}, 
  {3,2} 
} 
*/ 

The simple answer is that "often" it does not matter if the sort is stable.

The "real" answer is we need your help. Every rant does help but arguments with source-code speak louder.

It is only logical that there should be a choice of sorting algorithms.

I just learned of the Timsort algorithm which is used in Python and Java. This is a stable sort with a hybrid algorithm. It takes about 1300 lines of C code.

Looking forward to seeing your solution.

_tom

new topic     » goto parent     » topic index » view message » categorize

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

_tom said...

I just learned of the Timsort algorithm which is used in Python and Java. This is a stable sort with a hybrid algorithm. It takes about 1300 lines of C code.

Looking forward to seeing your solution.

_tom

I have just now uploaded the sort module to the Contributions page, using the pseudonym Mike. Some changes were made to the original sort interface that I use. But it is still quite simple.

I hope that someone can rigorously test it and prove that it works as intended.

_tom, I've cursorily looked at Timsort. It has some interesting ideas which I might incorporate into my routines since the general idea is similar, ie, more-or-less an enhanced Merge Sort.

Spock

new topic     » goto parent     » topic index » view message » categorize

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

Spock said...

I have just now uploaded the sort module to the Contributions page, using the pseudonym Mike. Some changes were made to the original sort interface that I use. But it is still quite simple.

Thankyou for making this, needed sorting algorithm, available to Euphoria users. Its about time o[ had a stable sorting method.

Using the RDS allsorts.ex program I found that it is faster than quick_sort and hybrid_sort.

Get it from: http://rapideuphoria.com/msort.zip

Thanks,

_tom

new topic     » goto parent     » topic index » view message » categorize

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

from my point of view:

1. Euphoria 3.1.1 was rapid from all aspects, it only needed a comprehensive and up to date standard library, to make the language even more rapid and standard.

2. What scares me in other languages, is that there are too many ways to do the same task - it makes it much harder to maintain and understand different coding styles.

For example, Euphoria 3.1.1 forced me to declare variables at the beginning of a routine - which might be less efficient/safe, but had the great advantage of readability and simplicity; i.e.: I could read and understand the programs much faster.

So the balance between improving the scope of variables, and the ease of maintaining and understanding others codes, is not so obvious for me.

I find Euphoria 3.1.1 variable's scope easier to understand and maintain, de facto.

3. For me, Euphoria's sequence is incomparable to other programming structures. Actually, 90% of my effort, before I found Euphoria, was to calculate the memory and make hard decisions about variables types.

Euphoria's sequence is not like an array in other language. Array in other language needs to be planned very well before it may be used. To decide which type of array to use it may take a long time, needs lots of headache pills, and eventually your decision might be wrong after all.

Euphoria sequences are dynamic storage container, much more flexible and powerful then arrays and structures in other languages. You can write a big program using only one sequence - for everything, without needing headache pills at all.

So, comparing Euphoria sequences to arrays in other languages, is misleading and ridiculous.

Atoms and Sequences are definitely the main identity/philosophy of Euphoria from my point of view. Without it - Euphoria is just another language, no matter how friendly it is.

4. I would like to see less built-in options - because it leads to many programming styles and less readability and maintainability; And many more standard libraries written in Euphoria.

new topic     » goto parent     » topic index » view message » categorize

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

Shian_Lee said...

from my point of view:

1. Euphoria 3.1.1 was rapid from all aspects, it only needed a comprehensive and up to date standard library, to make the language even more rapid and standard.

Which is what 4.0.0 achieved....

Shian_Lee said...

2. What scares me in other languages, is that there are too many ways to do the same task

Not sure why this scares you. It's a plus for me. Nothing wrong with flexibility.

Shian_Lee said...

it makes it much harder to maintain and understand different coding styles.

I don't think it has much effect here. Different coders will always have wildly different coding styles regardless...

Shian_Lee said...

For example, Euphoria 3.1.1 forced me to declare variables at the beginning of a routine - which might be less efficient/safe, but had the great advantage of readability and simplicity; i.e.: I could read and understand the programs much faster.

So the balance between improving the scope of variables, and the ease of maintaining and understanding others codes, is not so obvious for me.

I find Euphoria 3.1.1 variable's scope easier to understand and maintain, de facto.

Actually, older versions of Euphoria were inconsistent here. At the module or file level, you could declare a variable immediately before use (which is the most readable form for me), but not in a routine. If one style is really better than the other, then why not enforce it universally?

I like 4.0.0 since it lets the coder pick the style which is most readable to them.

Shian_Lee said...

3. For me, Euphoria's sequence is incomparable to other programming structures.

Euphoria's sequence is not like an array in other language. Array in other language needs to be planned very well before it may be used. To decide which type of array to use it may take a long time, needs lots of headache pills, and eventually your decision might be wrong after all.

Euphoria sequences are dynamic storage container, much more flexible and powerful then arrays and structures in other languages. You can write a big program using only one sequence - for everything, without needing headache pills at all.

So, comparing Euphoria sequences to arrays in other languages, is misleading and ridiculous.

Atoms and Sequences are definitely the main identity/philosophy of Euphoria from my point of view. Without it - Euphoria is just another language, no matter how friendly it is.

True, but most other languages have other types that have the same advantages of a sequence. java.util.Vector for example......

I agree that a comparison to an array or a struct may not be the appropriate one. Perhaps it's better to compare to a List or Vector type.

In that case, functionally there is no difference. No headache pills in either. (Else David Cuny would not have been able to write his Eu2Java translator converting sequence objects to instances of java.util.Vector so easily...) It's definitely more of a philosophy thing. (Although most other languages have an equiv type, they don't necessarily have the same philosopy backing it...)

new topic     » goto parent     » topic index » view message » categorize

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

Shian_Lee said...

2. What scares me in other languages, is that there are too many ways to do the same task - it makes it much harder to maintain and understand different coding styles.

<snip>

4. I would like to see less built-in options - because it leads to many programming styles and less readability and maintainability; And many more standard libraries written in Euphoria.

For Google's Go language, this was a major design consideration. I think this is what we were talking about when we discussed "minimalism".

new topic     » goto parent     » topic index » view message » categorize

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

OK then... I didn't mention anything new.

Just wanted to add:

1. The subject here is "philosophy" - after all any vector/struct/list/array/sequence is just 0's and 1's. But Euphoria is ALL about sequences and the amazing simplicity of manipulating them.

Java - from my point of view, is a headache by itself. I get truly bored from Object-Oriented stuff, but this is personal. Yet, when you think about Java you think about Objects; when you think about Euphoria you think about Sequences. Sequences are the identity of Euphoria, the same way Objects are the identity of Java.

2. About different coding styles: I believe that the philosophy of the language itself has the responsibility to "put an end" to how many built-in options the language will supply.

Since I'm not a programmer, I am thinking from another point of view:

In the army, and specially the air force, and in a lot of electrical and mechanical equipment - designers finally realized that maintaining-time is more crucial then development-time.

It means that instead of 35 different kinds of screws they use only 3. And it means that instead of 100 different tools - jet engine can be replaced with few tools.

Engineers realized that as many options as you have to deal with - to learn, to remember, and to use - as less efficient and reliable is maintainability.

Technology is technology, and the human brain is the same. Also in programming maintaining-time is crucial - much more then development-time. As less options as you have to remember and learn - as quicker and reliable is maintainability.

The air force had to learn this fact in the hard way: many people died because of the complexity of the mechanical design. Jets could not be ready on time. But now they removed any unnecessary option and complexity, so it's possible to fix big problems in a very short time.

I hope that now and in the future Euphoria will remain simple. In real life, simple control panels are the key for saving human lives. Simplicity always wins at last.

But I believe that you all know that already. Thanks.

new topic     » goto parent     » topic index » view message » categorize

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

Shian Lee's comments provide some useful insights, and bring the thread back to its original topic.

I like the idea of "limiting the options" to limit complexity.

Thanks, Shian Lee for sharing your thoughts.

new topic     » goto parent     » topic index » view message » categorize

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

Shian_Lee said...

1. The subject here is "philosophy" - after all any vector/struct/list/array/sequence is just 0's and 1's. But Euphoria is ALL about sequences and the amazing simplicity of manipulating them.

... when you think about Euphoria you think about Sequences. Sequences are the identity of Euphoria ...

Well that might be a bit too much of a claim, but sequences certainly are one of the defining aspects of the language. There are other salient aspects as well though, such as

  • arguments are only passed by value
  • automatic garbage collection
  • use of words rather than symbols for punctuation
  • automatic conversion between floating-point and integers
  • operations work on scalars and vectors


    1 + 1 -> 2
    {1,2} + 1 -> {2,3}
    {1,2} + {4,8} -> {5, 10}

Shian_Lee said...

2. About different coding styles: I believe that the philosophy of the language itself has the responsibility to "put an end" to how many built-in options the language will supply.

Since I'm not a programmer, I am thinking from another point of view:

In the army, and specially the air force, and in a lot of electrical and mechanical equipment - designers finally realized that maintaining-time is more crucial then development-time.

It means that instead of 35 different kinds of screws they use only 3. And it means that instead of 100 different tools - jet engine can be replaced with few tools.

Engineers realized that as many options as you have to deal with - to learn, to remember, and to use - as less efficient and reliable is maintainability.

Technology is technology, and the human brain is the same. Also in programming maintaining-time is crucial - much more then development-time. As less options as you have to remember and learn - as quicker and reliable is maintainability.

The air force had to learn this fact in the hard way: many people died because of the complexity of the mechanical design. Jets could not be ready on time. But now they removed any unnecessary option and complexity, so it's possible to fix big problems in a very short time.

I hope that now and in the future Euphoria will remain simple. In real life, simple control panels are the key for saving human lives. Simplicity always wins at last.

But I believe that you all know that already. Thanks.

Yes, however it turns out that the situation is not that simple smile

Albert Einstein said...

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

Which can be paraphrased as "Everything should be made as simple as possible, but don't over do it."

Achieving simplicity is actually complex. A good book on this subject is Edward de Bono's "Simplicity".

Some of the issues that arise when striving for simplicity include

  • We all have a different perception of what is simple.
  • Reducing something to very simple components can have the side effect of making it harder (more complex) to use.
  • Things that are simple to use (and achieve much) are usually possess hidden complexity.

When we were children, arithmetic was hard and doing sums with big numbers was complex. We went to school and our ideas of complex/simple were constantly changing. Division ... Long Division ... decimals ... matrices ... exponentiation ... differential calculus ... imaginary numbers ... etc. The more we learned the more things became simple, to a degree. Each of us eventually come to a level of mathematical proficiency that no amount of extra tuition will transform into simplicity. And that level is different for each of us. This applies to most things in life, including programming languages. This is not a fault of the subject matter. It is not a fault in anything actually - it just is.

Some people would view Euphoria as a toy language that is simple and without any sophistication. And they are correct ... for them. Other people might find it bewildering with the twisted things that programmers do with it. And they too are correct ... for them. Where does one "draw the line"?

In your example, the military settled on 3 different types of screws. Why not 2, or 4, or even 1? Surely one screw type would have been the simplest? Well, of course yes, for some aspects but it would have made other things more complex or difficult or maybe not even possible.

What if we made Euphoria simpler by removing all flow control statements except the goto? Definitely simpler. But also not worth the effort of having a language this simple. Where does one "draw the line"?

What if we only had one type of file (one directional byte-stream like the old tape drives). This would simplify the language. The open() statement would no longer need to know if its a binary or text mode file. And we could get rid of the seek(), position(), where() routines. Not a problem, right?

Okay, I'm belabouring the point now, I know. But the question is really, if Euphoria is to be kept as a simple language, we need to define what simple means, and thus where to "draw the line".

Lee, can you give me specific things that would make the language simpler?

new topic     » goto parent     » topic index » view message » categorize

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

Shian_Lee said...

OK then... I didn't mention anything new.

Just wanted to add:

Derek already addressed this better than I could. However, I'd like to point out one thing:

Shian_Lee said...

In the army, and specially the air force, and in a lot of electrical and mechanical equipment - designers finally realized that maintaining-time is more crucial then development-time.

I know someone who served in the US Air Force, and another individual who worked for a manufactor of jet aircraft.

Shian_Lee said...

It means that instead of 35 different kinds of screws they use only 3.

Not so. I couldn't get an exact number, but a US jet requires more than 3 types of screws.

And of course, this doesn't include the variety of aircraft bolts and other fasteners used to assemble an aircraft - I couldn't confirm this, but I strongly suspect the number of bolts used outweighs the number of screws, since bolts are used in the high stress areas of an aircraft, which are many.

Shian_Lee said...

And it means that instead of 100 different tools - jet engine can be replaced with few tools.

Perhaps, but replacing a jet engine remains an involved and grueling process.

Shian_Lee said...

Engineers realized that as many options as you have to deal with - to learn, to remember, and to use - as less efficient and reliable is maintainability.

The air force had to learn this fact in the hard way: many people died because of the complexity of the mechanical design. Jets could not be ready on time. But now they removed any unnecessary option and complexity, so it's possible to fix big problems in a very short time.

Right, but at the same time, they avoided oversimplification. Jet aircraft design remains complicated. Like you said, the air force has strong motivation to make this as simple as possible, if they haven't done that yet, it's because it's not feasible.

new topic     » goto parent     » topic index » view message » categorize

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

How many different ways are there to replace that jet engine? I don't think there are very many. I'm pretty sure it has to be done in one way, step-by-step. I don't think Joe will have a different style of replacing the engine than Bob does. I don't think Bob is thinking, "If I could just replace this engine in this way, instead of that way, it would make so much more sense to me."

There are ways of programming that make it easier for some to write one way, and others to write in a different way, but both get the job done. And just because your way makes more sense to you when you write it, it doesn't mean that somebody working on your code at a later date will understand it better than the way someone else may have written it.

Reducing the number of necessary available and useful tools when replacing a jet engine is good. Reducing the number of available and useful tools when programming is not so good.

new topic     » goto parent     » topic index » view message » categorize

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

I think that rather than focusing on the number of ways by which the same thing can be accomplished in Euphoria we had better focus on how the task at hand is achieved in Euphoria, whichever the way we might want to use. That is to say, how simple/intuitive/uncomplicated is the way provided to us by Euphoria's syntax/semantics? On the whole, it's quite straightforward, but there are a few wrinkles here and there which need to be ironed out.

Quoting Shian Lee from another thread:

Shian_Lee said...

Now that Euphoria 3 is mature, and Euphoria 4 is great - it's about time to invest effort on making it friendly.

new topic     » goto parent     » topic index » view message » categorize

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

I think what everyone is referring to in recent comments here is the concept of a software design pattern:

Wikipedia said...

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

(emphasis mine)

There may be many ways to accomplish the same task, but the community will often converge on a single best practice for solving a single common problem. Those best practices should be reviewed and captured somewhere for others in to reference later. Perhaps this is worth of a Wiki section called "Euphoria Design Patterns" or something like that. These practices, however, are beyond the scope of the language itself.

It is up to the programmer, not the language author, to determine the "best" practice for his task. Hopefully the programmer is following our previously-defined design patterns in his work. It is up to the language author, not the programmer, to ensure that the language can accomplish the task as it is described by the programmer. Hopefully the language author is driven by logic and reason, and not just his own ambition for the language.

-Greg

new topic     » goto parent     » topic index » view message » categorize

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

ghaberek said...

I think what everyone is referring to in recent comments here is the concept of a software design pattern

...

These practices, however, are beyond the scope of the language itself.

Not quite. We were actually talking about language design, so the main focus here is on the language itself, e.g. whether or not it should have certain features, and how those features define/constitute the language identity/philosophy.

ghaberek said...

Hopefully the language author is driven by logic and reason, and not just his own ambition for the language.

Of course, no one here is questioning the developers' motivations.

new topic     » goto parent     » topic index » view message » categorize

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

GreenEuphorian said...
ghaberek said...

I think what everyone is referring to in recent comments here is the concept of a software design pattern

...

These practices, however, are beyond the scope of the language itself.

Not quite. We were actually talking about language design, so the main focus here is on the language itself,

Agreed.

To sum up, it appears Lee's position is that a particular software design pattern (or at least elements of it) should be put into the scope of the language itself and actively enforced by the language, whereas the other side disagrees and argues for various reasons why that software design pattern should remain separate from the language itself.

new topic     » goto parent     » topic index » view message » categorize

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

GreenEuphorian said...
ghaberek said...

Hopefully the language author is driven by logic and reason, and not just his own ambition for the language.

Of course, no one here is questioning the developers' motivations.

Well, that certainly was the case from time-to-time when Rob was in charge. blink

jimcbrown said...

To sum up, it appears Lee's position is that a particular software design pattern (or at least elements of it) should be put into the scope of the language itself and actively enforced by the language, whereas the other side disagrees and argues for various reasons why that software design pattern should remain separate from the language itself.

Right, that's what I am saying. The practices of software design and language design are separate. Restricting a language's features to enforce a set of design rules on the programmer is, well... bad. Let's not do that.

-Greg

new topic     » goto parent     » topic index » view message » categorize

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

jimcbrown said...

To sum up, it appears Lee's position is that a particular software design pattern (or at least elements of it) should be put into the scope of the language itself and actively enforced by the language, whereas the other side disagrees and argues for various reasons why that software design pattern should remain separate from the language itself.

It's true.

Placing a certain boundaries, as well as forcing a certain pattern, by the programming language itself - will help to maintain the code later, which can be crucial for success.

Personally, if I would like to get more programming-freedom then I would code in C or Assembly - not Euphoria. Part of being a very high level language is placing boundaries, which minimizing the chances of bugs or unreadable/unmaintainable code.

PLC programming is similar to Assembly... you have memory addresses, add/mov and such commands, and you can do whatever you like. If you override an Output address by mistake, you can easily kill someone - there is no variable's scope to protect you from stupid mistakes in a regular PLC.

I liked programming PLCs - but Euphoria is million times more fun and safe. And I hope that it will remain like this.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu