5 ms·

> "SPJ in an excellent series of talks lists these advantages of types... the biggest thing left out of clojure..." > "The biggest merit he says is in software

by platz 9y ago

> "SPJ in an excellent series of talks lists these advantages of types... the biggest thing left out of clojure..." > "The biggest merit he says is in software maintenence, and i really disagree with just a lot of this. it's not been my experience; the biggest errors are not caught by these type systems; you need extensive testing to do real-world effectiveness checking." I think Rich is dead wrong on types not providing good tools for software _maintenance_. He is attempting to discredit types because they do not catch all errors, or the toughest errors; that's fine, I don't agree with people that would say types do that for you. I think dynamism is great for speed of development and flexibility; but my impression about trying to debug and maintain clojure code is that one has to spend time tracing back the source of errors and shape of maps (pre-spec). Those issues are somewhat mitigated by having a good type system, and what you loose on the flexibility going with types, is a trade that I think returns much more that what you give up.

flavio81 9y ago
>"The biggest merit he says is in software maintenence, and i really disagree with just a lot of this. it's not been my experience; the biggest errors are not caught by these type systems; you need extensive testing to do real-world effectiveness checking." I think I fully agree with Rick Hickey on this, and I have mentioned the same before here in HN. The biggest and most serious errors are not caught by the (statically checked) type systems. I agree that simple type errors that, on a dynamic system without compile-time checks are not caught, will be then caught at runtime and you will say "oh, i need to get back and correct this, damn it". But this is a minor annoyance, that takes small time compared to the bugs i'm mentioning in the previous paragraph; bugs that can take days to be resolved.
- lliamander 9y ago
  I would say the main point of types is to prevent uninteresting bugs. For me that's a selling point because I don't want to be distracted by those kinds of bugs.
