3 ms·

"I can see your point, but, to pick a couple specific points—it is strictly better to have thorough documentation than not to, and it is also strictly better to

"I can see your point, but, to pick a couple specific points—it is strictly better to have thorough documentation than not to, and it is also strictly better to have a language with a defined grammar to support linters and the like than not to." These are still subjective choices, not errors. Think of it this way: It is almost always strictly better to use O(N) sort algorithms instead of N^2 ones. That does not make it an error to use an N^2 one, just a bad choice. "These aren’t trade-offs" Sure they are. They are tradeoffs in the same way N^2 vs N sort algorithms are. There are edge cases and weird situations where the N^2 ones are better. There are edge cases and weird situations where less thorough documentation is better. Are they common? No. I would venture a guess that most people, in fact, do not believe they are worth worrying about, and would roll their eyes. (IE imagine you have a super space limited device. Documentation that is not thorough and only concentrates on the "most important" parts may fit where thorough docs wouldn't) Same with defined grammars. Having a well defined grammar means people depend on it. It gives you less freedom. To be useful to others, it also often requires being LL or LALR or some variant, which limits how you can extend the language in the future. You are entirely welcome to say "all of the situations you present are super contrived and stupid". I would even agree. They are just examples i put 2 minutes thought into (ruby isn't my thing, i wrote some apps in it years ago and haven't touched it in probably 5 years). But the point is: They are still tradeoffs, even if you think they are obviously better or worse choices. "Perhaps you know of some features or strengths that Ruby has that wouldn’t be possible without these drawbacks?" Certainly you realize how subjective a thing this is? Even if the answer is "nothing would be worse" it doesn't suddenly make it objectively better instead of subjectively better. Everyone agreeing with an opinion does not turn it into a fact. Again, i think it would be reasonable to say "for the majority of ruby users, X would be better" and even "for 99% of ruby users, X would be better". But that's still subjective.

philwelch 9y ago
> Think of it this way: It is almost always strictly better to use O(N) sort algorithms instead of N^2 ones. That does not make it an error to use an N^2 one, just a bad choice. The distinction between an "error" and a "bad choice" isn't all that interesting to me, and this approach more or less makes it meaningless to criticize the design of literally anything.
- DannyBee 9y ago
  "The distinction between an "error" and a "bad choice" isn't all that interesting to me" I definitely wouldn't agree personally, but to each their own. " and this approach more or less makes it meaningless to criticize the design of literally anything." I can't fathom why you think this. All i answered is what the difference between the two types of criticism are. The only problem with this criticism is that the author is trying to claim these things are objectively wrong, repeatedly, and they are not. In fact, the author doing that just makes the author look silly, for starters. I can't see why that would make it meaningless to criticize the design of anything. It would, IMHO, be much better than current situation where the author pretends his criticisms are not subjective, when they very clearly are. Remember that objective things are true for all observers. So the author presenting it this way also means they claim it can't be viewed another way. That's not exactly an invitation to a discussion about the tradeoffs. It would be perfectly reasonable for the author to say "I disagree with these choices for these reason, and i think my choices are better for these reasons". Awesome! Let's talk about it. It's like writing an article claiming that choosing random pivots in quicksort is an error versus choosing median of 3. Or even better, claiming that using median of 3 is an error compared to median of median of 3. They aren't errors, and claiming they are is honestly not a very useful criticism.
  - philwelch 9y ago
    So, let me provide another example. Let's say I write a C compiler. The C specification says that certain things have "undefined behavior", which technically means the program could do anything. So my C compiler somehow outputs programs where many of these "undefined behaviors" actually result in reformatting the hard drive. If you define "error" by "deviating from a written specification", this is not technically an error, because "undefined behavior" can be anything. Yet, if someone actually used my underhanded C compiler to compile mission-critical production software, I feel comfortable characterizing that as an objectively bad decision--and so would the soon-former employer of that poor fool. You might say my example is contrived, and so is yours, so where does the truth lie? I think it goes back to my original point: it is strictly better to have thorough documentation than not to, and it is also strictly better for a language to have a defined grammar to support linters and the like than not to. Semantic quibbling about what is an "error" and what is "objectively wrong" aside--I think all (reasonable) observers would agree with these two points, which brings them as close to objective truth as we can get as far as this question is concerned.

philwelch 9y ago

> Think of it this way: It is almost always strictly better to use O(N) sort algorithms instead of N^2 ones. That does not make it an error to use an N^2 one, just a bad choice. The distinction between an "error" and a "bad choice" isn't all that interesting to me, and this approach more or less makes it meaningless to criticize the design of literally anything.

DannyBee 9y ago
"The distinction between an "error" and a "bad choice" isn't all that interesting to me" I definitely wouldn't agree personally, but to each their own. " and this approach more or less makes it meaningless to criticize the design of literally anything." I can't fathom why you think this. All i answered is what the difference between the two types of criticism are. The only problem with this criticism is that the author is trying to claim these things are objectively wrong, repeatedly, and they are not. In fact, the author doing that just makes the author look silly, for starters. I can't see why that would make it meaningless to criticize the design of anything. It would, IMHO, be much better than current situation where the author pretends his criticisms are not subjective, when they very clearly are. Remember that objective things are true for all observers. So the author presenting it this way also means they claim it can't be viewed another way. That's not exactly an invitation to a discussion about the tradeoffs. It would be perfectly reasonable for the author to say "I disagree with these choices for these reason, and i think my choices are better for these reasons". Awesome! Let's talk about it. It's like writing an article claiming that choosing random pivots in quicksort is an error versus choosing median of 3. Or even better, claiming that using median of 3 is an error compared to median of median of 3. They aren't errors, and claiming they are is honestly not a very useful criticism.
- philwelch 9y ago
  So, let me provide another example. Let's say I write a C compiler. The C specification says that certain things have "undefined behavior", which technically means the program could do anything. So my C compiler somehow outputs programs where many of these "undefined behaviors" actually result in reformatting the hard drive. If you define "error" by "deviating from a written specification", this is not technically an error, because "undefined behavior" can be anything. Yet, if someone actually used my underhanded C compiler to compile mission-critical production software, I feel comfortable characterizing that as an objectively bad decision--and so would the soon-former employer of that poor fool. You might say my example is contrived, and so is yours, so where does the truth lie? I think it goes back to my original point: it is strictly better to have thorough documentation than not to, and it is also strictly better for a language to have a defined grammar to support linters and the like than not to. Semantic quibbling about what is an "error" and what is "objectively wrong" aside--I think all (reasonable) observers would agree with these two points, which brings them as close to objective truth as we can get as far as this question is concerned.