Command Line Heroes - Hello, World: Programming Languages for the Polyglot Developer

Episode Date: September 24, 2018

Every new programming language is created to do something previously impossible. Today, there are quite a few to choose from. But which ones do you really need to know? This episode dives into the history of programming languages. We recognize the genius of “Amazing Grace,” also known as Rear Admiral Grace Hopper. It’s thanks to her that developers don’t need a PhD in mathematics to write their programs in machine code. We’re joined by Carol Willing of Project Jupyter, former Director of the Python Software Foundation, and Clive Thompson, a contributor to The New York Times Magazine and Wired who’s writing a book about how programmers think. Reminder: this season we’re building our very own, open source Command Line Heroes game. And you are invited to contribute—in whatever way makes sense for you. Visit Command Line Heroes: The Game over on GitHub for more info. And drop us a line at redhat.com/commandlineheroes, we're listening...

Hello world, is it signal or is it noise? All the work we do as developers, all the countless hours of coding and stressing and testing, it all comes down to that one question. Are we getting our signal across? Hello. Or is our signal lost? Are we just making noise? No, it's the world.

I'm Saran Yadbarek, and this is Season 2 of Command Line Heroes, an original podcast from Red Hat. In today's episode, we're found in translation. It's all about programming languages, where they came from and how we choose which ones to learn. We're doing a deep dive into the ways we talk to our machines, how those languages are evolving, and how we can use them to make our work sing. Daisy, Daisy, give me your answer true. If you're a developer like me, you probably feel pressure to be a polyglot,

to be fluent in a whole bunch of languages. You better know Java, better know Python, Go, JavaScript, Node. Gotta be able to dream in C++. Maybe know a classic like COBOL, just for cred. And you might even be worrying about a newcomer like Dart. It's exhausting. The weird thing is, the computers that we're talking to really only speak one language.

Machine language. All those ones and zeros flying by, all those bits. Every single language we learn is, at the end of the day, just another pathway to the same place. It all gets boiled down, no matter how abstracted we are when we're doing the work. And that's what I want you to keep in mind as our story begins. Because we're starting with the moment, the completely brilliant moment, when one woman said, you know what? I'm a human. I don't talk in bits. I don't think in bits. I want a program using English words. Might seem like a simple concept today, but once upon a time, that idea, the idea

you should be able to talk to a computer in your own way, was a joke at best, sacrilege at worst. Season two of Command Line Heroes is all about the nuts and bolts that underpin everything we do. And this episode's hero is a woman whose journey you need to know if you want to fully understand our reality. So, I give you the First Lady of Software. Ladies and gentlemen, it's with great pleasure that I present Commodore Grace Murray Hopper. Thank you. pleasure that I present Commodore Grace Murray Hopper. I went to Canada to speak at the University of Guelph and I had to go through immigration at Toronto Airport. And I handed my passport to immigration officer and he looked at it and looked at me and said, what are you? And I said, United States Navy. He took second real hard look at me. and then he said, you must be the oldest one they've got.

That was Rear Admiral Grace Hopper in 1985. She was 79 years old at the time, and delivering her famous lecture at MIT. Even then, Grace Hopper was a legend. She was the godmother of independent programming languages, the woman who used compilers so we could use human language instead of mathematical symbols. She received the National Medal of Technology and after she died,

the National Medal of Freedom. So, not a slouch. They called her Amazing Grace. I mean, if anybody was born to be a computer programmer, it was Grace. That's Claire Evans, a tech journalist and the author of a book called Broadband, about pioneering women in tech. Evans describes that early world of computers, the one Grace Hopper stepped into in the 1940s,

when she was just a young woman in the Navy Reserves, and computers were the size of a small room. All those early programmers, they were like a priesthood. You know, they were people that were specifically good at something that was incredibly tedious. Because, you know, this is before compilers, before programming languages, when people were really programming at the machine level, bit by bit. In order to have the Constitution to do that kind of thing, you really have to be a specific kind of person. And Grace really was that kind of person. Right away, she saw how crazy limiting it was

