4 ms·
I agree. I don't understand why people say things like "You can create bugs and make mistakes in any language." That's not the issue. The issue is how likely so
by cgmg 9y ago
I agree. I don't understand why people say things like "You can create bugs and make mistakes in any language." That's not the issue. The issue is how likely someone is to make mistakes in that language, and whether the way the language is designed makes it easier to shoot yourself in the foot.
- chrisco255 9y agoPlease read "The Shocking Truth about static Types" by Eric Elliott, which includes links to studies on bug density by programming language. JavaScript is in the middle of the pack, and programs built on JS are on average less buggy than C++ and Java. https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 https://medium.com/javascript-scene/the-shocking-secret-abou...
- cgmg 9y agoI didn't didn't mean to imply JS was more or less buggy than C++ or Java. Regarding the article you linked to, I recommend reading the discussion in the comments section (https://medium.com/@oxymor0n/eric-9f4869bb0ecb https://medium.com/@oxymor0n/eric-9f4869bb0ecb). The UC Davis paper, for example, concludes: "...language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat better than dynamic typing. "This is strong evidence that functional static languages are less error prone than functional dynamic languages … In order to strengthen this assertion we recode the model as above using treatment coding and observe that the Functional-Static-Strong-Managed language class is significantly less defect prone than the Functional-Dynamic-Strong-Managed language class with p = 0.034."
- danek 9y agoI read the studies he cited and I'm not sure we can conclude anything from them. As far as I can tell, "bug density by language" is not a thing you can measure in a meaningful way. It depends on the specific programmers at a specific point in their career, their skill level, domain knowledge for the project, scope of project, who the project manager is, their culture of testing, etc. For example a great JavaScript programmer will make a less buggy program than a mediocre c++ programmer. There is no silver bullet, though the article tries to pass off TDD as one. Also he does concede that static types can power tooling that might "feel like they make us more productive". Disclaimer: I prefer having types but I also think JavaScript is great and don't shy away from using it.
- chrisco255 9y agoI agree with all your points. I think, if anything, the study should show that JS is not inherently worse than any other language. It's got a bad rap, that mostly has to do with weird quirks in the language (i.e. == vs ===), but those quirks are easy to avoid. I do think testing in general is a good way to build more reliable programs.
- danek 9y agoYes, testing along with strict linter settings goes a long way.
- seanwilson 9y agoI didn't find that convincing at all and most studies like this are full of issues because coder productivity is notoriously hard to measure. The graph of bugs per language is just a simple count of how many GitHub issues were labelled "bug" which isn't meaningful. I don't even know why you need a study for this anyway. Working in a language where it's impossible to mix up strings and numbers, impossible to call a function with the wrong number of arguments etc. leads to less bugs by definition. Do you really need a study to prove you're more productive and your code is more secure in a language where mixing up types is impossible compared to using a language that lets you make that mistake? You can write secure code in assembly if you want but you're just making life hard for yourself.
- 13years 9y agoStudies are important simply because reality is often counter intuitive to theory.
- danek 9y agoThis is true but a study is useless if it can't measure the thing you want. Things in programming are notoriously difficult to quantify, compared to say, stuff in physics. Perhaps it's why there are so many holy wars.
- seanwilson 9y ago> This is true but a study is useless if it can't measure the thing you want. This is my point really. A misleading study is worse than no study as people use it to back up their points with a false air of legitimacy.
- chrisco255 9y agoHaving worked with JS for years, even with large teams, I can tell you that type errors are relatively rare. They happen, sure, but they are a small minority of overall bugs that are possible to generate in any program. Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type errors that after all, generally only come from incorrectly calling a function. I think JS code tends to be simpler than equivalent Java code and in my opinion, the simplicity of JS offsets its lack of explicit types. "Simplicity is prerequisite for reliability." -Dijkstra
- Matachines 9y agoEric Elliott is a joke even in the JS community.
- chrisco255 9y agoDude, don't know what the ad hominem is all about, but if you have rational arguments to dispute the studies by UC Davis or the methodology behind Lebrero's bug count analysis, I'd love to hear them.
- dangerface 9y agoFair point but I have tried more programming languages than I can list "the way the language is designed makes it easier to shoot yourself in the foot" is a fairly accurate description for all of them.