8 ms·

> Why would you not want to know about these bugs immediately and fix them early in the development process? That's a good question. But enforcing your codebas

> Why would you not want to know about these bugs immediately and fix them early in the development process? That's a good question. But enforcing your codebase to be a Rubix cube you have to twist and turn until the static type checker says Yes is not trivial. Its a tax. The real question is whether that tax is worth it when your goal is purely business delivery and not something else (eg, intellectual stimulation). Is it? Writing unit tests and code review are other means to root out bugs. But they also come with a tax. When are they worth the tax and when are they not worth the tax? In some cases we judge they are. In other cases not. A statically typed language typically asks us to turn off our brain and apply type verification everywhere. In this way, statically typed languages wield type verification more like a religion than a tool.

pklausler 9y ago
You can fix your interface bugs early in the development process with the aid of a compiler, or you can fix them later manually at much greater expense. When the "tax" is so much cheaper than the consequences, not paying the tax is crazy.
- wellpast 9y ago
  But "interface bugs" are the least of our problems. As evidenced by most bug queues that I've peeked at.
  - willtim 9y ago
    No true. I have to try and reverse engineer types whenever I use JSON APIs. The documentation provides only "samples". I literally have to experiment to find out what works with no guarantee it will keep working.
  - always_good 9y ago
    I don't know about that. How about the simple interface of "shouldn't be null".
    - deleted 9y ago
      [deleted]
    - wellpast 9y ago
      If null pointer exceptions are the most of your problems then I think you're doing pretty well. In my experience NPEs are the easiest bugs to root out and fix.
      - willtim 9y ago
        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).
dragonwriter 9y ago
> A statically typed language typically asks us to turn off our brain and apply type verification everywhere No, it doesn't. People are not using Haskell because they want to turn off their brain.
- wellpast 9y ago
  Let me rephrase: A statically typed language typically asks us to redirect our brains from asking the question, "Is type verification really needed in this particular instance to deliver my business value?" to instead solving the type-checker puzzle du jour.
  - dragonwriter 9y ago
    Plenty of modern statically-typed languages have dynamic escape valves (and plenty of dynamically typed languages have opt-in static validation.) It's true that choosing to use a static language without a dynamic escape valve for a component constitutes making the decision that, for the pieces of that component, dynamic freedom isn't an option that needs further considered.
  - pyrale 9y ago
    This is effortless once you have experience[1]. Besides, understanding the type of your data is beneficial, and so is it to be able to use types as an exploratory tool in a codebase you don't know. [1] Just like having experience in editor shortcuts bear an initial cost to make you more productive forever...
    - wellpast 9y ago
      Which part is effortless? Solving the type checker puzzle, or asking whether type verification is truly needed in a particular given instance?
      - pyrale 9y ago
        Thinking in types. 95% of the time, the type checker silently validates my input and the remaining 5% of the time, the trouble I get is understanding valuable information. There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate.
willtim 9y ago
> turn off our brain and apply type verification everywhere ... type verification more like a religion than a tool. A statically typed language can allow us to use dynamic typing if we want. For example, using a map of variants as a query result. Programming with maps of variants is even perfectly possible and pleasant in Haskell. Dynamic typing is not unique to dynamic languages!
raiflip 9y ago
Honestly I've never understood this argument that choosing types is too complicated. Most often I've seen it come from people without much experience in statically typed languages and imagine that having to determine the type will be difficult. After becoming familiar with the code base or library, particularly with modern IDE's it's rarely taken more than 10 seconds to choose a type. When reading another person's code, it does take some time to map out the relationship between the classes, but unless your code is in one giant file/function/object you're going to have to figure that out anyway.
- christophilus 9y ago
  I've programmed professionally in statically typed languages for > 15 years. (C#, various VBs, C++, F# (which is rad), and lately TypeScript) I've also dabbled in Haskell, OCaml, Rust, and a whole lot more. In fact, outside of Clojure, I've never liked a dynamic language (and I've used a few professionally). So, I'm someone with plenty of static-language experience, and I am in the boat that types are more complicated, in some ways. Just today, I had to figure out how to wrangle TypeScript into a shape I needed (and wound up with a solution that I didn't like but which got me past the compiler errors and on to more important work). There is a cost. There is also a benefit. So the question is, what does the cost/benefit analysis yield? Regardless, Clojure is worth learning. It's an amazing language.
  - tome 9y ago
    > Just today, I had to figure out how to wrangle TypeScript into a shape I needed (and wound up with a solution that I didn't like but which got me past the compiler errors and on to more important work). It would be really interesting, and indeed probably the most valuable contribution to this whole discussion, if you could write up what the problem was and why it wouldn't have occurred in Clojure!
- wellpast 9y ago
  From Rich's talk: "Now at this point I was an expert C++ user and really loved C++, for some value of love." Rich has had many years of experience in statically typed language.

pklausler 9y ago

You can fix your interface bugs early in the development process with the aid of a compiler, or you can fix them later manually at much greater expense. When the "tax" is so much cheaper than the consequences, not paying the tax is crazy.

wellpast 9y ago
But "interface bugs" are the least of our problems. As evidenced by most bug queues that I've peeked at.
- willtim 9y ago
  No true. I have to try and reverse engineer types whenever I use JSON APIs. The documentation provides only "samples". I literally have to experiment to find out what works with no guarantee it will keep working.
- always_good 9y ago
  I don't know about that. How about the simple interface of "shouldn't be null".
  - deleted 9y ago
    [deleted]
  - wellpast 9y ago
    If null pointer exceptions are the most of your problems then I think you're doing pretty well. In my experience NPEs are the easiest bugs to root out and fix.
    - willtim 9y ago
      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).

