1. RE: OpenEU
I also wanted to add that when it comes to massive and greedy corporate
entities which pay far more attention to marketing than quality while
eliminating all competition thus stifling innovation, I'm all for
sticking it to such beasts the best way plausible- with free Open Source
alternatives.
However, Robert Craig's clearly a small businessman trying to make an
honest buck with a truly innovative product so this lacks all of that
maverick to hell with the man appeal of Open Source. There should be
more companies like his in software. Small software companies are
embattled enough being the little fish in the pond without being forced
to compete with free software.
I realize some involved with OpenEU have made large contributions to the
language and as respectable and noteworthy as that is, I can't see how
that would entitle anyone to try and take the product out of his hands.
-Deric Wechter
Deric Wechter wrote:
This is just one man's opinion of course, but I find it a bit disturbing
that an Open Source Euphoria is being pursued.
I can emphasize and relate to the frustration of having a product you
love not getting the attention you think it deserves as I've been in
similar positions before with other products and have considered the
idea of copying them. The idea is seductive when something you care
about is not living up to what you perceive as its' potential.
However, all legal issues aside I personally think it's extremely
unethical. Euphoria clearly exists because of Robert Craig. The fact
that you're not satisfied with how he handles his product isn't a valid
reason to attempt to hijack it.
If you must take this drastic step, why not create a new language which
includes Euphoria-like features? All programming languages, including
Euphoria borrow concepts from previous ones however they don't amount to
exact replicas of each other.
While Mr. Craig is in this for profit, his prices are very reasonable.
It's certainly possible to pay a lot more for less. As is often
mentioned here, it's also an extremely stable product.
I know one could argue that all of the major established languages are
not solely in the hands of their creators but most of them were
developed under different circumstances and with a few exceptions they
tend to be a lot older than Euphoria is.
On the other hand, the fact that users clearly are this frustrated with
his nurturing of the product should prompt Mr. Craig to consider working
with the users to implement reasonable improvements.
While some suggestions such as GOTO and possibly Pass by Reference may
not fall in line with his vision of what the language should be,
certainly many reasonable improvements have also been suggested, such as
assigning values to variables in the statements which you declare them
in. Improvements such as that one just make too much sense any way you
slice them for them not to be implemented.
I'm with the Pass by Value camp on the Pass by Reference discussion. It
it rarely _necessary_ to _need_ to resort to using global variables.
Convenience issues aside, almost always there's a Pass by Value
solution.
Since you can get a Pass by Reference effect with global variables,
there is a workaround if you prefer to do things that way. It may not
be pretty or best coding practice, but many don't consider Passing by
Reference to be best coding practice either.
As far as strict data types go, it would be ideal if it were made a
seamless option. Sequences as we know them are indeed a double-edged
sword. The beauty and burden of sequences is how flexible they are.
The programmer is often in a position where he or she has to worry about
the type of data in a variable so the headache we're spared in
definition and scope is considerably offset by the headache of manually
ensuring the proper kind of data is being entered.
While not needing to manage various data types is an intended feature of
Euphoria, having the ability to optionally assign each atom in a
sequence a definite data type would only serve to enhance the language
while retaining the ability to use sequences as they are now.
Hypothetical Examples:
atom tatm = type_char
sequence tseq = {type_char, type_str, type_int, type_real}
if tatm = type_char then
...
end if
Even just having an optional int and real number type would make a big
difference. Character and String types could be used symbolicly while
still actually storing the data as sequences of ASCII codes.
That way, one could still ensure they're storing the type of data they
want to without fundamentally changing the way the language works.
Coders wouldn't suddenly start strict typing every sequence either.
It would be particularly useful for handling user input as Irv pointed
out.
-Deric Wechter
2. RE: OpenEU
- Posted by eugtk at yahoo.com
Aug 18, 2003
--- Deric Wechter <dericwechter at netscape.net> wrote:
> I realize some involved with OpenEU have made large
> contributions to the
> language and as respectable and noteworthy as that
> is, I can't see how
> that would entitle anyone to try and take the
> product out of his hands.
Believe me, a great deal of time passed before anyone
here even mentioned the idea of 'forking' Euphoria.
A number of very talented individuals came, tried Eu,
and then moved on, before anyone mentioned writing our
own Eu clone.
Look thru the archives; many of the early libraries
and
tutorials were written by people who no longer use
Eu.
Why is that?
My personal opinion is, many people recognized the
elegance and clarity of Euphoria immediately, and
were hoping to see it become widely used.
In an effort to make Eu even better and more popular,
these people made many reasonable suggestions for
improvements and extensions to the language.
(Like supporting Windows)
Unfortunately, RDS' concerns seem to be speed and
never breaking a single line of existing code, and
most
of those suggestions have basically been ignored,
or left as "exercises for the user".
Seeing little hope for change, many of those talented
people have moved on - some to invent their own
languages, others to use competing languages.
Since reasoning, pleading, shouting, and leaving
haven't worked, perhaps the threat of an OpenEu is a
last-resort effort to push RDS into the 21st century.
Certainly, there have been useful improvements
( the += shorthand, for example), and ports to Linux
and BSD. I believe that Rob wants to be responsive to
his
customers, but the basic design of Eu limits his
options.
If that is indeed the case, why not just say so, and
freeze
Eu at 2.4 - it does what it was designed to do very
well - and begin on the New Euphoria, implementing
some of those good suggestions?
Then there would be no need for an OpenEuphoria.
Regards,
Irv
3. RE: OpenEU
Ted Fines wrote:
>
> Hi all,
>
> Can anyone provide examples of successful and unsuccessful forked
> software
> projects?
>
> I understand and agree with many of the arguments both for and against
> an
> open source Eu competing with Euphoria. I'm just curious about what has
> happened in other instances.
In general forks are considered very very bad!!!
Most cases they split the user base, split resources and case
confusion.
A number of very famous peieces of software have gained much from
forking though (gcc probably being the most famous).
The *BSD Unix's are all very famous cases of forked software. I don't
know if this has helped or harmed BDS??
In this case though, OpenEuphoria isn't considered a fork since
the base "Euphoria" is a closed source product.
OpenEuphoria in general is an "Open Source" version of Euphoria (with
additions).
I'm sure there was a discussion about forking in the Eric Raymond's
book "The cathedral abd the Bazaar".
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
If you read this book and still don't think an Open Source Euphoria
(either OpenEuphoria or RDS's Euphoria) is a good idea then we agree
to disagree :)
... but as I said you can only fork software you have the source code
(and license) to already.
Regards,
Ray Smith
http://rays-web.com
