1. Broken Euphoria
Lets see...
Pete Lomax: His own Eu with many features found in the old OpenEU.
Mike Nelson: His own Eu integrating Method Euphoria.
Chris Bensler: His own language for Empire framework.
Derek Parnell: His own implementation of Eu written in D.
Matt Lewis: His own implementation of Eu with OO features.
Alexander Toresson: His own implementation of a Eu & C hybrid.
Ryan Johnson: His own FluidAE scripting language based on Eu.
Al Getz: His own implementation of Eu for WinClass?
More??
Who's left to contribute? Me? Well I dont know diddly squat about the C backend
so I cant do very much can I? No.
Thats eight people who may just take the source and abandon RDS Euphoria. While
that is fine, it wont help this official version of Euphoria improve any. I also
suspect that other languages like Python and Ruby will discover open Euphoria and
consume all it's benefits (like speed and sequences) and use them to their
advantage; rivaling any benefits Euphoria might have.
Example: Ruby has already taken our sequences.
In five years time there may be 20 Euphoria dervived languages with only a
handful of followers for each while official RDS Euphoria would be dead and
buried long before due to lack of interest and support beyond RDS.
How pleasent.
Regards,
Vincent
2. Re: Broken Euphoria
Vincent wrote:
[snip]
> Alexander Toresson: His own implementation of a Eu & C hybrid.
[snip]
> Thats eight people who may just take the source and abandon RDS Euphoria.
[snip]
Orac won't derive from any code in Euphoria, it has its own complete codebase.
That said, I feel the urge to tell you a little more about Orac, now that the
subject has been touched. I and Mike Vulcan has been working on it for the last
1.5 years. It shares a lot with Euphoria, but some of the biggest differences
will be the following:
* A sane inclusion and scope system
* Easy conditional compiling (as in uses if-statements)
* Structures (for example for easy interfacing with C libraries)
* Native size for integers (ie you get the full 32 bits on 32-bit systems and 64
bits on 64-bit systems)
* Forward referencing
We will first create an orac-to-c translator, but an interpreter will be quite
easy to code once we have the parser and libraries etc working, so an interpreter
will probably be created at a somewhat later stage.
The project has actually come quite far. Right now we are working on connecting
the parser and the il-to-c translator.
If you want to take a look at the code and maybe even try it out, it's available
in an svn repository at sourceforge:
http://sourceforge.net/svn/?group_id=143017
(Note that Mike's code is a bit out-of-date, as he sends updates to me a little
now and then, which I then commit.)
Regards, Alexander Toresson
3. Re: Broken Euphoria
- Posted by "Greg Haberek" <ghaberek at gmail.com>
Sep 27, 2006
-
Last edited Sep 28, 2006
> Who's left to contribute? Me? Well I dont know diddly squat about the C
> backend so I cant do very much can I? No.
>
> In five years time there may be 20 Euphoria dervived languages with only a
> handful of followers for each while official RDS Euphoria would be dead and
> buried long before due to lack of interest and support beyond RDS.
>
> How pleasent.
I'm with ya, Vince! A great man once said "United we stand, divided we
fall." If we're to advance Euphoria through open development, as Rob
plans, we musn't take the source and run with it, rather, improve it
and give it back. Only then will Euphoria truely advance.
I would like to see a "plug-in" or "extension" system for the
interpreter, kinda like PHP. That way, those who want to add features
like OOP and scripting can simply create an extension rather than a
whole new interpreter. Then they can distribute their extension with
their code for use with the interpreter.
Just a thought.
~Greg
4. Re: Broken Euphoria
- Posted by Al Getz <Xaxo at aol.com>
Sep 27, 2006
-
Last edited Sep 28, 2006
Vincent wrote:
>
> Lets see...
>
> Pete Lomax: His own Eu with many features found in the old OpenEU.
> Mike Nelson: His own Eu integrating Method Euphoria.
> Chris Bensler: His own language for Empire framework.
> Derek Parnell: His own implementation of Eu written in D.
> Matt Lewis: His own implementation of Eu with OO features.
> Alexander Toresson: His own implementation of a Eu & C hybrid.
> Ryan Johnson: His own FluidAE scripting language based on Eu.
> Al Getz: His own implementation of Eu for WinClass?
> More??
>
> Who's left to contribute? Me? Well I dont know diddly squat about the C
> backend
> so I cant do very much can I? No.
>
> Thats eight people who may just take the source and abandon RDS Euphoria.
> While
> that is fine, it wont help this official version of Euphoria improve any. I
> also suspect that other languages like Python and Ruby will discover open
> Euphoria
> and consume all it's benefits (like speed and sequences) and use them to their
> advantage; rivaling any benefits Euphoria might have.
>
> Example: Ruby has already taken our sequences.
>
> In five years time there may be 20 Euphoria dervived languages with only a
> handful
> of followers for each while official RDS Euphoria would be dead and buried
> long
> before due to lack of interest and support beyond RDS.
>
> How pleasent.
>
>
> Regards,
> Vincent
Hi Vincent,
Very interesting...But how do we get around this?
If, for example, *I* decide *I* want to change the keyword(s):
'include'
to
'include file'
and no body else wants this at all (they hate the idea)
then what am i supposed to do?
I think interest in RDS Eu will still be around, we'll just
have more to say about it. And also, perhaps once Rob sees
various versions he may pick something he likes for his own
'official RDS' version.
Rob already stated that everything else will remain intact
(message board, web site, contributions, etc.).
The only way RDS Eu will die is if RDS shuts it's Eu project
down, which i dont see Rob wanting to do at this point.
Perhaps Eu will become known as the first "Language Tree Language",
or whatever you want to call it.
Also, perhaps some things will become more clear after everyone
has had a hand at modifying the thing. What is good and what is
better, and what isnt good?
Then again, will someone like Pete be willing to work on a public
version if he's already knee deep into his own version of a language
similar to Eu? Perhaps he can comment on this.
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."
5. Re: Broken Euphoria
- Posted by Mario Steele <eumario at trilake.net>
Sep 27, 2006
-
Last edited Sep 28, 2006
Hello Vincent,
Vincent wrote:
> Example: Ruby has already taken our sequences.
While I agree with some of the facts that you have stated, I must dis-agree with
the part about Ruby taking Sequences. While, true, ther functionality of Arrays
is similar to Sequences, they are not sequences. One fact in this is very
aparent, by the simple fact, that with Sequences, you have to do:
sequence a
a = {4,5,6}
for x = 1 to length(a) do
? a[x]
end for
Where as Ruby, you can simply do:
a = [4,5,6]
a.each do |y|
? y
end
Blocks make things so much easier. LOL
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
6. Re: Broken Euphoria
- Posted by Ray Smith <ray at RaymondSmith.com>
Sep 27, 2006
-
Last edited Sep 28, 2006
Al Getz wrote:
>
> Vincent wrote:
> >
> Hi Vincent,
>
> Very interesting...But how do we get around this?
> If, for example, *I* decide *I* want to change the keyword(s):
> 'include'
> to
> 'include file'
> and no body else wants this at all (they hate the idea)
> then what am i supposed to do?
LGPL Euphoria first to help solve Vincent's issues ;)
If you want, you can download the source code of each official release and
merge your changes back in :)
Regards,
Ray Smith
http://RaymondSmith.com
7. Re: Broken Euphoria
- Posted by Ray Smith <ray at RaymondSmith.com>
Sep 27, 2006
-
Last edited Sep 28, 2006
Mario Steele wrote:
>
> Hello Vincent,
>
> Vincent wrote:
>
> > Example: Ruby has already taken our sequences.
Euphoria got's its sequences from languages like Lisp and Icon (AFAIK).
I don't think (?) Euphoria invented any new language features.
It just implemented some nice features from other languages.
Regards,
Ray Smith
http://RaymondSmith.com
8. Re: Broken Euphoria
- Posted by Derek Parnell <ddparnell at bigpond.com>
Sep 27, 2006
-
Last edited Sep 28, 2006
Vincent wrote:
>
> Lets see...
> Derek Parnell: His own implementation of Eu written in D.
> Thats eight people who may just take the source and abandon RDS Euphoria.
Speaking only for myself, you have it wrong, Vincent. I started working on my
Euphoria clone *because* of the past position of RDS with respect to
collabarative work on Euphoria - there was none.
I will continue with it because its started, because it will teach me things,
because it can be a 'playground' for experimentation, because others might like
it. This does not automatically mean that I will not also try to assist RDS with
the Open Euphoria concept. In fact, I intend to help RDS improve the Euphoria
('offical edition') language, if Robert will let me.
> Who's left to contribute? Me? Well I dont know diddly squat about the C
> backend so I cant do very much can I? No.
And yet, I would have thought that one thing you could do is contribute ideas.
And you could always learn C if you wanted to help.
> While that is fine, it wont help this official version of Euphoria improve
> any. I
> also suspect that other languages like Python and Ruby will discover open
> Euphoria
> and consume all it's benefits (like speed and sequences) and use them to their
> advantage; rivaling any benefits Euphoria might have.
>
> Example: Ruby has already taken our sequences.
And exactly why is that a bad thing? Firstly, they can do that now with out
seeing RDS's implementation of Euphoria. Secondly, Euphoria can also now
implement the better things found in other languages.
> In five years time there may be 20 Euphoria dervived languages with only a
> handful
> of followers for each while official RDS Euphoria would be dead and buried
> long
> before due to lack of interest and support beyond RDS.
Not likely. The '20 Euphoria dervived languages' are more likely to wither than
the standard release.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
9. Re: Broken Euphoria
Mambo has no basis in Euphoria.
I will continue to work on my own language.
I've been working on it for several years, I'm not about to abandon that so I
can start over.
First of all though. Why does the official version of Euphoria have to be the
winner? Is it really that inconceievable that Rob's vision of Euphoria is limited
and the Community's pressure to implement features will contaminate the elegant
language that people were attracted to in the first place? IMO, that's already
the case, and it's not even OSI yet.
I for one am not eager to see where this 'official' openEu goes as I listen to
all the sugarplum wishes.
I'm heavily considering whether I would even bother to get re-involved with the
eu community to work on openEu as my efforts and ideas were never appreciated in
the past anyways and I'm tired of defending myself. Not much incentive to
contribute anymore.
~ The difference between ordinary and extraordinary is that little extra ~
10. Re: Broken Euphoria
Derek Parnell wrote:
> Speaking only for myself, you have it wrong, Vincent. I started working on my
> Euphoria clone *because* of the past position of RDS with respect to
> collabarative
> work on Euphoria - there was none.
>
> I will continue with it because its started, because it will teach me things,
> because it can be a 'playground' for experimentation, because others might
> like
> it. This does not automatically mean that I will not also try to assist RDS
> with the Open Euphoria concept. In fact, I intend to help RDS improve the
> Euphoria
> ('offical edition') language, if Robert will let me.
Ok ok.. perhaps I misjudged you. I'm sure RDS would apprechiate your help after
witnessing how well you managed the Win32Lib project. BTW, when do anticipate
releasing the next version? I remember you saying within two weeks, several
months ago. 
> And yet, I would have thought that one thing you could do is contribute ideas.
> And you could always learn C if you wanted to help.
Well I mean I could do front-end changes and implement some of my VEEU front-end
features but someone will need to manage the C back-end and translate my
execute.e changes.
> And exactly why is that a bad thing? Firstly, they can do that now with out
> seeing RDS's implementation of Euphoria. Secondly, Euphoria can also now
> implement the better things found in other languages.
Well that depends on the license Rob chooses. If Robert goes with public-domain,
language developers could take the source they want and license it under
whatever complies with the rest of their language. Yet Robert can't do the same
without complying with licensing terms governing source code from different
languages. This could mean that Euphoria would need to change from public-domain
to a compatible license to satisfy the requirements or refrain from using their
source-code.
> Not likely. The '20 Euphoria dervived languages' are more likely to wither
> than the standard release.
No because most of these derivatives would have benefits over the official
language and would attract many from the exsiting user-base (assuming they are
open-source like the official implementation).
Robert and a couple contributers couldn't compete against 20 or more other FOSS
derivatives.
Regards,
Vincent
11. Re: Broken Euphoria
Mario Steele wrote:
>
> Hello Vincent,
>
> Vincent wrote:
>
> > Example: Ruby has already taken our sequences.
>
> While I agree with some of the facts that you have stated, I must dis-agree
> with the part about Ruby taking Sequences. While, true, ther functionality
> of Arrays is similar to Sequences, they are not sequences. One fact in this
> is very aparent, by the simple fact, that with Sequences, you have to do:
> }}}
<eucode>
> sequence a
> a = {4,5,6}
> for x = 1 to length(a) do
> ? a[x]
> end for
> </eucode>
{{{
>
> Where as Ruby, you can simply do:
> }}}
<eucode>
> a = [4,5,6]
> a.each do |y|
> ? y
> end
> </eucode>
{{{
>
> Blocks make things so much easier. LOL
>
> Mario Steele
> <a
> href="http://enchantedblade.trilake.net">http://enchantedblade.trilake.net</a>
> Attaining World Dominiation, one byte at a time...
I've read Ruby Garden articles in the past comparing Euphoria's sequences with
Rubies dynamic array feature. It seems that Euphoria's sequences have influenced
the design behind Ruby's implementation.
Regards,
Vincent
12. Re: Broken Euphoria
Vincent wrote:
>
> Lets see...
>
<snip>
> Ryan Johnson: His own FluidAE scripting language based on Eu.
<snip>
> Thats eight people who may just take the source and abandon RDS Euphoria.
<snip>
> Regards,
> Vincent
Just to be clear so there aren't any misunderstandings...
I am very happy to hear the Euphoria will become open source for 2 main reasons:
1) it will not die when RDS does, it will still be available as long as people
keep using it, and 2) FluidAE is open source, so it is good that the language it
is written in will also be open source.
I have no intention of ever creating a new fork. I fully support Rob's official
euphoria and overall i'm happy with its progress. If FluidAE becomes popular, i
hope it also causes euphoria to become more popular as well.
FluidAE will have it's own internal scripting language, which will basically be
Euphoria syntax, but it *might* have some minor modifications to the syntax,
specifically for simpler interfacing with modules within FluidAE. My intention is
_not_ to create a new, "better" language, but to simply make it easier to program
applications _for FluidAE_. The main modification i will make for the scripting
language will be to allow multiple programs to be executed simultaneously,
controlled by a built-in task manager. This wouldn't normally work because there
could be I/O conflics between programs. But, in FluidAE, applications never do
any direct I/O using built-in routines (such as puts, gets, etc.) Applications
only interface with Module apis to do what they need to do.
FluidAE itself, and FluidAE Modules will all be written in 100% official
euphoria. Infact, they will be left as raw source files. The (open source)
euphoria interpretor will simply be included with the FluidAE installation, along
with the necessary libraries.
By the way, even though i haven't worked on FluidAE for months, the project is
still alive, just incase anyone was starting to wonder... 
~Ryan W. Johnson
Fluid Application Environment
http://www.fluidae.com/
[cool quote here, if i ever think of one...]
13. Re: Broken Euphoria
Chris Bensler wrote:
>
> Mambo has no basis in Euphoria.
>
> I will continue to work on my own language.
> I've been working on it for several years, I'm not about to abandon that so
> I can start over.
>
> First of all though. Why does the official version of Euphoria have to be the
> winner? Is it really that inconceievable that Rob's vision of Euphoria is
> limited
> and the Community's pressure to implement features will contaminate the
> elegant
> language that people were attracted to in the first place? IMO, that's already
> the case, and it's not even OSI yet.
>
> I for one am not eager to see where this 'official' openEu goes as I listen
> to all the sugarplum wishes.
>
> I'm heavily considering whether I would even bother to get re-involved with
> the eu community to work on openEu as my efforts and ideas were never
> appreciated
> in the past anyways and I'm tired of defending myself. Not much incentive to
> contribute anymore.
>
>
> ~ The difference between ordinary and extraordinary is that little extra ~
Chris,
I'm well aware of your position towards Euphoria and RDS. I'm very suprized that
you even decided to participate on this mailing list again after your furious
exit.
I think we all know that Robert's reason behind doing this was to speed up
development and encourage people to implement exciting new features in his
official language. I think Robert considers forking and fragementation an ugly
side-effect of such a move but confident that his version will remain dominate. I
am, however, not so confident that he'd be right once all our influential coders
leave to launch their own projects.
Regards,
Vincent
14. Re: Broken Euphoria
Al Getz wrote:
> Very interesting...But how do we get around this?
> If, for example, *I* decide *I* want to change the keyword(s):
> 'include'
> to
> 'include file'
> and no body else wants this at all (they hate the idea)
> then what am i supposed to do?
<snip>
Conflicting ideologies about open-source software tends to ignite forking
efforts. I think a successful open-source project is capable of satisfying
peoples needs enough to mitigate forking. I believe its possible through a
compromise between acknowledging user requests and adhering to established
project guidelines.
Regards,
Vincent
15. Re: Broken Euphoria
Vincent wrote:
>
> Al Getz wrote:
>
> > Very interesting...But how do we get around this?
> > If, for example, *I* decide *I* want to change the keyword(s):
> > 'include'
> > to
> > 'include file'
> > and no body else wants this at all (they hate the idea)
> > then what am i supposed to do?
>
> <snip>
>
> Conflicting ideologies about open-source software tends to ignite forking
> efforts.
> I think a successful open-source project is capable of satisfying peoples
> needs
> enough to mitigate forking. I believe its possible through a compromise
> between
> acknowledging user requests and adhering to established project guidelines.
>
>
> Regards,
> Vincent
There are already different "improvements" to Euphoria floating around. Some of
them have some good ideas but none of them have really taken off. Maybe that is
because of using the slower translated version. Maybe it is because of perceived
added complexity to the language.
As long as RDS continues to be the arbiter of what is "Euphoria" (and I'm sure
many of us will continue to disagree with Rob from time-to-time) then I don't
think that forking will be much of an issue.
While they may exist, how many forks of Perl, Python, Ruby, etc. are you aware
of?
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
16. Re: Broken Euphoria
Jason Gade wrote:
> While they may exist, how many forks of Perl, Python, Ruby, etc. are you aware
> of?
I have to agree with Jason here, while there are forks of these languages, alot
of improvements have been done to the core itself, you don't see many, if any at
all of forks of these langauges. Though, with Ruby, between version 1.8 and 1.9,
there's many structure changes, and many dis-agreements about the changes, but
they are still occuring, and for the better, as the way "Matz" (The creator of
Ruby), is looking at the changes, as getting rid of alot of run around, while
making it more portable, since it will be using YARV (Yet Another Ruby Virtual
Machine), which would make the base code more portable, and such.
But, in any case, Euphoria really has nothing to worry about, as it's a strong
language, with a strong community, that really wants to see the language progress
further into the future. I belive that's why Robert finally decided, in his
mind, that Hey, all of these people want to see these features implemented, and
bugs fixed, and there's just not enough of me to go around. Correct me if I'm
wrong Rob. LOL So, instead of sitting here, debating tic-for-tac, GPL vers.
LGPL, BSD vs Public Domain, and so forth, Rob has the information that he wanted
to learn about, an opinion apon what types of licenses are out there, and which
would be best for him.
Further discussion about Forks, Licensing, and so forth, really does not resolve
anything. What needs to be figured out now, with Robert's input as well, is the
setup of how things are going to progress from here. Again, I say this in this
point, Robert has already made the decision, the source code is going to be Open.
True, he still needs to make a decision about License, but further pounding of
this into the ground of the differences between the licenses has gone on for way
to long. If you have another license you want to suggest, feel free. If you
have a wording for a license to include with the PD Open Source, post that. But
I think the arguments about the differences between licenses has been vamped and
re-vamped time and time again, for far to much.
Now, I go back to my quiet little corner of the Universe, and continue on my
plans for World Dominiation.
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
17. Re: Broken Euphoria
Vincent wrote:
>
> Chris Bensler wrote:
> >
> > Mambo has no basis in Euphoria.
> >
> > I will continue to work on my own language.
> > I've been working on it for several years, I'm not about to abandon that so
> > I can start over.
> >
> > First of all though. Why does the official version of Euphoria have to be
> > the
> > winner? Is it really that inconceievable that Rob's vision of Euphoria is
> > limited
> > and the Community's pressure to implement features will contaminate the
> > elegant
> > language that people were attracted to in the first place? IMO, that's
> > already
> > the case, and it's not even OSI yet.
> >
> > I for one am not eager to see where this 'official' openEu goes as I listen
> > to all the sugarplum wishes.
> >
> > I'm heavily considering whether I would even bother to get re-involved with
> > the eu community to work on openEu as my efforts and ideas were never
> > appreciated
> > in the past anyways and I'm tired of defending myself. Not much incentive to
> > contribute anymore.
> >
> >
> > ~ The difference between ordinary and extraordinary is that little extra ~
>
> Chris,
>
> I'm well aware of your position towards Euphoria and RDS. I'm very suprized
> that you even decided to participate on this mailing list again after your
> furious
> exit.
>
> I think we all know that Robert's reason behind doing this was to speed up
> development
> and encourage people to implement exciting new features in his official
> language.
> I think Robert considers forking and fragementation an ugly side-effect of
> such
> a move but confident that his version will remain dominate. I am, however, not
> so confident that he'd be right once all our influential coders leave to
> launch
> their own projects.
>
>
> Regards,
> Vincent
If someone were to fork Eu, either their version would be compatible with
official Eu so they could gain the benefits of the existing community and
codebase, or else their version will be incompatible, in which case it's not
really competition, is it?
If the fork is compatible, then much of the code produced for that version will
also work with the official version, thus the offical Eu will benefit from an
expanded community as well.
Many of those forks can try more radical things, which may prove to be worth
incorperating into the official version.
Forks would attract more attention and create curiosity around the official
version that those forks are modelled on. Don't you think people will wonder
where the forks are coming from and why?
Maybe one or two of the forks do manage to take off. Is that so bad?
I highly doubt that Euphoria would be affected by it, other than benefit.
Afterall, we have how many existing programming languages and still people not
only use Euphoria but are willing to pay for it, even if it is free. There will
always be people who are satified with Rob's version.
Alot of people will choose to use the offical version simply because it's more
reputable and has an existing history and codebase already.
~ The difference between ordinary and extraordinary is that little extra ~
18. Re: Broken Euphoria
Chris Bensler wrote:
> If someone were to fork Eu, either their version would be compatible with
> official
> Eu so they could gain the benefits of the existing community and codebase, or
> else their version will be incompatible, in which case it's not really
> competition,
> is it?
>
> If the fork is compatible, then much of the code produced for that version
> will
> also work with the official version, thus the offical Eu will benefit from an
> expanded community as well.
>
> Many of those forks can try more radical things, which may prove to be worth
> incorperating into the official version.
>
> Forks would attract more attention and create curiosity around the official
> version that those forks are modelled on. Don't you think people will wonder
> where the forks are coming from and why?
>
> Maybe one or two of the forks do manage to take off. Is that so bad?
> I highly doubt that Euphoria would be affected by it, other than benefit.
> Afterall, we have how many existing programming languages and still people not
> only use Euphoria but are willing to pay for it, even if it is free. There
> will
> always be people who are satified with Rob's version.
>
> Alot of people will choose to use the offical version simply because it's more
> reputable and has an existing history and codebase already.
If someone forked eu it's most likely to add features not in the original
release.
If it runs standard eu and there is only 1 fork, the problem isn't
so big.
The problem starts when their are mutliple forks, all with different feature
sets. I want to use feature x from fork y and feature a from fork b.
Because the eu source code (probably wont) force the fork sources to be open,
I'm at the mercy of the fork developers to give all other fork developers
their improvements so I can use the multiple new fork features in the same
program. Probably won't happen???
If forks are created to test new features and not as a competitor to the
official eu there won't be a problem.
If people start making closed source forks as competitors .. with new
features not in the original (and these forks become successful) then we
end up splintering the community.
There is no reason to make closed source forkes of the official euphoria.
It just won't grow Eu's uptake or community involvement.
If a number of really good developers get behind the official eu source they
should be able to keep the features at a standard as good as any fork
developers ... in this case ... any fork developers making closed source
versions are wasting their time.
If the closed source fork developers win (on features and users) we end up with
just another small closed source language :(
The eu source being open (for everyone all the time) does make a difference.
Regards,
Ray Smith
http://RaymondSmith.com
19. Re: Broken Euphoria
Chris Bensler wrote:
> Maybe one or two of the forks do manage to take off. Is that so bad?
> I highly doubt that Euphoria would be affected by it, other than benefit.
> Afterall, we have how many existing programming languages and still people not
> only use Euphoria but are willing to pay for it, even if it is free. There
> will
> always be people who are satified with Rob's version.
>
> Alot of people will choose to use the offical version simply because it's more
> reputable and has an existing history and codebase already.
Yeah ... what he said.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
20. Re: Broken Euphoria
Ray Smith wrote:
> If the closed source fork developers win (on features and users)
This conversation is starting to take on a bias that may not be useful. What
about the other forms of cutlery such as knives, spoons, and tea-spoons, ...
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
21. Re: Broken Euphoria
- Posted by ags <eu at 531pi.co.nz>
Sep 28, 2006
Jason Gade wrote:
> While they may exist, how many forks of Perl, Python, Ruby, etc. are you aware
> of?
How could you possibly fork Perl, it contains every possible feature ever
conceived of in any programming language anywhere! ;)
But seriously ... might be a good time to mention ActiveState.com they make
money by selling the Perl Dev Kit, Komodo IDE, etc. but bundle Perl itself into a
windows installer and distribute free along with sources etc. They have a few
closed sources quite close to Perl itself (like Perl for ISAPI) but they are
'free' too.
Quite a good model, IMHO. And a good example of the ways to make money from
open source. Good service and support can't easily be forked :)
Gary
22. Re: Broken Euphoria
Derek Parnell wrote:
>
> Ray Smith wrote:
>
> > If the closed source fork developers win (on features and users)
>
> This conversation is starting to take on a bias that may not be useful. What
> about the other forms of cutlery such as knives, spoons, and tea-spoons, ...
What bias?
.. and what is not useful about it?
Regards,
Ray Smith
http://RaymondSmith.com
23. Re: Broken Euphoria
- Posted by ags <eu at 531pi.co.nz>
Sep 28, 2006
Derek Parnell wrote:
>
> Ray Smith wrote:
>
> > If the closed source fork developers win (on features and users)
>
> This conversation is starting to take on a bias that may not be useful. What
> about the other forms of cutlery such as knives, spoons, and tea-spoons, ...
Who gives a fork?
24. Re: Broken Euphoria
Ray Smith wrote:
> If someone forked eu it's most likely to add features not in the original
> release.
> If it runs standard eu and there is only 1 fork, the problem isn't
> so big.
> The problem starts when their are mutliple forks, all with different feature
> sets. I want to use feature x from fork y and feature a from fork b.
> Because the eu source code (probably wont) force the fork sources to be open,
>
> I'm at the mercy of the fork developers to give all other fork developers
> their improvements so I can use the multiple new fork features in the same
> program. Probably won't happen???
Assuming that there is a bunch of closed source versions. That's a pretty big
maybe though.
How is that worse than having a single version that never gives you the
opportunity to even choose to use those features because they are never thought
of or don't fit into the Eu model?
> If forks are created to test new features and not as a competitor to the
> official eu there won't be a problem.
> If people start making closed source forks as competitors .. with new
> features not in the original (and these forks become successful) then we
> end up splintering the community.
You would rather force people to use the official Eu, even if it's inferior?
How many people choose to use Eu instead of some other mainstream language?
YOu don't think those forks will attract new users? Many of whom will likely
migrate to the official version.
> There is no reason to make closed source forkes of the official euphoria.
> It just won't grow Eu's uptake or community involvement.
> If a number of really good developers get behind the official eu source they
>
> should be able to keep the features at a standard as good as any fork
> developers ... in this case ... any fork developers making closed source
> versions are wasting their time.
> If the closed source fork developers win (on features and users) we end up
> with
>
> just another small closed source language :(
We are talking about the opportunity for people to take advantage of market
bubbles here. There is no long-term security in developing a closed source
version of an opensourced app. Either the closed source version is going to be
different enough that it's not practical to imitate and is not going to be direct
competition or the shining features will be incorperated into the OSI version.
Joe blow made his enhanced version, made a few bucks for a few years, and then
the OSI version caught up. The opensource community gets to observe how those
enhancements fair in practice in the meantime before deciding to jump the gun and
implement it themselves.
The main thing is not being locked into an agreement that will severly limit the
amount of participation. Even if that participation is not directly applied to
the opensource Eu, it is still going to benefit.
The bigger threat is from other opensourced versions, since they could easily
incorperate all of the official versions features and then outpace it. But I
don't see a problem with that. That's survival of the fittest.
It might be a dissapointment if Rob gets cut out of hte loop, but then again
maybe that's what he wants. I'm sure he will eventually.
In the end there probably would be 2 or 3 different forks that manage to get a
foothold and remain unique enough to have their own following. You know it Ray,
it's been like your motto: "no language is suitabe for every person and every
task" :)
If people are going to choose to use a different language, they will anyways.
> The eu source being open (for everyone all the time) does make a difference.
Yes, I'm pleased that Eu's future is secured.
I hate to say it but I predicted that Eu wouldn't go much further than v3.0
Not being negative, but from a practical point of view guaging by eu's history
and progress. My biggest problem with Eu has always been that I'm constantly
developing for the language instead of my own apps because Eu's community is too
small to provide an adequate selection. My motivation has always been to make Eu
more popular. A language can't survive without a codebase. If that were at all
practical, I would make my own language and who cares if anyone else uses it.
I'm glad to see that Rob is not abandoning it. Despite my disagreements, I
respect what Rob has done with Eu and would rather have Rob being too controlling
than Eu being a free for all.
~ The difference between ordinary and extraordinary is that little extra ~
25. Re: Broken Euphoria
Chris Bensler wrote:
>
> Assuming that there is a bunch of closed source versions. That's a pretty big
> maybe though.
>
> How is that worse than having a single version that never gives you the
> opportunity
> to even choose to use those features because they are never thought of or
> don't
> fit into the Eu model?
If a LGPL based license is used it doesn't mean there will only be 1 version.
It just means the source will be available for all versions.
Everyone can still go and make there own version with whatever features
they desire ... they just can't distribute the langauge without giving users
access to the source code.
> You would rather force people to use the official Eu, even if it's inferior?
see above .. there can still be forks ... LGPL'd licenses make it easier to
merge the changes back to an "offical" version.
> How many people choose to use Eu instead of some other mainstream language?
compared to how many people are programming, not many choose to use Euphoria. :(
> YOu don't think those forks will attract new users? Many of whom will likely
> migrate to the official version.
There can still be new forks .. see above
> The main thing is not being locked into an agreement that will severly limit
> the amount of participation. Even if that participation is not directly
> applied
> to the opensource Eu, it is still going to benefit.
Each user of a closed source fork is locked into an agreement with the author.
> In the end there probably would be 2 or 3 different forks that manage to get
> a foothold and remain unique enough to have their own following. .
The current and potential Euphoria user base isn't big enough to have 2 or 3
seperate versions. It's ok to have different distributions (like the activestate
example fo Perl and Python) ... but they add value to the open source version,
not a new slightly different versions).
>You know it
> Ray, it's been like your motto: "no language is suitabe for every person and
> every task" :)
People aren't going to choose 2 slightly different versions of Eu for different
tasks ... they will choose Java or C# or Python.
> Yes, I'm pleased that Eu's future is secured.
> I hate to say it but I predicted that Eu wouldn't go much further than v3.0
> Not being negative, but from a practical point of view guaging by eu's history
> and progress. My biggest problem with Eu has always been that I'm constantly
> developing for the language instead of my own apps because Eu's community is
> too small to provide an adequate selection. My motivation has always been to
> make Eu more popular. A language can't survive without a codebase. If that
> were
> at all practical, I would make my own language and who cares if anyone else
> uses it.
Open Sourcing Eu isn't a silver bullet ... there is still much to be done before
Euphoria becomes widely used ... years in fact ... this is just the beginning.
Euphoria may have (for example) a 0.01% user base ... in 2 years it might grow
to 0.1% .. I think that would be considered a success ;)
Regards,
Ray Smith
http://RaymondSmith.com
26. Re: Broken Euphoria
On Wed, 27 Sep 2006 16:17:29 -0700, Derek Parnell
<guest at RapidEuphoria.com> wrote:
>Vincent wrote:
>>Pete Lomax: His own Eu with many features found in the old OpenEU.
>Derek Wrote:
>
>Speaking only for myself, you have it wrong, Vincent. I started
>working on my Euphoria clone *because* of the past position of RDS
>with respect to collabarative work on Euphoria - there was none.
>
>I will continue with it because its started, because it will teach me
>things, because it can be a 'playground' for experimentation, because
>others might like it. This does not automatically mean that I will not
>also try to assist RDS with the Open Euphoria concept.
Very well said, sums up a lot of things for me as well.
>In fact, I intend to help RDS improve the Euphoria ('offical edition')
>language,
>if Robert will let me.
Just to be clear, I take more of a 'would not hinder' than an 'intend
to help' position. For instance positive has native 8-bit strings;
would I personally put that into openeu? certainly not. OTOH I would
not be shy of stating eg:
"everywhere the back end checks for a sequence type, you need
similar code to handle strings, and you need to jump through hoops
eg when appending a sequence to a string, as the string (1 byte
per element) has to be auto-expanded into a sequence (4 bytes per
element), as it does when replacing a string element (character)
with anything outside #00..#FF, or a string slice with a
non-string, bar special case for a zero-length sequence"
If asked I will reproduce code snippets to illustrate a point albeit
that my back end is written in asm and has an incompatible opcode set
compared to the RDS Eu back end.
When adding a new feature to positive, I always add appropriate tests,
most of which are written to work on both, eg:
s = "food"
i = 2
j = 3
--/**/ s[i..j]="e" --/* -- Positive
s=s[1..i-1]&"e"&s[j+1..$] -- RDS */
--/**/ if s!="fed" then --/* -- Positive
if not equal(s,"fed") then -- RDS */
fatal(...
I don't want to split the community. Perhaps my biggest hope is, or to
be more reserved, I'd be quite happy if, someone develops on Positive
because they find it easier but ships on RDS, eg because the latter is
faster/more stable/cross platform.
>> Who's left to contribute? Me? Well I dont know diddly squat about the C
>> backend so I cant do very much can I? No.
There is plenty to be done that does not necessarily need detailed
knowledge or experience. No-one as yet has officially put their hand
up for creating and maintaining a subversion repository on
sourceforge, for example (if that's what people want).
Documentation writers and testers are usually in short supply too.
>> In five years time there may be 20 Euphoria dervived languages with only a
>> handful
>> of followers for each while official RDS Euphoria would be dead and buried
>> long
>> before due to lack of interest and support beyond RDS.
>
>Not likely. The '20 Euphoria dervived languages' are more likely to wither than
>the standard release.
Again I have to agree with Derek. My darling little baby, Positive,
is, quite heartbreakingly, not the one I would bet on lasting longest.
Regards,
Pete
27. Re: Broken Euphoria
Ray Smith wrote:
>
> If a LGPL based license is used it doesn't mean there will only be 1 version.
> It just means the source will be available for all versions.
> Everyone can still go and make there own version with whatever features
> they desire ... they just can't distribute the langauge without giving users
>
> access to the source code.
They just can't expect to be compensated for their work.
And they can't choose to use a different EULA of their own preference.
Your are limiting the development to sporadic and part-time participation and
uncertain devotion.
If someone really wants to circumvent the LGPL it wouldn't really be too
difficult. As far as I know there is no clause that says your code has to be
readable. Just compilable right?
> > How many people choose to use Eu instead of some other mainstream language?
> compared to how many people are programming, not many choose to use Euphoria.
> :(
> > YOu don't think those forks will attract new users? Many of whom will likely
> > migrate to the official version.
>
> There can still be new forks .. see above
Just not many.
> Each user of a closed source fork is locked into an agreement with the author.
What does that have to do with anything? I was talking about keeping avenues
open to attract more participation instead building walls to keep people out.
> > In the end there probably would be 2 or 3 different forks that manage to get
> > a foothold and remain unique enough to have their own following. .
>
> The current and potential Euphoria user base isn't big enough to have 2 or 3
> seperate versions. It's ok to have different distributions (like the
> activestate
>
> example fo Perl and Python) ... but they add value to the open source version,
>
> not a new slightly different versions).
If they are only slightly different they will merge. If they don't merge, then
what's the problem if people choose to segregate? They obviously weren't
satisfied.
> >You know it
> > Ray, it's been like your motto: "no language is suitabe for every person and
> > every task" :)
>
> People aren't going to choose 2 slightly different versions of Eu for
> different
> tasks ... they will choose Java or C# or Python.
No, they will choose a different one because they prefer to.
> Open Sourcing Eu isn't a silver bullet ... there is still much to be done
> before
>
> Euphoria becomes widely used ... years in fact ... this is just the beginning.
> Euphoria may have (for example) a 0.01% user base ... in 2 years it might grow
>
> to 0.1% .. I think that would be considered a success ;)
Eu doesn't really need many features, it needs participation.
It needs a codebase. How is opensourcing going to change that?
It's unrealistic to beleive that we can expect any signifcant increase in
participation other than the initial burst.
There is no significant advantage to the average user if Eu is opensourced or
not.
Spin-offs, commercial and non, is the best chance for Eu's popularity IMO.
Once eu has a codebase, then things will begin to snowball.
~ The difference between ordinary and extraordinary is that little extra ~
28. Re: Broken Euphoria
Vincent wrote:
>
> Lets see...
<snip>
> Matt Lewis: His own implementation of Eu with OO features.
OK, I'll chime in...
<snip>
> Who's left to contribute? Me? Well I dont know diddly squat about the C
> backend
> so I cant do very much can I? No.
>
> Thats eight people who may just take the source and abandon RDS Euphoria.
> While
> that is fine, it wont help this official version of Euphoria improve any. I
> also suspect that other languages like Python and Ruby will discover open
> Euphoria
> and consume all it's benefits (like speed and sequences) and use them to their
> advantage; rivaling any benefits Euphoria might have.
>
> Example: Ruby has already taken our sequences.
They can't really consume all of our benefits. There's been enough
information out there already for anyone to reimplement RDS' version
of sequences. But part of the advantage of euphoria's sequences is the
speed of using them. This is achieved by integrating them with atoms and
integers and discriminating between them using 2 bits of the 32-bit
dword that references a euphoria object.
Anyone could look at the header supplied with the translator to figure
this out. But these other languages have a different concept of types
and how they work, so they can't really get euphoria's sequences. They
can get typeless, extensible arrays, which have been pointed out to have
existed before euphoria.
But ruby is still ruby, and I'm no more likely to use it no matter how
many features it copies from euphoria. On the other hand, there are
features in other languages that could benefit euphoria, and that could
be integrated into euphoria IMHO without compromising all that is
euphoria.
I can say that my motivations for working on the euphoria source (I first
bought the 2.3 source code) has been to push Rob into making some changes
that could improve the language. Part of the thinking was that requesting
a feature is all well and good, but providing working source code was
much much better. We have much more opportunities for that now.
> In five years time there may be 20 Euphoria dervived languages with only a
> handful
> of followers for each while official RDS Euphoria would be dead and buried
> long
> before due to lack of interest and support beyond RDS.
If you've looked carefully at ooeu, you'll notice that some features are
RDS compatible, and some are not. If you've followed my ooeu discussions
on this list with Rob, you'll also note that I would have been happy to
have created il files and feed it to the backend. Now I can actually
do that. There are many things that can be done through the front end
only, such as all of the OOP stuff in ooeu, goto and continue. So you
could code stuff that other people could use so long as they used the
standard backend. This provides a way for others to try out the features,
without requiring everyone who runs the code to get the forked interpreter.
I don't so much view my fork of euphoria as a real fork, but as an
alternative development branch.
Matt Lewis
29. Re: Broken Euphoria
... and I'm having trouble with the expression "fork eu" (especially spoken
with a Boston accent).
Derek Parnell
<guest@RapidEupho
ria.com> To
EUforum at topica.com
09/28/2006 03:27 cc
AM
Subject
Re: Broken Euphoria
Please respond to
EUforum at topica.co
m
Ray Smith wrote:
> If the closed source fork developers win (on features and users)
This conversation is starting to take on a bias that may not be useful.
What about the other forms of cutlery such as knives, spoons, and
tea-spoons, ...
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
30. Re: Broken Euphoria
Vincent wrote:
>
> also suspect that other languages like Python and Ruby will discover open
> Euphoria
> and consume all it's benefits (like speed and sequences) and use them to their
> advantage; rivaling any benefits Euphoria might have.
>
> Example: Ruby has already taken our sequences.
>
Vincent:
RUBY is a 26 meg download for windows version !
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
