4 ms·

>Personally, I don't understand people arguing against type systems on principle. Even Uncle Bob wasn't, I don't think. He just said that certain languages had

>Personally, I don't understand people arguing against type systems on principle. Even Uncle Bob wasn't, I don't think. He just said that certain languages had type systems with a level of strictness that he considered too extreme. >Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems No, not all, only certain classes. With haskell, for example, that comes at the expense of development velocity and performance (or at least, the ability to reason about performance). >There has to be something I'm missing since there are so many people arguing against types, notably Bob Martin himself. I think the key part people miss in the "more strictness" argument is that stricter types lengthen development and if your biggest risk is errors in specification (the article makes assertion and in my domains, that's been my experience too), so you are risking a vast amount of wasted time spent on perfecting the wrong thing.

Silhouette 9y ago
With haskell, for example, that comes at the expense of development velocity and performance (or at least, the ability to reason about performance). That seems a little unfair. The biggest challenge with reasoning about performance in Haskell is usually its non-strict semantics. That issue is only incidentally related to Haskell's type system being significantly more capable than those of many other programming languages.
tpush 9y ago
> With haskell, for example, that comes at the expense of development velocity and performance (or at least, the ability to reason about performance). The (depending on perspective) weaker ability to reason about performance in Haskell stems from laziness, which itself has nothing to do with type systems. It's clashes with side-effects are solved _via_ the type system (The IO type). Regarding development velocity: _The developers_ are choosing how much time they spent on proving things to the type checker. Sure, writing a function that requires of its argument the type { n % 2 == 0 } or something is more labor intensive than just using Int and runtime panicking on invalid values. But you can choose do just that instead! There is no decree that on has to be as precise in their types as possible, no matter how much a given type system is able to express.

Silhouette 9y ago

With haskell, for example, that comes at the expense of development velocity and performance (or at least, the ability to reason about performance). That seems a little unfair. The biggest challenge with reasoning about performance in Haskell is usually its non-strict semantics. That issue is only incidentally related to Haskell's type system being significantly more capable than those of many other programming languages.

tpush 9y ago

> With haskell, for example, that comes at the expense of development velocity and performance (or at least, the ability to reason about performance). The (depending on perspective) weaker ability to reason about performance in Haskell stems from laziness, which itself has nothing to do with type systems. It's clashes with side-effects are solved _via_ the type system (The IO type). Regarding development velocity: _The developers_ are choosing how much time they spent on proving things to the type checker. Sure, writing a function that requires of its argument the type { n % 2 == 0 } or something is more labor intensive than just using Int and runtime panicking on invalid values. But you can choose do just that instead! There is no decree that on has to be as precise in their types as possible, no matter how much a given type system is able to express.