Hacker News Reader

Comment by teodorlu | Hacker News Reader

I really appreciate both Clojure and Haskell. I agree that

> nearly all of the claims made about Clojure here can be made about haskell

, but I'm not sure about `more strongly´.

## DX with Haskell (and ML friends) I miss in Clojure:

- Harder to do sound, up-front design with data types and module interface, where implementation becomes almost trivial after when the type signatures make sense

- Consistency checks from compiler / type checker

## DX with Clojure I miss in Elm/Haskell:

- REPL ergonomics, where every action I could think of makes sense as a REPL command, leading to very small incremental pieces.

- Excellent default data structures with literal representation and serialization (EDN)

I'd love to read a point-by-point discussion of the article sections comparing Haskell and Clojure, though that's much to ask for in the comments field.

View on HN

I've done a non trivial amount of both Haskell and Clojure, and this comment really hits the nail on the head. Each has non-overlapping strengths that I miss when switching. However, I've lately found F# to be my nearly perfect blend of enough things that I regularly use that I mostly just use that or Haskell when I'm messing about with katas.

As someone who hasn't written any F#, I'm curious about F#'s advantages over Haskell.

I've had bad luck with Haskell's laziness causing hard to debug performance issues. Also the lack of libraries really hurts when it comes to even basics like queue and database interactions. Many times there's a few libraries that are all half finished. Don't get me wrong, I really like Haskell a lot, I just find that F# brings a lot of well-thought out compromise between Haskell and the wealth of libraries in .NET for production code. If it was my money in my startup, I'd have no qualms betting on F# to get me to market as soon as possible. If it was my personal OSS project that I work on for personal edification and enrichment, I'd choose Haskell nearly every time.

If I had to pick one single advantage of F# over Haskell, it would be the general lack of partial functions. F# also does some really neat things with pattern matching. (See, for example, active patterns.)

The C#-style object model is arguably an advantage for certain purposes. I always feel guilty doing it, but object oriented domain modeling really does feel more natural for certain classes of problem.

On the downside, F# lacks higher kinded types, and you're absolutely on your own when it comes to making sure things that should be pure are actually pure.

Really nice insight, thank you! Clojure has always been a bit of a mystery to me, so this is interesting to read.

- REPL ergonomics, where every action I could think of makes sense as a REPL command, leading to very small incremental pieces.

This is the only point I would dispute. The GHC interpreter `ghci` is very powerful and offers a lot of the same upsides. Beyond this, the language server offers in-code evaluation with "-- >>> expression" syntax, which is a cool new step towards fast looping UX. Clojure is certainly great at this, but I'd say Haskell is not far behind.

I've only dabbled with GHCI. I've used it as a standalone REPL for trying out small things, the same way I'd use a Python or Javascript REPL. I haven't used the REPL /the/ developer interface to the program. In Clojure, I would (1) start a REPL server, (2) connect to it from my editor, and (3) send expressions to it. I didn't develop Haskell that way, though I think it was possible with Intero[1].

Within the Clojure community, there's a perception that the Clojure REPL is one of its strongest selling points[2].

Are you using the REPL actively when developing?

Edit: really curious about the "-- >>> expression " syntax! I might have to give Haskell another go.

Edit 2: Example of this interaction in practice with VSCode[3]

[1]: https://github.com/chrisdone/intero#readme [2]: https://clojure.org/guides/repl/introduction [3]: https://github.com/haskell/haskell-language-server#features

This is definitely weaker than a SLIME-like REPL, but I use ghcid --warnings --test My.Module.Tests.runTest, where runTest is tasty's defaultMain, to get near-instantaneous test running on changes to files. (Since it's GHCi instead of GHC, waiting for a full compile is unnecessary, and it still has the necessary smarts about what needs reloading to avoid reloading the whole project every change.)

Have you tried out ghcid? It basically just runs ghci on your program every time you save, and gives an updated list of errors and warnings. Not interactive in the sense that you don't manually test your functions with it, but like 95% of debugging in Haskell is just fixing errors at compilation time. I find it to be a very nice developer experience. Just need a text editor and a terminal with ghcid open and you get immediate feedback as you program.

https://github.com/ndmitchell/ghcid

Haven't heard of it before, but this looks super interesting! Thanks for the recommendation. I really like the fact that my whole development workflow could be a text editor and a terminal.

I enjoyed developing Elm with TCR[1] a while back; also with an editor + a type checker (plus the revert part). I recompiled my whole source on each save; incremental recompilation should scale better.

[1]: https://medium.com/@kentbeck_7670/test-commit-revert-870bbd7...

I program in Haskell much more than in any Lisp.

But AFAIK, GHCi doesn't have any state saving functionality (I don't think the dev environment is even integrated enough for any to work), and the little code edition available is entire function only. The Haskell REPL is entirely oriented into the "you write the code on the editor -> you evaluate it on the REPL" way (again, AFAIK, the GHCi manual is huge).

That said, yes, it's a really seamless cycle of you write your code on the editor -> you evaluate it on the REPL, and yes, Haskell requires doing that very little, most problems stop at the type checker. Haskell does really not afford interactive programming, but I wouldn't classify that as a problem.

Reply on news.ycombinator.com