5 ms·

I've been programming for 40 years and I agree. Strong typing has a religious quality. You have to believe that most errors are caused by type mismatch, and I s

I've been programming for 40 years and I agree. Strong typing has a religious quality. You have to believe that most errors are caused by type mismatch, and I simply don't believe that. Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc.

kd913 6y ago
Why is it one or the other? Type errors also certainly occur. If you eliminate a class of errors by doing so, isn't that still less errors overall?
ctrl-j 6y ago
I like typescript not because it prevents most errors in my code, but because it prevents some errors. Those errors, in my experience, tend to be ones that are time consuming to identify and solve. A value of the wrong type passed forward because it's almost the right type can cause errors that make their way into production. I hear you say "so unit test your code!", and to that I reply, we're a c# shop that has only recently started pushing some of our code to the client. If you can convince management that we should shift our paradigm to allow for the time to write tests that don't add much to the sprint we're in, I can send you their email address. The fact is, a large portion of unit tests solve the same problems that strong types solve.
- Rapzid 6y ago
  I've spent more time helping people hunt down "undefined is not a function" and "Cannot read property of undefined" than just about anything else. Two observations from this: 1.) The fact that I even got involved meant the issues were particularly hard to track down 2.) These errors seem to be more of a time sync within a larger team/project than many realize Typically these were caused by either scope issues and/or some context object that's been riding dirty all day. In the case of the latter hunting down the code that did the naughty can be particularly soul crushing.
elmo2you 6y ago
I have a little less experience, only 30 years, but I have to fully agree with you. Not sure why you got down voted (maybe the religious popularity crowd rearing its head). I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (and the class of bugs they prevent) do not outweigh the usually larger code size (and often even additional complexity). Maybe I've just tried the wrong languages, but I was never convinced of the great improvements usually promised. At the same time, I have seen other people twist and jump through hoops, while vigorously holding on to their conviction how all that is an improvement. Sure, some errors will move from run time to compile time with typed languages. But if those are a systemic problem in your code, you probably have even bigger things to worry about (the ones you already keenly pointed out). From a cynical point of view, I can understand why corporate entities would love typed languages (for the increased code size and complexity), but that's another story.
- balfirevic 6y ago
  > Not sure why you got down voted For the (pretty obvious) logical error of claiming that you have to believe that most errors are caused by type mismatch to consider stating typing beneficial.
- jondubois 6y ago
  I have 15 years of development experience (including a lot of spare time spent on open source projects) and I also agree word-for-word.
say-vagnes 6y ago
It's not about most errors being due to type mismatch, as much as it is about being able to model your domain. By having types, you open the door to formally describing the building blocks of your system. This lets you create very specific, well understood, pure pieces that then are composed together to bring about your desired functionality. Why rely on documentation that a compiler cannot statically verify, as opposed to a type (annotation or otherwise) that can? I think you're correct regarding your "most errors are caused by" comment, and no programming paradigm will ever get rid of these - you can always find a way to write bad code. And you are also correct that there are type zealots out there who create beautiful prisons they call abstractions. But at the end of the day, types are a tool, and while I'd highly recommend learning them, I also recognize some projects and teams will never make use of them.
eyerony 6y ago
> poor documentation Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong.
- tome 6y ago
  > > poor documentation > Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong. Absolutely, and I'd go further: "Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc" Good static types (a la Hindley-Milner) encourage good architecture, serve is documentation that cannot go stale, and encourage good communication strategies between different parts of a codebase.

kd913 6y ago

Why is it one or the other? Type errors also certainly occur. If you eliminate a class of errors by doing so, isn't that still less errors overall?

ctrl-j 6y ago

I like typescript not because it prevents most errors in my code, but because it prevents some errors. Those errors, in my experience, tend to be ones that are time consuming to identify and solve. A value of the wrong type passed forward because it's almost the right type can cause errors that make their way into production. I hear you say "so unit test your code!", and to that I reply, we're a c# shop that has only recently started pushing some of our code to the client. If you can convince management that we should shift our paradigm to allow for the time to write tests that don't add much to the sprint we're in, I can send you their email address. The fact is, a large portion of unit tests solve the same problems that strong types solve.

Rapzid 6y ago
I've spent more time helping people hunt down "undefined is not a function" and "Cannot read property of undefined" than just about anything else. Two observations from this: 1.) The fact that I even got involved meant the issues were particularly hard to track down 2.) These errors seem to be more of a time sync within a larger team/project than many realize Typically these were caused by either scope issues and/or some context object that's been riding dirty all day. In the case of the latter hunting down the code that did the naughty can be particularly soul crushing.

elmo2you 6y ago

I have a little less experience, only 30 years, but I have to fully agree with you. Not sure why you got down voted (maybe the religious popularity crowd rearing its head). I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (and the class of bugs they prevent) do not outweigh the usually larger code size (and often even additional complexity). Maybe I've just tried the wrong languages, but I was never convinced of the great improvements usually promised. At the same time, I have seen other people twist and jump through hoops, while vigorously holding on to their conviction how all that is an improvement. Sure, some errors will move from run time to compile time with typed languages. But if those are a systemic problem in your code, you probably have even bigger things to worry about (the ones you already keenly pointed out). From a cynical point of view, I can understand why corporate entities would love typed languages (for the increased code size and complexity), but that's another story.

balfirevic 6y ago
> Not sure why you got down voted For the (pretty obvious) logical error of claiming that you have to believe that most errors are caused by type mismatch to consider stating typing beneficial.
jondubois 6y ago
I have 15 years of development experience (including a lot of spare time spent on open source projects) and I also agree word-for-word.

say-vagnes 6y ago

It's not about most errors being due to type mismatch, as much as it is about being able to model your domain. By having types, you open the door to formally describing the building blocks of your system. This lets you create very specific, well understood, pure pieces that then are composed together to bring about your desired functionality. Why rely on documentation that a compiler cannot statically verify, as opposed to a type (annotation or otherwise) that can? I think you're correct regarding your "most errors are caused by" comment, and no programming paradigm will ever get rid of these - you can always find a way to write bad code. And you are also correct that there are type zealots out there who create beautiful prisons they call abstractions. But at the end of the day, types are a tool, and while I'd highly recommend learning them, I also recognize some projects and teams will never make use of them.

eyerony 6y ago

> poor documentation Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong.

tome 6y ago
> > poor documentation > Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong. Absolutely, and I'd go further: "Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc" Good static types (a la Hindley-Milner) encourage good architecture, serve is documentation that cannot go stale, and encourage good communication strategies between different parts of a codebase.