4 ms·

I took a course that focused on Haskell in college. I enjoyed it. I love reading articles about how neat Haskell is. I've still never been convinced that I shou

I took a course that focused on Haskell in college. I enjoyed it. I love reading articles about how neat Haskell is. I've still never been convinced that I should use Haskell over a more mundane language for any actual project.

coolsunglasses 9y ago
I do pretty ordinary stuff and it makes my work a lot nicer. An open source example is the Elasticsearch client I wrote called Bloodhound: https://github.com/bitemyapp/bloodhound https://github.com/bitemyapp/bloodhound It makes writing and maintaining applications that use ES a lot more maintainable. Makes the Query API a lot more discoverable too.
hood_syntax 9y ago
Depends on what the project is. If parsing is the biggest part of the project then I would say Haskell is top-class in that respect. It has proven success stories. However, due to the lack of control over GC it has latency issues with certain kinds of work and it's not a great choice for writing demanding games. For me, one of the big holes in the Haskell story is a great, idiomatic GUI toolkit. That makes it a little more difficult to use for standard desktop applications, but not impossible (after all, there are binding to common frameworks like GTK etc).
- nicolashahn 9y ago
  Have to agree with you on all counts. I forgot about parsing, I generally don't have to do that. The final project my group attempted was a simple game/simulator in Haskell and it was by all counts a pain to work around the statelessness. When we were trying to create an interface for the game we also noticed the lack of good GUI libraries.
  - jfoutz 9y ago
    I'd extend parsing to any part of a compiler. Or a whole compiler. It's really nice for managing that complexity.
- paulajohnson 9y ago
  On the GUI toolkit issue, I'd recommend combining gtk2hs (which is a thin wrapper around GTK) with Reactive Banana. GTK signals are isomorphic with Banana events and GTK attributes are isomorphic with Banana behaviors. So you can connect up a button press signal from GTK to an Event, transform that event with data from some other behavior, and hence generate a new behavior which is connected to the GTK attribute of the text displayed in a text box. Your application logic is then expressed as the plumbing that pipes data from event sources to event and behavior sinks. This works well because the event plumbing is composable in ways that callbacks and state variables of native GTK aren't.
  - hood_syntax 9y ago
    Thanks for the advice! I'll look into that

coolsunglasses 9y ago

I do pretty ordinary stuff and it makes my work a lot nicer. An open source example is the Elasticsearch client I wrote called Bloodhound: https://github.com/bitemyapp/bloodhound https://github.com/bitemyapp/bloodhound It makes writing and maintaining applications that use ES a lot more maintainable. Makes the Query API a lot more discoverable too.

hood_syntax 9y ago

Depends on what the project is. If parsing is the biggest part of the project then I would say Haskell is top-class in that respect. It has proven success stories. However, due to the lack of control over GC it has latency issues with certain kinds of work and it's not a great choice for writing demanding games. For me, one of the big holes in the Haskell story is a great, idiomatic GUI toolkit. That makes it a little more difficult to use for standard desktop applications, but not impossible (after all, there are binding to common frameworks like GTK etc).

nicolashahn 9y ago
Have to agree with you on all counts. I forgot about parsing, I generally don't have to do that. The final project my group attempted was a simple game/simulator in Haskell and it was by all counts a pain to work around the statelessness. When we were trying to create an interface for the game we also noticed the lack of good GUI libraries.
- jfoutz 9y ago
  I'd extend parsing to any part of a compiler. Or a whole compiler. It's really nice for managing that complexity.
paulajohnson 9y ago
On the GUI toolkit issue, I'd recommend combining gtk2hs (which is a thin wrapper around GTK) with Reactive Banana. GTK signals are isomorphic with Banana events and GTK attributes are isomorphic with Banana behaviors. So you can connect up a button press signal from GTK to an Event, transform that event with data from some other behavior, and hence generate a new behavior which is connected to the GTK attribute of the text displayed in a text box. Your application logic is then expressed as the plumbing that pipes data from event sources to event and behavior sinks. This works well because the event plumbing is composable in ways that callbacks and state variables of native GTK aren't.
- hood_syntax 9y ago
  Thanks for the advice! I'll look into that