| 1 |
Sorry, I missed your reply. |
| 2 |
|
| 3 |
On Mon, Sep 4, 2017 at 3:32 PM, Marvin Gülker <m-guelker@×××××××××××.de> wrote: |
| 4 |
> Am 04. September 2017 um 12:07 Uhr -0500 schrieb R0b0t1 <r030t1@×××××.com>: |
| 5 |
>> Even if they can not present an argument like I have, |
| 6 |
>> they will probably only notice it if it misbehaves in some way. If it |
| 7 |
>> misbehaves more than other software on their system, who is to say it |
| 8 |
>> isn't a poorly designed language and/or ecosystem? |
| 9 |
> |
| 10 |
> I think that on a technical mailinglist you should convey your point |
| 11 |
> using technical arguments, not rhethorical ones. |
| 12 |
|
| 13 |
The technical reasoning in the argument I presented is "it doesn't |
| 14 |
work when I try to use it." It is not sophistry. |
| 15 |
|
| 16 |
> The reasoning is |
| 17 |
> errorneous. If your goal is not ultimate API stability, then Ruby's |
| 18 |
> design approach that focuses more on progress than on ultimate API |
| 19 |
> stability is not poor, but different. You can agree or disagree with the |
| 20 |
> goal, but you can't question the measures taken to implement it by first |
| 21 |
> stipulating a goal different from the one the measure was intended to |
| 22 |
> implement. Take a look at Ruby's versioning policy[1]; ultimate API |
| 23 |
> backward compatibility is not a design goal in minor versions of the |
| 24 |
> language. Ruby is simply not the right tool for the job if you want to |
| 25 |
> create for example an archive software that must run 20 years without |
| 26 |
> touching it. |
| 27 |
> |
| 28 |
|
| 29 |
The problem is there's a zeroth goal of every project: to be useful. |
| 30 |
If the software produced is hard to use or not usable at all, then all |
| 31 |
of the work spent on it is for naught. |
| 32 |
|
| 33 |
Suggesting that it is impossible to progress a language while |
| 34 |
maintaining language stability is fallacious reasoning. You can choose |
| 35 |
to do both, e.g. by structuring releases so that breaking changes are |
| 36 |
lumped together, as in Python. It is also the case that not all |
| 37 |
changes are good changes, though experimentation is key to success. |
| 38 |
|
| 39 |
> Even though, the problem is not as dramatic as you seem to imply. I |
| 40 |
> stand by my point that using private C interfaces is the programmer's |
| 41 |
> fault and there is nothing to be standardised here. Real breaking |
| 42 |
> changes of documented behaviour like the Bignum/Fixnum one are rare, and |
| 43 |
> the effects are moderate. Most of the software written in Ruby will not |
| 44 |
> have a problem with running on newer versions. |
| 45 |
> |
| 46 |
|
| 47 |
The problem is dramatic enough if there's people complaining about it. |
| 48 |
Granted, most distributions seem to take care of such issues for their |
| 49 |
users, so the only people complaining seem to be Gentooers. |
| 50 |
|
| 51 |
Other people who do not like the situation simply avoid Ruby. |
| 52 |
|
| 53 |
Cheers, |
| 54 |
R0b0t1. |
Archives