4 ms·

The point is that NPEs are a solved problem, just not in Java and Clojure. I am better able to stay focused on the real problems, as I never have to root out an

The point is that NPEs are a solved problem, just not in Java and Clojure. I am better able to stay focused on the real problems, as I never have to root out and fix bugs like this.

wtetzner 9y ago
Not to mention that the ease of fixing the bug has little to do with the cost of the bug showing up in production.
- wellpast 9y ago
  I can do all kinds of things to prevent bugs showing up in production. I once worked on a mission-critical piece of software in which the entire team was brought in to do a page-by-page code review for all newly written code. Of course, the cost outweighs the benefit in this case for most industry software that can afford a few bugs at the extreme expense of (this kind of) code review. Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time? And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board.
  - wtetzner 9y ago
    > And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board. Yes, actually, I don't find these things to be a particularly high burden, and the benefit, in my experience, easily outweighs it. When you're writing code, you have to think about what kinds of things will be passed to a given function, whether the compiler checks it or not. So I find having the compiler check mundane things like this lowers my cognitive load, because I don't have to worry so much about what to do if I get a null (fail, handle it in some way, etc.). I will agree, though, that the style of programming with maps so prevalent in Clojure makes a lot of sense in some programs. However, even then, there is a typing discipline that fits (row types).
  - pklausler 9y ago
    Honest question: have you ever written a large computer program in a programming language descended from ML (SML, OCaml, Haskell, &c.)?
    - wellpast 9y ago
      No I haven't. And, depending on how long life turns out to be, maybe I'll get to. But. I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupling and imprecise semantics. These two problems are a function of the experience and training (and value system) of the programmer building them, and programming languages can do very little to save a system from these plights. (It might be that a static programming language can help here inasmuch as it slows down the programmer from producing too much code, but I realize that's arguable and also that I'm making a wicked joke.) Still. All computers ask is for semantic precision and you don't need a static type verification to get precision. So clearly static type verification is unnecessary for producing programs that work. And clearly statically-typed everywhere PLs are asking the programmer to do extra work. That's prima facie true. So the burden is really on the MLer/Haskeller to prove that that extra work is giving overall delivery throughput to the programming team. Maybe it is, maybe it isn't. But I'm waiting for the clearly thought out justification. Haven't heard it yet.
      - wtetzner 9y ago
        > And clearly statically-typed everywhere PLs are asking the programmer to do extra work. I'm not convinced this is entirely true. The kinds of information that you encode in types is the kind of information that's useful to anyone reading the code. And if that information isn't written down somewhere, then the person reading the code (maybe you sometime later) has to reconstruct it themselves. And if it's useful to write that kind of information down, why not have the computer check that it's consistent?
      - Tehnix 9y ago
        > All computers ask is for semantic precision and you don't need a static type verification to get precision. So clearly static type verification is unnecessary for producing programs that work That's a bit contrived. No matter which language you write in, at some step a type check will happen. For dynamic types its at runtime and for static types its at compile time. > And clearly statically-typed everywhere PLs are asking the programmer to do extra work. That's prima facie true. So the burden is really on the MLer/Haskeller to prove that that extra work is giving overall delivery throughput to the programming team. Maybe it is, maybe it isn't. But I'm waiting for the clearly thought out justification. Haven't heard it yet. Here are just a few of the real world accounts of using Haskell in production, you can check out: - The Joy and Agony of Haskell in Production: http://www.stephendiehl.com/posts/production.html http://www.stephendiehl.com/posts/production.html - Haskell is Not For Production and Other Tales: https://www.youtube.com/watch?v=mlTO510zO78 https://www.youtube.com/watch?v=mlTO510zO78 - Production Haskell - Reid Draper: https://www.youtube.com/watch?v=AZQLkkDXy68 https://www.youtube.com/watch?v=AZQLkkDXy68 If these didn't convince you, there are tons of Haskellers that will attest that the type system in the long run has quite substantial benefits.
  - tome 9y ago
    > Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time? Yes! > And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Oh god yes! Simple Hindley-Milner typing is so cheap to use it's almost free! > Most static programming languages force you (or make it hard for you not) to do this verification across the board. Well, not really. In Haskell, for better or for worse, you can still use `fromJust` even if it is considered rather naughty.

