8 ms·

Courting Haskell

84 points by honzajavorek 7y ago

honzajavorek 7y ago
In the past two months I've been trying to learn the Haskell programming language. It's vastly different from anything I know, so it served me also as a way how to empathize with complete beginners to coding. This is a diary from my journey.
cdaringe 7y ago
To the whole article I say "ditto." Great summary. Also, didn't Guido say he wanted to eject the functional operators in Python? #hearsay
- sli 7y ago
  Slashdot had an interview with him where he talks about it[0], he basically says Python isn't the language for FP and then complains about readability which, YMMV on that one. I don't know if his opinion has changed in the last seven years, though. [0]: https://developers.slashdot.org/story/13/08/25/2115204/interviews-guido-van-rossum-answers-your-questions https://developers.slashdot.org/story/13/08/25/2115204/inter...
alephu5 7y ago
I've been been learning haskell by building a standard monolithic web application: Postgres DB, some static content, REST API and firebase authentication. It's taking longer than it would with a familiar language but so far I'm really enjoying the experience. I also took a small deviation a couple of weekends ago to build a simple OSM router and was pleased with the ease of development and performance. I'd recommend the book Practical Haskell by Alejandro Serrano Mena to get a firm introduction to the language and ecosystem of web applications. After that take at look at the libraries developed by FP complete.
- hopia 7y ago
  I'm using the same method as you. What are you using as the SQL and REST API libs? I'm using Servant and a library called Squeal for Postgres.
  - alephu5 7y ago
    I'm combining servant and Yesod into a single WAI app so that I can serve a web app and provide an API from the same server. For DB access I'm using persistent.
crimsonalucard 7y ago
A different way of thinking of abstraction or just a feeling of elegance or a feeling of power is not a sufficient explanation for why Haskell is so great. People want definitive and theoretically correct answers not talking points for a philosophical debate on programming styles. Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences.
- solomonb 7y ago
  Why does "Typed Functional Programming" have to be measurably "better" then OOP or procedural programming in order for Haskell to be considered a good language? All those questions at the end of your comment can be turned around the other way and are equally valid and unanswerable.
  - crimsonalucard 7y ago
    Why use it if it's not measure-ably better on some metric? It's important because we should only use things if they are better or the same. Not if they are worse. Sure, there are tradeoffs but if you quantify all tradeoffs something usually comes out better.
    - bawolff 7y ago
      If you can objectively measure the quality of a program (in a non-bs) way, you could probably make millions. There are whole industries around code health metrics.
      - crimsonalucard 7y ago
        I doubt I could make billions. I don't think it's that hard.
- dpatru 7y ago
  > Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences. Functional code tends to be shorter than procedural code. This allows you to think in bigger steps. For example, to read whitespace-separated numbers from stdin and print out their sum, in haskell you could write: main = interact $ show . sum . map read . words This uses very generic haskell functions to put the input into a list of strings, read each string as a number, sum the numbers and show the sum as a string. It seems to me that the equivalent procedural code would be much longer. Haskell's type system keeps track of what's going on and alerts you when you try to do something that doesn't make sense. For example, if you leave out the "read" function above, you would be trying to sum strings instead of numbers. Haskell's type checker would complain at compile time. This enables you to program at a high level without having to debug run-time errors because of type mistakes.
ggm 7y ago
At last! somebody else who is prepared to be honest about their fear of maths, and mathematical notation, and people who leap from "its just like school maths" to referring to the intimidating maths you skipped or failed in school and university. Its just like maths: requires deep brain structure wiring you may not have.
- Rerarom 7y ago
  I wonder why is there is so much fear of math on HN, which is essentially a STEM community. I would expect it among literary types, but not here.
  - bawolff 7y ago
    People overstate the connection between math and computer programming. Sure there are math heavy areas, but your average programmer isn't into them. At most programming typically involves the mildest amounts of whats in an intro to discrete math course.
  - Tarq0n 7y ago
    I think many people have a problem with mathematical notation, not maths itself. Mathematical notation is optimized for terseness and suitability for use on a whiteboard. Code has made great leaps in terms of readability and expressiveness compared to that, and is therefore more accessible to many people even when expressing the same concepts. For an example see the comments on the map/reduce post from yesterday.