dragonwriter 9y ago

> A statically typed language typically asks us to turn off our brain and apply type verification everywhere No, it doesn't. People are not using Haskell because they want to turn off their brain.

wellpast 9y ago
Let me rephrase: A statically typed language typically asks us to redirect our brains from asking the question, "Is type verification really needed in this particular instance to deliver my business value?" to instead solving the type-checker puzzle du jour.
- dragonwriter 9y ago
  Plenty of modern statically-typed languages have dynamic escape valves (and plenty of dynamically typed languages have opt-in static validation.) It's true that choosing to use a static language without a dynamic escape valve for a component constitutes making the decision that, for the pieces of that component, dynamic freedom isn't an option that needs further considered.
- pyrale 9y ago
  This is effortless once you have experience[1]. Besides, understanding the type of your data is beneficial, and so is it to be able to use types as an exploratory tool in a codebase you don't know. [1] Just like having experience in editor shortcuts bear an initial cost to make you more productive forever...
  - wellpast 9y ago
    Which part is effortless? Solving the type checker puzzle, or asking whether type verification is truly needed in a particular given instance?
    - pyrale 9y ago
      Thinking in types. 95% of the time, the type checker silently validates my input and the remaining 5% of the time, the trouble I get is understanding valuable information. There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate.

willtim 9y ago

> turn off our brain and apply type verification everywhere ... type verification more like a religion than a tool. A statically typed language can allow us to use dynamic typing if we want. For example, using a map of variants as a query result. Programming with maps of variants is even perfectly possible and pleasant in Haskell. Dynamic typing is not unique to dynamic languages!

raiflip 9y ago

Honestly I've never understood this argument that choosing types is too complicated. Most often I've seen it come from people without much experience in statically typed languages and imagine that having to determine the type will be difficult. After becoming familiar with the code base or library, particularly with modern IDE's it's rarely taken more than 10 seconds to choose a type. When reading another person's code, it does take some time to map out the relationship between the classes, but unless your code is in one giant file/function/object you're going to have to figure that out anyway.

christophilus 9y ago
I've programmed professionally in statically typed languages for > 15 years. (C#, various VBs, C++, F# (which is rad), and lately TypeScript) I've also dabbled in Haskell, OCaml, Rust, and a whole lot more. In fact, outside of Clojure, I've never liked a dynamic language (and I've used a few professionally). So, I'm someone with plenty of static-language experience, and I am in the boat that types are more complicated, in some ways. Just today, I had to figure out how to wrangle TypeScript into a shape I needed (and wound up with a solution that I didn't like but which got me past the compiler errors and on to more important work). There is a cost. There is also a benefit. So the question is, what does the cost/benefit analysis yield? Regardless, Clojure is worth learning. It's an amazing language.
- tome 9y ago
  > Just today, I had to figure out how to wrangle TypeScript into a shape I needed (and wound up with a solution that I didn't like but which got me past the compiler errors and on to more important work). It would be really interesting, and indeed probably the most valuable contribution to this whole discussion, if you could write up what the problem was and why it wouldn't have occurred in Clojure!
wellpast 9y ago
From Rich's talk: "Now at this point I was an expert C++ user and really loved C++, for some value of love." Rich has had many years of experience in statically typed language.