viernes, 26 de julio de 2013

Why Haskell at School matters

Today I want to share a wonderful experience.

I'm professor of introductory programming in two years at Florentino Ameghino School and one at Universidad Nacional de Quilmes, Buenos Aires, Argentina.

This time I want to speak about my work at the school. It's my second year as a professor. Kids have 15-16 and 16-17 years old (4th and 5th year of secondary school, respectively) .

Last year, 4th year students had not programming experience. The same does not occur to the current 4th year, since they have played for a long time with Scratch when they were in 3rd year.

For both courses I started with a language called Gobstones, which we use at the university where I studied (and where I'm actually working). This programming language was created for educational purposes with some basic features of imperative programming, but designed with total purity (you can't modify parameters, no I/O operations, no global variables, etc.). There is a very clear separation between commands and expressions, and the same with procedures (that denote commands) and functions (that denote pure expressions). Aditionally, you can not watch intermediate steps or even debug a Gobstones program. There is only an entry point called Main, and you can only see the input board and the output board (the execution result of that procedure).

On the other hand, this language presents an universe of discourse that is simple but challenging: coloured stones, a board with cells that contains them, and a grabber at a given cell. You can represent many different things using only those elements.


The primitive values (and types) are:
  • Red, Blue, Green, Black (Color type)
  • North, South, East, West (Direction type)
  • Integers
  • Booleans

The primitive commands are:
  • PutStone(<color>)
  • TakeStone(<color>)
  • MoveTo(<direction>)
The control structures are:
  • repeatWith <index> in <firstValue> .. <lastValue>
  • while(<boolean>) { <commands> }
  • if(<boolean>) { <commands> } else { <commands> }
And there are definitions of new procedures and functions:

procedure <procedureName>(<params>)
{ <commands> }

function <functionName>(<params>)

   <commands>
   return(<expression>)
}

To resume this introduction to Gobstones, here is a simple program that counts how many cells are there in the column and uses this number to put blue stones:

procedure PutNStones(n, color)
{
  repeatWith i in 1 .. n
    { PutStone(color) }
}

procedure GoToEdge(dir)
{
    while(canMoveTo(dir))
     { MoveTo(dir) }
}

function countCellsOfCurrentColumn()
{
    GoToEdge(South)
    result := 1
    while(canMoveTo(North))
    { 
        MoveTo(North)
        result := result + 1
    }
    return(result)
}

procedure Main()
{
    PutNStones(countCellsOfCurrentColumn(), Blue)
}

"Can I call procedures inside functions?", the answer is Yes. But the global state before and after you call a function remains the same. The effects that occur inside a function are undone when the function returns a value.

Gobstones sintax is C-like, so students don't have difficulties when they have to work on general purpose languages. They can learn many useful things like divide and conquer, parametrization, etc.

Last year, I spent eight months teaching basic programming concepts with Gobstones. This year, since children had already used Scratch, I spent only three months to teach the same concepts.

In the 4th year the results are:
  • Last year I had eighteen students. Only one was enthusiastic about programming. Four of them learned a lot, and they did the exercises just well. The rest were completely bored and did not want to participate too much.
  • This year I have fifteen students. They do a very excellent job. Only four of them are lazy, but the rest is quite well. Some are extremely brillant. All students get inspired because they're truly learning programming concepts, in contrast to Scratch where they learned only to write a lot of code without understanding their programs and the ideas behind them. However, Scratch is an excellent approach to make motivating programming projects at first, and it have good results.
In 5th year I started with Python and I proposed proyects to create games. We use a very easy framework, and they have designed very original games. Some students participate a lot, but many of them are still bored. Nobody learned significant concepts, because they produce a lot of code what they cannot reason too much about it.

My concerns, like other educators, are:
  • Why some (or most) children doesn't like programming?
  • What kind of students are successful at learning programming?
  • Who of them might have difficulties to learn this discipline?
  • How can we motivate students at this age to learn programming?
My conclusion so far was "Many are not interested in programming, I can do my best effort, but they will not learn more than any basic concepts".

Thankfully that was not the end.

I learned to program like those children, using Gobstones to learn the basic concepts of structured programming. Then, I met Haskell and many others. But only "Haskell" has expanded my knowledge about math and programming languages until limits never imagined. Now I'm studying concepts about category theory, and even I'm reading the HOTT Book. But why Haskell encouraged this? Have I got some special skills to understand abstract concepts and reason about the code I write (see properties in it)?

I don't know these answers either, but I have switched the approach in both courses: we are using Haskell now. We are focusing on functions, types, algebraic data types, lists, recursion schemes, etc.

The results are extraordinary:
  • A lot of apathetic students awakened from their lethargy. Now they are becoming very participatory, and they are answering very complex questions, sometimes even better than other more dedicated students.
  • Most students can infer very abstract solutions and model their ideas easily.
  • All of them agree that imperative programming was more difficult, and many are amazed that Haskell is a programming language.
