1. Evolution of Euphoria
- Posted by SDPringle Jan 11, 2015
- 1255 views
Forked from Re: Euphoria's strengths
What attracted me to Euphoria is a bit different:
- Fast enough
- Interpreted
- Can easily be bound to create a single executable
- Simple to use dynamic data structure
- No need for prototype files (like .h in C)
However, it seemed that many users were quite hostile to new ideas. There was an attitude that people were guarding the one true language from corruption.
That hasn't really changed.
- David
I have got the impression more than once that the other devs were trying to make EUPHORIA into Perl with a syntax more like Pascal. Most notable is the tendency to want to change the behavior of builtins that had acted a certain way for many years. Take, object(), and bit-wise operations, and now subscript opts. All changed.
The admins of any project determine which feature is a better approximation of the ideal and which are "corruption".
For example, one might say that or_bits should return positive integers because such is more intuitive. This interprets the bits as an unsigned integer. Others might say, because or_bits is a low level routine it should simply be as efficient as possible and return the bits as a signed integer.
S Pringle
2. Re: Evolution of Euphoria
- Posted by jimcbrown (admin) Jan 12, 2015
- 1245 views
I have got the impression more than once that the other devs were trying to make EUPHORIA into Perl with a syntax more like Pascal.
Is that really such a bad thing?
and now subscript opts. All changed.
I don't recall anyone changing subscript opts. What change where and when?
and bit-wise operations,
I particularly liked your version of this - where every bit could be accessed as if it were an element of a sequence, and the number of bits was not limited to the maximum size of the largest native integral value of the processor. A shame that no one has implemented this yet (even as a library that I could wrap in the parser or a preprocessor).
The admins of any project determine which feature is a better approximation of the ideal and which are "corruption".
Well, its the devs (of which you are a member) who decide this, not the admins (who you are also a member). We have many non-admin devs, and at least one non-dev admin.
For example, one might say that or_bits should return positive integers because such is more intuitive. This interprets the bits as an unsigned integer. Others might say, because or_bits is a low level routine it should simply be as efficient as possible and return the bits as a signed integer.
As a practical matter maybe it's not so important - if you really need to you can use poke4() and peek4s() to convert an unsigned value to a signed value, and poke4() and peek4u() to convert a signed value to an unsigned value.
