It amazes me how difficult it is to design new features to a programming language.  Once a language is baked in its original form it’s almost impossible to add new semantics let alone syntax rules.  Operators are hellish.  You want to invent new ones, but you are generally limited to the common symbols found on the standard keyboard.  That’s why so many languages focus on using braces and brackets, because they are free and easy to type.  Though, once you’ve allocated them to one purpose you cannot readily reallocate them to another.  You can try to overload them, and give them some contextual dependency, but that usually ends up in a mess.  I know, I advocated for a long time using the brackets as a filter operator for the X# language.  I even built in all the contextual baggage into the compiler so it would fundamentally work, most of the time.  In the end it was a wash.  If I could do it all over again, I’d find another way.


We get into this same trouble when designing new features for C#.  Symbols to use as new operators are scarce.  It’s even worse with keywords, you cannot make new ones.  That would break backward compatibility of the code.  Sure, C# 2.0 pulls some tricks and lets in some new terms in novel places, but you can only do this so much before that avenue dries up.  We bat around ideas about how to solve this problem once and for all.  Sometimes it seems like we spend way too much time thinking about it.  But, you know, eventually hard work does pay off.  In fact, I’ve come up with a solution that should suffice for all .Net languages.  I’m not certain, but it might be applicable to other languages as well.  Fortunately, for Microsoft, I’ve already filed the patent on it. It’s been a while, but legal has finally given me the go ahead to fully disclose it now.


You see the trouble really lies in the in-ability to set pieces of the language apart.  What you want to do is have a mechanism you can use to specify that a term is always special to the language, so that it can never be used by an application as a variable name or some other identifier.  Doing that solves the backward code compatibility problem. However, there is still only a small set of common symbols on the keyboard, so it’s not easy to find one.  Sure, you could imagine using other symbols available in the Unicode character set, but then you’d have to invent new keyboards to use just for the language, and I don’t want to re-invent the APL nightmare.  Still, if you had a spare symbol or two you could come up with a bracketing mechanism to set your keywords apart.  Some languages do this with a dollar-sign ($) prefix, other languages have other means.  But this is an ugly solution.  Extraneous symbols just get in the way of readability, and if you know anything about maintainability of code, you don’t want anything hindering you ability to read and understand it.


So I found myself perplexed one day last month, wanting to solve the problem but having no luck.  I’d tried just about every combination of symbols that I could think of, and yes I even tried putting keywords inside quotes, but it just looked bad.  I would try each one out using the IDE and put it in context with fragments of code.  Anders does this a lot when he’s working through a new idea, and it always seems to work for him.  I try to learn new tricks like this whenever I can.  Still it wasn’t helping.  Have you every tried to seriously read code that wrapped keywords in something like dots?  Try it


.foreach.(int x .in. numbers) …


Now tell me, is that a usable solution?  And that was the best one.  I just could not bear to end up with a language that looked like FORTRAN, could you?


So as I said, I was perplexed.  I was intellectually exhausted at this point.  It had been weeks and still nothing.  But, you know, that’s exactly the time when breakthroughs happen.  I was weary and almost to the point of beating my forehead into the monitor, when suddenly I saw something.  It was less of a thought and more of an optical illusion, a trick of the light, like when you eyes lock onto one of those mystery-eye puzzles, and then you truly see what has been there all along.  It hit me so fast I found I could not breathe.  The answer had been right in front of me the whole time.


I had been staring at a fragment of normal looking code, ready to be cut-and-pasted into yet another bad idea.


public class Foo {

  public int X;

  public float Y;



The answer was so simple it shook me to the bones.  We did not need new symbols.  Symbols got in the way.  We had something so powerful already that not only got out of the way, it enhanced readability. 


I’m talking about the blue.  Keywords are blue.  Everyone already knew this, but no one had ever seen it for what it truly was, for what potential it truly had.  It was the big jump that made the IDE experience so powerful.  Code was easier to read because of it, and it didn’t get in the way of reading the words.


Text has color.  Color has meaning.  Keywords are blue.  Believe me, from now on programming will never be the same. 


Sure it sucks for people using notepad or third party editors, but you cannot stand in the way of innovation!


Keep programming in the blue.