4 ms·

> I'm always going to favor the option with the best static type system, because I know it's going to help me (and anyone else working on the system, especially

> I'm always going to favor the option with the best static type system, because I know it's going to help me (and anyone else working on the system, especially newbies) keep things sane This is the usual general claim from one arguing for using static type verification in a given situation, but this is pretty fuzzy statement, no? "Keep things sane." We need to have more clear reasons than that, don't we? In my view, the end goal in business is to optimize productivity throughput over time (i.e., make sure that we can deliver business value as quickly as possible.) But I realize this is not as simple as today's immediate throughput at tomorrow's throughput's expense. So there is this goal of keeping things maintainable (probably what you mean by "sane") -- but to be even more clear: it's productivity/delivery throughput we are talking about, no? And if that's the case then we have to really justify that the static type dance is truly giving us that overall throughput. How do you do that? What is your general decision process about when to introduce type verification and when not? To be specific, let's say I need to ensure that the value for my "title" doesn't ever exceed 80 characters. I imagine that even in Haskell you would make this a String, no? So you would defer that length constraint to dynamic validation/logic? (Correct me if I'm wrong.) Well, then why are you choosing dynamic verification in that case but for other cases like "publication-date" choosing to have the type checker verify that it is a proper date value? What is your criteria? In my experience programmers usually just do what is idiomatic or most convenient in their programming language. Okay there is a Date primitive, I will use that. There is no Title or MaxString<Length> primitive, so I will just use an unbounded String. In other words, it's not a like a reasoned choice. Which makes me think, in general, the reasoning behind using a static type language is more fuzzy than usual. But if you have even a loose criteria for why you pick static typing for a value versus doing the value's verification dynamically, what is that criteria?

tome 9y ago
> But if you have even a loose criteria for why you pick static typing for a value versus doing the value's verification dynamically, what is that criteria? The same as with the choice of anything: what feature to work on this week, whether to automate a process or keep it manual, whether to use JSON or BSON or Protocol Buffers ... It's a judgement call and it's not really possible to give a good answer in a Hacker News comment.
- wellpast 9y ago
  I agree 100% with this. So if what you're saying here is that in Haskell that this choice is mine, that I can always completely avoid having to choose static verification if I so choose (ie, I can get it a la carte), then that is just plain awesome. Is that what you are saying?
  - tome 9y ago
    > I can always completely avoid having to choose static verification if I so choose Well, yes, roughly, of course! You can always choose to use extremely broad types that give minimal guarantees, for example Scientific instead of Double or Int, String instead of MyPreciseErrorType, Map String Dynamic instead of MyPreciseRecordType ... You'll find the Haskell ecosystem is not really designed around that kind of programming because Haskellers don't really like it but it can easily be done, semantically. It will also be a bit awkward syntactically, but it's certainly possible. And then you can opt in to types (a la carte) later by replacing broader types with narrower ones as your project manager refines his specification. But that's not really the point. You can bolt on types to Clojure and you can bolt on dynamism to Haskell. My point is that I've almost always found it better to start in a strongly typed language, even when the requirements are changing rapidly.
    - wellpast 9y ago
      That is an interesting preference. I usually hear it the other way. That people would prefer to start dynamic when they understand the problem/domain the least and then move to static types when they become more sure about the taxonomy of things.
      - bitwalker 9y ago
        For me, fleshing out as much of the types/taxonomy as I can is one of the first things I do before coding towards a solution. Even if the first stab is rough, adjusting the types as knowledge of the domain grows has never been a point of friction for me - most of those changes are incremental, and having the compiler remind me the places I need to update (such as pattern matches) means I don't have to put any mental effort towards that. Even when the changes are significant, I'm still going to have to make basically all the same changes I would have had to make with no type system too. Having the compiler help me out during quick iteration means I can feel comfortable that I'm not forgetting to update areas of the code impacted by changes - when I get to where I want to be, I can be fairly sure I didn't miss anything. That comfort is something I value a lot more highly these days.

tome 9y ago

> But if you have even a loose criteria for why you pick static typing for a value versus doing the value's verification dynamically, what is that criteria? The same as with the choice of anything: what feature to work on this week, whether to automate a process or keep it manual, whether to use JSON or BSON or Protocol Buffers ... It's a judgement call and it's not really possible to give a good answer in a Hacker News comment.

wellpast 9y ago
I agree 100% with this. So if what you're saying here is that in Haskell that this choice is mine, that I can always completely avoid having to choose static verification if I so choose (ie, I can get it a la carte), then that is just plain awesome. Is that what you are saying?
- tome 9y ago
  > I can always completely avoid having to choose static verification if I so choose Well, yes, roughly, of course! You can always choose to use extremely broad types that give minimal guarantees, for example Scientific instead of Double or Int, String instead of MyPreciseErrorType, Map String Dynamic instead of MyPreciseRecordType ... You'll find the Haskell ecosystem is not really designed around that kind of programming because Haskellers don't really like it but it can easily be done, semantically. It will also be a bit awkward syntactically, but it's certainly possible. And then you can opt in to types (a la carte) later by replacing broader types with narrower ones as your project manager refines his specification. But that's not really the point. You can bolt on types to Clojure and you can bolt on dynamism to Haskell. My point is that I've almost always found it better to start in a strongly typed language, even when the requirements are changing rapidly.
  - wellpast 9y ago
    That is an interesting preference. I usually hear it the other way. That people would prefer to start dynamic when they understand the problem/domain the least and then move to static types when they become more sure about the taxonomy of things.
    - bitwalker 9y ago
      For me, fleshing out as much of the types/taxonomy as I can is one of the first things I do before coding towards a solution. Even if the first stab is rough, adjusting the types as knowledge of the domain grows has never been a point of friction for me - most of those changes are incremental, and having the compiler remind me the places I need to update (such as pattern matches) means I don't have to put any mental effort towards that. Even when the changes are significant, I'm still going to have to make basically all the same changes I would have had to make with no type system too. Having the compiler help me out during quick iteration means I can feel comfortable that I'm not forgetting to update areas of the code impacted by changes - when I get to where I want to be, I can be fairly sure I didn't miss anything. That comfort is something I value a lot more highly these days.