Command Line Heroes - The C Change

Episode Date: October 1, 2019

C and UNIX are at the root of modern computing. Many of the languages we’ve covered this season are related to or at least influenced by C. But C and UNIX only happened because a few developers at Bell Labs created both as a skunkworks project. Bell Labs was a mid-twentieth century center for innovation. Jon Gertner describes it as an “idea factory.” One of their biggest projects in the 1960s was helping build a time-sharing operating system called Multics. Dr. Joy Lisi Rankin explains the hype around time-sharing at the time—it was described as potentially making computing accessible as a public utility. Large teams devoted years of effort to build Multics—and it wasn’t what they had hoped for. Bell Labs officially moved away from time-sharing in 1969. But as Andrew Tanenbaum recounts, a small team of heroes pushed on anyways. C and UNIX were the result. Little did they know how much their work would shape the course of technology.That's all for Season 3. If you want to dive deeper into C and UNIX, you can check out all our bonus material over at redhat.com/commandlineheroes. You’ll find extra content for every episode. Follow along with the episode transcript. Subscribe to the newsletter for more stories and to be among the first to see announcements about the podcast. See you soon for Season 4.

We are at the beginning of a new wave of research. Our creative powers are being stretched. These men are design engineers at Bell Telephone Laboratories. In the 1960s, Bell Labs in Murray Hill, New Jersey, was the epicenter of innovation, where our tech future took its first steps. There, they developed the laser. They developed the transistor. It was the cradle of information theory. And in 1968, all that innovation hit a new peak, when a fellowship of four programmers produced something so groundbreaking that it fundamentally changed

the way the world works. I'm Saran Yitbarek, and this is Command Line Heroes, an original podcast from Red Hat. All season long, we've been tracking some of the biggest stories in programming languages,

and we finally arrived at our season finale. I think we saved the biggest story for the end. It's the story of a language that made just about all those other languages possible. Exactly 50 years ago, C was designed at Bell Labs, a general purpose language so fundamental that we sometimes forget what a monumental achievement it really was. To get the full picture, we have to head back to the 1960s, just before the birth of C. It was a time when anything seemed possible. The 1960s Bell Labs was really almost a kind of Shangri-La. It was an R&D lab that really doesn't have any kind of analog today. That's John Gertner, author of The Idea Factory, Bell Labs, and the Great Age of American Innovation. We asked John to try and explain what was in the air.

What was it about this place and time that made Bell Labs, in his words, an idea factory? I think today we're sort of of the belief that competition creates great innovations, but I'm not sure that's true. And Bell Labs' achievements actually kind of stand in contrast to that. These were scientists and engineers who had not a lot of pressure on them. But at the same time, Bell Labs, because of its hierarchical place amongst research laboratories, could really hire the very best and the very brightest and give them both time to work on problems that they found interesting, and also a fair amount of funding. If you could make a good case that you had a

research project that was relevant to the sort of ideal and the goal of the phone company, you could really fund your research. And, John emphasizes, although Bell Labs was a product of this for-profit company, the ethos was closer to something academic. By letting employees run with their own ideas, Bell practiced similar open leadership principles to what you might find in open source communities. This was an era before Apple, before Google, before Microsoft, for instance, the history of computing often focuses on the kind of West Coast homebrew computer club sort of origins and what grew out of that. Like, you know, I think this was just as important. This was in what would now seem to be an unlikely place, which is suburban New Jersey. But, you know, these were scientists and researchers and computer engineers who were

making tremendous breakthroughs that would really have significant earth-shaking implications all over the world. One of those earth-shaking projects, one that was proving to be a huge challenge, was a little concept called timesharing. Could they build an operating system that a hundred, even a thousand users could be using all at once? That would be a game changer. Starting in 1964, the brainiacs at Bell Labs teamed up with General Electric and MIT to see if they could collectively push things toward this holy grail. MIT actually got the ball rolling a year earlier with something called Project Mac. But soon, you had all these top teams pushing together to build a mainframe time-sharing operating system.

John McCarthy actually introduced the concept back in 1959. Check out our episode about AI, episode 7, for that story. He imagined a large machine that could switch its attention between multiple users. McCarthy figured such a machine would have the potential to wildly expand all computing culture. I mean, imagine it. If a thousand users can be working on one machine, you've democratized the whole world of programming, the whole world of computers. So that group of heavyweights set out to make McCarthy's dream a reality. And they gave that imaginary operating system a name.

