3 ms·

So the old adage stands: you can write crap in any language.

by narag 7y ago

TheOtherHobbes 7y ago
And if you do, chances are good it'll end up on GitHub. 5.3 and 5.4 really nail it, IMO. And you can't even use bug fixes as a metric, because there's a difference between semantic bugs which will be significantly language-influenced, architectural bugs which are partly language-influenced, and user-expectation/experience bugs, which are broad-brush logical errors or misunderstandings. (There are probably other categories, but those are the obvious ones I can think of right now.) The real takeaway is there is as yet no objective metric for software quality. The best a working dev shop can do is implement a small but non-trivial sample project with known-good logic in a handful of candidate languages, and see what kind of trade-offs fall out.
- jrumbut 7y ago
  I'll agree with you for sure no objective metric for quality (that is broad enough to capture a satisfying amount of what we mean by quality). I do think user experience/expectation bugs are very language dependent though. First you have the quality of the String and Datetime libraries. Ruby has all kinds of high quality string functions that are a source of pain and bugs in C. Say your project wants to display the different between two datetimes as "5 minutes ago" or "last month" (in several languages). Saying "1.27 days ago" is correct to an extent but also not pretty. There exist high quality libraries for this, but not in every language, and a lot of devs would stumble on this feature. The other is UI creation, I would say it is easier and faster to create a really nice UI with HTML/CSS/JS than with native Android. Maybe I'm wrong on this example but I bet there is a pair of UI frameworks where this is true.
- mark-r 7y ago
  > user-expectation/experience bugs I consider those to be bugs in the spec, not the code. I once worked at a place that simply swept those under the rug - if it worked as documented, it didn't matter how many users couldn't get it to work. The bug report was closed as "not a bug"; you can imagine how frustrating that was.

So the old adage stands: you can write crap in any language.

by narag 7y ago

So the old adage stands: you can write crap in any language.

And if you do, chances are good it'll end up on GitHub. 5.3 and 5.4 really nail it, IMO. And you can't even use bug fixes as a metric, because there's a difference between semantic bugs which will be significantly language-influenced, architectural bugs which are partly language-influenced, and user-expectation/experience bugs, which are broad-brush logical errors or misunderstandings. (There are probably other categories, but those are the obvious ones I can think of right now.) The real takeaway is there is as yet no objective metric for software quality. The best a working dev shop can do is implement a small but non-trivial sample project with known-good logic in a handful of candidate languages, and see what kind of trade-offs fall out.

jrumbut 7y ago
I'll agree with you for sure no objective metric for quality (that is broad enough to capture a satisfying amount of what we mean by quality). I do think user experience/expectation bugs are very language dependent though. First you have the quality of the String and Datetime libraries. Ruby has all kinds of high quality string functions that are a source of pain and bugs in C. Say your project wants to display the different between two datetimes as "5 minutes ago" or "last month" (in several languages). Saying "1.27 days ago" is correct to an extent but also not pretty. There exist high quality libraries for this, but not in every language, and a lot of devs would stumble on this feature. The other is UI creation, I would say it is easier and faster to create a really nice UI with HTML/CSS/JS than with native Android. Maybe I'm wrong on this example but I bet there is a pair of UI frameworks where this is true.
mark-r 7y ago
> user-expectation/experience bugs I consider those to be bugs in the spec, not the code. I once worked at a place that simply swept those under the rug - if it worked as documented, it didn't matter how many users couldn't get it to work. The bug report was closed as "not a bug"; you can imagine how frustrating that was.