Am 03. September 2017 um 15:35 Uhr -0500 schrieb R0b0t1 <r03...@gmail.com>: > 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