They called it Multics. They worked on timesharing for years, but the project was a huge money suck. And after a decade, the end wasn't even in sight. Making matters worse, their head of research, Bill Baker, was a chemist who wasn't really interested in Bell's computer science department. And we can pile on one more problem, a problem of pride. One thing about Bell Labs that you see over and over again is that they oftentimes just worked on projects alone. I mean, there was a certain sense within Bell Labs that they had all the people they needed and all the ideas they needed and the best technologies. And if there was a problem worth solving, they could go at it. It may be the case

too that Multics didn't work for Bell Labs to some extent too, because of this sort of larger collaborative effort was not something that actually worked well within the Bell system or that satisfied the executives there. John Gartner is the author of The Idea Factory. His latest book is called The Ice at the End of the World. Bell Labs officially pulled out of the Multics project in April of 1969. So, end of story, right? As far as Bell Labs was concerned, the time-sharing multics dream was dead. Or was it?

Turns out, not everybody at Bell Labs gave up on the quest for time-sharing. Four stubborn holdouts held on to the dream after everybody else had moved on. And that story is next. Some dreams, frankly, are too big to die. It was a big deal. That's Joy Lisi Rankin. She's the author of A People's History of Computing in the United States. Joy and I got talking about the dream of timesharing and why it was too important to let go.

It was a big deal and it was quite ambitious. And up until that point, or sort of when the project was launched, most of the timesharing systems in the early 60s had maybe 40 or 50 terminals on a single mainframe. So going up an order of magnitude was substantial and perhaps more ambitious than anyone realized. So the project struggled in some ways to fulfill its initial goal, but nonetheless, sort of timearing continued to live on in different forms and indeed to thrive, not just at MIT, but elsewhere. Yeah. So when we talk about the 60s, who was driving the need for timesharing? You mentioned MIT, GE, Bell Labs. So are we talking about businesses? Are we talking about the academic community? Who was really driving it? I think the academic and business communities

both, as well as sort of scientific communities, were pushing because it was really, as I mentioned, a more one-on-one interactive experience of computing. But on the other hand, I would say educators were also pushing for it. And at a national level, there was a conversation about creating a nationwide computing utility. So basically a national time-sharing network. And really sort of thought leaders in the United States also had this language around time-sharing would be something that was comparable to electricity or phone or water service. Wow. Yes, I know. That's a big deal. It's a huge deal. Joy helped me remember that while this episode is focused on the team that built C and Unix over at Bell Labs,

the broader push for time sharing was really a movement, something bigger than any one team. Really, it was a push to think of computing as a public utility. And it had so many heroes we can't get to here. People like Bob Albrecht and Martin Greenberger and lots of others. Okay, with that caveat, here's the rest of my chat with Joy. So when John McCarthy first publicly talked about time sharing at MIT, in this speech he gave, he explicitly compared it to electricity and said, this is a way everyone can have computing, not just in universities and schools or businesses, but also in their homes.

Going back and reading articles and documents from that time, no question in many people's minds that there would be a computing utility and that it would and could be regulated. So there was a lot of faith and support for this sort of national time-sharing utility. So what's interesting is that by 1970, IBM actually pulled out of the time-sharing industry. Even GE, they sold their mainframe computer division, but they actually retained their time-share part of the business. Let's talk a little bit about that. What happened in 1970? I think 1970 has become sort of a marker of maybe an artificial marker of the fall of the promise of computing utilities or the time sharing industry. In some ways, it's false.

I think sort of it was by the late 60s, it was clear that MIT and Multics were struggling to sort of create this thousand or thousands of terminals time sharing system. And it was a very public, prominent project. And at the same time, in the late 1960s, tens of time-sharing businesses sort of providing computing on this utility model had sprung up around the United States and were booming. Sort of it was a tech bubble. And then the enthusiasm fell away. Not completely, because while GE sold its timesharing sort of mainframe computer business, they retained

their timesharing as a utility business through the 1970s and 1980s, and it was profitable. That's great. And universities like MIT continued to run timesharing systems also into the 1980s. So there's, I think, a public memory that timesharing was like a tech bubble that just died out in the 1970s, partially because there was so much attention to multics struggling. Yet it actually, if we sort of go back and look at how people were using it and how profitable it was and how successful it was, it thrived through the 1970s. Now, back at Bell Labs, a group of four technologists

wanted a time-sharing system of their own. Ken Thompson, Dennis Ritchie, Doug McElroy, and J.F. Osana. But they didn't want Multics. They wanted to leapfrog towards something cleaner and more powerful, something they called Unix. Multics was, I would say, the inspiration for Unix in the sense that some of the programmers who were working on Multics so enjoyed the benefits of programming on a time-sharing system that they wanted to create that environment for themselves when it was clear that Multics was struggling, these were programmers at Bell Labs, and they decided to try to create their own programming framework

