| 1 |
Am 04. September 2017 um 12:07 Uhr -0500 schrieb R0b0t1 <r030t1@×××××.com>: |
| 2 |
> Even if they can not present an argument like I have, |
| 3 |
> they will probably only notice it if it misbehaves in some way. If it |
| 4 |
> misbehaves more than other software on their system, who is to say it |
| 5 |
> isn't a poorly designed language and/or ecosystem? |
| 6 |
|
| 7 |
I think that on a technical mailinglist you should convey your point |
| 8 |
using technical arguments, not rhethorical ones. The reasoning is |
| 9 |
errorneous. If your goal is not ultimate API stability, then Ruby's |
| 10 |
design approach that focuses more on progress than on ultimate API |
| 11 |
stability is not poor, but different. You can agree or disagree with the |
| 12 |
goal, but you can't question the measures taken to implement it by first |
| 13 |
stipulating a goal different from the one the measure was intended to |
| 14 |
implement. Take a look at Ruby's versioning policy[1]; ultimate API |
| 15 |
backward compatibility is not a design goal in minor versions of the |
| 16 |
language. Ruby is simply not the right tool for the job if you want to |
| 17 |
create for example an archive software that must run 20 years without |
| 18 |
touching it. |
| 19 |
|
| 20 |
Even though, the problem is not as dramatic as you seem to imply. I |
| 21 |
stand by my point that using private C interfaces is the programmer's |
| 22 |
fault and there is nothing to be standardised here. Real breaking |
| 23 |
changes of documented behaviour like the Bignum/Fixnum one are rare, and |
| 24 |
the effects are moderate. Most of the software written in Ruby will not |
| 25 |
have a problem with running on newer versions. |
| 26 |
|
| 27 |
Marvin |
| 28 |
|
| 29 |
[1]: https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/ |
Archives