Slashdot Mirror
Do Strongly Typed Languages Reduce Bugs? (acolyer.org)
"Static vs dynamic typing is always one of those topics that attracts passionately held positions," writes the Morning Paper -- reporting on an "encouraging" study that attempted to empirically evaluate the efficacy of statically-typed systems on mature, real-world code bases. The study was conducted by Christian Bird at Microsoft's "Research in Software Engineering" group with two researchers from University College London. Long-time Slashdot reader phantomfive writes:
This study looked at bugs found in open source Javascript code. Looking through the commit history, they enumerated the bugs that would have been caught if a more strongly typed language (like Typescript) had been used. They found that a strongly typed language would have reduced bugs by 15%.
Does this make you want to avoid Python?
Does this make you want to avoid Python?
Strong typing is nice when people learn coding for the first time. Then they need to learn to do it without. The metric "less bugs in some code" is meaningless, just as the metric "fell over less" is with driving a bike. When you cannot do without training wheels than there is either something seriously wrong with you or you stopped learning way to early. The same applies to strong typing.
In essence, people that need strong typing do not have what it takes to get everything else right. They should stay away from professional coding altogether.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This observation doesn't make me wish to ditch a programming language, but it does make me glad I do test-driven development.
Warning: This signature may offend some viewers.
That seems to imply that the number of bugs is (relatively) constant. Adding automatic bounds checking to a language prevents a whole category of bugs, particularly ones that can be quite nasty. Sure if you had only skillful and exceptionally careful programmers, you wouldn't get those types of bugs either, but that's wishful thinking in most cases.
If there is some truth to what you I suspect its for tangental reasons. I'd hypothesize that languages that solve many of those categories of errors have much lower barriers to entry and therefor you get more cowboys using them who are making other kinds of mistakes because they're idiots and not because a programmer must make some fixed number of mistakes somewhere. Those people wouldn't be trusted with languages that didn't prevent them from introducing certain types of bugs because they would be counter productive for their team and create more problems than they solve, but languages that cut down on the potential types of mistakes that can be made mean there are entire categories of bugs that they can't introduce and that they can probably be productive.
It's another old adage: "Make something foolproof and the universe will invent a better fool."
And I suspect there is no such law at all as it seems based on nothing.
Better languages do result in less bugs. They may open vectors for a different type of bug, but that does not mean they are as frequent or as dangerous.
Take memory management. One misstep and your program gets killed or crashes because it reads or writes from memory that does not belong to it. Very easy to do in some languages, while other languages completely eliminate this class of bugs. Of course poor memory management can then result in memory leaks, but it won't crash, and not all such problems become memory leaks.
Some languages also practically eliminate arbitrary code execution and injection attacks, making them inherently more secure, at the cost of having bounds checks compiled into your program. This again eliminates a whole class of problems and introduces no new problems (maybe performance problems, but those are not bugs).
Then there is code maintenance and refactoring, something which is near impossible with loose languages. This is often why is not even attempted, leaving your with a code base that, if not planned in excruciating detail, will wither away and die. Just look at all those Javascript frameworks that rise and fall and don't even try to maintain backwards compatibility... I think it is because they all turn into unmaintainable pieces of spaghetti code that no sane programmer wants to keep working on for long.
It happens often enough that people write hundreds of lines of new code in a compiled language and actually find it runs correctly the first time. Perhaps you haven't experienced it yet... I have on many occasions.
What is wrong with Typescript?
I used JS for some of my hobby projects, but then switched to TS.
I found that the compiler catches a LOT of bugs. Type-Os, incompatible type assignments, incomplete branching (not all cases covered). At the end I even switched on the NULL checking, and I was astonished how many possible problems were still hiding in my code with regards to possibly NULL objects...
During my use, I did not see any real drawback.
The dependency on the compiler (external tool) was of course a negative point, but I looked at the generated code and I found it good enough that at any point I could abandon using the compiler, and carry on in plain JS.
So what is you negative experience?
Two additional advantages of strongly typed languages: ability to use refactoring tools, and easier code maintenance - particularly in code reading to recover business logic.
I am currently working with a Python (sub)program, part of a large web system that I do not have access to. The data comes in in messages of an undocumented JSON format, so from beginning to end the type of a variable is whatever the type it is, and the name of the 'variable' is whatever the label string associated with the data was. It is very difficult to deduce what any part of the processing means.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
Personally, I think strong typing is vastly overrated and those that need it should not be coding professionally.
Oblig. car analogy: those who need road signs shouldn't be driving professionally.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
Refactoring came out from the Smalltalk subculture so the claim to usability of refactoring tools or the lack thereof appears dubious. Lack of documentation in APIs and protocols is a perennial problem, though.
Ezekiel 23:20
The answer is obvious that for identical code strong typing will reduce bugs. And yet does typing force people to write in ways that lead creating bugs?
More importantly why isn't there some gray scale on typing that I could slowly turn on as my program design matures?
-Wall
-Wall -Werror
-Wall -Werror -Wextra
Also when writing in C++ mark sloppy convenience functions and constructors as deprecated so the scale above will complain and force you to fix them when the program matures.
I prefer strongly, statically typed programming than programming in e.g. Python. Like even Java, which is in many ways a horrible language, is more understandable for me. You need to understand the importance of the first two and last two words in that sentence though.
Why is it better for me to catch stuff at compile time? Because I prefer it that way.
Why is it preferable for Pythonistae to do whatever they do? Because they prefer it that way.
I have a very intelligent and productive friend who loves Python and has no problem with the way it handles types. I find Python annoying and avoid it, partially for that reason. But what would it even mean for him to be "wrong", or for me to be "wrong", or for either of us to be "right"? Nothing, that's what.
Stop bitching at each other and having stupid arguments like the "other side" is trying to steal your toys or come in your ice-cream.
Oblig: "LambdaConf 2015 - Dynamic vs Static Having a Discussion without Sounding Like a Lunatic" https://www.youtube.com/watch?v=Uxl_X3zXVAM
If one uses Strongly Typed Languages, one gets fewer Strongly Typed Language errors; only.
Yes. And?
Catching type errors during compile is worlds better than finding at runtime, perhaps by an end user. Does it prevent logic errors, or memory leaks, or failure to sanitize inputs, or race conditions? No. It doesn't. So what?
If one uses a thermometer to check the temperature of cooked meat, one only reduces one type of infection vector. Are you suggesting the use of thermometers to check cooked meat isn't a good idea, because it won't prevent malaria or syphilis? Because that is how ridiculous your argument is.
Typing isn't programming. You're saving twenty minutes a month by not declaring your types, and you're losing an opportunity to catch bugs sooner.
If you're spending more than 10% of your time typing code, you're either disabled, in which case I'm sorry, or you're typing with your forehead.
Professional developers spend 95% of their time trying to figure out if the shitty, broken code they're staring at us a bug or an accidental feature.
Type checking dramatically reduces the ability to write code that silently fails in production, meaning you never have something to unfound for a year, by which time the users will depend on the broken behavior and you'll need to preserve it for the rest of your life.
The article shows javascript as buggy and untyped with 3 + "0" = "30" -- the classic stupid example.
Everyone likes to say that Perl is weekly typed, because "1.5" + 1 = 2.5.
Everyone is incorrect. Perl is very very very very strongly typed. Not the variables, the operators. Not the nouns, the verbs. Developer says "add these two variables", and perl adds them. Because the developer said so. If the developer said "concatenate these two variables" then perl will concatenate them. Every time.
That sounds strongly-typed to me. "3" + "1" = 4; 3 . 1 = "31". Every time.
I dare you to find out what perl does with 3 + "information". Go ahead. I dare you.
My point is this. Human beings don't care about type. An apple is an apple, and an orange is an orange, and I can eat them together, cook them into a sauce, bake a pie, cut them up, juice them, or put them into a basket. Whatever I tell you to do with them, you'll never respond with "but apples can't do that because they aren't oranges". Just bake the g.d. pie, because I told you to.
Now, if you can explain to me why any language would ever use the same symbol for "add" and "concatenate", then you're smarter than I am. For the life of me, I've spent 30 years trying to understand that one. What idiot makes one symbol do two things, and then builds the language to guess which one to do based on the values themselves, at the language-level no less? Idiotic.
One of my assignments at Apple was cleaning up a framework that had thirty or more coders over the previous ten years. The first time I ran it through the static analyzer, there were over six hundred issues identified. I tracked down and fixed all of them over the next couple of months in the process of cleaning up the code to build under LLVM and pass the App Store rules.
Most of the easier cases were things like parameters of the wrong type being passed to methods, which caused no problem at runtime and hadn't been spotted before for that reason. The more difficult ones were mistakes in memory handling, and in a lot of cases, I found myself saying "holy shit, GCC lets you do THAT?"
Comparing Obj-C to Swift, I would say that easily 90% or more of those bugs can't be written in Swift at all unless you resort to the UnsafeMutablePointer types, which put it right in your face that you're doing something dicey.
I was a huge fan of loose coupling for all the years I was an Obj-c developer, but today I spend almost no time in LLDB, since almost all of the mistakes I make writing Swift are caught at compile time.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."