3 ms·

Easily half of my java was type info. If the number of bugs in a program is proportional to the program length, by omitting the type info a python program has f

by lemming 15y ago

Easily half of my java was type info. If the number of bugs in a program is proportional to the program length, by omitting the type info a python program has fewer opportunities for bugs. You're kidding me, right?

smackfu 15y ago
That line alone makes the whole thing a joke.
dexen 15y ago
That's true and he is right; having the programmer juggle types is human compiler at work. The more a human is relied upon, the more bugs result. Let the machine (here: the compiler or interpreter) do the dirty work. Of course, there are distinct classes of errors that occur only when programmer off-load juggling types to the computer, but that by itself doesn't invalidate his stance -- those errors are less prolific than errors associated with doing all type work by hand.
- ootachi 15y ago
  Are we talking about compile-time or runtime errors here? I can accept that manifest typing leads to more compile-time errors, but the idea that it leads to more runtime errors is nonsense. Types constrain, statically, the set of values that are permissible at any program point. They strictly reduce the possibility of runtime errors.
  - smackfu 15y ago
    And since most Java programmers will be in Eclipse, compile-time errors are really typing-time errors, and you have auto-complete anyways.
kenjackson 15y ago
I was going to write almost the exact same response. It's like someone saying, "I stopped writing tests. Reduced the LOC by half. And with no tests, we actually find fewer bugs!"
- smackfu 15y ago
  "I stopped writing null checks, because they just added LOC and that increases the number of bugs."
  - icebraining 15y ago
    That would've been true, if it meant the author had switch to a language without null references. http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc...
- danenania 15y ago
  "I stopped writing tests. Reduced the LOC by half. And with no tests, we actually find fewer bugs!" This can be true to an extent. Tests are a tradeoff that can potentially give you better stability, yes, but at the cost of more development time, longer builds, costlier maintenance, and more surface area for bugs. Like types, tests are appropriate in some cases, overkill in others. Imo, a lot of web functionality, especially for prototypes, isn't sufficiently complicated or critical (i.e. life or death or responsible for millions) to warrant tests, and the threshold for types is higher. Also depends a lot on the size of your team and skill of developers. If you're producing code with few bugs to begin with, tests have less value. It's really all a matter of judgment and right-tool-for-the-job. Generalisms just aren't useful.

by lemming 15y ago

smackfu 15y ago

That line alone makes the whole thing a joke.

dexen 15y ago

That's true and he is right; having the programmer juggle types is human compiler at work. The more a human is relied upon, the more bugs result. Let the machine (here: the compiler or interpreter) do the dirty work. Of course, there are distinct classes of errors that occur only when programmer off-load juggling types to the computer, but that by itself doesn't invalidate his stance -- those errors are less prolific than errors associated with doing all type work by hand.

ootachi 15y ago
Are we talking about compile-time or runtime errors here? I can accept that manifest typing leads to more compile-time errors, but the idea that it leads to more runtime errors is nonsense. Types constrain, statically, the set of values that are permissible at any program point. They strictly reduce the possibility of runtime errors.
- smackfu 15y ago
  And since most Java programmers will be in Eclipse, compile-time errors are really typing-time errors, and you have auto-complete anyways.

kenjackson 15y ago

I was going to write almost the exact same response. It's like someone saying, "I stopped writing tests. Reduced the LOC by half. And with no tests, we actually find fewer bugs!"

smackfu 15y ago
"I stopped writing null checks, because they just added LOC and that increases the number of bugs."
- icebraining 15y ago
  That would've been true, if it meant the author had switch to a language without null references. http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc...
danenania 15y ago
"I stopped writing tests. Reduced the LOC by half. And with no tests, we actually find fewer bugs!" This can be true to an extent. Tests are a tradeoff that can potentially give you better stability, yes, but at the cost of more development time, longer builds, costlier maintenance, and more surface area for bugs. Like types, tests are appropriate in some cases, overkill in others. Imo, a lot of web functionality, especially for prototypes, isn't sufficiently complicated or critical (i.e. life or death or responsible for millions) to warrant tests, and the threshold for types is higher. Also depends a lot on the size of your team and skill of developers. If you're producing code with few bugs to begin with, tests have less value. It's really all a matter of judgment and right-tool-for-the-job. Generalisms just aren't useful.