2 ms·
Yes, instead you have parameter passing bugs (what, it's not state if it's not an implicit global variable?). I suspect the bugs have more to do with what is c
by jeff_marshall 10y ago
Yes, instead you have parameter passing bugs (what, it's not state if it's not an implicit global variable?).
I suspect the bugs have more to do with what is considered an acceptable design pattern (and resulting cognitive load) than the state-passing style.
- nightski 10y agoWell not really in a language as strongly typed as Haskell. At least, it provides you the type machinery to prevent a large source of these sort of bugs. It's not the end of the story either, there are even much more powerful languages than it which are still in infancy.
- jeff_marshall 10y agoIf you would have substituted coq (or even ACL2 with guards checking enabled...) in the place of haskell I would agree. hindley-milner style type checking is nice, but once you admit that things like arrays exist (rather than just algebraic data types or cons cells), the power of languages like haskell is in design patterns like map() and reduce() rather than the type checker, IMO. Having worked in functional languages with an imperative bent (esp. ACL2 in the context of modeling microprocessors), you can get an awful lot of mileage out of a good static proof strategy that can be instantiated over a known design pattern (equivalence relations, map, reduce, etc) even when you pass a single, huge, state object to all your top level functions.
- codygman 10y ago> hindley-milner style type checking is nice, but once you admit that things like arrays exist How are these related? Haskell has arrays. Arrays can be represented as algebraic data types as well. What is it you think Haskell has trouble representing?