Aside...

Here's my dilemma: what should a blog post be? Some of the entries I've seen here are about the author's philosophy of programming. Others are news items. Being an inexperienced blogger I'll have to try various things to see what works best. Oh, and how do you measure success of a blog entry? I suppose the amount of feedback. By that measure, Ken Arnold's post "Are Programmers People?" is the winner of the Artima.com blogs so far. But that measure of success suggests that successful blog posts should be controversial, and rehashing an existing controversy is an easy way to get feedback. Not that I'm saying that that's what Ken is doing - just that it's easy to "win" by trolling for flames.

I'll take my own approach for now, which today is thinking aloud while reminiscing on a recent conference.

Python UK

I can't quite pinpoint it, but Python UK was almost more exciting than PyCon for me. Maybe it was the location: I'd never been to Oxford before, and while the conference itself was in a Holiday Inn outside the city, almost a piece of America away from home, I visited the city a few times and came away impressed with both its life and its concentration of ancient and historic buildings. Or maybe it was the fact that I wasn't so much the center of attention: I had more opportunity to watch presentations. Perhaps I also learned more because the topic of the whole conference was C and C++ (and Java) as well as Python.

One highlight of the conference was the attention being paid to Python outside the Python tracks. Apart from my own opening keynote (given to the whole conference, not just the Python tracks), where I summarized some of Python's history and influences, each of the following three days' keynotes, on various aspects of C and C++, mentioned Python at least once. For example, in Andrew Koenig's keynote about what's wrong with C++ (because of a travel restriction read by conference chair Francis Glassborow), he mentioned Python as one of the languages that had made him think about alternatives for some of C++'s problems. In general, quite a few died-in-the-wool C++ programmers showed interest in learning Python, and Python in a Nutshell was one of the bestsellers at the well-stocked bookstand.

My own take on C++, by the way, is that it has grown such incredible compile-time power that the average C++ programmer is stuck with following cookbook-style examples and cannot really understand why things work, or, especially, why they don't work. The more you think about it, the less you understand, unless you have the time and IQ points to really understand the deepest parts of the language definition. I'm sure there are places where this is just what the doctor ordered; but in most cases, I think Python's approach, a dumb compiler and a smart run-time, is much saner, and makes it simple for the programmer to predict what will happen. Another way of viewing the difference between the two languages is to say that in Python, all you've got is run-time; in C++, incredibly complex things go on at compile time, and then on top of that there's the run-time model, which boils down to a really low-level old-fashioned hardware model, whose existence you cannot abstract away because it affects when things go wrong at run-time.

Probably the talk I most enjoyed was neither about Python nor about C++, but about Haskell. Simon Peyton-Jones (Mr. Haskell himself AFAICT) gave a talk on metaprogramming in Haskell. Simon is an incredibly lively and entertaining speaker; he puts real drama in his presentations. I wish I could speak like that! Like Python, Haskell uses indentation for blocks; after that, the similarities stop. It is a strongly typed pure functional language, where just about everything is written as recursive functions, because the language has no looping construct. Because of this it will probably always remain a language of mostly academic interest: loops may be theoretically inferior to recursion, but I have no doubt that the human brain has special reasoning abilities for loops, and many real-world problems are most naturally expressed using loops rather than recursion. I'd say that a loop is a higher-level concept than recursion; recursion is more powerful, but also more low-level, like assembly language. That said, Haskell is incredibly expressive - and not just because it uses a very sparse syntax. (I picked up a book on Haskell, and it fell open on a page of list comprehensions - which are exactly like Python list comprehensions except that 'for' and 'if' are written using different symbols. The book claimed that no other language had this feature. Sigh.)

Anyway, metaprogramming is a new extension to Haskell, which lets the Haskell programmer write Haskell code that runs at compile-time and generates other Haskell code which is then incorporated into the program being compiled. This is just about the reverse of what Python does: in Python, you can invoke the compiler from the run-time (e.g. with "exec" or "eval"); in Haskell, you can invoke the run-time from the compiler. Both mechanisms are equivalent in power if you ask me. Curiously, Haskell uses $(...) to invoke the run-time from the compiler; this gives metaprogramming a vague Perlish flavor. It makes sense though: $(...) feels like substitution, and that's exactly what it does. Inside a substitution (and I suppose also outside), another kind of brackets is used to "quote" syntax (rather than parse it): [|...|]. (I mainly note this because it is a nice pair of symmetric brackets that may come in handy during language design when you need more styles of brackets than you have symmetric character pairs.) During Simon's elaboration of an example (a type-safe printf function) I realized the problem with functional programming: there was a simple programming problem where a list had to be transformed into a different list. The code to do this was a complex two-level lambda expression if I remember it well, and despite Simon's lively explanation (he was literally hopping around the stage making intricate hand gestures to show how it worked) I failed to "get" it. I finally had to accept that it did the transformation without understanding how it did it, and this is where I had my epiphany about loops as a higher level of abstraction than recursion - I'm sure that the same problem would be easily solved by a simple loop in Python, and would leave no-one in the dark about what it did.

main = do
  foreach [1..10] print
  ref <- newIORef 0
  while (test ref (< 5))
        (do 
	  print "Still running!"
          incr ref)