On Sun, Sep 3, 2017 at 1:08 AM, Hans de Graaff <gra...@gentoo.org> 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 <m-guel...@phoenixmail.de> wrote: > Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 <r03...@gmail.com>: >> 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 <r03...@gmail.com>: >> 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 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. 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: 1) RubySpec had nothing to do with the core Ruby implementation, 2) RubySpec is written in Ruby, and 3) it is impossible to define something by listing what it is not. 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. The last point may look like an irrelevant epistemological concern but is extremely relevant because the study of programming languages can only happen through mathematics. The same logic, stated differently, is what is used to conclude that the halting problem is intractable: if I only give you what x is not, it is always possible to use the rules already given to define an x that is not what someone else might intend x to be. If you search for something as simple as "Ruby BNF" or "Ruby standard" you will find plenty of comments going into the details of how no standard is actually complete, and how no standard is actually related to the Ruby project. The source below touches on some of the issues I presented above in a Ruby-specific way. 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. Cheers, R0b0t1. [1] https://github.com/rubinius/rubinius-website-archive/blob/cf54187d421275eec7d2db0abd5d4c059755b577/_posts/2014-12-31-matz-s-ruby-developers-don-t-use-rubyspec.markdown
