1. 30
  1.  

  2. 22

    Why can’t I learn Haskell the way I learned $BOZOLANG? Because $BOZOLANG is just like every other language you’ve already learned. Hash-mappy/stringy/numby/mutatey whatevers

    This is nonsense - Clojure, OCaml, Elixir etc can evidently be learned via web-apps without being “stringy/numby/mutatey whatevers”.

    Shame that most Haskell evangelists can’t be as honest as Simon Peyton Jones: the trade off for Haskell’s benefits is making things that are easy in other languages obscure and difficult (the ‘hair shirt’). Whether those trade offs are worth it is contextual and, probably, personal.

    1. 4

      Clojure, OCaml, Elixir

      Stronger point with OCaml than Elixir or Clojure, but you’d have to read very uncharitably to think I was talking about ML users. (Why would I be? ML users have and use a proper type system.)

      I was a Clojure user before Haskell. You’re still structuring your data in Clojure most often in terms of a Map, the semantics and general patterns involved aren’t much different from Python or Ruby. I was speaking to what’s most common in industry. Most programmers I’ve known are jumping between Ruby/Python/JS/Clojure or languages like them.

      1. 9

        I think you’re taking an overly reductionist line of thinking. Distilling languages down to “haskell’s type system” and “not haskell’s type system” will lead one to your philosophy, but misses out on a bunch of cool differentiating factors among languages. Erlang is great because of the concurrency model, Elixir builds on that with metaprogramming, Clojure inherits a lot of the nice qualities from the JVM, Scala brings an assload of complexity and pain to the act of writing code, python is as simple as dirt, rust has a reasonable type system and a great deal of control over your memory, etc, etc. Taking a binary approach to language classification is an over simplification and will constrain your thinking, which is objectively a Bad Thing.

        Also, as an aside, cut the crap with the smug tone, referring to languages your don’t like as $BOZOLANG isn’t constructive.

        1. 4

          I didn’t write the post because I wanted to talk about other languages. I wrote it because I wanted to explain why were taking a particular approach to teaching Haskell and why it requires taking learning the basics seriously (because it’s different).

          Haskell being different isn’t a value judgment, it’s an observation about the foundations of the language contra almost all others (pure lambda calculus vs. augmented lambda calculus or fully imperative semantics).

          If you’re secure in your choice of tools a single line like:

          Hash-mappy/stringy/numby/mutatey whatevers.

          shouldn’t create an entire sub-branch in a comment thread. That line also was not a value judgment, but a comment upon how easy it is for people to learn Ruby/Python/JS/etc. when they already know one of the other languages in that list.

          It doesn’t matter that Clojure inherits whatever from the JVM or Elixir adds metaprogramming and better syntax to Erlang. These are orthogonal to my point. I’ve used these languages (Clojure particularly) and am comfortable with them, I’m talking about the core semantics of the programming languages and how what they have in common is frequently ignored by programmers when reasoning about what it’s like to learn a programming language. When you learn Haskell, to understand it properly, you will need to be able to reason in terms of lambda calculus. It’s not difficult, but most people haven’t needed to learn this because very few programming languages have a pure lambda calculus as their core semantics.

          It’s about what’s different at the core. That’s all. You’re getting distracted by details irrelevant to the pedagogical issues because like most programmers, you’re taking for granted this collectively shared, fuzzy notion of “how programming works” that is mostly portable with minor modifications across most languages. Most programmers will never confront or understand what they’ve been taking for granted unless they use something outside that paradigm or they teach somebody that’s never programmed before.

          I should’ve made this clear in my initial reply but I let the OP’s “getting away from the point of the whole article” distract me.

          To understand a programming language, you have to learn the semantics of the programming language.

          1. 8

            I am not sure where I side in this argument, or if it is even necessary to take sides, but I think you are incorrect in assuming that people were offended by

            Hash-mappy/stringy/numby/mutatey whatevers.

            The part I found somewhat snarky and flippant was the use of the description $BOZOLANG for that group of languages, implying that they are useless.

            Not to mention that Haskellers tend to be somewhat arrogant about what they believe the “perfect” programming language is, so I already had to consciously overcome some prejudice before I could even start reading the article (and maybe I am showing that I still have some prejudice, in which case, I apologize).

            1. 4

              Haskell isn’t perfect, there’s tons I’d like to add/change/remove. (Fair chunk of Prelude, for example; the upcoming Dependent Haskell stuff is exciting but not perfect/ideal)

              I don’t even really want programmers-in-general to be convinced it’s a good language to use. I made the point recently on Quora that learning Haskell will not necessarily make you a better programmer in $DAYJOB. The article is about pedagogy, not language choice.

              I’ll edit the post so people stop getting distracted.

              1. 4

                Pre-emptive apologies if this is off-topic, but the thread seems mostly to be about this now.

                I see blog posts (and tweets, and reddit threads, etc) all the time about how Haskell has $THISIMPERFECTION therefore Haskell is completely worthless, and frequent posts (and tweets, etc) about how people who write Haskell are terrible people (usually not phrased as terrible – arrogant, pedantic, condescending, smug…pick a nasty adjective). You just did it yourself, though softening it with “tend to be.”

                Honest question: do you find snarking about Haskell and Haskellers to be more acceptable than snarking about other languages?

                I am new to Haskell, but honestly so far I haven’t met a single Haskeller who thinks Haskell is perfect – not even Kmett. And I see a bunch of Haskellers I know feeling that they must periodically assert that they know it isn’t perfect in order to avoid being labeled as arrogant, smug, etc. Do users of Golang or Ruby feel the need to frequently publicly assert their belief that their own language isn’t perfect?

                Again, I’m new, both to Haskell and to programming (Haskell is my first language; I was a linguist in my younger, more idealistic years), so these are sincere questions. This is in no way meant to posit a specific argument or take sides.

                1. 7

                  I am not flyingfisch, but I will answer from my perspective. 20+ years in industry, 10+ with Haskell, only one shipped professional project in Haskell, later abandoned and rewritten in C++.

                  do you find snarking about Haskell and Haskellers to be more acceptable than snarking about other languages?

                  No. All languages gets snarked about – and in most cases there is a kernel of truth under it.

                  And I see a bunch of Haskellers I know feeling that they must periodically assert that they know it isn’t perfect in order to avoid being labeled as arrogant, smug, etc.

                  This is because of fairly well earned reputation of Haskellers (mostly around the edges, not core people) being arrogant, pedantic, condescending and smug. When I gave talks on Haskell I did the same thing (I even had line, “Don’t worry, I am not one of ‘them’, lets have some fun”) – because I know the horrible reputation I am up against from the start of a talk. The Haskell core community is full of great people, but as you get out just a little toward the edges you meet the people that use Haskell as an arrogance set piece more than a programming language. They love being able to claim superiority and constantly throw it in others faces. Phrases like “Not smart enough to use Haskell, go use one of your ‘popular’ languages” and far worse / less useful things. This was doubly easy because in most cases they were completely abstracted from having to ship actual code in Haskell, so it gave criticism no purchase… they could claim whatever nonsense they wanted without evidence or reality intruding.

                  Do users of Golang or Ruby feel the need to frequently publicly assert their belief that their own language isn’t perfect?

                  No, because these languages both strive to be fairly inclusive, adopted by corporations and straightforward. Because they are constantly used on real production projects, their faults are laid bare and talked about constantly. Beyond that, the “You are too dumb to ever understand Ruby|Go” just doesn’t fly – they spend 5 minutes reading and have a basic app working – an hour later they have a basic Web App working. Also, both languages are populist and strive to grow in terms of users, something that Haskell has really only gotten on board with in the last few years… and is still have a lot of trouble with, let alone corporate adoption.

                  Again, I’m new, both to Haskell and to programming (Haskell is my first language; I was a linguist in my younger, more idealistic years), so these are sincere questions. This is in no way meant to posit a specific argument or take sides.

                  The bottom line is, if you want to promote Haskell or teach it… you have to be aware of the public perception of it. Beyond that, I think you have to go out of your way to avoid being arrogant, condescending, smug and asserting things without evidence like “This isn’t hypothetical – I’ve seen a lot of people give up on Haskell because this is how they tried to learn the language.” which you could simplify to “Trust Me” or “Because I Say So” – people burned by the Haskell community in the past will see that as dripping with arrogance.

                  This is unfair, you didn’t make Haskell have this reputation and were not even aware of it. However, you still have to deal with it. Enough people have been treated poorly by Haskellers (again, along the edges, not core people) and talked down to by them (mostly as a form of lame bullying) to view anyone who claims to come with good tidings from that camp with trepidation.

                  I think you just have to be aware that a lot of times, the people who might be reading your material have already been burned, they don’t come from a clean slate like you did.

                  1. 3

                    Thanks for writing this, you put my thoughts into words quite nicely. I said “tend to be”, because that’s been my experience, though I realize that YMMV.

                    I did not mean to be snarky in my comment, I was just making an honest observation about the experiences I have had with the Haskell community on their IRC channel and forums.

                    That said, I sincerely enjoy using the language, and I hope it continues to grow. And FTR, I have also met great Haskell community members, but for some reason the negative ones are the ones who are the first to pounce on beginners. Of course, that’s just been my experience, there may be some bias involved.

              2. 11

                I think I’ve finally realized why I find most of your writing so distasteful. I mean, I’ve always found your writing rather condescending (you knew that from our previous interactions), but here is a microcosm of the image you’re projecting in a single comment:

                If you’re secure in your choice

                but a comment upon how easy it is for people to learn Ruby/Python/JS/etc. when they already know one

                what they have in common is frequently ignored by programmers

                you will need to be able to reason in terms of lambda calculus

                but most people haven’t needed to learn

                You’re getting distracted

                like most programmers, you’re taking for granted

                Most programmers will never confront or understand

                what they’ve been taking for granted

                unless they use something outside that paradigm or they teach somebody that’s never programmed before.

                you have to learn the semantics

                Your writing is littered with authoritative prescriptions, but you are not a recognized authority on pedagogy. You write as if there’s one way to interpret or learn something, and I find that extremely off-putting.

                1. 6

                  Hi. I’m his coauthor, both of the book and that blog post. I am, in fact, a trained teacher. I have taught in universities, in technical colleges, in public schools in Japan, and in private schools.

                  Most of the sentence fragments you’ve picked out are not “authoritative prescriptions” at all; some of them aren’t even prescriptions, and a couple of them are seemingly quite uncontroversial (Haskell is based on a pure typed lambda calculus; if you eventually want to understand how Haskell works to any depth, you really do have to learn to reason in terms of lambda calculus. Perhaps you do not if you do not want to understand how it works under the hood). It’s fine that you don’t like the tone; other people have enjoyed it. And it’s fine if you personally can’t see through the tone to the content, but à chacun son goût.

                  Neither of us believes there is only way to learn anything. The book has one set of goals and priorities. His guide has another. Other Haskell books try other strategies. The world is generally a better place for having diversity, is it not?

                  1. 11

                    I don’t really see much to disagree with in what you’ve said. My issue is with bitemyapp’s tone in comments here. I see it as condescending and presumptive.

                  2. 1

                    You write as if there’s one way to interpret or learn something

                    I’ve mentioned at least two just in this thread, with different prerequisites and ideal circumstances. I even went into detail on the second one.

                    If your point is that you don’t need to learn the semantics of a programming language to understand the programming language, you are making a very controversial point indeed.

                    1. 14

                      Honest question [for bitemyapp] – do you feel the criticisms leveled at you by burntsushi have merit? I honestly agree with ‘em wholeheartedly and have consistently found your comments and tone hard to stomach and extremely off-putting. The thing is – I always thought this was what you intended.

                      I thought your goal was to be acidic and irritating while popping on every thread that mentions Haskell (or, half the time, doesn’t) to plug your book and be obnoxious so you don’t get ignored. I respected it as a business / marketing play and I think it worked fairly well for you as it was the only reason I poked at your blog and book – because I found you so contemptible.

                      If it has been you goal, let me compliment you on your effectiveness and skill at it, you are amazing. If it isn’t your goal, you might invest 6 minutes in this video by Sally Kohn (a TED talk): https://youtu.be/NCJTV5KaJJc and consider how much of your message is carried in tone, and more importantly how little of it will get through if your tone is abrasive to the reader.

                      1. 7

                        If your point is that you don’t need to learn the semantics of a programming language

                        No, that is not my point. Whether you’re correct or not is irrelevant (for example, I happen to agree with some of your points). My point is that your writing is unapproachable to me because of the number of assumptions littered at every turn about the knowledge and behavior of others. My evidence is the quotation in my previous comment. (The signpost is “you need” or “you did.”)

                        1. 1

                          I’m speaking from observation and experience teaching people Haskell. My coauthor is the real expert, but has never objected in my memory to anything I’ve said about pedagogy.

                          I’m not going to litter my writing with weasel words just to avoid giving you an excuse to complain. There are exceptions to the rule, that’s not material to my point and they’re uncommon and not densely concentrated in individual learners in my experience.

                          1. 11

                            I’m not going to litter my writing with weasel words

                            It’s quite possible to refrain from speaking from authority without using weasel words.

                            There are exceptions to the rule, that’s not material to my point and they’re uncommon and not densely concentrated in individual learners in my experience.

                            Again, you’re generalizing your experience instead of quantifying it.

            2. 9

              So now you need to understand ReaderT, which means needing to understand monad transformers and Reader. Understanding monad transformers requires understanding monads. Understanding Reader requires understanding the functor, applicative, and monad of functions. Understanding monads, applicative, and functor requires understanding higher-kinded types, constructor classes. Understanding constructor classes requires understanding typeclasses, kinds, and type constructors. Understanding higher-kinded types requires understanding type constructors and algebraic datatypes.

              Understanding kinds requires understanding types, which requires understanding terms and a teensy bit of how mathematical sets work. Understanding algebraic datatypes requires understanding products and sums. Understanding products and sums requires understanding addition, multiplication, types, cardinality, type constructors, and data constructors. Understanding type constructors requires understanding types and data constructors. Understanding data constructors requires understanding terms/expressions, functions, and values. Understanding terms, expressions, functions, and values requires understanding the lambda calculus.

              I think this degree of reduction is pretty absurd. Your own Haskell guide states

              Don’t sweat the stuff you don’t understand immediately. Keep moving!

              1. 2

                Working with the limitations of what’s available (such as in the guide) is one thing. It’s fine to cargo cult bits and pieces as you continue.

                Cargo culting the entire programming language along with common idioms? Ignoring something that can’t be explained temporarily is fine, as long as it’s not the majority of what you’re being shown and you’re not really going to have anything explained from the ground up. Just because having a type system makes it easier to guess-and-check doesn’t make it pedagogically sound.

                You can get away with this more if there’s a teacher or you’re pairing, but you still have to go back and learn how the language works at some point and when that time comes, how are you going to learn the language?

              2. 7

                To understand ScottyT, you’d need to understand ReaderT because that’s basically what it is

                I fundamentally disagree with this. To understand scotty you need to understand there is some context you can work in that gives you the computations you need to build a web application. That context is formed by ScottyT over some other monad. You do not need to understand the intricate details of monad transformers, and you certainly don’t need to understand the monads that Scotty was built on just to use Scotty.

                1. 4

                  You could use Scotty without understanding it, but my point is precisely about understanding.

                  You’ll thrash around and give up when you need to do something you can’t copy from previous demonstrations.

                  The point is about learning and equipping people to learn the rest of the ecosystem. I don’t care that somebody could follow along with a prebaked example, type it in, and fire it up and have a web server unless they are somehow learning the language in the process. In my experience, that’s not what results from doing this and it often leads to disappointment.

                  My co-author’s 10 year old son prefers learning Haskell with our book to the Minecraft modding tutorials he has precisely because he feels like he’s actually learning how things work in our book, whereas the Minecraft stuff is having him type in Java stuff without explaining how anything works. These are commercial Minecraft modding tutorials ostensibly written for children.

                  I explicitly mention an alternative approach that lets somebody dive into “practical” projects more quickly but it requires things like an in-person teacher to work more than rarely.

                  1. 2

                    I don’t care that somebody could follow along with a prebaked example, type it in, and fire it up and have a web server unless they are somehow learning the language in the process.

                    That is a hyperbole, and not what I was suggesting. You can teach someone the ability to learn an API from nothing without having them open up the source code and learn how it works. You can teach them how to develop an intuition for navigating the types in Haddock documentation - for example, what does it mean for a function to be an “entry point” (something akin to runScotty)? What do I have to provide this entry point, and how do I produce it?

                    Then you can teach them a little more about extension points and type classes, and how they can discover these through documentation. Haddock now generates concrete type signatures for instances, so your liftIO example can be discovered if one was to just expand the MonadIO type class and see liftIO :: IO a -> Scotty a, or whatever scotty’s monad is.

                    I don’t think what I’m suggesting here is giving people a prebaked example, but rather teaching them how to read the maps that are already presented to them, in order to get to their chosen destination as quickly as possible. I see similarities in what we’re suggesting, but my preference is a little more “top down”, whereas you want to approach things from the bottom up.

                    My co-author’s 10 year old son prefers learning Haskell with our book to the Minecraft modding tutorials he has precisely because he feels like he’s actually learning how things work in our book

                    Great, and I’m all for this style of learning - I share a common ground with that 10 year old son in that I also like to learn how things work. That said, many people - myself included now - simply do not have the time to learn how things work under the hood if we’re trying to learn something for a career change. It’s also worth noting that the 10-year old son does not have many years of experience building programs in other languages (my assumption could be false). When you already have such a comfort building software in other languages, I think taking so much rigour without letting them play openly could be a quick path to having them put the book down. Of course, these people may not be in your target audience, in which case this point can be dismissed.

                    I think there is a balance to be reached between exhaustive understanding and tangible results.

                  2. 4

                    Failing to be effective at Scotty because I didn’t understand monad transformers was why I stopped using Haskell for a project and just went back to Common Lisp; and the project I couldn’t finish after a few weeks in Haskell took a few hours — simply because I’m more fluent in CL. It was definitely a stumbling block for me.

                    1. 5

                      To build on what you’re saying, how are you supposed to know how to use an arbitrary IO action unless you know liftIO? You can’t so much as print something without knowing to use liftIO when you’re in ScottyT.

                      It turns into turtles(turtles := cargoCulting) all the way down if you follow this unconstructive method of teaching the language.

                      1. 2

                        I had a really good experience “cargo culting” Scotty using this post as a guide. It said use “liftIO” for one thing, so whenever I ran into something like that, I used liftIO! And after a while of using it (and finding lots of places I couldn’t use it, and figuring out why), I understood what it does. But that’s just how I learn, I know it doesn’t work for everyone.

                        1. 0

                          You were already a programmer to begin with right?

                          We’re writing for a larger audience than just experienced programmers and even among those I’ve seen many get frustrated with not knowing what’s going on. I actually just had someone in IRC mention they’re happier with the book than LYAH because they felt like they weren’t being shown what was actually going on.

                          Your experience isn’t implausible to us at all, but that’s part of the reason we wanted to write this post, many programmers take their experiences for granted as representing what most learners will experience if they attempt to learn the same concepts.