Boo to you, too!

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.

8 thoughts on “Boo to you, too!

  1. Mike Schinkel

    I loved his manifesto! While I didn’t agree with everything he decided ("def" for defining functions?), I wish I was able to spend the time to go off and design my own .NET language as he did!

    One concept thing I really like and hope you’ll consider adding to VB is syntactic attributes. I don’t particularly care how you implement them, but there are code patterns that as so intensely repetitive (like get/set in VB) that I would love to see them streamlined.

    I don’t know about others, but the smaller the source code file, the easier it is for me to grok the whole thing. Properties are one of the best extensions to OOP, but source code inflated by lots of gets & sets almost makes cancels out their pluses!

    I still believe strongly in the benefits of VB’s readability over C#’s terseness, so if you could maintain the readability but condense common and verbose patterns down to concise statements I think you’d be adding great benefits to the VB language.

    Reply
  2. Pingback: Richard Clark

  3. LarsBerg

    In specific response to extending the language, anyone who has ever spent some time with Scheme or Lisp misses this. It’s the sort of thing that sounds really scary and does, in practice occasionally get used for Great Evil. However, the number of times that it’s exactly what you need and enables you to write a much better program than you would’ve been able to without it always made me grateful it was there when I had it.

    I guess providing that power all depends on if you’re in the Paul Graham school of philosophy or not (http://www.paulgraham.com/langdes.html).

    Reply
  4. Ian Bicking

    "def" comes from Python, like most of the syntax. Even some of the metaprogramming is syntactically about the same thing that is being proposed for Python.

    Reply
  5. Fan

    The Builtin Literals are realy great features! I hope VB can add some of those such as dates or regular expressions.

    The VB language is now too static and too C#-like, it needs some dynamic things! Not limited to the late-binding. VB needs to be more simple and clean to attract more developers.

    Reply
  6. Mike Schinkel

    >> "def" from python

    I kind of figured that.

    But then, I also have real problems with "Dim." 🙂

    (Why-oh-why couldn’t MS add something like "LOCAL" and depreciate Dim?!? Everytime I use it I feel like I’m declaring a half-witted variable!)

    Reply
  7. Pingback: Panopticon Central

  8. Pingback: Richard Clark

Leave a Reply