Don pointed to the release of a new .NET programming language called boo. I downloaded the boo manifesto and took a look and it seems very interesting (and it’s nice to see some language experimentation going on on the CLR!). Some of the ideas aren’t unfamiliar – C# already has iterators and we’ve kicked around the idea of being able to enable late binding on a per-variable basis (called “duck typing” in the manifesto) – but others are less familiar. One idea I’m curious about seeing how it plays out is extensibility in the language. In the manifesto Rodrigo says:
I wanted a language I could extend with my own constructs.
This is one of those ideas that’s always seemed to me to be great on the face of it but questionable because of the law of unintended consequences. On the one hand, how can you argue with giving people the ability to extend the language as they see fit, especially given the fact that compiler releases can be a year or more? On the other hand, it’s so easy to screw up language design even when you’ve been doing it a long time that I wonder if you won’t quickly have a language that’s no longer comprehensible by man or machine.
One thing that Rodrigo loves about .NET is the nice way that the entire set of class libraries are architected together in a pretty clean and consistent manner. This is a great advance over the hodgepodge approaches of the past where fundamental libraries were incompatible or worked in entirely different ways. I wonder, though, if allowing extensible languages isn’t taking a step backwards into that world. Central control of a language ensures some reasonable amount of consistency in thought and design – if anyone is allowed to add extensions, will the language gradually devolve into the language of Babel? Or will only extensions that preserve the core style survive while the others die off? I guess we’ll just have to see.
I will add that one major problem with our compilers today is that entirely too much information is locked up in them. We’ve started exposing compilation information through mechanisms such as the Visual Studio code model, but we need to go a lot further to enable more advanced and extensible tools. It’s certainly possible to expose a lot more information about what exists in the code that’s being compiled without having to make that information modifiable outside of the compiler, and I think that’s something that’s unquestionably worth pursuing in the long run.