Saturday, October 1, 2011

@ConalElliott re: What resources & practices (teaching Haskell)

Conal Elliott asks: What resources & practices would you recommend for helping a group of Java & C++ programmers learn to work in Haskell? I saw the question first on Twitter, but my compression skills were not up to the task of answering there.

I have two recommendations: teach them the simplest definitions of the fundamentals; read programs with them, out loud, like children's books, skipping nothing.

These steps are often passed hurriedly, by teachers so steeped in a subject they don't realize how different their worlds are, by students eager to build things as quickly in a new programming language as they do in the old. Most likely, the students will assume that they just need to learn new syntax to be off and running. Indeed, I am sure they are capable, self-motivated software professionals and that they would succeed in learning Haskell, just without the deeper understanding that can make it such a joy.

As a test, ask your students to write down the definition of 'type'. I'll bet that their answers will be longer than 'set' and include some mention of bytes, words and big-endian. We were all trained to be mechanics instead of drivers, because all we had were go-carts.

C and its children will have left clutter in their minds. Types will be obstacles, efficiency a drug, correctness assured by machismo. They will gloss over code without really reading it, trying to fit it into an existing model. Saying things out loud helps slow things down, forces them to make connections between symbols, words and definitions so fundamental they are rarely written down. (I backtracked through Paul Hudak's book for hours trying to find out how to say '::'; newcomers ask pretty regularly in #haskell.)

Make sure they know all the places that patterns can appear in code and how they work. Make sure they know that data constructors are functions. Have them verify that with :type in GHCi. And that type constructors are functions, verifying with :kind. They should be familiar with the syntax and semantics of higher-order types before they meet IO, so that they understand it is not magic.

Lists, recursion, functional algorithms, none of these will be challenges, but constructs they have not seen before will give them much more trouble if they cannot deconstruct them to primitives. I cannot imagine Conal omitting such fundamental semantics from his lessons, but I can easily imagine both teacher and students, excited to build new stuff, skimping on the exercises necessary to flush out the old foundations and cement the new.

9 comments:

Zaki said...

How do you say "::"

Clifford Beshers said...

"has type"

lambdor said...

> Saying things out loud helps slow things down, forces them to make connections between symbols, words and definitions so fundamental they are rarely written down.

I think you're so right with that. Going from C++ to Java, C#, Python etc. is easy, because in some sense they are the same. But Haskell is a completely different category and you can't just skip over the fundamenteals. If I had to learn it again, I would definitely do very basic exercise.

danly said...

The problem with Haskell is not that it's obtuse or confusing; but that it's unreadable in the same manner as Perl.

There's a reason why many other languages opt to disallow most operator overloading.

Having <> <|> --> <-- and other 'symbols' change their meanings based on the underlying types means that for projects with 2 or more developers on board you're going to end up writing more comments than code.

danly said...

My personal frustration with Haskell was the insane amount of recasting I was doing to perform the simplest of tasks.

It seems like the moment you step away from algorithmic, abstract number crunching and into the land of I/O that Haskell crumbles into a hideous heap.

Anonymous said...

With all due respect, danly, if you don't like Haskell there are better forums to express it than in the comments of a post unrelated to your complaints other than that it is about Haskell.

(Your complaints themselves are not very accurate, but I won't clog the place further.)

MCAndre said...

Danly: Were you used to Perl or some other weakly-typed language? A major source of bugs is casting bad values (either implicitly or with C-like casting). You might find that after your program compiles in Haskell, you have a lot less bugs than you're used to.

danly said...

Anonymous: Considering the post is about converting C++/Java users it would seem that my particular failed experiment in conversion is relevant.

It's not like I just tried it for an afternoon, either. I used Haskell exclusively for home projects for about a year; producing a few toss-away games, plenty of web scraping scripts, et cetera.

MCAndre: I prefer strong typing, and usually abide by type constraints wherever possible in other languages; most of my recent work has been in C++ and C#.

However, with Haskell I felt as though I was spending more time divining how to get various libraries and types in Haskell to properly talk to one another then I was spending writing code.

I finally gave up on it when I went back to some old code, saw a myriad of specialized operators which I couldn't recall their purpose, and instead of busting open ghci to start inspecting I just archived my whole Haskell workspace and went back to C++.

I don't think I'm much of a slouch, either. I had high hopes for Haskell, and I still do. Most of my irritation with it would evaporate with better tools; but at the time Leksah was but a few months old and the Emacs support was dodgy at best.

Conal said...

Thanks, Cliff! I like your suggestions very much. We start tomorrow. I expect it'll be a lot of fun.