Hacker News new | ask | show | jobs
by billythemaniam 1108 days ago
I really hope just using static types alone doesn't give people confidence to refactor. It of course depends what "refactor" really means. Are we talking about a function, class, module/library, an entire application? Maybe in the function case, static type give more confidence, but in the others the way to de-risk is to have good tests. Static types only help catch one class of errors where refactoring can introduce several error classes depending on the specific case.

In other words, if static types alone are giving confidence to refactor, it is a false confidence except in the most trivial of cases.
1 comments
fredrikholm 1108 days ago
This is a sliding scale though; types in C and types in Haskell aren't the same. Most statically languages sit somewhere between the two extremes, where few veer towards the right.

As a consequence, a lot of peoples primary experience with type systems is limited to "this should return a list of strings", which like you said, is one small class of problems (though I'd argue it's huge win compared to not having that guarantee).

Every project needs tests, but like all things, what happens in practice is seldom ideal and thus the more you can offset to (reliable) automated tools the better.

link
proper_elb 1108 days ago
To add to this: A bit similar to Lisp, due to the different compiler plugins, Haskell is more like a family of dialects. One can be pretty vanilla about what the types should protect against, but one can also build arcane type-magic buildings that rely on the newest PL research.

Simple, vanilla Haskell is approximated more and more by the mainstream languages: Optional types, andThen().orElse() and friends and other things - which I am really happy about!

Why not use a more mainstream langauge then? For me, there are at least 3 hard reasons:

1) The stuff mentioned above is old, battle-tested and deeply embedded into the language and the community - it feels ergonomic to use.

2) IO-being-a-library is a paradigm that produces programs that I love to maintain, also when others written them.

3) Haskell has nice interfaces that I miss in mainstream languages, Functor and Monad for example. My prediction is that in around 5 years, mainstream languages will start to offer these kind of interfaces - starting from "Wait, what else can we do with andThen() and optional chaining and so on?"

link