1. Frozen language versions
A proportion of users appears to have a possibly large code base written using
early versions (between 2.2 and 2.5) of Euphoria. They are primarily concerned by
the need not to change a single line oj code in that base, which strangles the
language to near death.
Would it be possibl for RDS to release almost frozen versions of say 2.2, 2.3,
2.4 and 2.5 with only applicable bug fixes, but absolutely no added features?
This would probably meet the abovementioned needs better than new versions of the
language, and might allow more development to proceed, while users of early
versions would still benefit the bug fixes.
If bugs are found which affect the frozen versions, bugfix updates could be
issued, probably not on every main Euphoria release. The opportunity and schedule
would remain RDS' call.
The version list above may be too long, of course.
CChris
2. Re: Frozen language versions
CChris wrote:
>
> A proportion of users appears to have a possibly large code base written using
> early versions (between 2.2 and 2.5) of Euphoria. They are primarily concerned
> by the need not to change a single line oj code in that base, which strangles
> the language to near death.
Have these people communicated with you personally? I haven't seen these
messages on the list. I think you're confusing the fact that many (most?)
people who use Euphoria probably don't want or need the language changed.
Then there are those (like me) who would like to see some changes made, but
don't want to make the language into something that feels completely
different.
> Would it be possibl for RDS to release almost frozen versions of say 2.2, 2.3,
> 2.4 and 2.5 with only applicable bug fixes, but absolutely no added features?
> This would probably meet the abovementioned needs better than new versions of
> the language, and might allow more development to proceed, while users of
> early
> versions would still benefit the bug fixes.
Heh, maybe if those people were willing to pay for the support (but I suspect
that the price would be pretty high).
Matt
3. Re: Frozen language versions
Matt Lewis wrote:
>
> CChris wrote:
> >
> > A proportion of users appears to have a possibly large code base written
> > using
> > early versions (between 2.2 and 2.5) of Euphoria. They are primarily
> > concerned
> > by the need not to change a single line oj code in that base, which
> > strangles
> > the language to near death.
>
> Have these people communicated with you personally? I haven't seen these
> messages on the list. I think you're confusing the fact that many (most?)
> people who use Euphoria probably don't want or need the language changed.
>
No, instead they have explicitly posted on this forum stating that they hadn't
wished to upgrade to 3.0 or more out of various fears - "everything works" as one
of them said, could help you pinpoint this user. Not mentioning those who said
this when 2.5 was released. Do you wish a list of these? I have four names to
whom I think - and may have forgotten some -, and can fetch the relevant search
results, hopefully without too much pain.
> Then there are those (like me) who would like to see some changes made, but
> don't want to make the language into something that feels completely
> different.
And who will be prevented by the above. So the basic idea is to also serve their
needs, rather than having conflicting priorities and randomly split votes.
>
> > Would it be possibl for RDS to release almost frozen versions of say 2.2,
> > 2.3,
> > 2.4 and 2.5 with only applicable bug fixes, but absolutely no added
> > features?
> > This would probably meet the abovementioned needs better than new versions
> > of
> > the language, and might allow more development to proceed, while users of
> > early
> > versions would still benefit the bug fixes.
>
> Heh, maybe if those people were willing to pay for the support (but I suspect
> that the price would be pretty high).
>
> Matt
Would it? For bugs affecting the public distributions, I'm not sure there should
be a price tag at all.
CChris
4. Re: Frozen language versions
CChris wrote:
> A proportion of users appears to have a possibly large code base written using
> early versions (between 2.2 and 2.5) of Euphoria. They are primarily concerned
> by the need not to change a single line oj code in that base, which strangles
> the language to near death.
There's an awful lot of stuff that we can do with Euphoria
without breaking any existing code.
> Would it be possibl for RDS to release almost frozen versions of say 2.2, 2.3,
> 2.4 and 2.5 with only applicable bug fixes, but absolutely no added features?
RDS does not have the resources to cater to the very tiny minority of
people who are clinging to old versions out of fear (and laziness)
of upgrading. There is no reason that I know of why someone
should be afraid of upgrading to 3.1.1, other than maybe
registered users who think that the encryption available
in the 2.5 and earlier registered binder is offering them
some necessary protection.
I'm the same as most people in this regard.
If a program is working well for me, and I see a new
version come out that does not offer me anything new
that I really care about, I am reluctant to upgrade.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Frozen language versions
CChris wrote:
>
> Matt Lewis wrote:
> >
> > Have these people communicated with you personally? I haven't seen these
> > messages on the list. I think you're confusing the fact that many (most?)
> > people who use Euphoria probably don't want or need the language changed.
> >
>
> No, instead they have explicitly posted on this forum stating that they hadn't
> wished to upgrade to 3.0 or more out of various fears - "everything works" as
> one of them said, could help you pinpoint this user. Not mentioning those who
> said this when 2.5 was released. Do you wish a list of these? I have four
> names
> to whom I think - and may have forgotten some -, and can fetch the relevant
> search results, hopefully without too much pain.
Ok, I do remember those posts, but I agree with Rob's post. It would be
a massive undertaking to backport that stuff, and since there's code that
can't really be open sourced, it's even more difficult.
> > Then there are those (like me) who would like to see some changes made, but
> > don't want to make the language into something that feels completely
> > different.
>
> And who will be prevented by the above. So the basic idea is to also serve
> their
> needs, rather than having conflicting priorities and randomly split votes.
Anyone can make their own fork, or volunteer to provide bug fixes for
past versions, not unlike what many organizations do with security updates.
I think you're confusing different issues here.
I don't think that the people who haven't upgraded are really slowing down
'progress' around here. The real issue is that different people want
different things. I think it's a mistake to interpret that as the
'system' failing. It's easy to go and make lots of changes, but that
doesn't make the changes beneficial, or good.
I agree that there are some things that would make Euphoria a much more
powerful language, but I also don't want it to lose the things that make
it what it is right now. I think we've seen some important improvements
since Rob opened up the code, even if everything hasn't happened over
night. The fact that people strongly disagree with a proposed enhancement
doesn't make them obstructionists, even if you believe the feature is the
best thing since sliced bread.
In some ways, I agree that the discussion is a bit too chaotic, but only
to the point that I think some better way to formalize the proposals and
track them is required. The discussions themselves are great.
> >
> > Heh, maybe if those people were willing to pay for the support (but I
> > suspect
> > that the price would be pretty high).
> >
> > Matt
>
> Would it? For bugs affecting the public distributions, I'm not sure there
> should
> be a price tag at all.
Well, IIRC, the terms from registration of Euphoria was that you got a free
full edition of the next update. That's how bug fixes were always handled
in the past. It's a much more liberal regime in effect now. You get it
all for free from the start. And all that backporting is going to take
a lot of work.
Matt
6. Re: Frozen language versions
Matt Lewis wrote:
<snip>
> I don't think that the people who haven't upgraded are really slowing down
> 'progress' around here. The real issue is that different people want
> different things. I think it's a mistake to interpret that as the
> 'system' failing. It's easy to go and make lots of changes, but that
> doesn't make the changes beneficial, or good.
>
> I agree that there are some things that would make Euphoria a much more
> powerful language, but I also don't want it to lose the things that make
> it what it is right now. I think we've seen some important improvements
> since Rob opened up the code, even if everything hasn't happened over
> night. The fact that people strongly disagree with a proposed enhancement
> doesn't make them obstructionists, even if you believe the feature is the
> best thing since sliced bread.
<snip>
I think some people should print this on a sheet of paper, and hang it at
the wall above their bed. 
Regards,
Juergen
7. Re: Frozen language versions
Juergen Luethje wrote:
>
> Matt Lewis wrote:
>
> <snip>
>
> > I don't think that the people who haven't upgraded are really slowing down
> > 'progress' around here. The real issue is that different people want
> > different things. I think it's a mistake to interpret that as the
> > 'system' failing. It's easy to go and make lots of changes, but that
> > doesn't make the changes beneficial, or good.
> >
> > I agree that there are some things that would make Euphoria a much more
> > powerful language, but I also don't want it to lose the things that make
> > it what it is right now. I think we've seen some important improvements
> > since Rob opened up the code, even if everything hasn't happened over
> > night. The fact that people strongly disagree with a proposed enhancement
> > doesn't make them obstructionists, even if you believe the feature is the
> > best thing since sliced bread.
>
> <snip>
>
> I think some people should print this on a sheet of paper, and hang it at
> the wall above their bed.
>
> Regards,
> Juergen
At the risk of offending many programmers, let me give you an alternate
perspective from one of the minority who is reluctant to upgrade. I upgraded
through all the 2.x versions of Euphoria. I waited a while until the bugs were
worked out before upgrading to each new version. I stopped at 2.5 when Eu then
went open source with 3.x.
Why? Was I lazy? Was I timid? No. Because I do production coding in Euphoria.
I'm not a hobbyist or a weekend bit twiddler. I don't tinker with Eu for a few
hours each day. My team and I put out bulletproof applications deployed to tens,
hundreds, or thousands of users. Stability means more to me than anything. Some
of our code was written years ago. It not uncommon to have to go back in and make
a few minor or major code changes to an application as the associated systems it
maintains also changes. We then recompile and deploy to the enterprise.
Imagine this scenario (just a wild example - please don't ding me on details).
The now proposed NAN is introduced as a standard. Future programmers then propose
a change to the value() function. They feel that passing back 2 values {status
code, value read} is a waste of stack space and requires extra coding to get the
second value returned. Why not just pass back a single value using NAN to mean
GET_EOF and -NAN to mean GET_FAIL? Well then we can write a = value("12345") in a
single line. Just think of how much handier and faster to code that would be! The
idea is discussed and eventually adopted as the new standard.
I then go into code years old and make some minor change only to discover that I
now have to recode every place I used value() because I depended on receiving
back two values, not one. Sure, I could re-wrap the newer value function and call
it value_new and then recreate the behavior of the original value function so my
code will continue working. But why? My code was stable for years as it was. I
can't even imagine having to go back and change thousands of instances of code
just so save somebody some typing. I'm all for progress, but not at the expense
of breaking existing code. Change, enhance, add new functionality, but at least
change to newer function names to avoid such conflicts.
To me, legacy code is stable code. One man's opinion. Your mileage may vary.
Yours, OtterDad
Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford
8. Re: Frozen language versions
OtterDad wrote:
>
> I then go into code years old and make some minor change only to discover
Years ago I had to support an ancient heap of junk called BOS/Writer, laughably
described in the sales literature as a word processor. In my time there I saw
many junior staff arrive and leave, and it became part of my job description to
go and kick the latest idiot to recompile the thing on the latest compiler.
Pete
