Re: A controversial topic
- Posted by jimcbrown (admin) Feb 20, 2023
- 1320 views
Before we answer that about Euphoria, answer it for
This is the wrong way to think of a language, unless you are making an extreme leap away from the norm.
I think this is reasonable - we're asking why those other languages made it when OE didn't - i.e., what's different from OE that moved it away from the norm?
Heck, it's worth asking - how come Nim is so popular nowdays, relative to OE? Nim had it's start here, before moving to its own community.
Considering how OE has traditionally fought against being outstanding (in many ways),
I'd like to point out from my POV, and IMVHO, it was more for RDS Eu (the pre-FOSS days) where this was true.
arguing for uniqueness is a dead end.
Agree in part - effort is probably better spend moving the language to the norm first. Again, I think the lessons of Nim will be instructive here.
I recall introducing "string tokens", the fight against pretty much every word ("string") and meaning ("word" is like an atom) and origin (mIRC) and concept (Ai processing, small databases),
I don't really recall these - except for a vague recollection of why we'd want to target mIRC, a closed source and Windoze only system (and an IRC client rather than a language meant by its authors to be general purpose) - but again this was also in the RDS Eu days.
Incidentally, back then I also recall supporting a concept of strings as atoms for Eu (which RobCraig had mentioned was a feature of the language that was RDS Eu's predecessor).
and then it being picked up as a library in other languages,
Well, it's hard to stop the spread of good ideas. Also, why would we want to?
and then OE being formed out of RDS Euphoria and changing what i had done before incorporating it into OE.
Simply because there were many good ideas and the above was necessary to incorporate all of the ideas that did make it into OE.
OE's best features is the built-in sequence type, as linked data store, and user typecasting, to lock in a fixed format in a program.
And, as you point out, not unique to OE. Java has vectors, for example, and any object oriented language can easily accomplish the fixed format lock.
I would not use OE without these two, but sadly everything outstanding that could be built on them is disallowed because it wasn't already allowed or no one needs it right this minute.
I'd disagree on both points - in general, the team was happy to accept patches, and of course pretty much everyone needed everything five minutes ago. The issue back then, and which is still the case today, is getting volunteer effort to build these things.
They all have their strengths and weaknesses. Each requires a particular way of thinking about how to solve problems with programming languages. This "grab me and look at" sounds like marketing-speak. Before Perl was marketable, it worked. Before Python was marketable, it worked. Euphoria mostly works but needs more done before it works enough to be marketable.
Sadly, when OE was formed, a lot of work was put into "eye candy", such as maps,
Actually, hashmaps has become a basic data type of most languages now (Java has HashMaps, Python has dicts, Ruby has hashes, and so on).
It wasn't so much about eye candy but about updating OE to the norm.
or making case() better than any one else's case().
Ah, this one I remember well. There wasn't really a serious argument over this, it was more based on my misunderstanding on how other languages like C implement the switch-case statement, which lead me to question if we should do it like C and require hard constants/literals only for optimized speed or if it should be more flexible and allow variables.
I looked down the list of "improvements" and was repeatedly saying "we don't need that",
Well, it was about modernizing and moving to the norm, so we could build the better things on top more easily....
"too narrow of focus", etc etc..
... while trying to deal with the lack of volunteer effort.
I am not saying stuff didn't work (<coff>case, compiled tasks</coff>),
Ack on case. Don't recall an issue with compiled tasks (aside from in a translated shared lib, but the one known case where it came up (using std/http from a translated shared lib) the issue was resolved).
but to the extent it worked it could have been an include file.
That actually is the case for the maps described in https://openeuphoria.org/forum/137583.wc#137583
Instead of fixing 100% of the bugs, we got immensely complex preprocessors to twist source code so it fit .. something.
Technically, not a preprocessor (it's changes to OE's own tokenizer/etc). But point taken. Again, to fit the norm while trying to use what little volunteer effort existed as efficently as possible. Sometimes this meant compromises were made with the best of intentions that with hindsight, may have gone better if done differently.
I agree, no marketting until it's [Ph,f]ixed. Brownie points if you know where that Euphoria syntax is from. Also "killer app" has been mentioned before.
Sounds like there's widespread agreement on this point.
But everything people have asked for to make one is in opposition to the fundamental base of Euphoria. To me, the original beauty of RDS's Eu was it was interpreted, NOT compiled, so it could have been less restrictive about what it could do, and how fast it could evolve, as in keeping ahead of the crowd.
Kat
So it was RDS Eu that introduced the translator, in the 2.x series line. Not OE that did this.
But point taken. The oldest versions of RDS Eu did indeed only come in an interpreted flavour. Perhaps Phix is a better choice then, lacking the baggage of RDS Eu it avoids the need for the translation and C compiler steps. In practice Phix has also evolved faster (e.g. officially supporting threads and try-catch), despite having a smaller team for most of its existence - something I attribute to the overhead of C.
Just when you think you found something.. Xojo can recognize and read-ONLY (no writing to) serial hardware, and has easy timers, but it's arrays cannot be used like sequences. I am looking at that list of programming languages and seeing a centipede with at least one bullet in each foot. Someone placed those bullets to constrain the languages to what they wanted. As if the goal is to make the language the owners desire, instead of what an unknown unspoiled unindoctrinated new coder needs for the next currently-unknown killer app. We have a centipede that cannot climb onto the next step up.
Kat
Another issue is that to extend or change OE you have to know C - otherwise you can't update the baseline interpreter or the translator. With the self-hosted Phix, it's far easier to code your desired features or updates in Eu and then apply them to the Phix source code. Easier to overcome the barriers.
(Unlike RDS Eu, the cases of OE and Phix are less about the "owners" disallowing changes but more about folks requesting features that no one has time and interest and ability to implement. Even so, with Phix the barriers are still easier to overcome for the reasons stated above. It's the nice thing about FOSS - if you disagree, you can fork the project's source code and do it yourself.)
