4 ms·
Yes, Haskell is worse with those "trivial automated" (due to worse tooling, nothing about the language prevents that), but imo better with those "hunting down c
by youerbt 7y ago
Yes, Haskell is worse with those "trivial automated" (due to worse tooling, nothing about the language prevents that), but imo better with those "hunting down compiler errors". And I take easier manual work on hard problems over trivial automation any time.
Java and Python are simply not languages that encourage (or even make possible) writing code that is easy under those changes. In Haskell you have immutability (if something is declared, that's its final value, so I can simply move it around), purity (code that is basically context independent), dumb data structures (no "enterprise boolean" with nontrivial internal state and ceremony to initialize), functional (no code attached to mutable data that may implicitly require data to be in special state), no nulls in flow control (that are invisible to a compiler, so yea good luck moving function around that expects no nulls), ergonomic creation of data/types (so you don't have strings/integers everywhere that are opaque to a compiler).
There is no contest, really. Maybe with some modern languages like Rust or TypeScript, but I haven't tried those.
- dmitriid 7y ago> And I take easier manual work on hard problems over trivial automation any time. However, most changes/refactorings I usually encounter are due to trivial problems that can be automated. And I'd love to have those tools for FP where a lot of changes are still just that: rename a function or a field in a data structure, extract a function, rename/move a module, update type signatures etc. However, it looks like the stronger the static typing, the worse are the tools :) Not enough manpower to take care of them, perhaps?
- youerbt 7y agoYea... that's a trade off, unfortunately, and I won't pick sides here. Stronger static typing has so much potential for tooling, but none of that is reality, sadly. As for Haskell, I think, it's a combination of manpower (so popularity, really) and the fact that the compiler wasn't developed with tooling in mind. Thanks for conversation, stranger, and have a nice day!
- dmitriid 7y agoAnd same to you, kind stranger!
- tome 7y ago> most changes/refactorings I usually encounter are due to trivial problems that can be automated This is interesting because another popular argument against Haskell is "Haskell's type checker can only check trivial properties that can be automated". Either automating trivial things is valuable or it's not, and the anti-Haskell camp seems not to agree on which!
- dmitriid 7y agoAutomating trivial things is immensely valuable. And yes, Haskell’s type checker can only check a subset of things.