You've worked in several programming languages. What do you think was best in its time?

BB: The early, early days when everything was in assembler, I think the Pentium architecture was really beautiful. The first Pentium. It was probably the most fun assembler language to do, because it had two pipelines, and you could schedule instructions so that they were both busy. There's some amazing beautiful code.

Quake has a little segment of code that's unbelievably beautiful. It uses every register and every cycle. The floating point unit, too. And it's all kind of choreographed so that everything is busy and it's pumping out the maximum number of pixels. Beautiful, beautiful code by Michael Abrash.

Like early multi-threading.

BB: Yeah. It's at the very lowest level. You're keeping all the hardware busy. I really like C# for building big apps fast with big teams. I think it's awesome. A lot of people don't like Java or C# because they're kind of verbose, I think they sort of strike a balance between -- I don't know how technical you want to be --

Go ahead!

BB: I like C# and Java because they're very readable. It's a great language where people can communicate. They're not the most powerful languages, but really powerful languages have this problem that as you get more abstract, as the expression gets more powerful, it's harder for other people to understand. So, I think it's kind of a balance.

Maybe to have a little bit of verbosity, you have to say things multiple times, more boilerplate, but large teams can collaborate. C++, if it’s kept to a nice subset, is very powerful. Tools are unfortunately kind of crippled, but it's a reasonable language if you restrict yourself.

The problem with C++ and all the old C languages is a couple of things. Preprocessor just makes it impossible for the tools to really understand the code reliably. There are very few environments that actually can deal with C++, where you can find every reference a symbol would say. In large programs, it's really important to be able to navigate and browse code powerfully, to be able to say, "I want to find every place that this symbol is used." When Chrome is loaded into Visual Studio, which is a fine tool, it does a terrible job. It just doesn't find all the things, so it really slows you down.

Kenta Cho, he's an indie guy, he programs everything in D. That's curious.

BB: Yeah. I'm intrigued. The problem with D is it’s just not adopted as C++, which, you know, has got a lot of problems. A lot of people like D. I certainly would be rooting for it to be catch on. Another language that's even more different -- and this is going to sound like marketing speak, but I'm intrigued by Go -- because in a way they're ejecting a lot of problematic old things that are in object oriented programming, like inheritance for instance. And I like the treatment of interfaces. It's kind of intriguing.

If they can get their performance story to where they are equivalent to C or C++, because I think right now in a lot of benchmarks they are at maybe half the speed... They'll claim that benchmarks are tweaked, you know, for the language... So, when they get that performance story, which I think they will, even though it's a garbage-collected language, that will be a very compelling language.

I have this fantasy of writing a browser in Go because it's a really great language for concurrency. And it's clean like C#. There's no preprocessor, no header files, so it compiles really fast. I mean, those guys are insane about making a compiler fast, and that’s very important also, reducing friction.

When it takes a couple seconds to build, that's a huge difference from when Chrome takes like three minutes, and I go grab a snack. And that's on a special machine with 16 cores. That's really not bad for a C++ program on the scale of Chrome, but still, it's a big difference.

Why is Chrome built in C++ as opposed to something else?

BB: Performance. Webkit was built in C++. You just have so much control over memory and how things are laid out. Webkit, I wouldn't criticize it. It's the fastest rendering engine for HTML on the web, and Chrome is built on that.

Yeah, control. It's a pain to debug. A point of view reference takes you to another file because it's a template. Whereas you have references just built into Java like C#. Nothing is as pleasant as building in C#. C# and Visual Studio, it just works great.

There's a large crop of web 3D things now. What do you think about all of these?

BB: Yeah. It's amazing how long it's taken for 3D to come to the web, and now there's WebGL. I think WebGL will be the thing that people will standardize on if they want to do 3D using JavaScript in the browser, which for certain things is very compelling. You wouldn't want to build a triple-A game that way because JavaScript is slow, and WebGL is just OpenGL ES. It's not really full OpenGL. It's restricted. You probably can do pretty good games in JavaScript, but it would not be a Call of Duty-style thing.

Unity, they've got a great engine, but I think that they... There's a lot more to an engine than just graphics. And with integration with the tools, then you can have more code that would be compelling in the engine, too. And they have great tools. I'm not all that knowledgeable on what is in their plug-ins, so I wouldn't say that they're out of business because of WebGL.

But I think what they're interested in is... They don't want to have a plug-in. They want to reduce friction, so they would like to use something like Native Client, which is actually the group I'm in, to write the functionality they want to write. They just want to run native code for their engine. So, they'll have to have the 3D interface. And I know that they're working with the Native Client people, but it's still a classic web thing. It's very fragmented. Nobody knows yet. And we're only talking about Chrome. So they've still got to have plug-ins...