5 ms·

I honestly have no idea what all of that does. I'm sure I could work my way through it, but still... in other languages you can get a glimpse of the purpose of

I honestly have no idea what all of that does. I'm sure I could work my way through it, but still... in other languages you can get a glimpse of the purpose of a program even if you don't know the syntax. You can tell whether it is a parser, a game, a Hello World, or a web application. The other thing I dislike besides the opaqueness of Haskell is what another commenter described as "mechanically filling in" of code. I get that feeling every time I try strongly typed functional languages. I had the same feeling when I started with C++ and stuggled with `const`. I had an idea in my head, but couldn't convert it to code because the compiler didn't allow it. Instead of helping me, the syntax slowed me down, took me out of the "flow". It rarely, if ever, helped me avoid bugs. Now, I've probably learned avoidance strategies, and rarely have problems with `const` anymore. Haskell gives me that old feeling of programming in a straightjacket, multiplied by 1000.

klrr 13y ago
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/ 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.
- dllthomas 13y ago
  It's a matter of using the types to express meaningful constraints, so that well-typed is more likely to mean correct.
nbouscal 13y ago
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.
- zipfle 13y ago
  I always try to write code that my favorite English professors would approve of.
  - saraid216 13y ago
    My favorite English teacher would have written "So what?" at the bottom of most of my code. :(
- hcarvalhoalves 13y ago
  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.
  - nbouscal 13y ago
    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.
freyrs3 13y ago
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.
- CharlesMerriam2 13y ago
  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.
  - eru 13y ago
    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.)
  - chowells 13y ago
    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.
  - saraid216 13y ago
rybosome 13y ago
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.
- anaphor 13y ago
  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.
- codygman 13y ago
  That's exactly why I'm programming way more Haskell than Go these days.

klrr 13y ago

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/ 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.

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

nbouscal 13y ago

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.

zipfle 13y ago
I always try to write code that my favorite English professors would approve of.
- saraid216 13y ago
  My favorite English teacher would have written "So what?" at the bottom of most of my code. :(
hcarvalhoalves 13y ago
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.
- nbouscal 13y ago
  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.

freyrs3 13y ago

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.

CharlesMerriam2 13y ago
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.
- eru 13y ago
  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.)
- chowells 13y ago
  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.
- saraid216 13y ago

rybosome 13y ago

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.

anaphor 13y ago
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.
codygman 13y ago
That's exactly why I'm programming way more Haskell than Go these days.