Hacker News Reader

Comment by nbouscal | Hacker News Reader

If you don't know functional programming, of course you won't be able to understand functional code at a glance. You wouldn't expect someone who doesn't know imperative programming to intuitively understand imperative code at a glance either. It's not opaque, it just requires learning.

Not being able to convert the code in your head into type-safe functioning code just means that you don't understand the code well enough yet. That's not a bad thing about you or about the language, it's just the state of things. Once you gain that understanding, you'll be able to write code that compiles, and you'll also discover that now the compiler is your best friend. Writing Haskell is extremely comforting to me, because I know that the compiler has my back. It's not a straightjacket, it's a guardrail alongside a mountain highway.

View on HN

I don't think it's about functional programming, not even type systems. It's about all the idiosyncrasies Haskell throws at the programmer. Even the author adds in the end:

> I still don't really understand free. I definitely don't have a clue what kan-extensions are in general, or what Coyoneda is specifically.

So, he got a working program (because it's assumed it works if it compiles), but can't explain why, what the components are or do. I'm sure there are a plethora of strong points about Haskell, but his conclusion that you can just gloss over it is not making a good case for it in my opinion, it's actually a huge red flag.

I think you misunderstood the article. He knows exactly what the components allow him to accomplish, he just doesn't know how exactly they work or any of the math behind them. This is directly analogous to the situation in every other programming language: very few programmers know exactly how every library that they use works. This is good, because in practice there isn't time to learn the intricacies of every one of your dependencies.

To be clear, this also has very little to do with Haskell. kan-extensions is a library, it's not a part of Haskell itself. His point is that if you had a kan-extensions package in some other language, it would be a hell of a lot more difficult to use it in your program without learning the math yourself. And again, the key point here isn't that you can gloss over what the library allows you to do, it's that you can gloss over the complex abstract mathematics that went into the creation of the library. You can get the benefits of free monads without taking a course in category theory. That's definitely a good thing.

In addition to what nbouscal pointed out, I'd just like to say that I very explicitly did not assume it worked just because it compiled. The last code block doesn't just have the miniature library, it also contains code that uses it, and that code works perfectly. That's the opposite of assuming that because it compiles, it works.

Though the only way for something with those types to not work when it compiles would be for it to crash or go into an infinite loop. I didn't use any constructs capable of either of those, so it was very unlikely for it to fail once it compiled.

I always try to write code that my favorite English professors would approve of.

My favorite English teacher would have written "So what?" at the bottom of most of my code. :(

Reply on news.ycombinator.com