Hacker News Reader

Comment by daenz | Hacker News Reader

I learned Haskell a few years ago, enough to read it, but not fluent enough to comfortably write it. Haskell scratches a real intellectual itch, related to how it formally captures certain concepts (types, purity, etc). But my opinion is that Haskell collapses under the weight of its terseness and academic complexity. Can it be extremely elegant? Yes, in contrived examples[0]. Is it able to maintain this elegance when dealing with common problems? No.

0. https://wiki.haskell.org/Introduction#Quicksort_in_Haskell

View on HN

> I learned Haskell a few years ago, enough to read it, but not fluent enough to comfortably write it.

Several years ago I tried to learn Haskell, and while I got to the point where I could write Haskell code, I found reading it nearly impossible. Even code I'd written a day or two earlier I found extremely difficult to decipher. While I learned some interesting things from the time I spent trying to learn Haskell, I eventually gave up on ever actually using it.

Do you maybe have an example where it isn't able to maintain that "elegance"? In my experience of writing Haskell, I do write pretty terse, higher order code, with lots of higher order functions, applicative functors, monad transformers, and many other abstractions that relatively tersely describe what is happening.

The expressions may not be simple, because what is happening may just not be that simple, but (purely a feeling) compared how the code achieving the same would come out on other "mainstream" languages, Haskell still tends to come out on top for me.

Make it clash, which is a (strict, real) Haskell subset replacing VHDL and Verilog[1], and the difference is orders of magnitude. In my hobby use, I plain refuse to write anything else than simple glue logic in VHDL or Verilog now.

[1] Usually compiling to them.

How is developing with Haskell? I've been considering picking it up because I love functional programming. I usually write quick n dirty stuff in python and lately I've been picking up go as well, which is a breeze to write with.

Can I get moving quickly with Haskell or will it take a while to get accustomed to it switching from other languages? My fear is that, like when I started picking up rust, it'll be a bit of a slog.

> will it take a while to get accustomed to it switching from other languages

If you've never dealt with a language similar to Haskell, I think the learning curve is very steep. But it was one of the most worthwhile things I did in my programming life.

Or not, because now I'm stuck with a view of how the world could be, which at least in my professional work life is pretty much out of reach. (Might be different for everyone individually.)

> how the world could be

I already feel this way about Clojure vs other languages I know, or Ruby (what I get paid to do) vs Python (what I use when I must).

It gets tiring to know elegance and terseness and then have to use wooden clubs.

If Haskell is some steps further up the ladder, but opportunities to use it are very limited, it would make me even more frustrated.

> I do write pretty terse, higher order code, with lots of higher order functions, applicative functors, monad transformers, and many other abstractions that relatively tersely describe what is happening

Can other people understand what is happening? Can people with less expertise understand what is happening? Can you yourself understand what is happening 6 months from now?

Yeah, better than in other languages I'd argue, as the meaning of the code is not obscured as much. This becomes especially (but not exclusively) clear with clash vs. VHDL/Verilog.

You have to actually know Haskell first, obviously.

Does a junior developer understand the core abstraction of a given project written in any language? Chances are the answer is no. Haskell just expresses that inside the language, while other languages tend to rely on design patterns, or just simply distributing the logic between many parts, which are arguably more error prone.

But for all practical matter, they can better write a single isolated case because it has to abide by stricter typing rules, instead of only conventions that supposed to he upheld.

I also want to add: That was actually the point of my comment. "Applicative functors" may sound scary as a name, but the concept really does help in keeping things readable.

I've worked on commercial Haskell projects and it was actually quite nice! Tooling was a pain, libraries may be lacking, but describing a complex domain as a state machine in the type system with automatically generated tests (via properties) and formal methods to prove some of the core algorithms was a really interesting way to develop. Not sure it'd be my pick for my own startup though.

What formal methods did you use?

Combination of Agda, Isabelle, Coq, and TLA+ depending on the team - I mostly interacted with TLA+ and the compiled Haskell from Agda specs :)

Wow definitely want to pick your brain. How large/# of LOC were the Agda, Isabelle, and Coq specs? What industry was this?

Blockchain - two repos with specs are:

* https://github.com/input-output-hk/cardano-ledger

* https://github.com/input-output-hk/plutus

There's quite a few recent Isabelle repos such as https://github.com/input-output-hk/high-assurance-legacy

It seems to work pretty well for the things I've used it for. There are some problems that are better served by an imperative solution with in-place mutable array operations and so on, but the ST monad works pretty well for that.

I think that's one of the things that tends to take a long time to learn: Haskell imposes a lot of limitations up front on what you can do. The rules (and in particular the barriers between pure and impure code) aren't quite as rigid at they seem. There are ways to work around them without actually breaking any of the soundness rules.

(To be fair, there is one well-known foot gun, which is that if you lazily read from a file and close the file, the consumer of the file's contents will often get truncated results. So don't do that. Maybe it's been fixed by now, or that API's been deprecated? I haven't really kept up on current events in the Haskell world.)

> (To be fair, there is one well-known foot gun, which is that if you lazily read from a file and close the file, the consumer of the file's contents will often get truncated results. So don't do that. Maybe it's been fixed by now, or that API's been deprecated? I haven't really kept up on current events in the Haskell world.)

I think the API is still there, but lazy IO is so heavily discouraged that no one is using it. It's not relevant anymore and considered a mistake.

My problem with it is that nobody actually writes Haskell itself. Every real usage has N different language extensions, and everybody is writing with a different subset of those.

Beautiful language though, wish I could use it at work.

So what is "Haskell itself"? Writing everything with the Prelude and the `IO` Monad?

Sure some people go off the rails with some things, but it's possible to write mostly vanilla Haskell and get a lot done.

Reply on news.ycombinator.com