[C++] certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, "I wrote it; here, take it." It’s way too big, way too complex. And it’s obviously built by a committee. Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said "no" to no one. He put every feature in that language that ever existed. It wasn't cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that.

Ritchie and Thompson made an amazing team; and they played Unix and C like a fine instrument. They sometimes divided up work almost on a subroutine-by-subroutine basis with such rapport that it almost seemed like the work of a single person. In fact, as Dennis has recounted, they once got their signals crossed and both wrote the same subroutine. The two versions did not merely compute the same result, they did it with identical source code! Their output was prodigious. Once I counted how much production code they had written in the preceding year − 100,000 lines! Prodigious didn’t mean slapdash. Ken and Dennis have unerring design sense. They write code that works, code that can be read, code that can evolve.

I would try out the [C++] language [at AT&T] as it was being developed and make comments on it. It was part of the work atmosphere there. And you'd write something and then the next day it wouldn't work because the language changed. It was very unstable for a very long period of time. At some point, I said, no, no more. In an interview I said exactly that, that I didn't use it because it wouldn't stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language.

In the months before I made wiki, we had been having an argument. I think Kent Beck and I were on one side. People who had a lot of faith in the prevailing dogma of software engineering were on the other side. We said, "Collective code ownership is good." They said, "That's ridiculous. You'll never get responsibility. You'll never get quality if you don't have responsibility. And the only way you'll get responsibility is ownership. You have to pin the bugs back on somebody if you want them to ever rise above producing bugs." And I said, "Well that's wrong."

I believe C++ instills fear in programmers, fear that the interaction of some details causes unpredictable results. Its unmanageable complexity has spawned more fear-preventing tools than any other language, but the solution should have been to create and use a language that does not overload the whole goddamn human brain with irrelevant details.

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it.

As you get a game closer to done there are more graphical assets, and they get bigger and bigger and it takes longer to do things like load them or process them if you need to do some automated processing on them or recompute the lighting for the world, and it gets to a point where it becomes very sluggish to just try to get new things done and that was a real drag. And it's especially a drag when there's so many things to do and you feel like you can't do them very fast because of the computer. And part of that was programming in this programming language C++ that most engine programmers use to build things with, and I just had this very fatalistic attitude toward it like "Well... we can't do anything about that so I just have to like deal with this and get the game done". And then at some point I just changed thatI was like "Wait, is that really true? I know that that's what everybody thinks but is that really true?" And I was like "Yeah, no, it's not true". Like "I shouldn'tlike, we should finish this game in C++, but I don't have to accept that this is what I'm doing for the rest of my life. I can actually change this and do a different thing", and that's what led me to work on this new programming language. But as soon as I decided to do itas soon as I said "This is actually not an unfixable problem; we can do something about this", I became much happier, immediately, because I was no longer in jail; I was no longer in C++ jail for the rest of my life. So I try to use that as an example for other things as well. WheneverI know that feeling now; I know smaller versions of it, like when it comes to the way a game is designed, like "Oh, I realize I'm having this 'I'm in jail' feeling like I don't like this part of this game's design, but I've assumed that it just has to be the case." And I just go back and look, "Does it really have to be the case? Well, I mean, I decided that because this but we could make that decision differently if we're willing to pay the cost of making the decision differently. Is that cost worth me being happier with the game because it's a better game? Well, yes." So once you learn to revisit those decisions it becomes a very good thing to do and so that C++ instance I think was the biggest one, but I've learned to do that more often from that example.

I once worked on a project in which a software product originally written for UNIX was being redesigned and implemented on Windows NT. Most of the programming team consisted of programmers who had great facility with Windows and Microsoft Visual C++. In no time at all, it seemed, they had generated many screens full of windows and toolbars and dialogues, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and and unexplainable outcomes, they stood agog. It was left to the UNIX-trained programmers to fix things. The UNIX team members were accustomed to not knowing. Their view of programming as language-as-text gave them the patience to look slowly through the code. In the end, the overall 'productivity' of the system, the fact that it came into being at all, was not the handiwork of tools that sought to make programming seem easy, but the work of engineers who had no fear of 'hard.

Those were the people who saw the need. Marvin and Mikey and Miguel. They were the people who started it.

As soon as I learned about this miracle of chip making I thought, what is the key missing element? ... I'd been working on software so I decided that maybe that was what was necessary to bring all this power to life. I talked about that with a friend, Paul Allen, and we kept saying, "What can we do? Can we start our own software company?" It seemed impossible at the time because software was not done by independent companies. The companies that built the computers — IBM and DEC — they did all the software. And when we called them up and said, "We would like to do an operating system," they said, "who are you?" to which we said, "we're high-school students." That was s, uh — that was the end of that conversation.

I really don't like programming. I built this tool to program less so that I could just reuse code.

I had a plan. Learn Emacs. Learn UNIX. And learn programming language. What happened? I didn't learn Emacs. I didn't learn UNIX. And I invented a new programming language.