OpenEuphoria

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

• Posted by GreenEuphorian Oct 25, 2014
• 3714 views

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.

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.

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

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

• Posted by ghaberek (admin) Oct 28, 2014
• 3566 views

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.

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

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

• Posted by BRyan Oct 28, 2014
• 3510 views

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

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

• Posted by jimcbrown (admin) Oct 29, 2014
• 3465 views

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

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

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

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

• Posted by irv Oct 29, 2014
• 3423 views

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.

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

• Posted by DerekParnell (admin) Oct 31, 2014
• 3312 views

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.

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.

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.

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

• Posted by Spock Nov 03, 2014
• 3224 views

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

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

• Posted by _tom (admin) Nov 04, 2014
• 3172 views

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.

The same goes for alternative Hash algorithms and interface.

_tom

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

• Posted by Spock Nov 04, 2014
• 3135 views

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.

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.

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.

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

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

• Posted by Spock Nov 04, 2014
• 3060 views

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 
 

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

• Posted by jimcbrown (admin) Nov 05, 2014
• 3027 views

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

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

No.

I didn't until _tom's clarification.

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.

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?

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.

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

• Posted by Spock Nov 05, 2014
• 3024 views

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

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

• Posted by jimcbrown (admin) Nov 05, 2014
• 3026 views

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.

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

• Posted by petelomax Nov 05, 2014
• 2995 views
• Last edited Nov 06, 2014

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 

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

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

• Posted by _tom (admin) Nov 06, 2014
• 2883 views

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

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

• Posted by _tom (admin) Nov 12, 2014
• 2990 views

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

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

• Posted by jimcbrown (admin) Nov 17, 2014
• 2740 views

Which is what 4.0.0 achieved....

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

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

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.

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

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

• Posted by Shian_Lee Nov 17, 2014
• 2659 views

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.

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

• Posted by DerekParnell (admin) Nov 18, 2014
• 2667 views

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}
  

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

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?

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

• Posted by evanmars Nov 18, 2014
• 2541 views

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.

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

• Posted by ghaberek (admin) Nov 18, 2014
• 2542 views

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

(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

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

• Posted by jimcbrown (admin) Nov 18, 2014
• 2504 views

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.

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

• Posted by Shian_Lee Nov 18, 2014
• 2466 views

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.