Haskell isn't designed for "average people" or "most people" and why should it be?
Real human beings use Haskell every day and love it.
Real human beings are capable of learning about teh scary maths and abstract theories.
You studied philosophy? Are you aware that most people don't understand anything about philosophical theories other than The Secret? Have you thought about how maybe those theories can change people's lives even though they're not aimed at a lowest common denominator? E.g. by being influential in the long run, and also by being intellectually stimulating to people who do bother to learn about it?
Rails-style success is not the goal for Haskell. It is an explicit anti-goal: the motto is "avoid success at all costs."
Terse and rude counterpoint to your thesis: Average people are lazy idiots and designing your language to appeal to them will result in a very popular incoherent mess, like Java and Ruby, and Dijkstra will make pointed remarks at you from his grave.
> Students often develop mathematical anxiety in schools, often as a result of learning from teachers who are themselves anxious about their mathematical abilities in certain areas. Typical examples of areas where mathematics teachers are often incompetent or semi-competent include fractions, (long) division, algebra, geometry "with proofs", calculus, and topology.
The programming world lately is inundated with tutorials that take their pedagogical style from the Teletubbies or at best Bob Ross. Maybe that is not a viable way of teaching Haskell—maybe there will need to be actual study involved, with textbooks and exercises and trained teachers. I don't really know.
> So, if I look into my foggy crystal ball at the future of computing science education, I overwhelmingly see the depressing picture of "Business as usual". The universities will continue to lack the courage to teach hard science, they will continue to misguide the students, and each next stage of infantilization of the curriculum will be hailed as educational progress.
I truly think I am, but I'm still struggling to learn Haskell...
>the abundance of poor pedagogy is surely a big reason why so many people develop mathematical anxiety.
I'm one of them, but 28 years later, I'm finally realizing that mathematics actually aren't that hard.
>The programming world lately is inundated with tutorials that take their pedagogical style from the Teletubbies or at best Bob Ross. Maybe that is not a viable way of teaching Haskell.
I think you hit the nail on the head, here, and I would like to hazard the following opinion: this is a deeply cultural problem in the United States, where we operate under the implicit belief that learning should be fun.
I don't mean to suggest that learning isn't rewarding, deeply satisfying, and occasionally exhilarating, but beyond learning your ABCs, it's rarely fun in the traditional sense. The problem, as I see it, is that we're failing tell the truth: learning non-trivial things is tedious, grueling, difficult, and tooth-grindingly frustrating while still being one of the most worthwhile things in life. Instead, we try to teach difficult or non-obvious concepts with the pedagogical equivalent of coloring books.
Stated differently, we simultaneously tell our youth that one has to "work hard" and "make sacrifices" for things like sports, while telling them that intellectual pursuits should be nothing less than blissfully entertaining.
As a general rule, I avoid anything labeled as being "for beginners", unless it's from a foreign editor. I'm lucky to be a fluent speaker of French, and I've noticed that French textbooks systematically approach subject matters in a rigorous, Cartesian, matter-of-fact way ... and this from grade 1!
It sucked. I mean it was awful. I spent weeks pouring over this thing, fighting the kind of frustration I described above.
And I got a D+ in undegraduate pre-calculus. I'm not a "math guy", but like everybody else, coloring books don't cut it after you start growing armpit hair. Big-boy concepts require big-boy methods.
Agreed, and thanks, that looks like an interesting paper.
In Gothenburg, Sweden, where I studied, Haskell is the first introductory language for students of CS and (I believe) CE. I know people who had barely even used a computer when they started there who are quite proficient with Haskell.
A side benefit of that is that the dorks like me who had been coding Perl and C and whatever for years before were thrown back to "oh shit, I have to actually study" mode and thus equalized with the people who were starting from scratch.
In terms of gender, when I started studying women were way less likely to have been coding since the age of 6. In the exam for a later course on Advanced Functional Programming that included monad transformers, functional embedded languages, the basics of dependently typed programming, and a semi-large Haskell programming project, I was happy to see a female classmate who hadn't programmed at all before university get the best score of anyone. But I digress... (Shoutout to Elin if you're reading!)
I'm somewhat anxious that my way of talking about this stuff might make people think that Haskell is way more difficult to learn than other languages, which I don't think is the case. I think people probably forget how much trouble they had grokking concepts like "objects" and "superclasses" and "generators" and so on. Haskell might be difficult in some other ways. Maybe in some ways it forces you to really understand things more than other languages. But it's still very possible to learn to program in Haskell without being exceptionally good at math.
Also, some of what people find tricky about Haskell is also present in other ML-style languages. I learned about O'Caml and some SML, and also Scheme, before I got into Haskell. So I knew about functional recursive styles of programming, and algebraic data types, and probably the biggest new things were lazy evaluation and the complete lack of side effects leading to the need for monadic sequencing. Those are not insurmountable.
Edit: By the way, I also appreciate how Haskell is becoming a sort of grass roots study group for coders to learn more about math, algebra, category theory, and what have you. It is not at all constrained to the universities anymore. This article is at the top of HN right now! Interesting times.
I think you're on to something here. It may be that programming languages that require you to 'reboot' are better suited to people totally new to programming than to people that already know how to program using some other methodology.
This is because compared to your old, well used and worn tools that new tool starts off as a set-back rather than an advantage and we more or less expect an instant productivity boost from new technology. That set-back then becomes a huge hurdle to overcome.
The question a programmer faced with a problem to solve is always one of investment: should I invest my time and effort into this new technology that will make me x times more productive or simply a better programmer (or someone capable of tackling more complex problems) a year or more down the line, or should I break out my trusty tools and turn a buck today (or turn a buck for my employer).
In most cases that equation works out in favor of the old tools so the energy required would need to be offset by concrete short term gains if a person is to switch from one tech to another.
That lack of concrete short-term gains is the big stumbling block for old hands, and if you manage to hack that then I think a lot of these better technologies would find traction.
People new to programming don't have that particular hang-up and I'd expect them to do much better with such new tool or different tools. (But they'd have the same problem if they needed to switch to other tools, it's just that in this particular instance they have a blank slate advantage, that evaporates the moment they become proficient in that technology.)
I went to the same school (I presume) in Gothenburg. I came into the CS classes with a decent amount of math background, and a small amount of programming classes (FORTRAN, C, ADA and other kinds of evil you use in chemistry and physics). Our CS intro classes were Java and Haskell. Haskell didn't feel like a reboot to me, it felt like using math to write programs, so at least for me, Haskell felt a lot more accessible than learning OO concepts in Java did. I am sure lecturers caring more about Haskell also mattered, but at least for my background, getting the Haskell concepts was a easier than the Java concepts.
This comment and the parent comment was really interesting. It's made me think about my current path and somethings I have done/learned that has incrementally pushed me towards functional programming over a long window of time.
I have played with Scheme, along with a half-completed SICP read through. I have also played with Haskell, along with partial read throughs of LYAH and real-world Haskell. Those experiences, although incomplete, have been important to me as a programmer. I don't think those actually 'sold' me on FP though.
I took a detour for some time and decided to become a better programmer using OO methodologies. I used TDD, I memorised SOLID and all that. Read up on design patterns and then used them practically. All well and good. From my toying with Scheme, Haskell and associated literature, I wasn't entirely satisfied. The code I produced was always a bit, I'm not sure, but not entirely satisfiying. It looked and worked better than what I get given to review when considering freelancers for an extra pair of hands - part of that is because of PHP I think. I carried on this way for a while in any case.
In my own self-learning, I'd started looking at language design and compilers. I read some books and decided I didn't have enough mathematical skills to consume the texts. I turned to learning discrete mathematics. That was a big eye opener. As I was reading about formal logic, set theory, proofs, etc, my mind kept turning to the problem of applying this in my work. Haskell and FP came to mind too. I believe doing this helped it finally click that a functional approach can be taken successfully in most of the work I do.
Whilst I was doing this, I had a fairly simple project that, if designed correctly, could make my life easier in future projects. I took an OO approach, designed the UML, started writing tests, etc. I decided that it was over-engineered or at least it was a lot of work for what I was trying to do. I decided to take an FP approach. I had the project completed with far less code that I was happier with. In the same language. That was almost like an 'epiphany moment'. I started getting seriously interested about functional programming then. I am now starting to see the flaws and bloat in the approaches I was taking before.
I recently read Out of the Tar Pit again. I had read it before but I didn't really get it. This time it excites me and made my brain whir with ideas. Especially on how I can make these approaches compatible with the constraints of my day job.
I actually now digest as much as I can about FP. Haskell, as an important player, frequently comes up. After laying the ground work, monads make a lot more sense. Haskell as a language excites me.
In my opinion, and I am self-taught when it comes to computers so it may not be 100% applicable, here is what I did to start my transition from imperative to declarative:
a) experiment with functional programming. Not actually get it and be ok with that. Carry on down the path.
b) Read HN and note articles posted about FP
c) Continue learning about imperative programming and consume the advice from OO thought leaders. Apply it to your work.
d) Learn a bit about maths and what it actually is, especially realising it's not just rote computation and application of algorithms from school.
e) Take a functional approach instead of an OO approach within the language you are working with. I did this in PHP. Not only will it show you how FP compares, it will also show you why Haskell/OCaml/etc by way of the deficiencies for FP in your chosen languages. In PHP, the type system (arrays as your Everyman...) and inconsistent type hints, explicit closing over of variables in outer scopes and piss-poor support for modules is one. Biggest is the only way to pass a function in the function namespace is to use a a fully-qualifies string (so function name along with namespace - you get undefined constant otherwise). With Java, it might be that you cannot have stand alone functions, which would suck.
This helped a lot for me but I'm sure spending a long time learning about software down to the hardware in my spare time contributed a lot to this too.
I had similar moments of epiphany while taking a course on abstract algebra and writing down some theorems in the form of Agda definitions.
As you may know, Agda is a Haskell-inspired language that has an even more powerful type system that makes it possible to define arbitrarily strong types, so that for instance you can define the type of a function that sorts a list—and then know confidently that any implementation of that type does indeed sort a list.
Anyway, when learning Agda, one comes across the notion that programs and proofs are in some sense the same thing. In other words that the code for a function can be read as a proof that the type of that function is inhabited. This seemed to me kind of bizarre and magical at first...
The more I thought about it, the more it made real sense, and not only that, it helped me understand proofs in a much more intuitive way. Before, if you had asked me what a proof is, I might have said "it's a very strict way to argue that a statement really is true." I didn't know that such proofs can be given formal structure... I couldn't really explain how to relate it to programming or functions...
But now that I've to some degree internalized the notion, if you ask me what a proof is, I might say it's an unambiguous description of how to transform an input into an output.
If you call the input P and the output Q, then P is a premise and Q is a conclusion, and the proof is the "arrow" P -> Q that through some well-defined sequence of "truth-preserving transformations" gives you knowledge of Q assuming nothing but P (and some fundamental axioms).
And in the world of programming, P is an input argument and Q is a resulting value, while the "arrow" P -> Q is a well-defined sequence of correct transformation that produces a Q-value given only a P-value (and some fundamental primitive functions).
So in this sense you can say that the implementation of a function is actually a kind of logical argument.
If you want to make use of this insightful connection (the "Curry-Howard equivalence"), however, your programming language needs to be pretty strict. If your P -> Q argument suddenly throws a null pointer exception, it's not much of an argument—it means your claim of being able to produce a Q given P is false.
This connection really helped me to understand both proofs and programs in a deeper way.
1. I'd heard of Agda but never read any code. What a brilliant language. I've added it to my list of my languages to spend time with.
2. I think your experience with Agda, especially the realisation that programs = proofs, leading to the Curry-Howard correspondence is exciting and rightfully bumps Agda to the top of my list.
Functional programming has also opened my eyes with type systems too. That actually, an inconsistent and weak type system is a bigger liability than once thought - I'm realising that daily. Especially with null values and "trying to call method on non-object" errors.
> ... Our intention is not to use any deep theorems of category theory, but merely to employ the basic concepts of this field as organizing principles. This might appear as a desire to be concise at the expense of being esoteric. But in designing a programming language, the central problem is to organize a variety of concepts in a way which exhibits uniformity and generality. Substantial leverage can be gained in attacking this problem if these concepts are defined concisely within a framework which has already proven its ability to impose uniformity and generality upon a wide variety of mathematics.
(John Reynolds, "Using category theory to design implicit conversions and generic operators", 1980.)
This is completely unrelated, but I found this paper to be similarly brilliant in its simplicity, clarity, and rigorous explanation: https://ramcloud.stanford.edu/raft.pdf
I have a hard time already convincing myself that correct sequential imperative algorithms are indeed correct - which probably means that I'm a bad programmer, but I can't change who I am. So convincing myself that that Raft, a concurrent algorithm, is correct (meets its specification) from an informal description is completely out of question - where is the formal proof of correctness?
Pedagogy is related to teaching children, andragogy is the education of adults. Each has unique challenges in that the young lack a base of knowledge and adults may have their own conceptual frameworks that need to be addressed.
Fair enough. Teaching non-developers functional programming may prove an entirely different challenge than teaching procedural programmers functional programming.
If you ever see anything online that has more than, say, half a dozen users, then it is NEVER the case that it suffers from "poor pedagogy". Why? Because it only takes 1 person to explain something, even if it's brief, people will start linking to there and eventually that method of explanation spreads. Like pointers in C, or classes - who would say they "suffer from poor pedagogy"? Anything is easy to teach, it just takes a single person who undersatnds it.
But.
If you ever see a technology truly suffer from "poor pedagogy" then it has a secret: in some fundamental, underlying way, it sucks.
Now the rules of the game are different. Suddenly, those who understand it will keep it under their breath and muddy the issue. No one will be explicit about these design choices and simply explain it: to explain it is to criticize it.
Then you have this case where people are holding their tongue, and those who eventually figure something out join that small cabal and simply don't mention it in normal, sane terms. They just don't - it would be rude to do so.
So remember. If you ever perceive poor pedagogy online in any tech subject, then it is camouflage, you are being lied to. In some fundamental way nobody will mention, it simply sucks.
At that point it's up to you to read between the lines and decide whether it still has enough benefits for you to learn it.
If you can explain clearly why something "sucks," then that explanation will spread and soon enough everyone will agree that you are right and the thing is useless and bad.
But if you notice yourself spreading irrational FUD under throwaway nicknames, and people don't seem to quickly catch onto your point, it may be that secretly and fundamentally, you are trolling.
it's inappropriate to make ad hominem attacks here, please refrain from doing so.
I didn't name any shortcomings in Haskell, I gave a general rule of thumb.
However, as you yourself demonstrate dramatically, by using an ad hominem and saying "spreading irational FUD", if I did have a clear and rational understanding of why your prefered technology has underlying shortcomings as a trade-off, which learners need to deal with, then I certainly would keep that information to myself. Who wants to be skewered by a community?
For this reason, you will never see clear explanations in that format. Instead, people who have attained that information for themselves will simply keep it to themselves - they won't teach it at all. They will teach it without reference to alternatives or to the strength of trade-offs that have been made.
That's why it will seem like a case of "poor pedagogy". But it never is that. It's a case of people in the know politely avoiding teaching it.
Please note that this is just my personal opinion, you can disagree with it. I didn't mean to start a debate.
You were claiming, with extremely vague reasoning from a throwaway account, that any technology with a reputation of bad pedagogy—obviously referring to Haskell—"fundamentally sucks."
Ad hominem fallacy is when you use a character attack but pretend it is a logical argument. I don't claim to make a logical argument—there's nothing logical in your comment to respond to.
If you don't want to start debates on the internet, try not telling people that the technology of their choice "fundamentally sucks."
Haskell doesn't have a reputation of bad pedagogy per se. My only point was what anyone's reaction should be when their personal impression is "bad pedagogy", in any area of software. It means that something is missing.
The idea that I'm "obviously referring to Haskell" and attacking me for it is beneath a response.
By the way this thread is an excellent example of why if I did have clear arguments for limitations baked into technology xyz, I certainly wouldn't share them: leaving learners in the difficult position of being presented difficul material/approaches, without a context, by those who understand it but keep mum about any limitations or difficulties.
(An example would be the syntax for standard library container operations in C++ (stl things), like with vectors. Nobody is going to explain that this syntax is so much uglier than higher-level vector/array syntax due to history, because the minute they did it would become obvious that there should be a CoffeeScript-like intermediate syntax parser that turns easy syntax into C++. Instead, it's presented without any such context, and nobody fixed the fact that this is harder to learn, harder to parse or debug, and more error-prone, than higher-level interpreted languages. It's just silently accepted without reference to this being a historical design trade-off.
I'm not objecting to it, but if something seems to be described circuitously or not being taught very well, then you're probably not being told the whole story.
Note that just as your original comment was murky and seemingly accusatory, so was my original reply to you—because I was parodying you.
You talked about unspecified things fundamentally and secretly sucking... so I said that you might be fundamentally and secretly trolling... who knows if any of these claims are true? They're both murky, vague, and somewhat paranoid.
The more straightforward argument you're producing now seems interesting, and I agree to some extent. I'll happily admit that Haskell—just like every single language—has historical warts and problems. Some of them are being addressed by the community, with some of them the community is stuck in arguing, etc.
C++ has always been firmly committed to backwards compatibility, which is one reason it is such a successful industrial language. Haskell has some of that too, and incompatible changes made to the core language are rare and always met with suspicion.
However, I don't think the Haskell community is especially dogmatic about the perfection of their own language. If anything, people are constantly discussing ways to make it better.
> The idea that I'm "obviously referring to Haskell" and attacking me for it is beneath a response.
You were replying directly to a post that claimed "the haskell community is, on the whole, truly awful at pedagogy" so it's easy to see how mbrock mistakenly concluded that, when you said "in some fundamental, underlying way, it sucks", you were referring to Haskell (when in fact you meant something entirely different).
His point is that your argument is so difficult to follow that it looks ad hoc. That, in combination with your throwaway account, raises red flags for trolling.
Ad hominem attacks are informal fallacies, granted, but they're still sometimes relevant.
>Anything is easy to teach, it just takes a single person who undersatnds it.
Spoken like someone who's never taught a difficult subject.
More to the point: this is what anti-intellectualism looks like, and it's not something to be proud of. If you made the effort to understand the occasional cryptic idea, you'd be amazed at the number of useful things you would learn.
I'm sorry, can you give a single example in the arts and sciences of something that has a reputation for "poor pedagogy"? (But is in fact just inherently difficult.)
Here are some inherently difficult subjects: quantum field theory, advanced calculus, orbital mechanics. Do any of these subjects suffer from a reputation of "poor pedagogy"?
I was referring instead to specific technological solutions, and, specifically, to encountering the idea that a subject "merely" suffers from poor pedagogy.
My comment had zero to do with the difficulty of any subject.
> Average people are lazy idiots and designing your language to appeal to them will result in a very popular incoherent mess, like Java and Ruby, and Dijkstra will make pointed remarks at you from his grave.
This is so funny
Yeah, Ruby and Java are not great. But they get the job done and produce value, and a lot of people use it.
I couldn't care less what Dijkstra thinks, he's not the one paying my bills
If you can see the value in Haskell great. But I find it hard to remember where are the big technology companies using Haskell (or tools built with it). Maybe because if you force 'mathematical consistency' in an inconsistent world everything else sucks
Sure. I'm a huge fan of bash scripts but I'm certain that attempting to enforce mathematical consistency on that language would be a comical disaster. (Although Gabriel Gonzales's "pipes" library for Haskell does make reference to a categorical interpretation of Unix pipes—hey, it's like this "math" stuff is quite widely applicable.)
Look up Facebook's use of Haskell if you're curious about industry use.
I worked for a startup that used Haskell for its entire backend, including a custom kind of graph database. I joined my coworkers to a Haskell hackathon in Zürich and met hundreds of people using the language commercially (and happily).
It's not that Java and Ruby suck—it's just that they're incoherent and messy. That may sound like slander but I have used both languages professionally, I have contributed to both Rails and the Ruby interpreter, I don't think they are bad tools. Everything is a tradeoff. If you CAN'T see the value in Haskell, I humbly recommend you look into it, but I can't force you to become interested.
No. The goal is to be useful in both research and industry by means of principled design based on mathematics and engineering. If that scares you, fine, you don't have to be interested in everything. If you think everything that's not designed to appeal to some notion of an "average programmer" is necessarily obfuscated and impossibly difficult, that's on you. Go ahead and avoid it.
No it is not. Haskell appeals to a certain audience, for the same reason that assembly and C/C++ appeal to a certain audience (fun fact: this category pattern will also be available in C++17 to be known as Concepts).
Sure, it is a niche language, and might have too steep a learning curve for the average programmer, but it is used in production, by real world businesses, and people write real world code with it.
Real human beings use Haskell every day and love it.
Real human beings are capable of learning about teh scary maths and abstract theories.
You studied philosophy? Are you aware that most people don't understand anything about philosophical theories other than The Secret? Have you thought about how maybe those theories can change people's lives even though they're not aimed at a lowest common denominator? E.g. by being influential in the long run, and also by being intellectually stimulating to people who do bother to learn about it?
Rails-style success is not the goal for Haskell. It is an explicit anti-goal: the motto is "avoid success at all costs."
Terse and rude counterpoint to your thesis: Average people are lazy idiots and designing your language to appeal to them will result in a very popular incoherent mess, like Java and Ruby, and Dijkstra will make pointed remarks at you from his grave.
http://www.paulgraham.com/avg.html