I'm surprised that this one hasn't made the rounds more. John Siracusa at Ars Technica has written a piece called Avoiding Copland 2010 (there's now a Part 2 and Part 3), where he claims that the lack of a memory managed language/API set will create a Copland style crisis for Apple in the next several years. Longhorn/Windows Vista is supposed to provide its new functionality via CLR/C# API's, so I imagine that Siracusa is looking at that and getting nervous. It has taken Microsoft longer than expected to pull this off, and depending on which rumors you believe, some of the more ambitious attempts to use managed code had to be scaled back in order to ship a product. If it is any consolation, the Linux folks have exactly the same problem that Apple does.

Lots of people have commented on Siracusa's post, and a number of folks have pointed back to languages like Lisp, Smalltalk, and Dylan. Rainer Joswig, a long time Lisp hacker has written his opinion on what this means for the Lisp community. I found it amusing that around the same time that I saw Joswig's post, MIT announced that they were open sourcing the CADR Lisp Machine operating system, and the Gwydion Dylan developers announced the availability of OpenDylan 1.0b1. You can say what you like, but Lisp and Smalltalk machines were both systems where everything was build in a managed language. Some people think that automatic memory management only helps developers, but I think that you can get some improvements in reliability and security as well. Of course, as we've discovered with Java and C# code, it's also possible to create very inefficient code.

Much has been written about the arrival of dual core processors, and rumor sites have produced screenshots of quad processor Intel Macs. I think that it's more likely that the needs of highly concurrent hardware will push Apple (and everybody else) to a Copland style breaking point. AnandTech has confirmed what many have suspected, that there are some fairly serious problems with threading in OS X. If applications need to become more concurrent in order to take advantage of new hardware, then that is going to be a bigger deal than memory management issues. We know that techniques like garbage collection can help to deal with the reliability and modularity problems associated with manual memory management. But we don't really have any good solutions for making concurrent programming less error prone. Maybe I'd better dig up all that Actor language stuff that initially led me into graduate school.

There's one more wildcard, which is the whole question of whether or not desktop operating systems and applications are where the future of computing is going. In today's environment, you'd think that all innovation in computing is happening in the Web or Web 2.0 space, and that if we could just get a local storage mechanism and a decent drawing model into web browers, we could just swear off desktop computing all together. Given the number of times that I've had to kill a wedged Safari or Firefox, I'd have to say that I think that's a bit premature. Still, one never knows.

In some ways, I'd be glad if Apple, or even better, the whole desktop computing world, had a Copland moment. Maybe that would give people a chance to take a deep breath and wonder whether what we have is the best that we can do.