1. Re: Phix features to import into Open Euphoria
- Posted by useless_ Dec 22, 2012
- 1560 views
Or any other language, for that matter. But you'll quickly run into the optomisation for niche issues, standards, and clique inertia. While i admire your desire to improve Euphoria, this is the point when people start their own programming language.
useless
useless, what do you mean by "this is the point when people start their own programming language". Are you implicitly advocating it? Just to be clear.
Mostly, no, not advocating it, but then i am wierd. Splitting up programming resources is usually a bad idea. It's only when the ideas are radical to the local proscribed environment, and has followers, that an offshoot can work.
I fought hard for various things in Euphoria, many humans saw no advantage in anything i was suggesting. In 1998, i think three people in the world thought Eu should handle strings in any way. Even the functions that i wrote code for and proved solved problems, which were subsumed into OpenEuphoria, are renamed and scattered about (like sort_columns for sorttok, split for parse, join for deparse), ending my legacy of attribution for the string fight. I gave up on Eu for irc, i wrote code, i used it, there was too much pushback, i didn't want to start my own language to incorporate all my work, so i gave up. Pete didn't, he wrote Phix, why he intentionally maintains any compatability to Eu, i don't know. Rob Craig lost control of OpenEuphoria's direction, i lost anything i did that made it into OpenEuphoria, nothing i did made it into RDS Euphoria, Pete has control of Phix. It's a multi-edged sword.
I'd like to point out that Matt put good functionality into OOEU many years ago, yet those ideas still aren't in OpenEuphoria. Pete, ditto with Phix, and Karl, ditto with Bach, ditto with those people who wrote preprocessors in the archives at RDS. But Matt still writes core Eu code to this day, and his good ideas from over 10 years ago still aren't in OpenEuphoria!
There is one difference now that didn't exist in the dark ages: you can start with OpenEuphoria, change the code to add your ideas, recompile, and see if anyone is interested. While you lose sync with OpenEu's development, at least you got your code up the flagpole without starting a whole new language.
useless
Forked into: Language improvement
2. Language improvement
- Posted by jimcbrown (admin) Dec 22, 2012
- 1593 views
Forked from Re: Phix features to import into Open Euphoria
Mostly, no, not advocating it, but then i am wierd. Splitting up programming resources is usually a bad idea. It's only when the ideas are radical to the local proscribed environment, and has followers, that an offshoot can work.
I actually disagree with this. Different people have different tastes, and sometimes the only way to get something to be exactly what you want is to do it yourself.
Of course, I might be weird as well. I prefer to see a big Euphorian language community from which Phix and OpenEuphoria are two different standards. I'm not sure if anyone else agress with me.
I fought hard for various things in Euphoria, many humans saw no advantage in anything i was suggesting. In 1998, i think three people in the world thought Eu should handle strings in any way. Even the functions that i wrote code for and proved solved problems, which were subsumed into OpenEuphoria, are renamed and scattered about (like sort_columns for sorttok, split for parse, join for deparse), ending my legacy of attribution for the string fight.
This was already debunked. Derek wrote those functions from scratch. Nothing from your strtok is currently in Euphoria.
I gave up on Eu for irc, i wrote code, i used it, there was too much pushback, i didn't want to start my own language to incorporate all my work, so i gave up.
I saw no pushback when I was around.
Why would it be necessary to create your own language for adapting Eu to IRC?
Pete didn't, he wrote Phix, why he intentionally maintains any compatability to Eu, i don't know.
I'm glad he did. Big Euphorian community and all that.
Rob Craig lost control of OpenEuphoria's direction,
He made an educated choice to do this.
i lost anything i did that made it into OpenEuphoria,
If you're refering to your strtok stuff .. already debunked.
nothing i did made it into RDS Euphoria,
This is true. RDS Euphoria wasn't open source.
I'd like to point out that Matt put good functionality into OOEU many years ago, yet those ideas still aren't in OpenEuphoria.
But Matt still writes core Eu code to this day, and his good ideas from over 10 years ago still aren't in OpenEuphoria!
OOEU is probably the easiest to go with in terms of merging changes, since its from an earlier version of the same codebase.
Of course, the reason that a lot of OOEU changes aren't in OpenEuphoria is because Matt either didn't like the way that particular change worked out in OOEU itself, or because he didn't like the implementation of it in OOEU.
Pete, ditto with Phix, and Karl, ditto with Bach, ditto with those people who wrote preprocessors in the archives at RDS. Pete has control of Phix. It's a multi-edged sword.
A lot of those people, such as Karl, left before Euphoria was open source. Although Bach might not be too difficult to merge in, there are licencing issues that only Karl and Rob Craig could resolve. Otherwise, all those features in Bach would have to be redone from scratch.
There is a push to get Phix features into OpenEuphoria, but since Phix is a completely unrelated codebase, all those features have to be redone from scratch in OpenEuphoria.
Starting with 4.0, OpenEuphoria has special support for invoking preprocessors, which makes those older preprocessors much more relevant.
There is one difference now that didn't exist in the dark ages: you can start with OpenEuphoria, change the code to add your ideas, recompile, and see if anyone is interested. While you lose sync with OpenEu's development, at least you got your code up the flagpole without starting a whole new language.
I feel that it's quite likely that if these code changes were made public and open source, they'd quickly find their way into the OpenEuphoria mainline.
A big thing is that a lot of feature requests do not come with a patch to implement the changes. This is fine, but doing the hard work and showing that your idea works is a big help.
3. Re: Language improvement
- Posted by jimcbrown (admin) Dec 22, 2012
- 1523 views
BTW, eukat has previously contributed code that went into the OpenEuphoria mainline, and she is still listed in the credits file.
http://scm.openeuphoria.org/hg/euphoria/file/6a40c057e911/docs/credits.txt (line 44)
4. Re: Language improvement
- Posted by mattlewis (admin) Dec 26, 2012
- 1459 views
OOEU is probably the easiest to go with in terms of merging changes, since its from an earlier version of the same codebase.
Of course, the reason that a lot of OOEU changes aren't in OpenEuphoria is because Matt either didn't like the way that particular change worked out in OOEU itself, or because he didn't like the implementation of it in OOEU.
All of that is true. Additionally, a lot of the really cool stuff only worked using the euphoria back end. Making them work with the C back end was a much bigger task that I never got around to. That was much more difficult, and the front end stuff was getting very difficult to work with, in part at least due to some early design decisions I made.
Matt
