The biggest lie about Haskell is that it's easy to learn. No it's not, and I do use it at work. Sure, it's not THAT difficult to get a basic understanding until you get to the usual Functor, Applicative, Monad stuff, which you can understand if you imagine them as context bubbles. Once you put something into a side-effect bubble (IO), you cannot take it out, so you're obligated to work inside of that bubble. This analogy should get you far enough. You're now ready to build toy projects.
But, even if you finish the Haskell Book(http://haskellbook.com), which is like 1300 pages, you're still going to be unable to contribute to a serious code base. Anyone who says otherwise is lying. Now, you have to understand at least 20 language extensions which you find randomly at the top of files {-# LANGUAGE ExtensionHere #-}. Now you have to understand how to really structure a program as either a stack of monad transformers, or free monads or anything else. Then you get into concurrency and to do that you have to understand how Haskell actually works, what non-strict computation does etc. etc. Otherwise you're going to get some nasty behaviour.
You think I'm done? Let's get to Lens. You can use Lens after a relatively short time of reading the docs. But to understand Lens? Very few people actually understand Lens.
Don't get me wrong, Haskell has spoiled me, and I don't really want to touch any other language (I still like Clojure, Rust, Python, Erlang). Once you get past that the language is a joy to use.
Lens is a library, not part of Haskell the language, it's also not particularly widely used. If you are going to conflate the ecosystem with the language, then we could equally talk about the complexity of dependency injection frameworks, AbstractSingletonProxyFactoryBeans, aspect-oriented bytecode weaving, and enterprise Java beans when discussing how much "easier" Java programming is.
I have programmed both Java and Haskell professionally on multiple codebases. I honestly found more ad-hoc and incidental complexity in the Java world. At least the Haskell libraries generally were consistent in the abstractions used. Java the language, also had a lot of hidden complexity, for example its memory model (required knowledge for concurrent programming).
>Sure, it's not THAT difficult to get a basic understanding until you get to the usual Functor, Applicative, Monad stuff, which you can understand if you imagine them as context bubbles. Once you put something into a side-effect bubble (IO), you cannot take it out, so you're obligated to work inside of that bubble. This analogy should get you far enough. You're now ready to build toy projects.
The analogy with Promises, which by now everybody knows, even if pedantically flawed because they don't fit this or that criterium of Monads, is quite useful to get the idea...
Coincidentally: it’s also the only programming language I know of where someone has written a lengthy blog post about how I’m in fact, not too dumb to comprehend it.
I didnt think about how hard Haskell is because I never forced myself to learn it. It just didnt interest me. With Java or C# I can make so many things with minimal friction. The other language that people talk about being hard is Rust. I am going to assume theres blog posts about it not being hard.
I like that with Go or Erlang everything I learned 5 or more years ago has still stuck to me. With D I can be effective quickly. With Rust I struggle a bit. Rust is probably great for building a web browser but doing backend web development feels way more work than Go or even Python (CherryPy). Haskell I dont even remember a darn thing anymore.
Haskell was used in the first programming class at university and that was excellent. Some people that already know how to program had to throw their preconceptions out the window. So everyone was either a novice at programming entirely or at least a novice at functional programming. It wasn’t problem at all. I’d argue most students wrote better code in that class than they did in the imperative/OO classes that followed. Especially the students that weren’t (and likely never did become) programmers.
The thing about imperative and OO programming is that it’s hard to do well. I honestly havent seen more than 1/10 developers write ”good” OO code even after 10 or 15 years as professionals. Large scale OO is a cognitive load that requires extreme focus, skill and talent. I prefer functional (or OO using an extreme functional discipline like all immutable types etc) because I don’t have that talent, focus and skill.
My point isn’t that Haskell should be the language of choice. I think it’s a great language but I think e.g laziness makes it too hard to reason about performance and behavior. Today I’d recommend F# I think.
"You are already smart enough to write Haskell"... if you accept that you are too dumb for most of Haskell and are therefore okay with being cut off from most of its ecosystem.
Digging into a dependency due to a bug or custom feature is something that usually happens on any bigger project of mine. If I have to expect that I won't be able to work in a dependencies codebase because it will most likely contain (multiple) concepts that I won't be able to understand, then that's a big no-no.
I have only done Haskell during college and my friend is doing Haskell in web backend in production so I'd say I have a pretty good feeling about the skill gap in Haskell. There are many concepts that he tries to explain to me which I don't get 100% but it really does feel like all I need is more time. It was like that at first with monads and then phantom types, row types, hkt etc. I'd say the biggest detractor for people is that it takes more than 1 blog post and 1 hobby project to comprehend everything. It may take 1-2 years to learn all the concepts. To me the beautiful thing is that the concepts learned aren't some language quirks but instead general programming/math concepts which you simply cannot think about in simpler languages like C#. With all that, I'm still heavily put off from Haskell by all the tooling and I just can't let go of the comfort of working in Visual Studio. In 10 years I hope either C# gets some of my favorite things from Haskell like HKT and better inferrence or Haskell gets better tooling and broader ecosystem. My bet is on the former but gafter keeps postponing HKTs spec after spec.
most people drive cars, and yet have very little understanding of how it actually works internally. As long as the interfaces are well designed, this works fine for most.
No one has ever been able to explain to me why I should use Haskell instead of something else. I get answers about idempotence and list comprehension and strong typing which are great tactics but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.
I know Carmack has presented a case to code in a pure functional style here https://www.gamasutra.com/view/news/169296/Indepth_Functiona... but that somewhat precludes the necessity of switching to another language from C++. Further, he advocates for a new keyword 'pure' to assist the compiler like const does, perhaps not knowing that const doesn't actually help the compiler out in practice.
Imagine you spent a career learning the piano. Would you expect to pick up the violin as if you were an expert?
Would it be reasonable to declare violin sucks! I've played piano for 30 years, vibrato is so hard it must be wrong, tell me why I should learn the violin?
Actually probably a lot will come with you, your dexterity and music theory will be quite useful, as will your ear.
But really, the instruments are very different and if you want to level up your sense of pitch or really learn how to sing a melody, the violin can be great for that...
Violin is definitely much harder to pick up than piano though, regardless of experience with other instruments. Obviously mastery is hard for both, but getting a basic pleasant melody out of a piano is far easier than doing the same with a violin.
Haskell is rather similar to a violin in that respect.
>Would you expect to pick up the violin as if you were an expert?
Rightly or wrongly, in programming we do expect this. We keep saying things like how languages are only tools, and how terms like "Java programmer" is as absurd as "Casio mathematician".
If you have effortlessly switched between imperative OO languages many times before, it's easy to think that any language you can't quickly learn must be because it's fundamentally and abnormally difficult.
There is some utility in carving out a subset of a language to make the remaining part easy to comprehend and easy to contribute to. C++ is a large and complicated language but every team seems to be using a different subset of it. The same thing would happen with Haskell. Every one might have a different idea of where to draw the line for restricting advanced features. The author might decide that Haskell 98 plus OverloadedStrings is good enough. That's a valid stylistic choice. I would have drawn the line further; I personally think features to simulate dependent types aren't worth it (think singletons or DataKinds or TypeInType) but lens is absolutely necessary even though it is difficult for beginners to understand. But ask a colleague of mine, and you might receive a response that we should embrace complicated type-level programming like the kind seen in Servant, but instead restrict TemplateHaskell. All these are valid stylistic choices but they fragment the community. And eventually debugging other people's code bases (say dependencies) you would sooner or later have to face features you don't use.
Let us not forget the roots of Haskell as a research language where ideas in functional programming are to be tried out. When it emerged in the 1980s it was literally because a committee wanted a solid foundation to replace a disparate mélange of functional programming languages. It succeeded in that, and immediately introduced new features then considered highly novel (e.g. type classes). In this sense, Haskell will never be as practical and pragmatic as Go, where moderately modern language features aren't even in the language. Choosing a language like Go could be a valid choice, and so is choosing a language like Haskell.
Haskell is no doubt an interesting language. I have yet to work on a project where it was the obvious choice but I’ve played around with it enough to like it.
What I don’t like are some (not all) of the people who use Haskell and talk about it online. They can be incredibly obnoxious. Haskell is not a tool they work with, it’s their entrance to a class of software engineers that you’re not capable of being part of.
Just for the record: Anyone can learn Haskell. If you’re struggling with it that’s because of a tooling / literature issue. Haskell people (even the nice ones) are bad at explaining the language. The tooling isn’t very friendly and the language is a shit sandwich to debug.
The concepts therein are no more difficult to grasp than any other in programming. Is a Monad a box or a burrito? Please stop. It’s a language feature that allows you to do certain things more concisely than the alternative. Stop pretending it’s magic and show people how to use it and why they should. Stop drawing pictures.
No, algebraic data types are not hard to understand. You just make a big deal out of them because you think the word algebraic sounds cool.
I could keep going but I think I’ve made my point.
Dear Haskell people: Get over yourselves. Do not mistake the larger software community’s disinterest in your pet language for their inability to use it. That’s simply not the case. If people had to use it even ‘lowly js devs’ would master it.
Everyone else: If you haven’t used it already it is a very cool language and worth learning even if just for personal edification. Don’t let the self appointed high priests turn you off. Don’t expect their help either.
I remember Rob Pike unveiling Go at a Google talk years ago and some Googler got up and said "why would Go be better than Haskel?" and Rob said "Because I can't understand Haskel source code and I'm pretty sure you could understand Go source code right now."
I think this is still one of the strongest selling points for Go. It is a pretty solid language with a few basic concepts which are repeated constantly. Sure, it doesn't have generics, error handling is a mess and the language design isn't as consistent as it should be.
But what it does, is pushing everybody to write simple code which is easy to understand. So many times I found the documentation (of some library) to be incomplete, but jumping right into the code answered the questions I had. I can't say that about every language.
“Much ink has been spilled waxing lyrical about the supposed mystique of monads. Instead, I suggest a path to enlightenment:
1. Don't read the monad tutorials.
2. No really, don't read the monad tutorials.
3. Learn about Haskell types.
4. Learn what a typeclass is.
5. Read the Typeclassopedia.
6. Read the monad definitions.
7. Use monads in real code.
8. Don't write monad-analogy tutorials.
In other words, the only path to understanding monads is to read the fine source, fire up GHC, and write some code. Analogies and metaphors will not lead to understanding.”
2. Chris/kqr's “The ‘What Are Monads?’ Fallacy?”, which mirrors the advice from Stephen Diehl:
“Instead, learn to use specific monads. Learn how Maybe a works, learn how Either e a works. Learn how IO a and [a] and r -> a works. Those are all monads. Learn to use them with the >>= operator and with do notation.
Once you've learned how to work with all of those, you'll have a really good idea of how monads can be used.
Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.”
Condescending tutorials seem to be an integrated part of Haskell culture. The rationale might be that people who don't already know Haskell should to talked to like kids. "Don't be scared, a monad is just like a Burrito!" and so on.
I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available.
I actually think Haskell is a very enjoyable language, but there is a culture around it which treats the type concepts (arrows, monads etc.) like goals in themselves rather than tools to achieve something useful.
Honestly, this blog post is cute but it does not actually give you understanding and insight into these concepts. Imho the only way to internalise these are through practice. Write code, get annoyed by repetition/boilerplate/etc... and discover that abstraction Foo solves that problem.
This is one of two posts that made things click for me. This one clearly distinguishes Functors, Applicatives, and Monads visually so that I don't get hung up on the names every time I encounter them.
The other article that demonstrated the practical purpose or path to constructing Monads showed a number of them using nested procedural syntax formatted to look like do-notation. [I can't remember the title/link, if anyone knows please post.] It went through async/await, maybe or list and showed them rearranged with the 'monad'ic parts off to the right where semi-colons might be.
Do-notation just took that and flattened the nested structures. The appreciation that these different computational contexts could all be structured the same way while focusing on what's happening apart from these contexts really demonstrated why it's useful and the power of being able to encapsulate these seemingly different ideas.
I'm sure I'll need to find a part-3 in my journey (perhaps Monad transformers) and so on, but I've at least got a good footing from those.
If learning it is no harder than any other programming language that presumes that every other programming language is equally easy to learn. Furthermore it assumes that people have an equally easy job learning whatever language they learn.
Neither one of these conditions are remotely indicated by research on the subject, therefore the statement is false.
Also I did try learning Haskell at one point and I found it harder than some other languages, I would say I found it Erlang level hard which I tried at about the same time( about 2009) but I think Erlang has a little more inclusiveness to their community IMHO
> Neither one of these conditions are remotely indicated by research on the subject, therefore the statement is false.
That does not follow. "Research does not prove it" means "therefore we don't know it's true", not "therefore it's false".
To your wider point: I think (but cannot prove) that some peoples' brains find FP easier to learn and some peoples' brains find procedural easier. And I think (but can prove even less) that the large majority find procedural easier.
> Neither one of these conditions are remotely indicated by research on the subject, therefore the statement is false.
What is the standard unit of measurement for quantifying just how difficult a language is to learn? Is there a standard unit of measurement for quantifying the competence of a person learning a programming language?
> If learning it is no harder than any other programming language that presumes that every other programming language is equally easy to learn.
Did you click through to the article? The HN title is (currently) "Learning Haskell is no harder than learning any other programming language". The article's actual title is "You are already smart enough to write Haskell".
You appear to be responding to what a zealous mod wrote not what anyone actually believes.
I really like the concise, well explained university course Brent Yorgey put together several years ago [1]. It also works well as a book club at work.
I always wondered whether imperative languages feel more intuitive to most programmers because they are:
a) Inherently simpler and require no prior advanced knowledge of math.
b) They are the default in every curriculum and once your brain is wired that way everything else seems counter-intuitive.
I remember in the first grade of my elementary school we were taught basic algebra and how sets work (union, intersection etc). I understood both concepts but I couldn't relate sets to the outside world. Like why do I even need this. Maybe new programmers feel this way about functional languages and Haskell.
I am a skilled Scala developer with knowledge of FP sufficient enough to make two contributions to the Typelevel cats/kittens ecosystem. Yet I was not even able to start a hobby project in Haskell. I always start and fall back to Python shortly after. Is it just me?
That's actually interesting. Was it the base prelude typeclasses that are too different ? AFAIK scala uses monadic code too .. I expected not too much difficulties using haskell. Maybe that's the syntax ?
I'd argue that it's not as simple. But there's a relativity factor here.
1) Haskell is much like math. You look at some concepts and ideas and fail to see what it is about, until 20 years down the road you finally click that "maaan" discrete mathematics was already encompassing 90% of computation it just wrapped it in counting instead of concrete computer instructions. Mathematicians have this culture of going too far, too concise, too fast for most of the population.
2) Mainstream culture imposes a negative toll on this because when you're fed Java or PHP (let's say you learned in the 2000s when they were peak fad) you'll interpret Haskell through them, brain already set on a belief, and it will make it twice harder. And it's really hard to disentangle the weird bliss of being able to manipulate elements through an interface (here it would be the syntax its idioms) from "objective reality". I too was enamored by PHP associative array syntax (so fun compared to C or Java lack thereof) and F5 to see a website change before my eyes. Haskell feels like a punishment compared to this. Not even counting the social aspect of it .. wordpress made people have colleagues and money.
Anyway, keep learning haskell (and FP, and logic, and math).
From my perspective, it isn't cut-and-dry. The quick response I give is:
If you are developing a business application and no one dies if something goes wrong for a few hours, the answer is "hell no". Productivity takes a hit for no strong upside to the biz.
If you are developing a safety-critical system, the answer is "maybe". This one is more obvious.
The more complex reasoning is that ultimately, almost every software system has to interface with the outside world in some way. Putting your functional programming layer as your principal interface between your internal and external domains is an extremely high-cost endeavor due to the complexity of handling things you can't predict. If your system is safety-critical, and you have extensive control over the external domain (e.g. dedicated, redundant sensor networks), you might be able to justify this added complexity because you can control many more variables than you would be able to otherwise.
An alternative approach that seems ideal to me at this time is to use imperative techniques as the principal architecture, and then use functional within that domain in the specific cases where it can be justified. Good examples of this would be C#/LINQ, or even invocation of F# from C# (e.g. rules engine). Imperative is extremely good at handling side-effects and managing exceptions. Functional is deterministic if you can keep it on rails. Using both where most suitable w/ interop between seems to be the most productive approach.
A quick corollary could be: "If you are exclusively using functional techniques to build your application, you are probably making a mistake".
The funny thing is that software engineering tools exist to relieve programmers of mental overload. This in turn can be used to build more complicated systems, at the cost of another level of mental overload.
So this begs the question: where are the complicated systems written in Haskell that could not have been realized in other languages? Or are Haskell programmers only using the language to sleep better at night?
i've learned rust in a month of coding sparsely. in fact, i'm as comfortable today at writing rust as i am at writing go.
i've been struggling to learn haskell for over half a year.
i think it's an amazing language, don't get me wrong.
but the fact that haskell is not harder to learn than any other programming languages is false.
after taking a few online course, tutorials and so on, i still believe it's one of the most interesting (if not the most interesting) programming language in existence and also the hardest.
>What do you need to write real Haskell? The core of the language is extremely simple. If you understand how to write and use
>pure functions and values
>pattern matching
>sum and product types
>how to glue together IO to make side effects
You can do pure functions, pattern matching, and sum and product languages in plenty of other languages that have much more user-friendly syntax, community, and documentation. Also doesn't hurt that they have impure IO so you don't have to jury-rig impure IO using a monad.
I took a Haskell class couple of years back (Functional Programming) as reference I worked for 12 years before as Software Engineer using Pascal, C, C++, Java, Perl, Shell, Python, Visual Basic, and I felt like I was learning Chinese, I really put extra effort, but Monads, Applicatives, etc were complicated and way above my head. I really never found a reason to continue that punishment, I admire the teacher and the community who work on it, maybe not for me. But not easy
[+] [-] li4ick|6 years ago|reply
But, even if you finish the Haskell Book(http://haskellbook.com), which is like 1300 pages, you're still going to be unable to contribute to a serious code base. Anyone who says otherwise is lying. Now, you have to understand at least 20 language extensions which you find randomly at the top of files {-# LANGUAGE ExtensionHere #-}. Now you have to understand how to really structure a program as either a stack of monad transformers, or free monads or anything else. Then you get into concurrency and to do that you have to understand how Haskell actually works, what non-strict computation does etc. etc. Otherwise you're going to get some nasty behaviour.
You think I'm done? Let's get to Lens. You can use Lens after a relatively short time of reading the docs. But to understand Lens? Very few people actually understand Lens.
Don't get me wrong, Haskell has spoiled me, and I don't really want to touch any other language (I still like Clojure, Rust, Python, Erlang). Once you get past that the language is a joy to use.
[+] [-] willtim|6 years ago|reply
Lens is a library, not part of Haskell the language, it's also not particularly widely used. If you are going to conflate the ecosystem with the language, then we could equally talk about the complexity of dependency injection frameworks, AbstractSingletonProxyFactoryBeans, aspect-oriented bytecode weaving, and enterprise Java beans when discussing how much "easier" Java programming is.
I have programmed both Java and Haskell professionally on multiple codebases. I honestly found more ad-hoc and incidental complexity in the Java world. At least the Haskell libraries generally were consistent in the abstractions used. Java the language, also had a lot of hidden complexity, for example its memory model (required knowledge for concurrent programming).
[+] [-] duckqlz|6 years ago|reply
[+] [-] coldtea|6 years ago|reply
The analogy with Promises, which by now everybody knows, even if pedantically flawed because they don't fit this or that criterium of Monads, is quite useful to get the idea...
[+] [-] octagonal|6 years ago|reply
[+] [-] giancarlostoro|6 years ago|reply
I like that with Go or Erlang everything I learned 5 or more years ago has still stuck to me. With D I can be effective quickly. With Rust I struggle a bit. Rust is probably great for building a web browser but doing backend web development feels way more work than Go or even Python (CherryPy). Haskell I dont even remember a darn thing anymore.
[+] [-] alkonaut|6 years ago|reply
The thing about imperative and OO programming is that it’s hard to do well. I honestly havent seen more than 1/10 developers write ”good” OO code even after 10 or 15 years as professionals. Large scale OO is a cognitive load that requires extreme focus, skill and talent. I prefer functional (or OO using an extreme functional discipline like all immutable types etc) because I don’t have that talent, focus and skill.
My point isn’t that Haskell should be the language of choice. I think it’s a great language but I think e.g laziness makes it too hard to reason about performance and behavior. Today I’d recommend F# I think.
[+] [-] hobofan|6 years ago|reply
"You are already smart enough to write Haskell"... if you accept that you are too dumb for most of Haskell and are therefore okay with being cut off from most of its ecosystem.
Digging into a dependency due to a bug or custom feature is something that usually happens on any bigger project of mine. If I have to expect that I won't be able to work in a dependencies codebase because it will most likely contain (multiple) concepts that I won't be able to understand, then that's a big no-no.
[+] [-] kungito|6 years ago|reply
[+] [-] chii|6 years ago|reply
I say the same is for haskell.
[+] [-] jimbob45|6 years ago|reply
I know Carmack has presented a case to code in a pure functional style here https://www.gamasutra.com/view/news/169296/Indepth_Functiona... but that somewhat precludes the necessity of switching to another language from C++. Further, he advocates for a new keyword 'pure' to assist the compiler like const does, perhaps not knowing that const doesn't actually help the compiler out in practice.
[+] [-] yomly|6 years ago|reply
Would it be reasonable to declare violin sucks! I've played piano for 30 years, vibrato is so hard it must be wrong, tell me why I should learn the violin?
Actually probably a lot will come with you, your dexterity and music theory will be quite useful, as will your ear.
But really, the instruments are very different and if you want to level up your sense of pitch or really learn how to sing a melody, the violin can be great for that...
[+] [-] ummonk|6 years ago|reply
Haskell is rather similar to a violin in that respect.
[+] [-] koala_man|6 years ago|reply
Rightly or wrongly, in programming we do expect this. We keep saying things like how languages are only tools, and how terms like "Java programmer" is as absurd as "Casio mathematician".
If you have effortlessly switched between imperative OO languages many times before, it's easy to think that any language you can't quickly learn must be because it's fundamentally and abnormally difficult.
[+] [-] cuddlecake|6 years ago|reply
[+] [-] kccqzy|6 years ago|reply
Let us not forget the roots of Haskell as a research language where ideas in functional programming are to be tried out. When it emerged in the 1980s it was literally because a committee wanted a solid foundation to replace a disparate mélange of functional programming languages. It succeeded in that, and immediately introduced new features then considered highly novel (e.g. type classes). In this sense, Haskell will never be as practical and pragmatic as Go, where moderately modern language features aren't even in the language. Choosing a language like Go could be a valid choice, and so is choosing a language like Haskell.
[+] [-] gassah_qwert|6 years ago|reply
What I don’t like are some (not all) of the people who use Haskell and talk about it online. They can be incredibly obnoxious. Haskell is not a tool they work with, it’s their entrance to a class of software engineers that you’re not capable of being part of.
Just for the record: Anyone can learn Haskell. If you’re struggling with it that’s because of a tooling / literature issue. Haskell people (even the nice ones) are bad at explaining the language. The tooling isn’t very friendly and the language is a shit sandwich to debug.
The concepts therein are no more difficult to grasp than any other in programming. Is a Monad a box or a burrito? Please stop. It’s a language feature that allows you to do certain things more concisely than the alternative. Stop pretending it’s magic and show people how to use it and why they should. Stop drawing pictures.
No, algebraic data types are not hard to understand. You just make a big deal out of them because you think the word algebraic sounds cool.
I could keep going but I think I’ve made my point.
Dear Haskell people: Get over yourselves. Do not mistake the larger software community’s disinterest in your pet language for their inability to use it. That’s simply not the case. If people had to use it even ‘lowly js devs’ would master it.
Everyone else: If you haven’t used it already it is a very cool language and worth learning even if just for personal edification. Don’t let the self appointed high priests turn you off. Don’t expect their help either.
[+] [-] nickbauman|6 years ago|reply
[+] [-] arendtio|6 years ago|reply
But what it does, is pushing everybody to write simple code which is easy to understand. So many times I found the documentation (of some library) to be incomplete, but jumping right into the code answered the questions I had. I can't say that about every language.
[+] [-] ducaale|6 years ago|reply
[+] [-] modernerd|6 years ago|reply
Instead, I really like:
1. Stephen Diehl's “Eightfold Path to Monad Satori” from “What I Wish I Knew When Learning Haskell”:
http://dev.stephendiehl.com/hask/#monads
“Much ink has been spilled waxing lyrical about the supposed mystique of monads. Instead, I suggest a path to enlightenment:
1. Don't read the monad tutorials. 2. No really, don't read the monad tutorials. 3. Learn about Haskell types. 4. Learn what a typeclass is. 5. Read the Typeclassopedia. 6. Read the monad definitions. 7. Use monads in real code. 8. Don't write monad-analogy tutorials.
In other words, the only path to understanding monads is to read the fine source, fire up GHC, and write some code. Analogies and metaphors will not lead to understanding.”
2. Chris/kqr's “The ‘What Are Monads?’ Fallacy?”, which mirrors the advice from Stephen Diehl:
https://two-wrongs.com/the-what-are-monads-fallacy
“Instead, learn to use specific monads. Learn how Maybe a works, learn how Either e a works. Learn how IO a and [a] and r -> a works. Those are all monads. Learn to use them with the >>= operator and with do notation.
Once you've learned how to work with all of those, you'll have a really good idea of how monads can be used.
Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.”
[+] [-] goto11|6 years ago|reply
I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available.
I actually think Haskell is a very enjoyable language, but there is a culture around it which treats the type concepts (arrows, monads etc.) like goals in themselves rather than tools to achieve something useful.
[+] [-] pwm|6 years ago|reply
[+] [-] karmakaze|6 years ago|reply
The other article that demonstrated the practical purpose or path to constructing Monads showed a number of them using nested procedural syntax formatted to look like do-notation. [I can't remember the title/link, if anyone knows please post.] It went through async/await, maybe or list and showed them rearranged with the 'monad'ic parts off to the right where semi-colons might be.
Do-notation just took that and flattened the nested structures. The appreciation that these different computational contexts could all be structured the same way while focusing on what's happening apart from these contexts really demonstrated why it's useful and the power of being able to encapsulate these seemingly different ideas.
I'm sure I'll need to find a part-3 in my journey (perhaps Monad transformers) and so on, but I've at least got a good footing from those.
[+] [-] bryanrasmussen|6 years ago|reply
Neither one of these conditions are remotely indicated by research on the subject, therefore the statement is false.
Also I did try learning Haskell at one point and I found it harder than some other languages, I would say I found it Erlang level hard which I tried at about the same time( about 2009) but I think Erlang has a little more inclusiveness to their community IMHO
[+] [-] AnimalMuppet|6 years ago|reply
That does not follow. "Research does not prove it" means "therefore we don't know it's true", not "therefore it's false".
To your wider point: I think (but cannot prove) that some peoples' brains find FP easier to learn and some peoples' brains find procedural easier. And I think (but can prove even less) that the large majority find procedural easier.
[+] [-] yakshaving_jgt|6 years ago|reply
What is the standard unit of measurement for quantifying just how difficult a language is to learn? Is there a standard unit of measurement for quantifying the competence of a person learning a programming language?
[+] [-] tome|6 years ago|reply
Did you click through to the article? The HN title is (currently) "Learning Haskell is no harder than learning any other programming language". The article's actual title is "You are already smart enough to write Haskell".
You appear to be responding to what a zealous mod wrote not what anyone actually believes.
[+] [-] aaronmu|6 years ago|reply
We defaulted to PHP and C# in the past.
We have quite some experience training people who just graduated and even people with backgrounds outside of tech.
Training someone from zero to autonomously writing production code is a lot easier in F# compared to PHP and C#.
We educate people in Elm and Haskell and switch over to F# when they’re ready to try building the first real thing end to end.
[+] [-] thrower123|6 years ago|reply
[+] [-] Tempest1981|6 years ago|reply
[+] [-] nvarsj|6 years ago|reply
https://www.seas.upenn.edu/~cis194/fall16/
[+] [-] olah_1|6 years ago|reply
https://www.amazon.com/Get-Programming-Haskell-Will-Kurt/dp/...
[+] [-] AnthonBerg|6 years ago|reply
[+] [-] tome|6 years ago|reply
https://github.com/bitemyapp/learnhaskell
[+] [-] colluphid|6 years ago|reply
[+] [-] massysett|6 years ago|reply
[+] [-] rishav_sharan|6 years ago|reply
[+] [-] macando|6 years ago|reply
a) Inherently simpler and require no prior advanced knowledge of math.
b) They are the default in every curriculum and once your brain is wired that way everything else seems counter-intuitive.
I remember in the first grade of my elementary school we were taught basic algebra and how sets work (union, intersection etc). I understood both concepts but I couldn't relate sets to the outside world. Like why do I even need this. Maybe new programmers feel this way about functional languages and Haskell.
[+] [-] ThrowawayR2|6 years ago|reply
c) That's the way microprocessors actually work. Machine language is just imperative commands and branch instructions.
[+] [-] vojta_letal|6 years ago|reply
[+] [-] agumonkey|6 years ago|reply
[+] [-] agumonkey|6 years ago|reply
1) Haskell is much like math. You look at some concepts and ideas and fail to see what it is about, until 20 years down the road you finally click that "maaan" discrete mathematics was already encompassing 90% of computation it just wrapped it in counting instead of concrete computer instructions. Mathematicians have this culture of going too far, too concise, too fast for most of the population.
2) Mainstream culture imposes a negative toll on this because when you're fed Java or PHP (let's say you learned in the 2000s when they were peak fad) you'll interpret Haskell through them, brain already set on a belief, and it will make it twice harder. And it's really hard to disentangle the weird bliss of being able to manipulate elements through an interface (here it would be the syntax its idioms) from "objective reality". I too was enamored by PHP associative array syntax (so fun compared to C or Java lack thereof) and F5 to see a website change before my eyes. Haskell feels like a punishment compared to this. Not even counting the social aspect of it .. wordpress made people have colleagues and money.
Anyway, keep learning haskell (and FP, and logic, and math).
[+] [-] verttii|6 years ago|reply
[+] [-] bob1029|6 years ago|reply
If you are developing a business application and no one dies if something goes wrong for a few hours, the answer is "hell no". Productivity takes a hit for no strong upside to the biz.
If you are developing a safety-critical system, the answer is "maybe". This one is more obvious.
The more complex reasoning is that ultimately, almost every software system has to interface with the outside world in some way. Putting your functional programming layer as your principal interface between your internal and external domains is an extremely high-cost endeavor due to the complexity of handling things you can't predict. If your system is safety-critical, and you have extensive control over the external domain (e.g. dedicated, redundant sensor networks), you might be able to justify this added complexity because you can control many more variables than you would be able to otherwise.
An alternative approach that seems ideal to me at this time is to use imperative techniques as the principal architecture, and then use functional within that domain in the specific cases where it can be justified. Good examples of this would be C#/LINQ, or even invocation of F# from C# (e.g. rules engine). Imperative is extremely good at handling side-effects and managing exceptions. Functional is deterministic if you can keep it on rails. Using both where most suitable w/ interop between seems to be the most productive approach.
A quick corollary could be: "If you are exclusively using functional techniques to build your application, you are probably making a mistake".
[+] [-] amelius|6 years ago|reply
So this begs the question: where are the complicated systems written in Haskell that could not have been realized in other languages? Or are Haskell programmers only using the language to sleep better at night?
[+] [-] eklavya|6 years ago|reply
[+] [-] pi-victor|6 years ago|reply
[+] [-] ummonk|6 years ago|reply
>pure functions and values >pattern matching >sum and product types >how to glue together IO to make side effects
You can do pure functions, pattern matching, and sum and product languages in plenty of other languages that have much more user-friendly syntax, community, and documentation. Also doesn't hurt that they have impure IO so you don't have to jury-rig impure IO using a monad.
[+] [-] spicyramen|6 years ago|reply