Over the last week or two, there were a huge number of programming language related posts. They fell into three categories, and I'm going to discuss them in their order of importance (to me).

1. Metaprogramming facilities

Ian Bicking and Bill Clementson were the primary sources on this particular discussion. Ian takes up the simplicity argument, which is that metaprogramming is hard and should be limited -- of course, this gets you things like Python 2.4 decorators, which some people love, and some people hate. Bill Mill hates decorators so much that he wrote the redecorator, a tool for replacing decorators with their "bodies". In Lisp, this is called a macroexpander. Bill Clementson is a Lisp guy (like me), so he doesn't understand why you'd want to handicap your language. For the kinds of programming that is most interesting to me, I want the full power of those features. I'd much rather have macros added to Python than optional type declarations (but that's for later in this post). At least Python is getting cool stuff like PJE's work on generic functions. Bill (Clementson) provided a list of metaprogramming and domain specific language resources

2. Concurrency

Tim Bray and Herb Sutter provided the initial spark here. The basic theme is that the processor vendors are finding it really hard to keep the clock speed increases going (that's actually been a trend for all of 2004), so they're going to start putting more cores on a chip. Exactly how many is dependent on which vendor you talk to. Aces Hardware and X-Bit labs have more details on the technology and vendor plans. But the big take away for software is that uniprocessors are going to get better a lot more slowly than we are used to. So that means that uniprocessor efficiency matters again, and the finding concurrency in your program is also going to be important. This impacts the design of programming languages as well as the degree of skill required to really get performance out of the machine. So add the burden of truly understanding concurrency to the burden of metaprogramming and watch a whole bunch of heads explode.

Once that basic theme went out, then people started digging up relevant information. Patrick Logan produced information on Erlang, Mozart, ACE, Doug Lea, and more. Brian McCallister wrote about futures and then discovered that they are already in Java 5.

It seems to me that Java has the best support for threaded programming. The dynamic languages seem to be behind on this, which is must change if these predictions hold up. I did play with Candygram, a Python based version of Erlang's concurrency primitives, over the vacation. While it provides nice abstractions for concurrency, I have to wonder how much actual concurrency there is, given the Python global interpreter lock. The same goes for Georg Bauer's expansion of his laazy evaluation module for Python to include futures.

My last Wintel box was a dual processor box, and the second processor did wonders for the responsiveness of the system. But most of the software I was using was single threaded so often I wasn't getting that much of a benefit. And that's the part of the problem that isn't solved by many concurrency abstractions. They don't really help with extracting the latent concurrency from the program, or helping the programmer decide when to parallelize or not. Compilers for languages like Fortran can do some of this, but what about languages where there is no compiler?

Since I'm working on desktop apps at the moment, I'm less impacted by this stuff than folks working on big server apps, but I can think of plenty of information mining problems that I'd like to solve in the context of my own personal computer versus a server off somewhere else. Plus real concurrency is cool, and you don't have that until you have the hardware that can do it.

3. Optional type checking in Python

Guido van Rossum did a pair of posts on this topic. The second post is the scariest because he starts talking about generic types in Python, and after seeing the horror that is Java and C# generics, it doesn't leave me with warm fuzzies.

Patrick Logan, PJE, and Oliver Steele had worthwhile commentary on the whole mess. Oliver did a good job of breaking out all the issues, and he worked for quite a while on Dylan which had optional type declarations. PJE seems to want types in order to do interfaces and interface adaptation, and Patrick's position seems to be that optional type declarations were an artifact of the technology, but now we have type inference so we should use that instead. That's a convincing argument to me, except that I'm not up on the expressive power of modern type inference, so I'm concerned that there will be lots of untypable stuff, that will need hints from the programmer. Ideally, this would be integrated with your development environment, so there would be an affordance for displaying the type annotations. Imagine your program text moving around all Expose like to accommodate the annotations.

I'll just go on to point out that Tim Bray posted about a programming problem where static types didn't help at all (he was using Java), so I won't be getting rid of my tests even if the inferencer does show up.