for humans to be using a language meant for machines. It was like trying to walk down the street by telling every atom in your body what to do. Possible? Sure. Efficient? No. There had to be a shortcut between a programmer's intentions and a computer's actions. Humans had been mechanizing mathematical thinking ever since the abacus. There had to be a way to do that again with computers. In the past, mathematicians used to have to do all this arithmetic, you know, all this tedious

step-by-step work in order to get to the really interesting solutions and then computers came along and offered the possibility of doing that arithmetic you know by machine therefore freeing the mathematician to think lofty intellectual you know systems oriented thoughts except for that's not really what happened ultimately the computer came along and then the mathematician had to become a programmer. And then they were stuck once again doing all these bit by bit, you know, tedious rule oriented little calculations in order to write the programs. So I think Grace's perspective on it was she wanted to make sure that computers could assist mathematicians to think great thoughts and do great things without bogging them down in the details. Hopper was joining a long line of thinkers. You've got Pascal in the

17th century with the first calculator. You've got Babbage in the 19th century with the analytical engine. There's this big, beautiful line of inventors who want to build things to supercharge the human brain. Things that let us process more data than we could ever manage on our own. That's the lineage Grace Hopper was stepping into when she invented something that everybody thought was impossible. I mean, Grace's idea that people should be able to communicate with their computers using natural language and that that language should be machine independent, therefore interoperable between different computing machines was revolutionary in its time.

People that got behind her, this notion that she called in the early days automatic programming, were considered to be like space cadets in the community of programmers and computer people. And the people who weren't on board eventually became known as the Neanderthals. It was this huge rift in the computing community. Hopper did not have an easy time convincing her superiors to cross that rift, but she saw it as her duty to try. There's always a line out here. That line represents what your boss will believe at that moment in time. Now, of course, you can step over it, you don't get the budget.

So you have a double responsibility to that line. Don't step over it. But also keep on educating your boss so you move the line further up so next time you can go further into the future. That future she pushed toward is our present. Pretty much every language that you and I rely on owes a debt to Hopper and her first compiler. So that's Space Cadets 1, Neanderthals 0.

The idea that we could code not with numbers, but with human-style language. All of a sudden you're typing, go to operation 8 or close file C. It was programming made human. Grace was uniquely aware of the fact that, you know, computing was going to be a world changing thing, but it wasn't going to be a world changing thing if nobody understood how to access

it or use it. And she wanted to make sure that it was as open to as many people as possible and as accessible to as many people as possible. And that required a certain level of concession to, you know, comprehensibility and readability. So ultimately, the desire to create programming languages came from, you know, wanting to give more points of entry to the machine and taking it away from this priesthood and opening it up to a greater public and a new generation. I want to pause here and just underline something Claire said. Programming languages as we know them today come from a desire to open the tech up, to take it away from a priesthood of math PhDs and make development accessible. The spirit of the compiler that does all that work,

it's motivated by a sense of empathy and understanding. Claire's got a theory about why Hopper was the woman to deliver that change. It has to do with Hopper's work during World War II. She was doing minesweeping problems, ballistics problems, oceanography problems. She was applying all of these different diverse disciplines representing all the violent, chaotic, messy realities of the war and translating them into programs to run on the Mark I computer. She knew how to do that translation between languages. And I don't realities of the war and translating them into programs to run on the mark one computer she knew how to do that translation between languages and i don't mean computer languages i mean like

you know human languages like she understood how to listen to somebody who was presenting a complex problem try to understand where they were coming from what the constraints and affordances of their discipline was and then translate that into something that the computer could understand. In a way, she was like the earliest compiler, like the embodied human compiler, because she understood that you had to meet people on their level. Compiling as an act of empathy and understanding. I think we can all keep that in mind when we learn new languages

