Hacker News Reader

Comment by Surio | Hacker News Reader

Relevant points on Haskell, from another discussion, and sort of echoes my own thoughts:

http://news.ycombinator.com/item?id=5314701

http://news.ycombinator.com/item?id=5314507

At university the very first language we are taught is Haskell. Lots of people had never programmed before, in anything and everyone managed fine. Nothing scary at all, no need for an understanding of category theory or anything.

Monads are (fairly) simple things that just have a really bad reputation, partly the fault of the haskell docs which make them seem complex.

Firstly:

Functors are things we can map over in a logical way; thats it. Monads are just a fancy way of saying "side-effects might happen here" (obviously not in all cases, but its fair enough for most uses - things like the Maybe Monad are not side effects)

I know monads are supposed to be simple, but I've been playing with Haskell on and off for years now and I still can't figure out how do-notation desugars into >>= operations.

It's not intuitive, but it's straightforward once you understand the semantics. There are basically two cases. Case 1:

    x <- monadicFunctionA
    monadicFunctionB

is rewritten as:

    monadicFunctionA >>= \x -> monadicFunctionB

The important thing here is that x is just the variable name in an lambda expression that you don't see. Case 2:

    monadicFunctionA
    monadicFunctionB

is rewritten as:

    monadicFunctionA >> monadicFunctionB

Where >> === >>= \_ ... . Given these rules, you can approximate do-notation like so:

    monadicFunctionA >>=
    \x -> monadicFunctionB >>
    monadicFunctionC ...

    do
      a
      rest

desugars to

    a >>
    do
      rest

and

    do
      x <- a
      rest

desugars to

    a >>= \x ->
    do
      rest

Monads are fairly easily expressed in mathematics but trying to explain them conversationally appears to be an exercise in futility. There are dozens or hundreds of these explanations on the Internet and haven't seen one that hasn't been declared so wrong by the ones-who-know. (edit: and I'm not one-who-knows but I'm pretty sure "side effects might happen here" falls in this category). Classes, objects, functions, and so forth don't have these issues. There are nitpicks and minor variances between how different languages conceive these, but all seem to be fairly easy to explain and understand.

I don't know, my dinner table explanation of monads has always been that they are DSLs. Even the Gentle Introduction offers this viewpoint (it develops a DSL in Haskell, as a monad, for writing resourceful computations, that is, computations which consume some user-definable resource at each step and automatically suspend upon consumption of all available resources).

After all, one of the philosophies of software development is that you're essentially building up your application as a layer of languages, each of which uses the constructs of the language beneath it as its own primitives, until at the highest level you have what is nothing more or less than a language built from the ground up to express the actions of your application in the simplest terms.

You can write a lot of Haskell software without ever delving much more into monads than what I just wrote. It's really that easy. Monad transformers also tend to scare people, but that is silly. A monad transformer just takes the DSL that you've already made with your current monad and it adds in new language features and functionality for you automatically. That's all.

Classes and objects don't have this issue because there is no underlying formal definition for them. They're also less general. Most descriptions of basic OOP ideas are on the same level as "side effects might happen here"; there's just nobody to correct them and nothing to correct them against.

Don't get me started about pointers. They're at least as difficult to grasp for most beginners than monads ever were. Hell, people have days of trouble just with references as in Java!

Functions do have this issue, and most of what different languages call "functions" aren't. It's just that unlike monads, functions have entered the common mind and people talking about them informally far outnumber those interested in correctness. And many people have plenty of problems with things like higher-order functions.

I'm curious what school you went to, there can't be a lot of universities that teach Haskell?

University of Texas at Austin teaches Haskell to 2nd year students in a required course: CS 337 - Theory in Programming Practice.

Programming Languages is also taught in Haskell, but it's an optional course and languages varies by professor.

Imperial College London, I believe the Oxford also teach Haskell to first year CS students.

Glasgow University teaches Haskell to 2nd year students.

University of Bristol teaches Haskell in the first year (along with C, Java and a Prolog varient called Frill) if you're doing CS or CSE (Computer Systems Engineering, four year mix of CS and EE).

I wouldn't be surprised if Oxford and Cambridge both teach it as well since last I looked (well over a decade ago now) their CS courses had a heavy theoretical slant and Haskell and the Lambda calculus go together well!

I'd imagine that the likelihood of being taught Haskell at university correlates well with the university treating CS as an offshoot of it's maths department.

Reply on news.ycombinator.com