Re: [gentoo-user] Ruby - 3 versions - seriously????
On Tue, Sep 5, 2017 at 4:32 AM, Marvin Gülker wrote: > Real breaking > changes of documented behaviour like the Bignum/Fixnum one are rare, and > the effects are moderate. This isn't even "breaking" yet. Only deprecated. -- konsolebox
Re: [gentoo-user] Ruby - 3 versions - seriously????
Sorry, I missed your reply. On Mon, Sep 4, 2017 at 3:32 PM, Marvin Gülker wrote: > Am 04. September 2017 um 12:07 Uhr -0500 schrieb R0b0t1 : >> Even if they can not present an argument like I have, >> they will probably only notice it if it misbehaves in some way. If it >> misbehaves more than other software on their system, who is to say it >> isn't a poorly designed language and/or ecosystem? > > I think that on a technical mailinglist you should convey your point > using technical arguments, not rhethorical ones. The technical reasoning in the argument I presented is "it doesn't work when I try to use it." It is not sophistry. > The reasoning is > errorneous. If your goal is not ultimate API stability, then Ruby's > design approach that focuses more on progress than on ultimate API > stability is not poor, but different. You can agree or disagree with the > goal, but you can't question the measures taken to implement it by first > stipulating a goal different from the one the measure was intended to > implement. Take a look at Ruby's versioning policy[1]; ultimate API > backward compatibility is not a design goal in minor versions of the > language. Ruby is simply not the right tool for the job if you want to > create for example an archive software that must run 20 years without > touching it. > The problem is there's a zeroth goal of every project: to be useful. If the software produced is hard to use or not usable at all, then all of the work spent on it is for naught. Suggesting that it is impossible to progress a language while maintaining language stability is fallacious reasoning. You can choose to do both, e.g. by structuring releases so that breaking changes are lumped together, as in Python. It is also the case that not all changes are good changes, though experimentation is key to success. > Even though, the problem is not as dramatic as you seem to imply. I > stand by my point that using private C interfaces is the programmer's > fault and there is nothing to be standardised here. Real breaking > changes of documented behaviour like the Bignum/Fixnum one are rare, and > the effects are moderate. Most of the software written in Ruby will not > have a problem with running on newer versions. > The problem is dramatic enough if there's people complaining about it. Granted, most distributions seem to take care of such issues for their users, so the only people complaining seem to be Gentooers. Other people who do not like the situation simply avoid Ruby. Cheers, R0b0t1.
Re: [gentoo-user] Ruby - 3 versions - seriously????
On Mon, Sep 4, 2017 at 12:49 PM, Michael Orlitzky wrote: > On 09/04/2017 01:07 PM, R0b0t1 wrote: >> >> For almost all languages but Ruby (and Perl) you can take code written >> against one minor version and compile it in the next minor version. > > > This isn't a language issue with Ruby, it's a culture/package-management > one. For a long time, it's been easy to bundle dependencies in Ruby. The > result is a culture of saying "I need the version of ruby-foo that was > released on my birthday that one time mercury was in retrograde, and > also I'd like the version number to have a seven in it somewhere because > that's my daughter's age." When two package authors come up with two > different requirements like that, you end up needing *two* versions of > ruby-foo installed. > That's very insightful. However, I think developers originally started requesting versions with such specificity because breaking changes, even minor ones, were made with such consistency. At a certain point this does simply spill over into maintainer preference but package maintainers may be following the lead of the language developers. E.g. most Python packages provide extremely stable interfaces. Cheers, R0b0t1.
Re: [gentoo-user] Ruby - 3 versions - seriously????
Am 04. September 2017 um 12:07 Uhr -0500 schrieb R0b0t1 : > Even if they can not present an argument like I have, > they will probably only notice it if it misbehaves in some way. If it > misbehaves more than other software on their system, who is to say it > isn't a poorly designed language and/or ecosystem? I think that on a technical mailinglist you should convey your point using technical arguments, not rhethorical ones. The reasoning is errorneous. If your goal is not ultimate API stability, then Ruby's design approach that focuses more on progress than on ultimate API stability is not poor, but different. You can agree or disagree with the goal, but you can't question the measures taken to implement it by first stipulating a goal different from the one the measure was intended to implement. Take a look at Ruby's versioning policy[1]; ultimate API backward compatibility is not a design goal in minor versions of the language. Ruby is simply not the right tool for the job if you want to create for example an archive software that must run 20 years without touching it. Even though, the problem is not as dramatic as you seem to imply. I stand by my point that using private C interfaces is the programmer's fault and there is nothing to be standardised here. Real breaking changes of documented behaviour like the Bignum/Fixnum one are rare, and the effects are moderate. Most of the software written in Ruby will not have a problem with running on newer versions. Marvin [1]: https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/
Re: [gentoo-user] Ruby - 3 versions - seriously????
On 09/04/2017 01:07 PM, R0b0t1 wrote: > > For almost all languages but Ruby (and Perl) you can take code written > against one minor version and compile it in the next minor version. This isn't a language issue with Ruby, it's a culture/package-management one. For a long time, it's been easy to bundle dependencies in Ruby. The result is a culture of saying "I need the version of ruby-foo that was released on my birthday that one time mercury was in retrograde, and also I'd like the version number to have a seven in it somewhere because that's my daughter's age." When two package authors come up with two different requirements like that, you end up needing *two* versions of ruby-foo installed. Even if both packages could happily use the same, latest version of ruby-foo -- you get what upstream says in most cases. And what upstream says is usually crap, because they bundle everything and will never notice annoying incompatibilities like end-users do.
Re: [gentoo-user] Ruby - 3 versions - seriously????
On Mon, Sep 4, 2017 at 1:49 AM, Marvin Gülker wrote: > Am 03. September 2017 um 15:35 Uhr -0500 schrieb R0b0t1 : >> I think the takeaway from Alan's comment is that Python is unnaturally >> stable compared to other interpreted languages. One might be inclined >> to think Python developers consider their work to be a widely used >> tool as opposed to a toy to play with. > > If you regard Ruby as a toy language, I'm inclined to say that quite a > number of (most often Rails) applications use it in for serious > projects. > I don't doubt they're attempting to be serious. >> These are all fairly major changes for a minor release. I'm not really >> sure any of this evidence supports the opinion that Ruby doesn't >> experience breaking changes more regularly than other languages. > > I have not made the claim that Ruby is more stable than other languages, > especially did I never say that Ruby is as stable as Python. My > intention was the counter the statement that every Ruby minor release is > a "complete new language". The changes I listed are breaking, but not to > a degree that justifies the "complete new language" statement. > For almost all languages but Ruby (and Perl) you can take code written against one minor version and compile it in the next minor version. I don't disagree that the language at large is more or less the exact same thing, but there is enough different to prevent a program from compiling - thus, it's a new language. >> Situations like the above, and reliance on private C interfaces, are >> what makes it seem plausible to me that there are packages that >> require a version that has no listed breaking changes. > > Using unsupported private C interfaces is going to make any package > break in any language over time. This is not Ruby's fault. > Perhaps not in the technical sense, but there is software written against those interfaces and people use it. Perhaps those interfaces should be standardized? >> This statement makes me think you haven't tried to understand the >> issue, as that ISO document - to the best of my knowledge, I can't >> actually view it without paying money - implements Ruby 1.8.1 and >> potentially some features from 1.9. Hearsay indicates it was started >> at the behest of the Japanese government so that they could use Ruby >> for internal projects as their rules seem to require standards >> documents for software. This is important, because it shows that there >> is no real effort by Ruby's lead developer or the Ruby community to >> produce a legitimate standards document. > > I've not worked with the ISO document. You requested a formal standard, > and I replied that there's an ISO document, which I regard as a > standard. I didn't know that it describes such an ages old version of > Ruby (though I should have known better given the date). Since the 2.4.0 > release post on ruby-lang.org justifies removal of Fixnum/Bignum with > the interpreter not being compliant with the ISO standard, I was under > the impression that it was still usable. If it isn't, I apologise. > You can still use it, but it only defines Ruby ~1.8. To most that means it is not usable. I'm not certain why they bothered to quote it for justification. Grasping at straws? Standards can exist and still be useless. That the standard would be so vague as to not guarantee any interoperability between vendors was something that some users feared when it was still relevant. >> In practice one finds more references to something called RubySpec >> which is an executable implementation of what people like to call a >> specification. RubySpec appears to be discontinued[1], but even when >> it was in use there are three things that should be pointed out: > > The RubySpec was started as a community effort indeed, but if you only > read the Rubinius view of it, you're going to see a lot of bias. The > Rubinius main maintainer retracted from the effort by his own > decision. Consequently, the RubySpec is now maintained by the core team > of the canonical Ruby implementation[1]. Thus, it is not true that the > core developers do not make use of RubySpec. > This is sufficiently new that I hadn't learned of it. Still though, there is more than one Ruby implementation, and past behavior w.r.t. creating a language specification has me dubious that the specification will be maintained to a useful degree. The issue in the past when RubySpec was a separate project was that everyone seems to have ended up ignoring it, because writing testcases is no fun. Unless there are strictly enforced project guidelines I don't expect the existence of ruby/spec to mean anything more than the existence of RubySpec. And, again, there are still crucial areas of the language left undefined, namely its grammar. >> If you look at the RubySpec code you will see that the "specification" >> consists of testcases that attempt to define the behavior of Ruby. As >> mentioned, these tests are written in Ruby, and are subject to bugs
Re: [gentoo-user] Ruby - 3 versions - seriously????
Am 03. September 2017 um 15:35 Uhr -0500 schrieb R0b0t1 : > I think the takeaway from Alan's comment is that Python is unnaturally > stable compared to other interpreted languages. One might be inclined > to think Python developers consider their work to be a widely used > tool as opposed to a toy to play with. If you regard Ruby as a toy language, I'm inclined to say that quite a number of (most often Rails) applications use it in for serious projects. > Then why does he have all three installed? I cannot answer that. I lack the insight into the Gentoo Ruby deployment process. > These are all fairly major changes for a minor release. I'm not really > sure any of this evidence supports the opinion that Ruby doesn't > experience breaking changes more regularly than other languages. I have not made the claim that Ruby is more stable than other languages, especially did I never say that Ruby is as stable as Python. My intention was the counter the statement that every Ruby minor release is a "complete new language". The changes I listed are breaking, but not to a degree that justifies the "complete new language" statement. > Leading into my next point, I remember some conversations about people > discussing the Ruby parser and how there was no BNF description of the > language. Consequently (from memory) there was at least one > implementation of Ruby were encountering regressions in the parser > between versions that were undocumented and not detected until the > releases had already been made. The result was that code was > semantically different between some versions. Regrettably I'm having > trouble citing this one. It was JRuby as far as I know, but don't nail me on that. I don't have it ready either, nor do I have the exact circumstances in memory. > Situations like the above, and reliance on private C interfaces, are > what makes it seem plausible to me that there are packages that > require a version that has no listed breaking changes. Using unsupported private C interfaces is going to make any package break in any language over time. This is not Ruby's fault. > This statement makes me think you haven't tried to understand the > issue, as that ISO document - to the best of my knowledge, I can't > actually view it without paying money - implements Ruby 1.8.1 and > potentially some features from 1.9. Hearsay indicates it was started > at the behest of the Japanese government so that they could use Ruby > for internal projects as their rules seem to require standards > documents for software. This is important, because it shows that there > is no real effort by Ruby's lead developer or the Ruby community to > produce a legitimate standards document. I've not worked with the ISO document. You requested a formal standard, and I replied that there's an ISO document, which I regard as a standard. I didn't know that it describes such an ages old version of Ruby (though I should have known better given the date). Since the 2.4.0 release post on ruby-lang.org justifies removal of Fixnum/Bignum with the interpreter not being compliant with the ISO standard, I was under the impression that it was still usable. If it isn't, I apologise. > In practice one finds more references to something called RubySpec > which is an executable implementation of what people like to call a > specification. RubySpec appears to be discontinued[1], but even when > it was in use there are three things that should be pointed out: The RubySpec was started as a community effort indeed, but if you only read the Rubinius view of it, you're going to see a lot of bias. The Rubinius main maintainer retracted from the effort by his own decision. Consequently, the RubySpec is now maintained by the core team of the canonical Ruby implementation[1]. Thus, it is not true that the core developers do not make use of RubySpec. > If you look at the RubySpec code you will see that the "specification" > consists of testcases that attempt to define the behavior of Ruby. As > mentioned, these tests are written in Ruby, and are subject to bugs in > Ruby that are made undetectable, or very hard to detect, by the > self-referential relationship of the behavioral specification and the > language. This sounds logical to me, and I agree. I'm not the correct person to address this to, though. From the formal point of view, I surely cannot compete with you. The spirit in the Ruby development appears to follow not a formal, but a practical approach, which is always going to be inferior. > What I have read in this regard leads me to conclude that Ruby is not > a language that I should use for my development, and it pains me to > say this. Use the tool that fits the job for you. I wonder if I was perceived as using Ruby everythere; this isn't the case. Actually, I don't write much Ruby code currently, but much more C/C++. Marvin [1]: https://github.com/ruby/spec
Re: [gentoo-user] Ruby - 3 versions - seriously????
On Sun, Sep 3, 2017 at 1:08 AM, Hans de Graaff wrote: > The situation with ruby really isn't different from python or perl at > all. We also have multiple python versions in the tree just like with > ruby. perl is not slotted but faces the same issues on each version (e.g. > the "no . in INC path anymore" issue that made ruby 1.8 to 1.9 such a big > deal). > I think the takeaway from Alan's comment is that Python is unnaturally stable compared to other interpreted languages. One might be inclined to think Python developers consider their work to be a widely used tool as opposed to a toy to play with. Consequently the number of breaking changes does seem to be far higher in Ruby. Please see my reply to Marvin below. > I find it very unlikely that you would *need* all three versions, unless > you are doing ruby development and want to actively use all three. The > RUBY_TARGETS="ruby22" advice matches the current default in the profile. > Then why does he have all three installed? On Sun, Sep 3, 2017 at 5:31 AM, Marvin Gülker wrote: > Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 : >> Seeing as the OP is saying there are 3 versions queued for merge and >> he has not installed any of them by hand it looks like Alan is >> right. Perhaps the OP is using "old" Ruby based software, but software >> of that age in another language could work on new interpreters. > > I took a moment and looked up the release announcements for the minor > version releases between the versions the OP has installed: > > * https://www.ruby-lang.org/en/news/2015/12/25/ruby-2-3-0-released/ > * https://www.ruby-lang.org/en/news/2016/12/25/ruby-2-4-0-released/ > > 2.4.0 saw breaking changes, 2.3.0 not. In 2.4.0, the most notable > breaking change was the unification of Fixnum and Bignum into > Integer. Other breaking changes affected the standard library (stdlib): > > * Tk was dropped from the stdlib. > * XMLRPC was dropped from the stdlib. > * Support for OpenSSL <= 0.9.7 was dropped from the stdlib. > > For Tk specifically, the reason for the removal was that the maintainer > got demotivated by useless and even hostile feedback[1] and since nobody > wanted step up, the library was removed from the stdlib[2]. > > The exact judgement of how grave these changes are is subjective. Fixnum > and Bignum were not classes commonly used in Ruby code, so it may be > viewed as a detail. They saw a more frequent use in C extensions, which > may then be viewed more grave; the release announcement iself is pretty > clear on this topic: > > Ruby 2.4.0 release announcment from 2016-12-25: >> All C extensions which touch the Fixnum or Bignum class need to be >> fixed. > > I was not too happy with this either, but most software continued to > work. > These are all fairly major changes for a minor release. I'm not really sure any of this evidence supports the opinion that Ruby doesn't experience breaking changes more regularly than other languages. E.g. Python doesn't see name changes or standard class removals in minor versions. There has only been one major set of breaking change to date, Python 2 to Python 3, and it seems like the Python developers will continue > I don't know the reason why the OP was left with three versions of > Ruby. Given the above release announcements, there are not too many > reasons why his software should not work with newer versions of > Ruby. > > All this only applies to the core language. Some RubyGems packages > release very rigorously and some even make use of undocumented features > of (the C interface of) the Ruby language. That's however a different > problem. > Leading into my next point, I remember some conversations about people discussing the Ruby parser and how there was no BNF description of the language. Consequently (from memory) there was at least one implementation of Ruby were encountering regressions in the parser between versions that were undocumented and not detected until the releases had already been made. The result was that code was semantically different between some versions. Regrettably I'm having trouble citing this one. Situations like the above, and reliance on private C interfaces, are what makes it seem plausible to me that there are packages that require a version that has no listed breaking changes. I admit I have not looked in great detail because I do not have the time. > Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 : >> One of the reasons I dislike Ruby is that there is no complete >> specification of the language available, making this statement >> (technically) untestable. > > There *is* a formal complete ISO specification of the language available, > approved in 2012[3]. > This statement makes me think you haven't tried to understand the issue, as that ISO document - to the best of my knowledge, I can't actually view it without paying money - implements Ruby 1.8.1 and potentially some features from 1.9. Hearsay indicates it was started at the behest of
Re: [gentoo-user] Ruby - 3 versions - seriously????
Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 : > Seeing as the OP is saying there are 3 versions queued for merge and > he has not installed any of them by hand it looks like Alan is > right. Perhaps the OP is using "old" Ruby based software, but software > of that age in another language could work on new interpreters. I took a moment and looked up the release announcements for the minor version releases between the versions the OP has installed: * https://www.ruby-lang.org/en/news/2015/12/25/ruby-2-3-0-released/ * https://www.ruby-lang.org/en/news/2016/12/25/ruby-2-4-0-released/ 2.4.0 saw breaking changes, 2.3.0 not. In 2.4.0, the most notable breaking change was the unification of Fixnum and Bignum into Integer. Other breaking changes affected the standard library (stdlib): * Tk was dropped from the stdlib. * XMLRPC was dropped from the stdlib. * Support for OpenSSL <= 0.9.7 was dropped from the stdlib. For Tk specifically, the reason for the removal was that the maintainer got demotivated by useless and even hostile feedback[1] and since nobody wanted step up, the library was removed from the stdlib[2]. The exact judgement of how grave these changes are is subjective. Fixnum and Bignum were not classes commonly used in Ruby code, so it may be viewed as a detail. They saw a more frequent use in C extensions, which may then be viewed more grave; the release announcement iself is pretty clear on this topic: Ruby 2.4.0 release announcment from 2016-12-25: > All C extensions which touch the Fixnum or Bignum class need to be > fixed. I was not too happy with this either, but most software continued to work. I don't know the reason why the OP was left with three versions of Ruby. Given the above release announcements, there are not too many reasons why his software should not work with newer versions of Ruby. All this only applies to the core language. Some RubyGems packages release very rigorously and some even make use of undocumented features of (the C interface of) the Ruby language. That's however a different problem. Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 : > One of the reasons I dislike Ruby is that there is no complete > specification of the language available, making this statement > (technically) untestable. There *is* a formal complete ISO specification of the language available, approved in 2012[3]. Marvin [1]: Exact reasoning of the maintainer is here (in reply to me): http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/436401 [2]: https://bugs.ruby-lang.org/issues/8539 [3]: https://www.iso.org/standard/59579.html
Re: [gentoo-user] Ruby - 3 versions - seriously????
On Sat, Sep 2, 2017 at 4:37 PM, Marvin Gülker wrote: > Am 02. September 2017 um 22:57 Uhr +0200 schrieb Alan McKinnon > : >> OK, so disclaimer up front. I detest Ruby. I hate it with a passion. > > There is nothing one can do against that, but... > >> Each new minor version of ruby is a whole new language and the devs >> are OK with large breaking changes between minor version numbers. > > ...this is factually incorrect. There are new features added quite > often, but minor versions are generally backwards-compatible. The one > exception was the 1.8->1.9 switch years ago. One of the reasons I dislike Ruby is that there is no complete specification of the language available, making this statement (technically) untestable. Seeing as the OP is saying there are 3 versions queued for merge and he has not installed any of them by hand it looks like Alan is right. Perhaps the OP is using "old" Ruby based software, but software of that age in another language could work on new interpreters. Cheers, R0b0t1.
Re: [gentoo-user] Ruby - 3 versions - seriously????
Am 02. September 2017 um 22:57 Uhr +0200 schrieb Alan McKinnon : > OK, so disclaimer up front. I detest Ruby. I hate it with a passion. There is nothing one can do against that, but... > Each new minor version of ruby is a whole new language and the devs > are OK with large breaking changes between minor version numbers. ...this is factually incorrect. There are new features added quite often, but minor versions are generally backwards-compatible. The one exception was the 1.8->1.9 switch years ago. I have done quite a bit of web developing with it and never had an API break problem with Ruby itself, save the aforementioned 1.8/1.9 switch. Granted, gems are quite different. RubyOnRails especially releases new (breaking) versions way too fast for me; that's why I prefer to use different libraries. Marvin
Re: [gentoo-user] Ruby - 3 versions - seriously????
On 02/09/2017 15:33, Andrew Lowe wrote: > Hi all, > I'm in the process of doing a world update and due to a failed compile, > I have cause to look up through the list of stuff to compile/update. > Imagine my surprise when I saw there were three versions of Ruby wanting > to update: > > [ebuild U ] dev-lang/ruby-2.4.1-r4 [2.4.1-r3] > [ebuild U ] dev-lang/ruby-2.3.4-r4 [2.3.4-r3] > [ebuild U ] dev-lang/ruby-2.2.7-r4 [2.2.7-r3] > > Have I managed to stuff up something on my machine or is this really the > case, there has to be three versions? And to make matters worse, they > are not big version jumps, + 0.1 -> 2.2, 2.3 & 2.4. > > I would prefer to get rid of Ruby, but, if memory serves me correctly, > someone associated with the kernel decided it would be a good idea to > use yet another language for something, obviously Python wasn't good > enough > > Thoughts on the magically multiplying Rubies would be greatly > appreciated, Welcome to the giant clusterfuck that is RubyWorld(tm). Just be thankful you don't have to support corporate internal code written in it. Or package gems. OK, so disclaimer up front. I detest Ruby. I hate it with a passion. You have to understand what Ruby is. It is not a language. It is 5 languages. Like python27 and python3 are really different languages with much in common. The difference is the python devs have solid reasons for doing python3 and the transition has been mostly smooth. Each new minor version of ruby is a whole new language and the devs are OK with large breaking changes between minor version numbers. So why 3 rubys? Because they are 3 languages and you have packages that for whatever reason are tied to different rubys. Just pretend to yourself that they aren't really ruby22, ruby23 and ruby24 - they are php, perl and python (or whatever 3 language names you like that help you get past the 3 rubys! thing). You probably need all 3. As housekeeping, you can put this in make.conf: RUBY_TARGETS="ruby22", and remove all ruby versions from world and let depclean, revdep-rebuild and emerge world take care of the details. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Ruby - 3 versions - seriously????
On Saturday, 2 September 2017 14:33:31 BST Andrew Lowe wrote: > I'm in the process of doing a world update and due to a failed compile, > I have cause to look up through the list of stuff to compile/update. > Imagine my surprise when I saw there were three versions of Ruby wanting > to update: > > [ebuild U ] dev-lang/ruby-2.4.1-r4 [2.4.1-r3] > [ebuild U ] dev-lang/ruby-2.3.4-r4 [2.3.4-r3] > [ebuild U ] dev-lang/ruby-2.2.7-r4 [2.2.7-r3] > > Have I managed to stuff up something on my machine or is this really the > case, there has to be three versions? And to make matters worse, they > are not big version jumps, + 0.1 -> 2.2, 2.3 & 2.4. > > I would prefer to get rid of Ruby, but, if memory serves me correctly, > someone associated with the kernel decided it would be a good idea to > use yet another language for something, obviously Python wasn't good > enough > > Thoughts on the magically multiplying Rubies would be greatly > appreciated, > > Andrew Won't portage let you remove any of them? On my system only qtwebkit and webkit-gtk need ruby, and they seem happy to accept version 2.2.6. Nothing apparently to do with the kernel. -- Regards, Peter.