or wonder why something isn't compiling at all. The compiler's job should be to meet your language where it lives. Grace Hopper knew that once humans could learn to speak programming languages, and once compilers began translating our intentions into machine language, well, it was like opening the floodgates. She knew that computing could never develop as an industry, as a world-changing force, if it was too siloed and too specific. And the people who were its practitioners couldn't communicate with the people whose problems needed to be put on the machine, so to speak. So she was really quite expert at that kind of human translation, which I think, yeah, made her uniquely qualified to be thinking about and creating programming languages. Hopper's work on English-style data processing language eventually evolved into COBOL,

which is sort of perfect because COBOL is not flashy. It's very down to business. And so was Grace Hopper. In a way, she gave us a language that sounded a lot like her. Also like Hopper, cobalt's got longevity. It's still around 60 years later. Okay, so Grace Hopper's compilers were like babblefish, parlaying meaning between programmers and their machines. And they were translating things from higher and higher levels of abstraction. Then, a few decades later, we get another crucial ingredient added to the language mix. So picture this.

The free software community took off in the 1980s. But when the Unix alternative GNU was created, there weren't any free and open compilers to go with it. In order for GNU to give us a real open source alternative to Unix, in order for programming languages to thrive in the open source world, the community would need to pull a Grace Hopper. We needed an open source compiler.

Here's Langdon White, a platform architect at Red Hat, talking about where things stood. In the 80s, you can still go spend 10 grand pretty easily on a compiler. The free part was a big deal, right? I don't have an extra 10 grand lying around to go buy myself a compiler. Plus the fact that I'd have to buy myself a compiler for every platform on a target. So, you know, in those days, it was mostly Unix, but all the different flavors, right? So you wouldn't be able to just buy one, you would also have to be able to you'd have to

buy multiple for different architectures or different vendors. LinkedIn notes that it was more than just costs at stake. In some cases, it was the coding work itself. People don't realize that it matters how you structure your code in very specific ways. So, you know, like doing nested for loops or doing nested while loops or that kind of thing may be okay, depending on the compiler. So, you know, if you don't know how it's optimizing your code, it's very, very difficult to know how to write your code to get the most optimization. Suffice to say, we needed a free option, an accessible option, a trustworthy option.

What we needed was the GNU C compiler, the GCC. That was the beast, first released in 1987, that merged Grace Hopper's compiler revolution with the free software movement. It standardized things and let everybody compile what anybody else had written. The richness of our languages is thanks to that moment. The fact that the GCC was open sort of moved languages to a different level. Carol Willing works at Project Jupiter, and she's the former director of the Python Software Foundation. People started realizing that proprietary languages, while they served a purpose at the time,

they weren't going to gain the acceptance and adoration of the developer community. Because if I'm a developer, I'm going to want to learn what is most commonly used, and as well as what is new and on the forefront. I don't necessarily want to develop a skill that will lock me into one technology. I think one of the reasons that Python was so successful is it was open source. It had a very clean syntax. What it was doing is it was allowing people in a common way to solve problems quickly, efficiently, and also to allow people to collaborate. And I think those are the signs of good programs and good libraries is if you can

get your work done with a minimum amount of headache and you can share it with others, I think that's golden. Over the years, the GCC evolved to support Java, C++, Ada, Fortran, I could go on. By having a common underlying interface like the GCC, it lets people take languages and then customize them to their particular needs. For example, in the Python world, there's many different libraries. And even specifically in the scientific Python world,

we've got things like NumPy and Scikit-Image, Scikit-Learn. And each of those have sort of a more specific task that they are known for. So we've also seen things like bioinformatics and natural language processing. And so people are able to do many different things working off of a common base, but then putting elements into their languages or libraries that allow them to optimize problem solving in their particular industry or area. So this is what happens when compiler technology runs headfirst into the open source movement, right? Over time, the collision creates a big bang of new community-supported languages

that anybody can learn and build with. There are hundreds and hundreds of those languages being used today. As open source became more popular and more accepted, what we've seen is a proliferation of languages. There were a number of languages around cell phone technology and mobile, different languages that helped make game development more straightforward, all-purpose languages like Python and Ruby that were sort of foundational for the web development and delivery of web applications and websites. The list goes on. And yeah, that Tower of Babel we're building is just going to get more packed in the future. But look, you can also see it as a cornucopia, a language feast,

