Featherweight Musings

Friday, July 30, 2010

Teaching programming

I taught a second year course on Java programming last semester, and, being in a university (and being a programming languages person), I think about teaching programming a fair bit. In particular, which languages should we teach?

Here is how I would design a curriculum if I were king (or head of programme or whatever):

1st year: assembly (8086, none of this RISC crap) and Haskell in parallel (in fact I would start with machine code and lambda calculus for the first few weeks).

2nd year: C and Python, again in parallel

3rd year: C++ and Java.

You could swap Haskell for some other pure, lazy, functional language if you like, and Javascript, Ruby, or Perl for Python, and Java for C#, and you probably don't need C++ and Java in the third year, one or the other would do.

And of course, this wouldn't work in real life --- you would scare off most of the students in the first year and it would only appeal to the very smartest and geekiest of students. But I think it is a good order: students would get some key concepts (recursion, pointers, machine organisation) early which they can apply when the learn the later langauges. The problem with learning Java first and then the fun stuff, is you don't learn your lessons that way - programming in C helps to make you a better Java programmer, but not vice-versa.

I think this organisation would give a good appreciation of real-life computers (too many students have no idea about how their Java programs relate to bits and bytes); and how to think about programming in a 'smart' way (higher order functions etc.)

A final advantage, the languages match the scale of the exercises: small programs in assembly/Haskell up to large programs in Java, just the way it was all designed.

I honestly think this would be the best way of teaching programming to good students. Unfortunately, a CS degree is about more than just programming, and students get a say in how they are taught, so it will never catch on.

Wednesday, July 21, 2010


My project for last weekend was to learn how to program in Python. Possibly an ambitious goal for a weekend, but I feel I have a good grasp of the basics.

I didn't find it a hard language to learn, I guess it is designed that way, but being familiar with Groovy and Javascript probably help. I've only written small programs, but here are some thoughts:

I love the syntax and general feel, it feels very 'right'. Most things are done the way I would do them. I like indentation much better than braces and don't miss semi-colons one bit. On the other hand, it is much more readable than Perl. The only things I object to is colons to initiate block statement and pass statements rather than empty blocks, both seem to go against the minimalist syntactic philosophy, and both seem unnecessary.

In fact I love the language. It seems very good at what it sets out to do, much like C and unlike C++. There are very few rough edges, and lots of things that make you go "nice!".

I like the support for first-class functions, lambdas, map, filter, etc. Syntax for lists, slices, list comprehensions, generators, etc. I thought slices could have been used instead of the range() expression.

The jury is still out on yield.

Not using types is liberating in small programs. But my Groovy experience is that I quickly want to use them for documentation once the programs get larger ("just use variable names" you say; OK, I want compiler-checked documentation). Optional/hybrid types are the obvious solution. Maybe it is because I'm too used to C/Java programming.

The inefficient implementation scares the hell out of me. But, intellectually, I know it doesn't matter for 99% of applications, but still... Also I would prefer the implementation was not as obvious to the programmer (in docs as well as reflective code).

I like the duck typing approach to objects. It feels so much more lightweight than implementing interfaces. It makes me think that interfaces could be supported in a typed language much more easily. Not sure how, but something like Donna Malayeri's blend of nominal and structural types could be helpful.

I find the way fields of classes are handled strange: adding fields when they are assigned to fits nicely with the way variables are used, but feels very uncomfortable for fields. I think this is Java/C++ conditioning at work, and I haven't written programs that make use of this facility yet, so I am reserving judgement. It may well be a good idea, but it gives me the creeps.

I like the 'everything is public' philosophy, although I fear that those of a more software engineering bent would be horrified.

In conclusion, I like Python a lot. Of the scripting/dynamic programming languages I've looked at, it is my favourite. I hope to have an opportunity to use it for something serious soon.

And I still have the feeling that there is a huge space for a programming language with some of the dynamic features of a language like Python, combined with a more heavyweight class system (virtual classes) and optional typing to make a very pleasant general purpose language.

Women and Computer Science

Let it be known that I have been thinking about the issue of women in computer science. More precisely the fact that they are extremely under-represented.

This was in part set in motion by a talk on the subject by Barbara Crump at the NZCSRSC.

Anyway, I have lots of thoughts and opinions, but mainly for now I am reading and pondering. Musings on the subject will have to wait until I feel sufficiently informed, which may take some time...