- runT1ME 9y ago
  What kind of errrors do you think are not caught with static typing? Usually people who say this aren't familiar with languages that have type classes...
  - flavio81 9y ago
    >What kind of errrors do you think are not caught with static typing? Citing awj's post above: "Some of the biggest errors are subtle failures in the implementation of business logic." Other examples: - bumping into unkonwn bugs of a library you are calling - implementation of an external (library) function behaving differently than the documentation - various memory leak problems - locking issues - race conditions etc
    - runT1ME 9y ago
      >"Some of the biggest errors are subtle failures in the implementation of business logic Static typing can prevent errors in business logic. >various memory leak problems - locking issues - race conditions All are bugs that static typing has had tremendous success in preventing. Have you any experience in a HM like type system?
      - flavio81 9y ago
        >All are bugs that static typing has had tremendous success in preventing. Please do elaborate, it could be a great post. But If you mean to say that locking issues can be prevented because you can apply STM (software transactional memory) by using suitable Monads, then, well, i can also have STM in a dynamic language, even applying it by wrapping code in an "atomic" context (i.e. see the STMX library for Common Lisp) so the statements contained within are performed atomically (and thus guaranteed to work or either roll-back.) As for memory leaks, Haskell (if that's the HM language you had in mind) automatically manages memory, so I would guess this isn't a problem at all. However, automatic management memory management is orthogonal to "static vs dynamically typed". Thus, i'm curious, and yes, i don't have enough experience with HM-type languages, which should be the way to go if one wants to use static typing...
awj 9y ago
No, I think his point is valid. Some of the biggest errors are subtle failures in the implementation of business logic. Cases where what the code does and what it looks like it does fail to line up. Static typing can be brought to bear on those (encode your business logic in the type system), but what parts that fails to cover still need good testing. Plus, how do you test that your types correctly encode your business logic? I'm still more in the static camp than out of it, but I can recognize that the problem is not as cut and dried as we want to believe. There's are reasons this pendulum has swung back and forth over the decades, and I don't see anything to suggest those reasons have changed.
- platz 9y ago
  > how do you test that your types correctly encode your business logic types, as most commonly used do not _directly_ encode business logic; they just provide constraints i.e. it is not an all-or-nothing situation. You can still write unit tests.
  - yogthos 9y ago
    What you have to demonstrate is that static typing catches a statistically significant amount of additional errors over plain unit tests. Nobody has been able to show this to be the case so far in practice.
    - platz 9y ago
      Requiring statistically significant studies pretty much guarantees no provable claims can be made for any side; since that amounts to a social science laden with shaky assumptions and ambiguous modeling. Since it's is a standard of proof that no-one can achieve, i don't see why mention it here. But to go along with this for a moment, I liked your response to this paper here https://www.reddit.com/r/Clojure/comments/73q8c2/a_largescale_study_of_programming_languages_and/dnsqypt/ https://www.reddit.com/r/Clojure/comments/73q8c2/a_largescal... ; Though I'm not sure how we're deciding what is "statistically significant" in contrast to what the researchers have decided is statistically significant. Were their calculations incorrect? However, you claim to reveal their "real conclusion", in contrast to their Actual Conclusion, in which they do indicate that "Among functional languages, static typing is also somewhat better than dynamic typing." Still, I do not place much stock in these studies for the aforementioned reasons. I also think you have to be careful about where you have placed the "burden of proof". (You've placed it on requiring poof that static types provide X benefit. One can just as well turn this around and require poof that eschewing static types provide X benefit; so we cannot a-priori place such demands in either direction).
tome 9y ago
What the two replies (at the time of writing) to this comment have missed is that maintenance and avoiding errors are not the same thing!

by platz 9y ago

flavio81 9y ago

>"The biggest merit he says is in software maintenence, and i really disagree with just a lot of this. it's not been my experience; the biggest errors are not caught by these type systems; you need extensive testing to do real-world effectiveness checking." I think I fully agree with Rick Hickey on this, and I have mentioned the same before here in HN. The biggest and most serious errors are not caught by the (statically checked) type systems. I agree that simple type errors that, on a dynamic system without compile-time checks are not caught, will be then caught at runtime and you will say "oh, i need to get back and correct this, damn it". But this is a minor annoyance, that takes small time compared to the bugs i'm mentioning in the previous paragraph; bugs that can take days to be resolved.

lliamander 9y ago
I would say the main point of types is to prevent uninteresting bugs. For me that's a selling point because I don't want to be distracted by those kinds of bugs.
runT1ME 9y ago
What kind of errrors do you think are not caught with static typing? Usually people who say this aren't familiar with languages that have type classes...
- flavio81 9y ago
  >What kind of errrors do you think are not caught with static typing? Citing awj's post above: "Some of the biggest errors are subtle failures in the implementation of business logic." Other examples: - bumping into unkonwn bugs of a library you are calling - implementation of an external (library) function behaving differently than the documentation - various memory leak problems - locking issues - race conditions etc
  - runT1ME 9y ago
    >"Some of the biggest errors are subtle failures in the implementation of business logic Static typing can prevent errors in business logic. >various memory leak problems - locking issues - race conditions All are bugs that static typing has had tremendous success in preventing. Have you any experience in a HM like type system?
    - flavio81 9y ago
      >All are bugs that static typing has had tremendous success in preventing. Please do elaborate, it could be a great post. But If you mean to say that locking issues can be prevented because you can apply STM (software transactional memory) by using suitable Monads, then, well, i can also have STM in a dynamic language, even applying it by wrapping code in an "atomic" context (i.e. see the STMX library for Common Lisp) so the statements contained within are performed atomically (and thus guaranteed to work or either roll-back.) As for memory leaks, Haskell (if that's the HM language you had in mind) automatically manages memory, so I would guess this isn't a problem at all. However, automatic management memory management is orthogonal to "static vs dynamically typed". Thus, i'm curious, and yes, i don't have enough experience with HM-type languages, which should be the way to go if one wants to use static typing...

awj 9y ago

No, I think his point is valid. Some of the biggest errors are subtle failures in the implementation of business logic. Cases where what the code does and what it looks like it does fail to line up. Static typing can be brought to bear on those (encode your business logic in the type system), but what parts that fails to cover still need good testing. Plus, how do you test that your types correctly encode your business logic? I'm still more in the static camp than out of it, but I can recognize that the problem is not as cut and dried as we want to believe. There's are reasons this pendulum has swung back and forth over the decades, and I don't see anything to suggest those reasons have changed.

platz 9y ago
> how do you test that your types correctly encode your business logic types, as most commonly used do not _directly_ encode business logic; they just provide constraints i.e. it is not an all-or-nothing situation. You can still write unit tests.
- yogthos 9y ago
  What you have to demonstrate is that static typing catches a statistically significant amount of additional errors over plain unit tests. Nobody has been able to show this to be the case so far in practice.
  - platz 9y ago
    Requiring statistically significant studies pretty much guarantees no provable claims can be made for any side; since that amounts to a social science laden with shaky assumptions and ambiguous modeling. Since it's is a standard of proof that no-one can achieve, i don't see why mention it here. But to go along with this for a moment, I liked your response to this paper here https://www.reddit.com/r/Clojure/comments/73q8c2/a_largescale_study_of_programming_languages_and/dnsqypt/ https://www.reddit.com/r/Clojure/comments/73q8c2/a_largescal... ; Though I'm not sure how we're deciding what is "statistically significant" in contrast to what the researchers have decided is statistically significant. Were their calculations incorrect? However, you claim to reveal their "real conclusion", in contrast to their Actual Conclusion, in which they do indicate that "Among functional languages, static typing is also somewhat better than dynamic typing." Still, I do not place much stock in these studies for the aforementioned reasons. I also think you have to be careful about where you have placed the "burden of proof". (You've placed it on requiring poof that static types provide X benefit. One can just as well turn this around and require poof that eschewing static types provide X benefit; so we cannot a-priori place such demands in either direction).

tome 9y ago

What the two replies (at the time of writing) to this comment have missed is that maintenance and avoiding errors are not the same thing!