and sort of time-sharing system. And that's what became Unix. Joy Lisi Rankin is the author of A People's History of Computing in the United States. Dennis Ritchie would later describe him and the three other Bell Labs coworkers as a fellowship. The fellowship wanted to work as this tight quartet of developers, and they needed the hardware to accommodate their programming. But Bell Labs really had moved on from the time-sharing dream. And as much as Bell Labs could be a utopia for research,

this was a case where they'd hit their limit. So they rejected proposals for that new hardware. It was just too pricey. Why take the risk? But the fellowship soldiered on. Thompson and Ritchie asked for a machine like the GE645, which they'd been using to work on Multics. When they couldn't get the funding for that,

they just scribbled ideas about file systems on paper. Eventually, they managed to implement some of their ideas in a game they called Space Travel, which ran on a PDP-7. They kept on working with that PDP-7, which was basically in the same class as a Commodore 64. Bit by bit, with no backing from Bell, at least at first, that fellowship gave their time-sharing dream new life in the form of something they called Unix. But here's the thing. The Unix operating system was being created in assembly language.

I mean, these guys were transferring files to their PDP-7 on paper tape. So you can imagine, they're trying to build this groundbreaking thing with less than ideal tools. And again, with no backing from the bosses. Unix was coming to life, but it was still missing a language that would really let it sing. The first attempt at a new language for Unix was something Ken Thompson wrote, called B. Which was a derivative of BCPL. That's Andy Tannenbaum.

He's a professor of computer science in Amsterdam and the author of many books, including the classic Computer Networks. Just listen to his backstory on Thompson's B language. So B is a derivative of BCPL, which was an attempt to make a CPL compiler, which would actually work, which was based on ALGOL 60, which of course came from ALGOL 58, which is an attempt to do Fortran better. Got that straight? The point is, B came with a lot of baggage. It wasn't much of a breakaway from all those predecessors. And as a result, it really wasn't up to the challenge of making Unix sing. B didn't know data types, for starters.

And besides, its assembly language counterparts were still yielding programs faster than was possible using the B compiler's threaded code technique. BCPL and B had only one data type, the Word. But Words were great on the IBM 704 and 709 and 7090 and 7094, which were word-oriented machines. But starting with the 360 and all the many computers, they were byte-oriented machines, and having only a single data type, the word, was not a good idea. It was a terrible match for modern computers. So clearly, B wasn't going to hack it. So all the machines the team had worked on before were word-oriented.

But having things only oriented toward a single-size object, like Andy said, wasn't going to work. Luckily, at this point, the powers that be at Bell Labs came back on board, sensing that something exciting was happening here. They funded a $65,000 PDP-11. And that machine was not word-oriented. That machine was byte-oriented.

Now, armed with the PDP-11, Dennis Ritchie could step in and tackle their language problem head-on. You know, Dennis basically, with a little bit of input from Ken, decided to write a new language that was much more structured and had other types,

such as character and int and long and so on. So from 1971 to 1973, Dennis Ritchie is modifying the B language. He adds a character type and builds a new compiler so it doesn't have to use threaded code anymore. At the end of two years, B had transformed into a brand new language called C. C was this powerful hybrid. It had high-level functionality, but it also had detailed features that let users program operating systems. It hit a sweet spot.

It was abstracted from the machine level just enough that it could be ported to other machines too. Turns out that C was much more than a language for just messing around with applications. It was a nearly universal tool for programming, just as capable on a personal computer as it was on a supercomputer. And that mattered hugely because the personal computer revolution was just around the corner. Once it was clear that C was the way to go, the Unix kernel was rewritten in C, and so were a lot of its components.

So if you wanted to use Unix, you were going to be using C. The success of C and the success of Unix were tied together. Well, the reason that C caught on was not so much that it was a better language than B, which it was, but it was the language Unix was written in. And when Unix was widely distributed, it came with a C compiler, and eventually it came with two C compilers. And so people who were using Unix, and there were a lot of them after a while, all had a C compiler,

and everything in Unix and all the utilities were all written in C. So naturally, and C was a pretty good language to boot, and since it came with Unix, you know, why look for something else? From there, the value of C only grew. Well, C and Unix were kind of co-dependent in the beginning because, you know, Unix was written in C and it had a C compiler. And so they sort of grew up together. And at a certain point, C was popular enough on Unix systems that Steve Johnson, for example, wrote the portable C compiler, which then could produce code for other machines. And eventually C compilers were written for operating systems other than Unix. And people

