|
Is it really true that static types reduce over-all bug density? Types deemed extraneous
|
|
|
|
|
Someone wrote: Is it really true that static types reduce over-all bug density?
No, it's diligence on the part of the developers(s) that does that.
|
|
|
|
|
TDD can effectively cut your shipping bug density in half
TDD is an artifact of using non-static, dynamically typed scripting languages, because you can't tell if the code will even run unless you, well, run it. What non-static, dynamically typed languages have done is created a whole new class of bugs, specifically type error bugs, that don't exist in statically typed languages because they are compiler errors, not runtime "bugs."
Granted, TDD, has other merits, but one thing that you will not see in a statically typed language are unit tests to verify that the code "simply runs", which is the first, if not the most predominant, form of unit test you'll see in non-static, dynamically typed scripted languages. Unless the person writing the unit test doesn't know what they are doing, or, more than likely, come to languages like C# from Python/Ruby/Javascript experience.
From my personal experience with Ruby, Python, and Javascript is that I waste considerably more time either writing unit tests or being a human unit test, and then fixing stupid type and syntax errors, than I ever have when I writing C, C#, C++, Pascal, or even assembly language code.
Marc
|
|
|
|
|
I absolutely disagree. While essential in dynamically typed languages, TDD is still a useful discipline in statically typed languages. Its saved my arse many times - especially detecting that changes in the code base have had unintended side effects.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: TDD is still a useful discipline in statically typed languages.
I didn't intend to disagree with the benefits of TDD in statically typed languages, though it seems it came across that way.
Marc
|
|
|
|
|
The "bug density graph" (how did they came up with it btw?) seems wrong... How did they came up with it?
And "53.62" "density" for C++.. what does that even mean?
However complicated I think C++ can be, I don't believe well maintained big open source project (say KDE) has 1 bug every 2 lines (53.62 "density"), that's ludicrous!
I know I have way more bug in my Javascript code than in my C# code for example (we could substitute C# for java in the graph< I suppose)
And many C++ error would be pointer problem I presume, which has nothing to do with strong typing...
|
|
|
|
|
|
tanks for the finding!
and confirmation of the foolishness of this ludicrous article!
|
|
|
|
|
“A developer’s job is to build — build it fast and build it right.” Let's go back to kLoC, it's so useful
|
|
|
|
|
Kent Sharkey wrote: kLoC, it's so useful
The
frack
it
is
.
|
|
|
|
|
I was hoping you'd notice that one
TTFN - Kent
|
|
|
|
|
|
Kent Sharkey wrote: Let's go back to kLoC, it's so useful
And why not? But the metric should be:
1) have you implemented the requirement in the least lines of code...
2) and, where applicable, as a re-usable component, and...
3) in a generic enough way that it can handle other use cases...
4) considering possible performance impacts...
5) as well as, where applicable, being thread safe...
6) with a clean separation of concerns...
7) and in a way that makes it easily to replace dependencies as well as being replaceable itself,
8) and did you implement any code contracts...
9) write unit tests for the any complicated stuff...
10) and write some helpful documentation as to why you're solving the problem the way you did.
So:
I guess that's too complicated for most managers to figure out when they do a performance review...
Thus:
Performance reviews are BS anyways, because nobody actually considers 1-10.
Which leads us down the rabbit hole of "peer" performance reviews, something the Holacracy[^] folks try to do. I've never participated in such an environment, so I have no idea if that actually works well. I came close once, but it was Ruby on Rails, and by the time the interview process was over, I was really glad I didn't get the job.
Marc
|
|
|
|
|
Speaking at the Converge conference in Hong Kong this week, Microsoft's Peggy Johnson revealed that the company will continue to build software for cars rather than create vehicles. Your car has been upgraded. It will reboot in 20 seconds. (Hope you're not on the highway)
|
|
|
|
|
Hmmm yes, the Microsoft car - where the blue screen of death really means what it says.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
Mobile use, support via WebAssembly, and many imaginative options are in in the works for the popular object-oriented language "Our chief weapon is surprise...surprise and fear"
|
|
|
|
|
Kent Sharkey wrote: the popular object-oriented language
Python is not an object oriented language. It is, at best, a "method wrapper" language, distinguishing between "functions" and "methods", functions which are wrapped in a class.
Python:
- Method overloading: Nope, because how can you overload a method with different type parameters in languages that are dynamically typed?
- Visibility: Everything is public, unless you think prefixing your class members with __ so that they are name mangled counts as "private"
- Inheritance: In a dynamic language like Python, what's the point? You can simply implement a different duck, the ducks don't have to be derived from the same species. Maybe it sometimes makes it easier to re-use common functionality, but it's little better than a mix-in.
Marc
modified 5-Jun-16 19:13pm.
|
|
|
|
|
Of those points, only Visibility (encapsulation) is really an essential feature of an OO language.
Smalltalk, for example, doesn't support method overloading, and is dynamically typed. It supports Inheritance in much the same way as Python.
I hope you're not going to try and claim that Smalltalk isn't object-oriented?
It may be a better question to consider whether the languages you're more familar with are truly OO, after all Alan Kay (father of Smalltalk) did coin the term.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: (encapsulation) is really an essential feature of an OO language.
True, I new I was sticking my arse out in the wind.
Marc
|
|
|
|
|
After a lengthy meeting in March and subsequent discussions, the actual feature list is shaping up to offer C++ developers a lot more hand-holding in modern cloud-based environments. Let me guess: braces and semi-colons?
Maybe they'll finally add the interrobang as an operator?
|
|
|
|
|
Calling a game "hard" would seem to be a matter of personal judgement. Not so, according to an international team of computer scientists. At least that's how they're explaining why they play it all the time
Or:
"But Mom, I'm doing important research!"
|
|
|
|
|
Now, one of the the most advanced AI outfits, Google’s DeepMind, is taking safety measures in case human operators need to “take control of a robot that is misbehaving [that] may lead to irreversible consequences,” which I assume includes but is not limited to killing all humans. "I'm sorry, Dave. I'm afraid I can't do that."
|
|
|
|
|
The AI may find this "design flaw" and remove it smoothly with some mock-up
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
If I remember correctly, in the films the problems all started when humans tried to turn it off.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
It is called, in very technical jargon, a "power switch"
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|