Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

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