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.

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. :(

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.

Think of how you looked at C++ code before you learned to program and you'll see the same phenomenon. Very little of your knowledge about imperative programming transfers over to Haskell so it's not surprising that you look at it and see gibberish. It's the same way many people can pick up Latin-derivative languages quickly after learning a few, but find that their knowledge doesn't transfer and struggle to learn Mandarin or Russian.

Hmmm... Not really. People familiar with BASIC can read most C++. People glancing at a Russian Newspaper see sentences, words, stories.

I've seen a fair amount of lambda style code, prolog, and so on. This code just looks ugly.

For what it's worth, this is perfectly standard Haskell code, perhaps even on the simpler side.

(Not saying that you have to like it. Just giving perspective.)

Author of the article here.

I learned to program very young. I was fluent in BASIC as my first language. I couldn't read the slightest bit of C++ when I first exposed to it. The syntax is hugely different because it's optimized for handling features. There are new operators like ++ everywhere. There's crazy template stuff. I couldn't even start to guess at what the various unary * and & operator applications meant.

I eventually learned enough C++ to make sense out of those constructs. The reason they show up is that they make sense for operating at the level C++ is intended to operate at.

Haskell introduces a lot more new ideas than C++ ever did. It has radically different syntax than C++ because it makes it easy to work at the level Haskell is intended to work at.

There is no way in which the code in that article is ugly. It's very simple, very clean code that uses ideas you've never been exposed to, in syntax that reflects those ideas.

And I'm glad to have backup from someone else who knows the language in a sibling comment.

> People glancing at a Russian Newspaper see sentences, words, stories.

Of course they do. That's because a Russian newspaper is using the same design language as an English newspaper. But the semantic language itself isn't legible. You can't tell that яблоко is a kind of fruit by "glancing" at it, unless you know Russian.

Learning functional programming is not trivial, especially if you come from the imperative paradigm. Haskell was my first language and I still struggled not to think procedurally in the beginning , and the type-checker refused almost all of my programs. But after a while you start to get less and less type errors, and soon types will be your friend and guide you when writing programs.

I have to say though; static types itself doesn't prevent bugs, they only prevent common errors. But if you got an expressive type system like Haskell (or OCaml etc.) you can write well-typed programs. A great example is Yesod[0], which is a web framework completely designed around being well-typed.

0. http://www.yesodweb.com/

EDIT: Okey, "well-typed" may not be the right term. TAPL calls every program that pass the type-checker well-typed so what I meant is programming written type-safe.

It's a matter of using the types to express meaningful constraints, so that well-typed is more likely to mean correct.

For what it's worth, my own experience has been that becoming fluent with the functional style makes the imperative style seem really bizarre. I've made multiple attempts to learn Go, but for the life of me I can't; it seems so byzantine and archaic, like a creaking, inconsistent Rube Goldberg machine. The feeling in functional languages that everything is an expression and evaluates to a value actually feels really liberating; everything can be thought of a series of transformations.

This is not meant to argue with you, merely to provide the viewpoint that imperative programming is yet another valid way of performing computation, not necessarily the _natural_ way.

To be fair not everything makes sense as a value, which is the reason why Unit or () exist, because things that cause side-effects still need to evaluate to some value.

That's exactly why I'm programming way more Haskell than Go these days.