Hacker News Reader

Comment by danidiaz | Hacker News Reader

I think Haskell is a possible alternative to Go/Python/Ruby for these kinds of tasks.

But nothing's perfect. Some possible annoyances you might encounter:

* Much of the functionality required to be a valid "Python alternative" is not on the base packages. You'll have to install extra packages much sooner than with Python. And you'll have to know what packages to install.

* Despite having proper sum types, most I/O libraries in Haskell rely on exceptions for signalling errors. And Haskell has no proper stack traces. If you are not careful, you might find yourself pining for Go's multiple return values.

(Some would add "having to use the IO monad" to the list of annoyances, but I think it actually helps.)

View on HN

I found ocaml to be a more flexible alternative -- I can sprinkle printf for quick debugging without having to alter types. (I think this is what you mean by "having to use the IO monad". I didn't work with haskell much, so it's possible there's an easy way around this there.) And stack traces in ocaml are reasonable, though not quite as verbose as python's.

But your point about needing to install extra packages stands for either language.

You should look into Debug.Trace for quick printf-like debugging. Usage: trace ("error occurs here") (f x)

OCaml is currently my language of choice. I love functional programming, been doing it for a while now, but it's nice to know that if I read an algorithm in a textbook, I can just implement it as-is instead of doing a translation to be purely functional (and sometimes having to fight to get back the asymptotic complexity). The module system is also absolutely great, and should be copied shamelessly by more languages.

Haskell doesn't ban imperative programming, it simply distinguishes it in the types.

True, what I mean is that I can be "messy" in OCaml for the sake of expediency. In principle, I prefer Haskell's clean approach, in practice I'm a bad programmer who sometimes does naughty things.

Well, Haskell does force you to go and update your types about your effects, and fix the use sites to do proper lifting.

I don't feel this costs much, though, so even in quick&dirty mode, I feel that Haskell is quite productive enough.

Proper sum types aren't enough to replace exceptions.

Imagine every IO action having its own error type in a sum type. How do you compose them?

Composing the different error types wouldn't unify.

The best attempt I've seen in Haskell is the control-monad-exception[1] library, but I'm not sure how well that would interact with everything.

[1] https://hackage.haskell.org/package/control-monad-exception

> Imagine every IO action having its own error type in a sum type. How do you compose them?

Perhaps by converting each error type to a common sum type. Something like "Either (Either error1 error2) result". Typeclasses like "Bifunctor" are quite useful for massaging the errors around:

http://hackage.haskell.org/package/bifunctors-4.2/docs/Data-...

Asynchronous exceptions do pose a problem for this approach though, as they can pop up in any function at any time. And perhaps a fully sum-type-based approach would clutter function signatures too much anyway.

Check out how rust handles error composition using its Result type

Reply on news.ycombinator.com