The point is that NPEs are a solved problem, just not in Java and Clojure. I am better able to stay focused on the real problems, as I never have to root out and fix bugs like this.

wtetzner 9y ago

Not to mention that the ease of fixing the bug has little to do with the cost of the bug showing up in production.

wellpast 9y ago
I can do all kinds of things to prevent bugs showing up in production. I once worked on a mission-critical piece of software in which the entire team was brought in to do a page-by-page code review for all newly written code. Of course, the cost outweighs the benefit in this case for most industry software that can afford a few bugs at the extreme expense of (this kind of) code review. Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time? And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board.
- wtetzner 9y ago
  > And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board. Yes, actually, I don't find these things to be a particularly high burden, and the benefit, in my experience, easily outweighs it. When you're writing code, you have to think about what kinds of things will be passed to a given function, whether the compiler checks it or not. So I find having the compiler check mundane things like this lowers my cognitive load, because I don't have to worry so much about what to do if I get a null (fail, handle it in some way, etc.). I will agree, though, that the style of programming with maps so prevalent in Clojure makes a lot of sense in some programs. However, even then, there is a typing discipline that fits (row types).
- pklausler 9y ago
  Honest question: have you ever written a large computer program in a programming language descended from ML (SML, OCaml, Haskell, &c.)?
  - wellpast 9y ago
    No I haven't. And, depending on how long life turns out to be, maybe I'll get to. But. I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupling and imprecise semantics. These two problems are a function of the experience and training (and value system) of the programmer building them, and programming languages can do very little to save a system from these plights. (It might be that a static programming language can help here inasmuch as it slows down the programmer from producing too much code, but I realize that's arguable and also that I'm making a wicked joke.) Still. All computers ask is for semantic precision and you don't need a static type verification to get precision. So clearly static type verification is unnecessary for producing programs that work. And clearly statically-typed everywhere PLs are asking the programmer to do extra work. That's prima facie true. So the burden is really on the MLer/Haskeller to prove that that extra work is giving overall delivery throughput to the programming team. Maybe it is, maybe it isn't. But I'm waiting for the clearly thought out justification. Haven't heard it yet.
    - wtetzner 9y ago
      > And clearly statically-typed everywhere PLs are asking the programmer to do extra work. I'm not convinced this is entirely true. The kinds of information that you encode in types is the kind of information that's useful to anyone reading the code. And if that information isn't written down somewhere, then the person reading the code (maybe you sometime later) has to reconstruct it themselves. And if it's useful to write that kind of information down, why not have the computer check that it's consistent?
    - Tehnix 9y ago
      > All computers ask is for semantic precision and you don't need a static type verification to get precision. So clearly static type verification is unnecessary for producing programs that work That's a bit contrived. No matter which language you write in, at some step a type check will happen. For dynamic types its at runtime and for static types its at compile time. > And clearly statically-typed everywhere PLs are asking the programmer to do extra work. That's prima facie true. So the burden is really on the MLer/Haskeller to prove that that extra work is giving overall delivery throughput to the programming team. Maybe it is, maybe it isn't. But I'm waiting for the clearly thought out justification. Haven't heard it yet. Here are just a few of the real world accounts of using Haskell in production, you can check out: - The Joy and Agony of Haskell in Production: http://www.stephendiehl.com/posts/production.html http://www.stephendiehl.com/posts/production.html - Haskell is Not For Production and Other Tales: https://www.youtube.com/watch?v=mlTO510zO78 https://www.youtube.com/watch?v=mlTO510zO78 - Production Haskell - Reid Draper: https://www.youtube.com/watch?v=AZQLkkDXy68 https://www.youtube.com/watch?v=AZQLkkDXy68 If these didn't convince you, there are tons of Haskellers that will attest that the type system in the long run has quite substantial benefits.
- tome 9y ago
  > Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time? Yes! > And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Oh god yes! Simple Hindley-Milner typing is so cheap to use it's almost free! > Most static programming languages force you (or make it hard for you not) to do this verification across the board. Well, not really. In Haskell, for better or for worse, you can still use `fromJust` even if it is considered rather naughty.