> significantly increases bug count per delivered software feature.
Going to need a source for this.
Going to need a source for this.
You can easily find information on duck typed programs being significantly shorter and that statically typed and ducked typed programs have the same bug count per line. You can also look at the language defective tables showing ducked type Clojure as having the least bugs in commerical software and statically typed C++ having the most bugs in commerical software.
Google is your friend here.
"Number of bugs will drastically increase" is simply wrong.
Type checking prevents bugs before they ship.
Type checking mostly shows that code can be compiled successfully. The thing it was designed to do.
i've read some of these studies, they don't prove much. it's typically languages with inexpressive type systems like java.
>Type checking mostly shows that code can be compiled successfully. The thing it was designed to do.
what languages are you thinking of when you say things like this? these debates are useless because one person is thinking of the type system of language X and the other person is thinking of language Y. a lot of heat but little light.
I don't see how e.g. [1] or [2] are "falling flat on their faces".
[1] https://fsharpforfunandprofit.com/posts/designing-with-types...
[2] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
or even something as basic as non-nullable types, enforced at compile time. a clear, obvious win.
The duck typed code is also significantly shorter, less lines of code per software feature means less bugs per released software feature.
It's very difficult to compete against just having less code. You only needed to write 1000 lines of code instead of 3000 lines of code? Then you just eliminated 66% of the bugs.
Static typing on the other hand catches less than 1% of bugs.
So you can go for the duck typing approach and remove 66% of the bugs in your code or the static typing approach and remove 1% of the bugs in your code.
Which approach do you think works better?
If you're not going to bring bold numbers to support bold claims, why should any of us bother listening?
I mean you could always try to find some sources to try and prove me wrong if you want?
"I mean you could always try to find some sources to try and prove me wrong if you want? "
That's not really how it works though. If you make a claim, either you back-it up or it's irrelevant.
Case and point: I believe that a flying tea pot created the universe. By your logic I am right and it should be up to you to prove me wrong.
So to conclude this argument, if you are correct, you should prove it as the person who responded to you asked you to do.
Failing that,your comment goes back to being nothing more than your opinion instead of a fact.
If s/he thinks that what I'm saying is wrong so strongly then they can go back that up with something. They will obviously fail terribly because I'm correct but that is their choice.
I use python add my day job, and I hate writing and dealing with typing. I do admit it makes it easier to reason about other people's code though, especially when faced with libraries that don't have any hints.
Docstrings are usually a lot better than type hints for that purpose.
I could write "Humans have actually always had blue skin and hair, but due to a cosmic ray warping our ocular nervous response systems 1000 years ago, we now see humans the way we see them today". And I'd damn well hope someone would ask me to back this absurdity up with evidence.
... and thus: "lalalala I can't hear youuuuuuuuu over the sound of being right!" doesn't make for a good look, is basically what I'm telling you, and asking you to please either cite some sources, or stop doubling down on having to be right because you said so. This is such a ridiculous exchange I'd swear I was having it as an elementary school teacher.