began writing all kinds of software, you know, from database systems to, you know, heaven knows what, in C because it was available and it worked and it was efficient. So soon enough, things that had nothing to do with Unix were being written in C because the merits of the language were obvious. Andy describes how total the C takeover was. I mean, C was in the right place at the right time. You know, in the 1970s, computing was much smaller than it is now. The average person didn't have a computer or knew nothing about a computer. But, you know, universities and big companies had computers, and many of them had Unix, and C came with it, and so they used C.

And it just established a very large base of software, a large base of programmers. You know, if a company wanted a C program, you could put out an ad and there would be C programs available. If they wanted a programmer for B, nobody would apply. In the C world, there was infrastructure. Software, libraries, headers, all these tools. And this created a virtuous circle. So it just became more and more popular. Now the emergence of the internet would raise security concerns about C,

and those are partway addressed in variants like C Sharp. It can feel sometimes like all the excitement is about newer languages like Python or Go. But one of the things we try to do on this podcast is remember how tied we are to our history. And the influence of C really is still incredible. One of the most obvious modern places where C makes its mark is in the godchild of Unix, Linux, which, yes, is very much written in C. Even the standard compiler for Linux projects, the GCC,

is written in C. It may not be obvious, but all those open source programmers out there today jamming away on Linux are tied to a language that was first built for them almost half a century ago. And the reign of C just grows with each passing year. It turns out the two dominant operating systems in the world now are Android, which runs on Linux, which is a rewrite of Unix, and iOS, which is a 4.4 Berkeley Unix. And so both Android and iOS are in fact Unix. My suspicion is, you know, probably close to all of the servers in the world run on some version of Unix or Linux.

And so it has a huge influence behind the scenes, and any system running Unix is going to be oriented towards C, and all the stuff written for that thing is going to be in C. You know, it's just everywhere. Andy Tannenbaum is a professor of computer science and the author of Computer Networks. Fun side note, he's also the creator of Minix, a free open source version of Unix, which actually inspired Linus Torvalds to create Linux.

And yep, Andy wrote Minix in C. Today, C is in every corner of our lives, from rovers on Mars to the browsers of our desktops. It's gone on to influence a lot of the languages we looked at this season. Languages like Go and JavaScript and Perl. And thanks to its deep bonds with Unix, C may well be the most omnipresent language on Earth. The recipients of the 1998 National Medal of Science Award, the team of Kenneth L. Thompson and Dennis M. Ritchie

from Bell Laboratories Lucent Technology. Back in the 60s, those four Bell Labs employees, Ken Thompson, Dennis Ritchie, Doug McElroy, and J.F. Osana, they had to beg for a little recognition and funding. But in 1998, Thompson and Ritchie received the National Medal of Science for their work on sea and eunuchs. They also shared the $1 million Turing Award. Not too shabby. All season long, we've been tracking the movements and magic of some of our favorite programming languages. Whether they got their start by hitching onto an OS the way C did, or capitalized on new infrastructure like Go did, one thing remains constant.

Languages have lives. They're born, they grow, mature. Sometimes they grow old and die. The more we learn about them, the more it's clear that our programming languages are really these vital forces, always changing to match the times. Our job is to notice those changes and respond in kind. Our languages are often our best tools for building the world we want. That's it for Season 3 of Command Line Heroes.

I hope you enjoyed listening as much as we enjoyed putting it together. Season 4 is already in the works, and we'll be getting that out to you soon. Command Line Heroes is an original podcast from Red Hat. You can dive deeper into the story of C, or any of the programming languages we covered this season, if you head over to redhat.com slash command line heroes. I'm Saran Yitbarek. Until next time, keep on coding. Hey, I'm Jeff Ligon. I'm the Director of Engineering for Edge and Automotive at Red Hat. When I say edge computing, the average person probably thinks smart device, smart fridge, smart watch, smart speaker.

But edge computing goes way beyond that. A fridge with a Wi-Fi connection is one thing. A robotic vehicle that's sorting packets and using AI to plan its route through the warehouse, that's something else entirely. At that level of complexity, you've got software in the cloud, software in the warehouse, software in the robot. How would you even manage an update without a common system? This is where Red Hat's Edge solutions come in. We simplify and streamline operations from the cloud to the farthest edge across all kinds of devices and use cases because everything should just work everywhere. Find out more at redhat.com slash edge.