and we're going to help you sort through that feast next. Okay, so I know where the language flood came from, but how do we make sense of it all? How do we pick out languages that matter to us? It's a big question, so I brought in some help. Clive Thompson's one of the best writers out there for making sense of the tech world. He's a columnist at Wired, a contributing writer at the New York Times Magazine, and he's working on a book now about the psychology of computer programmers, which is perfect because we need to know what's going on in our brains when we choose which ones to learn. Here's me and Clive hashing it all out. When I was first starting out as a new developer, I just said, you know, let me find the best one.

I'm going to get really good at it and then I'll be done. But it's not quite that simple. Why are there so many programming languages? Each language has sort of a bias of things that it's good at. So typically, the reason why someone creates a new language is there's something they want to do that the existing languages aren't good for. JavaScript is a good example of that. Netscape, you know, had created a browser back in the mid-90s, and all these webmasters wanted to do something a little more interactive.

They wanted there to be a way to have a bit of scripting inside their website. And so these demands were coming to Netscape, and they were like, all right, we need, there's nothing out there that can do this. We need a scripting language that we build inside our browser. And so they hired Brendan Eich, who was considered a senior guy. He was like, I think he was like 32 and everyone else was like 21. I'm a senior in developer world.

And they gave him 10 days to make JavaScript. So he literally just didn't sleep for 10 days. And he frantically cranked out a scripting language, you know, and it was kind of ungainly and kind of a mess, but it worked. And like, you know, it allowed people to do very simple things,

you know, buttons and dialogues and pop-ups and whatnot. And so that's an example of a language that, you know, it was created to do something that wasn't really possible at that point in time. That's fascinating. So that's why so many languages exist

is that people keep on finding a reason to do something that no one else can do. So what is so interesting to me about the relationship between developers and our programming languages is we have such a strong attachment to these tools. Why is that? There's a couple reasons why.

One is that sometimes it's literally just an accident of what was the first language that you learned. And it's kind of like your first love. I think there's also like different personalities work with different types of languages. Like you look at Facebook and it was designed with using PHP and PHP is, you know, kind of a hairball of a language, right? Like it's very irregular. And it sort of grew in these fits and starts. And that's sort of the way Facebook feels too. Like, you know, in comparison, you know, the guys at Google decided, well, we want a super high performance language because Google, at Google, we're all about, you know, things running really fast and things, you know,

sustaining trillions of users at once. And so they decide to make Go. And Go is a really terrific language for that sort of high-performance computing. Let's go a little bit deeper. Is it that I, as a developer with my specific personality, am going to be naturally attracted to certain languages or that the language I work in might influence my personality? Well, definitely both. But I do think that there is a really strong resonance

that people find when they hit a language that they like. You go to a computer science curriculum and you sort of learn what you have to learn. You know, like they're all teaching Java, sometimes more JavaScript or Python. But the point is, you're forced to learn it, so you learn it. But what do people do when they have the choice? And this is where you really see how the sort of emotional or psychological style of someone gravitates towards a language. Because I talked to one guy who tried learning JavaScript a bunch, And it was just sort of,

it's kind of an ugly language to look at. It's got the curly bracket nightmare going on. And so he tried and failed and tried and failed and tried and failed. And then one day he saw a friend working in Python and it just looked so clean and beautiful to him. He was kind of a writer and it's often regarded as a writerly type of a language because the sort of indentation makes everything easy to read.

And it just clicked with him because there was just something about the way that Python worked and looked, its beautiful spareness that hit him. So talking with Clive, I realized there are languages that are thrust upon us. I'm talking about those ancient languages that are just baked into everything we work with, the code Latin. But there are also languages we choose, the languages that fit our personalities. And if you want to know what's new and shaking things up, you want to ask a developer what they use on the weekend. Here's more of our conversation. So when I ask people, you know, what are you kind of doing in your spare time,

