6 ms·

I like to categorize many features that lower initial difficulty as "deferred technical debt." There are type system features that ensure a higher degree of cor

by wting 12y ago

I like to categorize many features that lower initial difficulty as "deferred technical debt." There are type system features that ensure a higher degree of correctness, but it's not fun debugging compiler errors when you're trying to get something working. For example, being forced to handle errors immediately via return codes or option types is not "fun". By comparison, exceptions act as a giant GOTO and no one blinks an eye. Dynamic typing is also another form of deferred technical debt. It is preferable to handle type errors at runtime or through testing instead of at compile time. People who claim very few bugs are a result of type errors typically do not have experience with ADTs or stronger type systems than Java / C++ / C.[0] > Most programmers think that getting run-time errors, and then using a debugger to find and fix those errors, is the normal way to program. They aren't aware that many of those errors can be detected by the compiler. And those that are aware, don't necessarily like that, because repairing bugs is challenging, and, well, sorta fun. I don't think this attitude has changed in the past 16 years. People prefer to debug a run time stack rather than deal with compile errors, perhaps even more so with the rise of dynamic languages. [0] Clojure community likes to argue that bugs arise from mutability more than type safety, but I don't have not experience to comment either way.

waps 12y ago
I disagree strongly with exception versus error codes. It sounds reasonable until you look at what real programmers (the kind that isn't perfect) will do and how it affects production code. Real life programmers don't know the stack up and down and haven't read the documentation for the stuff they use. They will not have thought through every possible error case. Sucks, but that's real life. So any solution that depends on either of those will simply fail. So there's 2 ways to have parts of your program signal errors to other parts. The question that matters is what will mediocre programmers do ? If you force em to give errors through return codes, they will flat-out ignore the errors. That means errors, and all meta-information about them (like which file it is that won't open, or which host doesn't respond, that sort of thing) disappears into a black hole. It MAY end up in some log file, or it may not. Crucially, sometimes it disappears into a logfile that is custom to the library being used (at least in C). Needless to say, you will have memory leaks when this happens, and you will have invalid state. It may also lead to crashes directly, if it doesn't it will lead to "delayed crashes" (like OOM), and all sorts of fun behavior (which is why some system engineers prefer direct crashes : it makes the point where the problem gets created easy to identify). If you give them exceptions they will not handle the exceptions, nor will they get try ... finally correct. This will lead to memory leaks and inconsistent data. And it may lead to program crashes, BUT crucially it will preserve the error that was originally detected, and log it in the main program, making fixing the error critical. Is this "deferred technical debt" ? I can understand your reasoning, but I think checked exceptions are a much, much better solution than return values. What I find especially irritating is the moronic attitude that testing somehow makes up for not having static types. I have never seen a program that has half the tests any statically typed language automatically executes. Not even once.
- ryanobjc 12y ago
  Yeah I totally agree here. There is a lot of hand wringing about hiring 'the best programmers' etc, but the reality is everyone is human and humans make mistake. Lets make the systems resilient to mistakes that humans make - strange how this seemingly simple statement is actually quite controversial around here! In truly large systems, all of the above happens and more. This is why error handling in C is so problematic, and why we toss it with Java. That go is bringing it back, is a little worrysome. Then again, go might be a hackers language, and might ultimately end up being the repository of write-once programs that aren't maintained.
- Dewie 12y ago
  > What I find especially irritating is the moronic attitude that testing somehow makes up for not having static types. Or that static types are useless, because "you will need to make unit tests, anyway". As if the static types don't save you from making a lot of unit tests. But I guess it's useless to wear a seatbelt, because if you crash head-on with semi-trailer you will die, anyway.
- wting 12y ago
  > I disagree strongly with exception versus error codes. It sounds reasonable until you look at what real programmers (the kind that isn't perfect) will do and how it affects production code. I prefer option types or checked exceptions, but mentioned return codes because Go is making them popular again. The most recent GnuTLS bug comes from an ignored return code: http://blog.bro.org/2014/03/dissecting-gnutls-bug.html http://blog.bro.org/2014/03/dissecting-gnutls-bug.html
Dewie 12y ago
> There are type system features that ensure a higher degree of correctness, but it's not fun debugging compiler errors when you're trying to get something working. > For example, being forced to handle errors immediately via return codes or option types is not "fun". > It is preferable to handle type errors at runtime or through testing instead of at compile time. Is that right.
- wting 12y ago
  Yeah, the wording kind of sucked there. It's better stated as, "Dynamic language users prefer to handle type errors at runtime or through testing instead of at compile time."
nnq 12y ago
> People prefer to debug a run time stack rather than deal with compile errors ...probably because most popular languages give you compiler errors that sound like "#@#E WTF @#@$ WTF2x @#/&^( WTF3x..." whereas a stack trace is something that one can easily follow and make some sense of even if you are just touching the languge for the first time.

by wting 12y ago

waps 12y ago

I disagree strongly with exception versus error codes. It sounds reasonable until you look at what real programmers (the kind that isn't perfect) will do and how it affects production code. Real life programmers don't know the stack up and down and haven't read the documentation for the stuff they use. They will not have thought through every possible error case. Sucks, but that's real life. So any solution that depends on either of those will simply fail. So there's 2 ways to have parts of your program signal errors to other parts. The question that matters is what will mediocre programmers do ? If you force em to give errors through return codes, they will flat-out ignore the errors. That means errors, and all meta-information about them (like which file it is that won't open, or which host doesn't respond, that sort of thing) disappears into a black hole. It MAY end up in some log file, or it may not. Crucially, sometimes it disappears into a logfile that is custom to the library being used (at least in C). Needless to say, you will have memory leaks when this happens, and you will have invalid state. It may also lead to crashes directly, if it doesn't it will lead to "delayed crashes" (like OOM), and all sorts of fun behavior (which is why some system engineers prefer direct crashes : it makes the point where the problem gets created easy to identify). If you give them exceptions they will not handle the exceptions, nor will they get try ... finally correct. This will lead to memory leaks and inconsistent data. And it may lead to program crashes, BUT crucially it will preserve the error that was originally detected, and log it in the main program, making fixing the error critical. Is this "deferred technical debt" ? I can understand your reasoning, but I think checked exceptions are a much, much better solution than return values. What I find especially irritating is the moronic attitude that testing somehow makes up for not having static types. I have never seen a program that has half the tests any statically typed language automatically executes. Not even once.

ryanobjc 12y ago
Yeah I totally agree here. There is a lot of hand wringing about hiring 'the best programmers' etc, but the reality is everyone is human and humans make mistake. Lets make the systems resilient to mistakes that humans make - strange how this seemingly simple statement is actually quite controversial around here! In truly large systems, all of the above happens and more. This is why error handling in C is so problematic, and why we toss it with Java. That go is bringing it back, is a little worrysome. Then again, go might be a hackers language, and might ultimately end up being the repository of write-once programs that aren't maintained.
Dewie 12y ago
> What I find especially irritating is the moronic attitude that testing somehow makes up for not having static types. Or that static types are useless, because "you will need to make unit tests, anyway". As if the static types don't save you from making a lot of unit tests. But I guess it's useless to wear a seatbelt, because if you crash head-on with semi-trailer you will die, anyway.
wting 12y ago
> I disagree strongly with exception versus error codes. It sounds reasonable until you look at what real programmers (the kind that isn't perfect) will do and how it affects production code. I prefer option types or checked exceptions, but mentioned return codes because Go is making them popular again. The most recent GnuTLS bug comes from an ignored return code: http://blog.bro.org/2014/03/dissecting-gnutls-bug.html http://blog.bro.org/2014/03/dissecting-gnutls-bug.html

Dewie 12y ago

> There are type system features that ensure a higher degree of correctness, but it's not fun debugging compiler errors when you're trying to get something working. > For example, being forced to handle errors immediately via return codes or option types is not "fun". > It is preferable to handle type errors at runtime or through testing instead of at compile time. Is that right.

wting 12y ago
Yeah, the wording kind of sucked there. It's better stated as, "Dynamic language users prefer to handle type errors at runtime or through testing instead of at compile time."

nnq 12y ago

> People prefer to debug a run time stack rather than deal with compile errors ...probably because most popular languages give you compiler errors that sound like "#@#E WTF @#@$ WTF2x @#/&^( WTF3x..." whereas a stack trace is something that one can easily follow and make some sense of even if you are just touching the languge for the first time.