Am 04. September 2017 um 12:07 Uhr -0500 schrieb R0b0t1 <r03...@gmail.com>: > 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/
