On Mon, Sep 4, 2017 at 1:49 AM, Marvin Gülker <m-guel...@phoenixmail.de> wrote:
> 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.
>
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 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.
>
Then thank you, that is all that I hoped to convey.
>> 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++.
>
I don't think anyone thought you were necessarily endorsing Ruby.
However, I do think that people who detest Ruby are not necessarily
misinformed. 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?
Cheers,
R0b0t1.
