|
|
|
|
|
|
by marktangotango
4006 days ago
|
|
|
>> Train internal talent up to it, dumbass. Train an X programmer on Y, and you'll most likely get Y written as X for quiet some time, until they gain experience, if ever. The disconnect I've always had with using Haskell for anything is; you never get a result until the entire computation is complete. Oh but monads they say. Well, monads seem an aweful lot like procedural code (to me, the uninitated, unpracticed) so what's the point again? That's not meant as a criticism of Haskell, but just one persons thought process on the issue. I'd use SML if I could. |
|
|
Most companies are run by short-sighted mediocrities who don't look more than 3 months into the future. I think longer term. In the long term, the transition is worth it. The benefits of moving from Java to Haskell or Clojure, say, are worth a few months of struggling and first-time code. If you have half-decent programmers and a culture that allows people to take time to learn how to do things right, that pays itself off within the year.
The disconnect I've always had with using Haskell for anything is; you never get a result until the entire computation is complete.
That's not really true. If you need strictness, you can force evaluation and you don't need to use monads. I'm writing a Haskell class and I cover `seq` before I tackle monads in all their glory (i.e. beyond "here's how you do some basic I/O").
Oh but monads they say. Well, monads seem an aweful lot like procedural code (to me, the uninitated, unpracticed) so what's the point again? That's not meant as a criticism of Haskell, but just one persons thought process on the issue.
That's a fair point. Yeah, do-notation is a way to write imperative-looking code in a functional way. The truth is that for small programs, imperative code is often much more readable. That's how recipes are written, for example. Five lines of imperative code never killed anyone. It's when a function gets to 4,000 lines (often with multiple authors) that imperative programming completely shits the bed.
Monads, in short, are... a way to abstract around the concept of computational context so we can define what "stateful effects" are. `IO` has access to anything the machine can do. `ST` is single-threaded but stateful. `STM` can update some state (`TVars`) but has to follow the transactional rules. `State s` is a pure monad that looks stateful because it uses explicit state. Then we get to the monad transformer stacks, which are... potentially very complicated. (Phil Freeman's work with row types and the `Eff` monad in PureScript may replace the MT stacks one day.)
The point, in short is: imperative code is not evil, we're not trying to do away with it. We want to segregate it into functions that are preferably easy to read so we can reason about what stateful effects do happen. In Haskell, the monad system allows us to enforce this at the type level. You can look at the type signature and get an upper bound (unless "cheat functions" like `unsafePerformIO` are used; and they generally shouldn't be) on the space of stateful effects that can occur.