6 ms·

But at its best (as in Haskell), static typing just means that the compiler is enforcing the requirements of your interfaces. Why would you not want to know ab

But at its best (as in Haskell), static typing just means that the compiler is enforcing the requirements of your interfaces. Why would you not want to know about these bugs immediately and fix them early in the development process when it's cheap to do? Why wouldn't you want the compiler recheck everything automatically every time you change your interfaces? Everybody's always fixing bugs. Static typing makes it more likely that the bugs you're working on are closer to the problem domain, instead of being crap work that should have been caught at compilation time with better languages and compilers.

wellpast 9y ago
> 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.
- 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.
jernfrost 9y ago
I see the value of statically typed languages as I've used Swift quite a lot and quite like it. It is way more strict than say Java and C++. However when I compare my coding with Swift to the dynamic language Julia, it is way more fun and fast to write Julia code. Up to a certain point of course. As I pass about 1000 lines of code I start feeling a bit uncomfortable about the lack of static type checking to catch my changes. However this is mostly down to me being lazy and not bothering to write tests. I've spend some time with Haskell, and tried writing some code for a simple geometry library in Haskell. Quite cool language, but I could write the same code in much fewer lines in Julia and much faster. Haskell has just too much mental overhead. It requires far more investment than other languages to learn and I've learned plenty. Nothing has required as much effort as Haskell. Despite the effort I never felt like I could write any real and practical programs with it. I honestly think the Haskell fan club is slightly deluded. If Haskell was truly as amazing as they think, we ought to have seen a lot more amazing software being made in Haskell. We don't. Far more interesting things seems to have been done in newer languages such as Go, Rust, Swift and Julia. That ought to be a hint that Haskell isn't quite the silver bullet that the fan club thinks it is.
- Tehnix 9y ago
  > Up to a certain point of course. As I pass about 1000 lines of code I start feeling a bit uncomfortable about the lack of static type checking to catch my changes. This is indeed where statically typed languages come in to shine - refactoring and maintenance. With a powerful type system you can be much more assured that your refactors or small/big changes here and there don't break the whole system or unexercised parts of it. > It requires far more investment than other languages to learn and I've learned plenty. Nothing has required as much effort as Haskell. Despite the effort I never felt like I could write any real and practical programs with it. That's often attributed to the fact that Haskell isn't just another syntax slapped on an Algol-like language. It's not just different syntax (ML-style), but an entirely different approach to programming. This often leaves experienced programmers frustrated with the experience that they are starting from scratch (without realising that, that is what they are doing). Some nice advice is giving by Gabriel Gonzales here http://www.haskellforall.com/2017/10/advice-for-haskell-beginners.html http://www.haskellforall.com/2017/10/advice-for-haskell-begi.... > I honestly think the Haskell fan club is slightly deluded. If Haskell was truly as amazing as they think, we ought to have seen a lot more amazing software being made in Haskell We have a lot of amazing software in Haskell already, e.g. Facebooks Haxl, Pandoc, QuickCheck, Yesod, Servant and many more. The argument that Haskell isn't doing stuff right because we don't see it everywhere is quite silly. By that metric PHP would be the best designed language ever...

wellpast 9y ago

> 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.
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.

jernfrost 9y ago

I see the value of statically typed languages as I've used Swift quite a lot and quite like it. It is way more strict than say Java and C++. However when I compare my coding with Swift to the dynamic language Julia, it is way more fun and fast to write Julia code. Up to a certain point of course. As I pass about 1000 lines of code I start feeling a bit uncomfortable about the lack of static type checking to catch my changes. However this is mostly down to me being lazy and not bothering to write tests. I've spend some time with Haskell, and tried writing some code for a simple geometry library in Haskell. Quite cool language, but I could write the same code in much fewer lines in Julia and much faster. Haskell has just too much mental overhead. It requires far more investment than other languages to learn and I've learned plenty. Nothing has required as much effort as Haskell. Despite the effort I never felt like I could write any real and practical programs with it. I honestly think the Haskell fan club is slightly deluded. If Haskell was truly as amazing as they think, we ought to have seen a lot more amazing software being made in Haskell. We don't. Far more interesting things seems to have been done in newer languages such as Go, Rust, Swift and Julia. That ought to be a hint that Haskell isn't quite the silver bullet that the fan club thinks it is.

Tehnix 9y ago
> Up to a certain point of course. As I pass about 1000 lines of code I start feeling a bit uncomfortable about the lack of static type checking to catch my changes. This is indeed where statically typed languages come in to shine - refactoring and maintenance. With a powerful type system you can be much more assured that your refactors or small/big changes here and there don't break the whole system or unexercised parts of it. > It requires far more investment than other languages to learn and I've learned plenty. Nothing has required as much effort as Haskell. Despite the effort I never felt like I could write any real and practical programs with it. That's often attributed to the fact that Haskell isn't just another syntax slapped on an Algol-like language. It's not just different syntax (ML-style), but an entirely different approach to programming. This often leaves experienced programmers frustrated with the experience that they are starting from scratch (without realising that, that is what they are doing). Some nice advice is giving by Gabriel Gonzales here http://www.haskellforall.com/2017/10/advice-for-haskell-beginners.html http://www.haskellforall.com/2017/10/advice-for-haskell-begi.... > I honestly think the Haskell fan club is slightly deluded. If Haskell was truly as amazing as they think, we ought to have seen a lot more amazing software being made in Haskell We have a lot of amazing software in Haskell already, e.g. Facebooks Haxl, Pandoc, QuickCheck, Yesod, Servant and many more. The argument that Haskell isn't doing stuff right because we don't see it everywhere is quite silly. By that metric PHP would be the best designed language ever...