it'll be all this weird stuff. I think it's actually one of the things that's sort of, you know, nice and laudatory about developer behavior is that they tend to be very, very curious people. I know people that decided, I'm going to learn Erlang, just a hell of it. I'm trying to imagine these projects that people are working on

on the weekends. And it's almost like the project is secondary. It's like the learning of the tool, the language is more important. That's really what they're there for. Exactly. I mean, this is sort of why you'll see people just constantly reiterating over and and over again like these calendaring and to-do list things because it's a very quick way just to sort of figure out yeah what does this what does this language do and how does it work and it almost doesn't matter what i'm building so long as i'm building something they want to know what it feels like to think in that language you know like is it going to be is it going to feel um you know thrilling and and easy and fluent in a way that I'm not experiencing with the current languages? Is it going to open up doors to make things easier to do?

And so there's a possibility space that occurs when you encounter a new language that can be really exciting, imaginatively exciting. So I'm a Ruby, I'm a very proud Ruby on Rails developer. And I think it was about two years ago that another pretty well-known Ruby developer, Justin Searles, did this really, really great talk advocating for this idea that a language doesn't need to be sexy to be used. And his thesis, his whole point was that Ruby was really exciting because it was new. And it kind of got to a point about a couple years ago where it just didn't need any more things. You know, it was done. It was a stable language.

It was a mature language. And as a result of it being mature, it's not as exciting for developers. It's not this new toy to play. And so we kind of slowly move away from it and onto the next shiny thing. So, you know, in a sense, it's almost our own curiosity

that might kill a language or make it a little, you know, more stale, independent of whether the language is actually good or bad. No, I think that's absolutely true. In fact, the downside of this deep, you know, curiosity and desire to self-educate that you see amongst developers is that they're constantly trying to find the new shiny thing

and use that language to replicate things that are already basically done pretty well by their languages, right? Right, yeah, absolutely. Curiosity is a benefit and a trap. Mm-hmm, mm-hmm, yeah, Yeah, beautifully put. Sometimes our curiosity may be a trap, but it's also the thing that fuels the evolution of languages.

Every new language is created because someone said what if? They come about because that developer wanted to do something different. They wanted a whole new way of saying it. I think Grace Hopper deserves a last word here. I will instantly materialize the site. You and I will hunt you for 24 hours. And see if I can get you to take another look. We can no longer afford that phrase.

It's a dangerous one. The story of Grace Hopper and the first compiler reminds us that there's always a better way to do something if we can just find the words. And no matter how abstract those languages become, whether we're floating high or low over the ones and zeros of machine language, we need to make sure it's a smart choice. We choose the language, or maybe even build the language, that helps our intentions come closer to reality.

If you want to learn more about languages and compilers, you are not alone. We pulled together some super useful material to help you dive deeper, and it's all waiting for you in our show notes. Check it out at redhat.com slash command line heroes. Next episode, we're tracking the complicated path toward making open source contributions. What are the real-life struggles of maintainers? How do we make that very first pull request? We're taking you through Contributing 101. Command Line Heroes is an original podcast from Red Hat.

Listen for free on Apple Podcasts, Google Podcasts, or wherever you do your thing. I'm Saranya Dvarek. Until next time, keep on coding. Hey, I'm Jeff Ligon. I'm Director of Engineering for Edge and Automotive at Red Hat. One of the most exciting things about edge computing right now is the potential to join forces with AI. There's so much data on the ground that businesses can use to improve services.

But running sophisticated AI workloads at the edge is just not a do-it-yourself operation. You get buried in the details very quickly. Specialized hardware, custom-built this and that, workloads in the cloud and at the edge. How do you pick the right devices? What's the OS? How do you update everything? At Red Hat, we don't think those details should be where you have to focus. You can hand that complexity to us. Our edge solutions provide a consistent operational experience for even the most complex workloads. From the data center to the cloud to the farthest edge. Learn more at redhat.com slash edge.