4 ms·

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: * M

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.)

bstpierre 12y ago
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.
- kxs 12y ago
  You should look into Debug.Trace for quick printf-like debugging. Usage: trace ("error occurs here") (f x)
- gnuvince 12y ago
  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.
  - Peaker 12y ago
    Haskell doesn't ban imperative programming, it simply distinguishes it in the types.
    - gnuvince 12y ago
      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.
      - Peaker 12y ago
        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.
Peaker 12y ago
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 https://hackage.haskell.org/package/control-monad-exception
- adrusi 12y ago
  Check out how rust handles error composition using its Result type
- danidiaz 12y ago
  > 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-Bifunctor.html 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.

bstpierre 12y ago

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.

kxs 12y ago
You should look into Debug.Trace for quick printf-like debugging. Usage: trace ("error occurs here") (f x)
gnuvince 12y ago
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.
- Peaker 12y ago
  Haskell doesn't ban imperative programming, it simply distinguishes it in the types.
  - gnuvince 12y ago
    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.
    - Peaker 12y ago
      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.

Peaker 12y ago

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 https://hackage.haskell.org/package/control-monad-exception

adrusi 12y ago
Check out how rust handles error composition using its Result type
danidiaz 12y ago
> 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-Bifunctor.html 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.