- bawolff 7y ago
  Do people actually claim haskell-ish math (i.e. abstract algebra type stuff) is just like school (highschool?) math. If so, i wish i was in their high school. Sounds much more interesting than mine.
ssivark 7y ago
Though I’m not much of a Haskell programmer (spent some time learning it and writing toy programs), I would use a different motto to characterize Haskell: Stop prescribing (loose) design patterns; make them tight and refactor them into libraries, so they need only be written once. More than anything else, the language aims at providing modularity (and terseness, on the macro scale) for the programmer (while trying very hard to compile to something efficient). Even laziness is to enable more modularity. The “make design patterns tight” part is what ends up needing abstract mathematical reasoning (category theory is basically mathematical pattern reasoning distilled to its essence). The other consequence of abstracting patterns into libraries is that novice programmers end up with a lower “writing code” -vs- “reading+thinking” ratio compared to other languages. And this can be jarring to folks whose attitude is to learn by writing code (to discover patterns in the process).
- zozbot234 7y ago
  I wouldn't say that Haskell is "trying very hard" to enable efficient compilation. It might be trying hard given what the existing language semantics looks like, but we still don't have e.g. an elegant model that can equally account for both strict and lazy code (even though there's quite a bit of research in this area, based on fairly natural considerations). Reasoning about what code patterns actually require the use of general GC (because they involve creating references that might outlive their pre-defined scope, as with general closures) and what patterns might dispense with this is another source of potential efficiency improvements.
- ncmncm 7y ago
  "All patterns are anti-patterns." A pattern is a common expression form that your chosen language is unable to capture in a library. As we get better languages, what had been patterns turn into ordinary library components. Patterns composing those with one another and with core language features either become more library components, or challenges for subsequent language design.
  - mikekchar 7y ago
    I really disagree with this viewpoint. Patterns are just patterns. It doesn't matter if your language is able to express the pattern in a reusable form or not. The whole point of a pattern is that it is a common solution to a class of problems given a set of circumstances. Even if you have a "super awesome pattern" widget that you can use, you still need to know whether or not that pattern is appropriate for the problem you have and the circumstances in which the problem is expressing itself. Even beyond that, most programmers will be dealing with many more than one programming language in their lifetime. Learning well known design patterns is about understanding the abstractions, the problems and the circumstances so that when you are faced with a similar situation in another language you can efficiently see if there are capabilities that will help you out. Basically, consider the situation where you say, "Here's how I do X in this language. How would I do a similar thing in that language"? A design pattern gives you a name that you can use instead of "X". It also gives you a context where you can realise, this pattern is appropriate in here, but not appropriate there. When you talk to people you can simply say, "Can I easily implement a functor here? If not, how can I get similar utility in the same circumstances? Are there any caveats that are different than the normal ones?" It seriously speeds up the conversation. It also allows one to think about programming more generally rather than thinking of it only in terms of a specific programming language. Edit: grammar
avindroth 7y ago
no mention of haskellbook.com is surprising!
- olah_1 7y ago
  I read that book for 6 months straight, followed all the exercises, and quit when I realized I couldn't write a simple script that did something useful. But boy did I sure evangelize Haskell throughout the process! facepalm
  - solomonb 7y ago
    HPFFP was the book that finally made the language 'click' for me. It took 13 months to complete and only towards the very end did I start to get an understanding of how to structure an actual program larger then a leet code exercise. Its a _really_ different language from what I was used to (Javascript, Python, Ruby, etc). The book covered a lot of material that felt very basic to me, but interspersed with that was material that covered concepts I had never even considered, this was the case in the early chapters as well as later on. I found that the early chapters setup lots of concrete examples that later on would be revealed as simplified cases of highly abstract structures that occur all over the place. Uncovering these is a very magical experience. For that reason alone, I tell people to just grind through the book rather then skipping ahead to the more exciting material later on. But you don't have to like HPFFP or Haskell, nobody has to like anything. For me, Haskell is a joy to use and provides a seemingly never ending source of learning material to explore.
  - hopia 7y ago
    I started building straight away from day 1, getting a decent REST API together is surprisingly easy. You really don't need to understand most of the advanced type level stuff to stay productive. Maybe you tried to go for too high abstraction level straight off the bat? That can turn out very depressing on Haskell.
    - olah_1 7y ago
      Yes, for that reason I recommend Will Kurt's Haskell book instead. It's way more practical.
proc0 7y ago
" Powerful! It takes just a few lines to implement your own clone of Vim:" Uh, ok lol. " If SQL or Python read like an English sentence, then Haskell reads like math. Feels like math. It is math. " This is basically why there's a learning curve. Any analogy used as a learning example will typically fall short because in order to fully grasp the concepts you just have to learn the math behind it, because that's by design (denotational semantics).
alexashka 7y ago
Learning Haskell to write better software is like learning the language of the Eskimo and their elaborate vocabulary surrounding snow, only to realize most of the world doesn't have snow and that real progress is made by science, not linguistics.
- christiansakai 7y ago
  This fits my experience. But then I am only an average engineer.
- hopia 7y ago
  Ironically, Haskell pioneers exactly in programming scientific research while the rest of the languages focus more on the linguistics rather than the science.
  - alexashka 7y ago
    Haskell is the epitome of linguistics - it took a bet on an arbitrary set of conditions - lazy evaluation, immutability. These linguistic choices inform the rest of the language - monads were only invented as an escape hatch out of the prison the language designers put themselves into! If you think we ought to spend some more decades researching how to walk using our hands instead of our feet for getting around and are excited about the upcoming scientific literature regarding hand strength exercises required and all the rest of it, no problem. Most everyone else is walking using their feet just fine - they are solving other problems, namely real world problems that involve walking places.
    - youerbt 7y ago
      Ah, the classic - "we are producing REAL software over here". Always reminds me of this: https://steenschledermann.files.wordpress.com/2014/05/no-thanks-were-too-busy1.jpg https://steenschledermann.files.wordpress.com/2014/05/no-tha...
      - deleted 7y ago
        [deleted]
Rerarom 7y ago
You keep mistyping Clojure as Closure
andolanra 7y ago
"[Haskell is], indeed, heavily founded on mathematical theories (category theory and lambda calculus)." This is a pretty common reason given for why Haskell is "math-ey", but I'd argue it's simultaneously a bit misleading and also a bit boring. The part that's misleading is "Haskell is based on category theory": while a major feature of programming in Haskell (the monad abstraction) was inspired by category theory, the truth is that moment-to-moment programming in Haskell doesn't have much to do with category theory unless you want it to. Even monads require zero knowledge of category theory in order to understand or use! Some people find usefulness in category-theoretic abstractions, but many others—myself included!—don't at all: I've actually improved the performance of Haskell code in the past by cutting out category-theoretic abstractions in favor of simpler code, and by now I steer clear of most Haskell code that wears category theory on its sleeve. The part that's boring is that "Haskell is based on lambda calculus". The lambda calculus is a mathematical description of a simplified model of computation with functions and binding… and that's basically it. Almost every modern programming language uses variable binding as a basic feature, and in that sense, is "based on lambda calculus". Plenty of other languages, for example, are inspired deeply by Lisps (like JavaScript or Ruby) which in turn were directly inspired by the lambda calculus, but I don't think that lineage makes them particularly math-like. Instead, being "based on lambda calculus" usually just means that they have variables and closures—something true of almost every popular language used today! Now, Haskell-as-practiced can have a fair bit of math-inspired abstraction in it, which can be daunting to someone new to Haskell. Some of that abstraction is useful (e.g. monads), some of it isn't, but the fact that it exists is more about vocal Haskell programmers and bloggers, and much less about Haskell-the-language being "heavily founded on mathematical theories". And you'll also find plenty of programmers and bloggers arguing against the more math-heavy parts of the ecosystem: just in the past month I've seen plenty of Haskell programmers passing around links like https://www.simplehaskell.org/ https://www.simplehaskell.org/ which advocates for exactly this less-mathy approach to Haskell.
- the_duke 7y ago
  The big problem here is documentation. Most beginner Haskell resources go into complicated monad explanations very early on, instead of just showing how to use them like a tool. Intermediate resources are even worse.
deleted 7y ago
[deleted]
leshow 7y ago
Just like to point out that you don't need to know category theory to program Haskell. You don't need to read or watch Bartosz' videos to program (though they are great fun to watch), that part in the blog is a bit specious. LYAH isn't a great pedagogical resource. I recommend the Haskell First Principles book. It's long but rewarding and has frequent questions.
axilmar 7y ago
Too much drama for no reason. Haskell is a programming language; it has some neat features, and some downsides. If it's the right tool for the job at hand, use it, otherwise use something else.

84 points by honzajavorek 7y ago

In the past two months I've been trying to learn the Haskell programming language. It's vastly different from anything I know, so it served me also as a way how to empathize with complete beginners to coding. This is a diary from my journey.

cdaringe 7y ago

To the whole article I say "ditto." Great summary. Also, didn't Guido say he wanted to eject the functional operators in Python? #hearsay

sli 7y ago
Slashdot had an interview with him where he talks about it[0], he basically says Python isn't the language for FP and then complains about readability which, YMMV on that one. I don't know if his opinion has changed in the last seven years, though. [0]: https://developers.slashdot.org/story/13/08/25/2115204/interviews-guido-van-rossum-answers-your-questions https://developers.slashdot.org/story/13/08/25/2115204/inter...

alephu5 7y ago

I've been been learning haskell by building a standard monolithic web application: Postgres DB, some static content, REST API and firebase authentication. It's taking longer than it would with a familiar language but so far I'm really enjoying the experience. I also took a small deviation a couple of weekends ago to build a simple OSM router and was pleased with the ease of development and performance. I'd recommend the book Practical Haskell by Alejandro Serrano Mena to get a firm introduction to the language and ecosystem of web applications. After that take at look at the libraries developed by FP complete.

hopia 7y ago
I'm using the same method as you. What are you using as the SQL and REST API libs? I'm using Servant and a library called Squeal for Postgres.
- alephu5 7y ago
  I'm combining servant and Yesod into a single WAI app so that I can serve a web app and provide an API from the same server. For DB access I'm using persistent.

crimsonalucard 7y ago

A different way of thinking of abstraction or just a feeling of elegance or a feeling of power is not a sufficient explanation for why Haskell is so great. People want definitive and theoretically correct answers not talking points for a philosophical debate on programming styles. Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences.

solomonb 7y ago
Why does "Typed Functional Programming" have to be measurably "better" then OOP or procedural programming in order for Haskell to be considered a good language? All those questions at the end of your comment can be turned around the other way and are equally valid and unanswerable.
- crimsonalucard 7y ago
  Why use it if it's not measure-ably better on some metric? It's important because we should only use things if they are better or the same. Not if they are worse. Sure, there are tradeoffs but if you quantify all tradeoffs something usually comes out better.
  - bawolff 7y ago
    If you can objectively measure the quality of a program (in a non-bs) way, you could probably make millions. There are whole industries around code health metrics.
    - crimsonalucard 7y ago
      I doubt I could make billions. I don't think it's that hard.
dpatru 7y ago
> Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences. Functional code tends to be shorter than procedural code. This allows you to think in bigger steps. For example, to read whitespace-separated numbers from stdin and print out their sum, in haskell you could write: main = interact $ show . sum . map read . words This uses very generic haskell functions to put the input into a list of strings, read each string as a number, sum the numbers and show the sum as a string. It seems to me that the equivalent procedural code would be much longer. Haskell's type system keeps track of what's going on and alerts you when you try to do something that doesn't make sense. For example, if you leave out the "read" function above, you would be trying to sum strings instead of numbers. Haskell's type checker would complain at compile time. This enables you to program at a high level without having to debug run-time errors because of type mistakes.

ggm 7y ago

At last! somebody else who is prepared to be honest about their fear of maths, and mathematical notation, and people who leap from "its just like school maths" to referring to the intimidating maths you skipped or failed in school and university. Its just like maths: requires deep brain structure wiring you may not have.

Rerarom 7y ago
I wonder why is there is so much fear of math on HN, which is essentially a STEM community. I would expect it among literary types, but not here.
- bawolff 7y ago
  People overstate the connection between math and computer programming. Sure there are math heavy areas, but your average programmer isn't into them. At most programming typically involves the mildest amounts of whats in an intro to discrete math course.
- Tarq0n 7y ago
  I think many people have a problem with mathematical notation, not maths itself. Mathematical notation is optimized for terseness and suitability for use on a whiteboard. Code has made great leaps in terms of readability and expressiveness compared to that, and is therefore more accessible to many people even when expressing the same concepts. For an example see the comments on the map/reduce post from yesterday.
bawolff 7y ago
Do people actually claim haskell-ish math (i.e. abstract algebra type stuff) is just like school (highschool?) math. If so, i wish i was in their high school. Sounds much more interesting than mine.

ssivark 7y ago

Though I’m not much of a Haskell programmer (spent some time learning it and writing toy programs), I would use a different motto to characterize Haskell: Stop prescribing (loose) design patterns; make them tight and refactor them into libraries, so they need only be written once. More than anything else, the language aims at providing modularity (and terseness, on the macro scale) for the programmer (while trying very hard to compile to something efficient). Even laziness is to enable more modularity. The “make design patterns tight” part is what ends up needing abstract mathematical reasoning (category theory is basically mathematical pattern reasoning distilled to its essence). The other consequence of abstracting patterns into libraries is that novice programmers end up with a lower “writing code” -vs- “reading+thinking” ratio compared to other languages. And this can be jarring to folks whose attitude is to learn by writing code (to discover patterns in the process).

zozbot234 7y ago
I wouldn't say that Haskell is "trying very hard" to enable efficient compilation. It might be trying hard given what the existing language semantics looks like, but we still don't have e.g. an elegant model that can equally account for both strict and lazy code (even though there's quite a bit of research in this area, based on fairly natural considerations). Reasoning about what code patterns actually require the use of general GC (because they involve creating references that might outlive their pre-defined scope, as with general closures) and what patterns might dispense with this is another source of potential efficiency improvements.
ncmncm 7y ago
"All patterns are anti-patterns." A pattern is a common expression form that your chosen language is unable to capture in a library. As we get better languages, what had been patterns turn into ordinary library components. Patterns composing those with one another and with core language features either become more library components, or challenges for subsequent language design.
- mikekchar 7y ago
  I really disagree with this viewpoint. Patterns are just patterns. It doesn't matter if your language is able to express the pattern in a reusable form or not. The whole point of a pattern is that it is a common solution to a class of problems given a set of circumstances. Even if you have a "super awesome pattern" widget that you can use, you still need to know whether or not that pattern is appropriate for the problem you have and the circumstances in which the problem is expressing itself. Even beyond that, most programmers will be dealing with many more than one programming language in their lifetime. Learning well known design patterns is about understanding the abstractions, the problems and the circumstances so that when you are faced with a similar situation in another language you can efficiently see if there are capabilities that will help you out. Basically, consider the situation where you say, "Here's how I do X in this language. How would I do a similar thing in that language"? A design pattern gives you a name that you can use instead of "X". It also gives you a context where you can realise, this pattern is appropriate in here, but not appropriate there. When you talk to people you can simply say, "Can I easily implement a functor here? If not, how can I get similar utility in the same circumstances? Are there any caveats that are different than the normal ones?" It seriously speeds up the conversation. It also allows one to think about programming more generally rather than thinking of it only in terms of a specific programming language. Edit: grammar

avindroth 7y ago

no mention of haskellbook.com is surprising!

olah_1 7y ago
I read that book for 6 months straight, followed all the exercises, and quit when I realized I couldn't write a simple script that did something useful. But boy did I sure evangelize Haskell throughout the process! facepalm
- solomonb 7y ago
  HPFFP was the book that finally made the language 'click' for me. It took 13 months to complete and only towards the very end did I start to get an understanding of how to structure an actual program larger then a leet code exercise. Its a _really_ different language from what I was used to (Javascript, Python, Ruby, etc). The book covered a lot of material that felt very basic to me, but interspersed with that was material that covered concepts I had never even considered, this was the case in the early chapters as well as later on. I found that the early chapters setup lots of concrete examples that later on would be revealed as simplified cases of highly abstract structures that occur all over the place. Uncovering these is a very magical experience. For that reason alone, I tell people to just grind through the book rather then skipping ahead to the more exciting material later on. But you don't have to like HPFFP or Haskell, nobody has to like anything. For me, Haskell is a joy to use and provides a seemingly never ending source of learning material to explore.
- hopia 7y ago
  I started building straight away from day 1, getting a decent REST API together is surprisingly easy. You really don't need to understand most of the advanced type level stuff to stay productive. Maybe you tried to go for too high abstraction level straight off the bat? That can turn out very depressing on Haskell.
  - olah_1 7y ago
    Yes, for that reason I recommend Will Kurt's Haskell book instead. It's way more practical.

proc0 7y ago

" Powerful! It takes just a few lines to implement your own clone of Vim:" Uh, ok lol. " If SQL or Python read like an English sentence, then Haskell reads like math. Feels like math. It is math. " This is basically why there's a learning curve. Any analogy used as a learning example will typically fall short because in order to fully grasp the concepts you just have to learn the math behind it, because that's by design (denotational semantics).

alexashka 7y ago

Learning Haskell to write better software is like learning the language of the Eskimo and their elaborate vocabulary surrounding snow, only to realize most of the world doesn't have snow and that real progress is made by science, not linguistics.

christiansakai 7y ago
This fits my experience. But then I am only an average engineer.
hopia 7y ago
Ironically, Haskell pioneers exactly in programming scientific research while the rest of the languages focus more on the linguistics rather than the science.
- alexashka 7y ago
  Haskell is the epitome of linguistics - it took a bet on an arbitrary set of conditions - lazy evaluation, immutability. These linguistic choices inform the rest of the language - monads were only invented as an escape hatch out of the prison the language designers put themselves into! If you think we ought to spend some more decades researching how to walk using our hands instead of our feet for getting around and are excited about the upcoming scientific literature regarding hand strength exercises required and all the rest of it, no problem. Most everyone else is walking using their feet just fine - they are solving other problems, namely real world problems that involve walking places.
  - youerbt 7y ago
    Ah, the classic - "we are producing REAL software over here". Always reminds me of this: https://steenschledermann.files.wordpress.com/2014/05/no-thanks-were-too-busy1.jpg https://steenschledermann.files.wordpress.com/2014/05/no-tha...
    - deleted 7y ago
      [deleted]

Rerarom 7y ago

You keep mistyping Clojure as Closure

andolanra 7y ago

"[Haskell is], indeed, heavily founded on mathematical theories (category theory and lambda calculus)." This is a pretty common reason given for why Haskell is "math-ey", but I'd argue it's simultaneously a bit misleading and also a bit boring. The part that's misleading is "Haskell is based on category theory": while a major feature of programming in Haskell (the monad abstraction) was inspired by category theory, the truth is that moment-to-moment programming in Haskell doesn't have much to do with category theory unless you want it to. Even monads require zero knowledge of category theory in order to understand or use! Some people find usefulness in category-theoretic abstractions, but many others—myself included!—don't at all: I've actually improved the performance of Haskell code in the past by cutting out category-theoretic abstractions in favor of simpler code, and by now I steer clear of most Haskell code that wears category theory on its sleeve. The part that's boring is that "Haskell is based on lambda calculus". The lambda calculus is a mathematical description of a simplified model of computation with functions and binding… and that's basically it. Almost every modern programming language uses variable binding as a basic feature, and in that sense, is "based on lambda calculus". Plenty of other languages, for example, are inspired deeply by Lisps (like JavaScript or Ruby) which in turn were directly inspired by the lambda calculus, but I don't think that lineage makes them particularly math-like. Instead, being "based on lambda calculus" usually just means that they have variables and closures—something true of almost every popular language used today! Now, Haskell-as-practiced can have a fair bit of math-inspired abstraction in it, which can be daunting to someone new to Haskell. Some of that abstraction is useful (e.g. monads), some of it isn't, but the fact that it exists is more about vocal Haskell programmers and bloggers, and much less about Haskell-the-language being "heavily founded on mathematical theories". And you'll also find plenty of programmers and bloggers arguing against the more math-heavy parts of the ecosystem: just in the past month I've seen plenty of Haskell programmers passing around links like https://www.simplehaskell.org/ https://www.simplehaskell.org/ which advocates for exactly this less-mathy approach to Haskell.

the_duke 7y ago
The big problem here is documentation. Most beginner Haskell resources go into complicated monad explanations very early on, instead of just showing how to use them like a tool. Intermediate resources are even worse.

deleted 7y ago

[deleted]

leshow 7y ago

Just like to point out that you don't need to know category theory to program Haskell. You don't need to read or watch Bartosz' videos to program (though they are great fun to watch), that part in the blog is a bit specious. LYAH isn't a great pedagogical resource. I recommend the Haskell First Principles book. It's long but rewarding and has frequent questions.

axilmar 7y ago

Too much drama for no reason. Haskell is a programming language; it has some neat features, and some downsides. If it's the right tool for the job at hand, use it, otherwise use something else.