When I presented Haskell at first time in both groups, they were making conclusions in only two hours about these topics:
  • Functions, expressions and types (they answer questions about the type of functions and expressions)
  • Parametric polymorphism and polymorphic functions
  • Currification
  • Sum and product types
  • Pattern matching.
  • Partiality and the use of Maybe.
On second class with 5th year (another two hours) they have learned:
  • Lists, their constructors and operations (head, tail, null, etc.). They infered the types of all the functions and see the correspondence of what they do based on the types.
  • Map, filter and fold, comparing them with iterative implementations in Python. They infered the types of the paremeter functions. One girl understood the difference between foldr and foldl, and she said "if the binary operation is associative the result is the same".
  • Finally, we discuss why the name "map" for the function map.
When the last class finished, one boy come to me and complained: "professor, when will we start learning challenging things in Haskell?". I had to explain that many programmers find very diffcult the concepts they are learning at the moment, but for them, for some reason, it was an extremely easy job.

My latest personal conclusions of what it is happening are the following:
  • They are very happy seeing an algebraic data type implementation of a Pokemon, since they note that programs have this kind of definitions and properties, in contrast with the drawings they see on screen that are only showy. They enjoy recognizing how abstract the code is, and most of them don't reach these conclusions when they program in imperative languages.
  • They don't enjoy making games and having fun at school, they want to learn relevant ideas that they can use in real and even complex situations. They want to be useful and give correct answers to challenging problems.
  • Haskell does not encourage you to think like a machine. Most people don't like it (and me neither). Many children have not a procedural mind, but they can abstract a lot, so we can take a very good aproximation exploiting this. They can learn operational concepts later, but they can't if they don't feel confortable with what they're programming and reasoning about their code. This is posible with the correct approach.
Finally, I want to share what they have done in both years.

      11 comentarios:

      1. Fascinating! I run a computer programming at my local school, mostly we do Python. Would be very interested in the tasks you used as learning tools (have you used projecteuler.net?). At least two of the kids in my club would probably be interested in Haskell.

        ResponderEliminar
        Respuestas
        1. The school has a virtual classroom (moodle), so I use it. Also I designed my own activities (they're in Spanish but I can translate it if you want to).

          Eliminar
        2. Have you posted the activities (in Spanish, or translated in English) anywhere online?

          Eliminar
      2. This is awesome! I would have thought that a functional language would be harder to teach. But yeah, I can see how variable reassignment alone tends to confuse people.

        Do you have a curriculum outline? How are you introducing concepts? Or perhaps, you might do what Khan Academy does and put out a couple videos? I'm very interested in your approach. I have in the past, been approached from time to time about tutoring programming, and I had assumed an imperative language would be easier to learn. Apparently, it isn't.

        ResponderEliminar
        Respuestas
        1. There are two teachers in the classroom, and between fifteen and eighteen students. These are good numbers and this makes the difference too.

          I designed my own curriculum. Every concept is introduced asking to children what solution they found or think to some problem. For instance, if you want to teach "repetition", the introductory problem may be "how can you put 500 red stones in a cell". The brute solution is "call 500 commands", and the smart one is "repeat 500 red stones". They try to infer the sintax of the solution, then I guide them to the final conclusion. You can do this with all the concepts you want to teach, including polymorphism, currification, function composition, etc.

          Imperative languages help us to teach some kind of concepts (stateful computations, variable re-assigment, imperative loops, sequence of commands, etc.). These are important concepts but these languages don't help with other kind of concepts like types, expressions, function abstraction, function parameterization, parametric polymorphism, simpe data structures, their operations and representation invariants, etc.

          I consider that those topics provide great ideas generally applicable to programming, whatever the language in which they are applied. But another reason is that it seems that many kids enjoy these topics, as opposed to the imperative concepts that some students do not get internalized.

          Eliminar
      3. Been admiring Haskell from afar for years. And now you tell me that 5th graders are better at Haskell than I am! Curse my imperatively brainwashed mind...

        Please record the same lessons you give to your 5th graders and upload to youtube! :)

        ResponderEliminar
        Respuestas
        1. Don't be mad. Many of this kids will not work as programmers. Programming is more than understanding programming concepts, but when you learn them you gain brillant ideas for your entire life :)

          Eliminar
      4. Excellent, Fede!!!!!!
        Amazing use of Gobstones and Haskell!
        I am proud that you used them so well!!!!!

        ResponderEliminar
      5. Fede.
        You are a very good teacher!
        You did not settle for thinking that the problem is the students.
        This tipe of practice is whhat I expect as coordinator. :-)
        Thank you for share this article!

        ResponderEliminar
      6. > she said "if the binary operation is conmutative the result is the same"

        she probably meant "associative" ;)

        ResponderEliminar