General Programming Language Comparison

Hey guys, this is Maads 101, and today I'm going to be comparing several different languages, um, to just explain what's different about each one and why different programming languages are good for different things. So here are the languages I'm going to be talking about. A lot of them are pretty common, and I've actually had a decent amount of experience with all of them, so I'm going to be comparing them in a bunch of different areas, and I'll basically get at why, um, you would use a different language for, uh, different tasks.

So here are the three areas in which I'm going to be comparing these languages. The first is, uh, what I would use the language for. The second is how the language actually looks when you write code in it. And the third, which will come last because I think it's, uh, I think it's the most interesting but it's also the hardest to understand, is how the actual language works—how it runs your code. Um, this is not necessarily specific to the language; it's specific to the implementation of the language, uh, but it's still important to analyze and look at.

So the first thing I'm going to talk about is how the programming language is actually used. This is, uh, probably the most interesting question that a lot of you want to see the answer for, so I'm talking about it first. It's also the highest-level thing to look at. We're not actually going to be looking at code; I'm just going to list a couple of languages for different purposes.

So the first purpose I'm going to talk about is, uh, simple scripts. For instance, let's say I want to, uh, delete several files with similar names, or I want to create a bunch of folders with sequential names, or I want to download a bunch of files from the internet with, uh, you know, sequential URLs or something like that. It's for things that maybe I want a program to loop through and do a bunch of things for me, but it's actually pretty simple what I want it to do. Uh, in this case, I would probably use one of the languages you see on the screen there because, uh, those languages have very little overhead, so I can pretty much just start writing code in them immediately and running the code. I don't need to open some fancy editor or create a new project or have a bunch of boilerplate code just to have a main function or something like that. These are the languages I would use for a really simple program.

Next, I'll talk about games because actually it turns out that a lot of people get into programming because they want to make games, which I'm not surprised about. So if you want to make games, you're probably going to end up using C or C++, if you want to make, like, a really high-performance game for a console or a PC, just because, um, when you use C++, you have the most control over what you're doing. So you can make a more efficient, more reliable code. But that's not necessarily always true; you can usually get away with—uh, for some types of games, you can code them completely in a different language like JavaScript or Java, or, uh, even Objective-C or Swift if you're on Mac or iPhone.

Uh, the next thing I'm going to talk about is servers, and this is kind of an abstract concept, but basically anything that is, uh, an entity on the internet that exists. So it could be a web server, like a website, or it could be a server for a game or anything in between, like an SMS messaging server, something that, uh, your cell carrier would use. Uh, those can be written in pretty much any language, uh, but here are the ones out of my list—just, uh, they're no in no particular order—just of, uh, the languages that I've actually used for a server before.

Uh, and graphical apps—this is kind of a subset of games, but these are more just apps that you would make that aren't necessarily going to have to be high performance. So they're not necessarily games, but you want them to have a graphical interface. Uh, Objective-C and Swift are for Mac pretty much exclusively, and I would use JavaScript, of course, for the internet if you're making a website, but for, uh, cross-platform, Java's pretty good, and for Windows, C is something that people use.

Um, and the last category, the last use that's worth noting is embedded systems and operating systems. So when you boot up your computer, it loads your, you know, pretty quickly—it's not the first thing that happens, but it loads your operating system, which is Mac OS X, and that has a bunch of internal code that knows how to look at your hard drive and handle events from your keyboard. And, uh, it knows about the mouse and the camera and all that. The operating system is usually written in C or C++. If you use Linux, your operating system is written in C, because that's the language that Linux is written in, and if you use Mac or Windows, it's probably a lot of C++.

Uh, I've never actually seen an operating system that uses Go, but theoretically it's possible, so it would be cool to look out for that.

So now I'm going to talk about, uh, the appearance of each programming language. This is the syntax; it is how, uh, I write code in the language and basically what characters I use and what keywords I use and, uh, just how the code looks. So just as a visual comparison, here is a very similar program written in both Java and Ruby. Uh, it doesn't actually do anything; it's just an example. You can see how different the code looks—and it's not just because they're different colors. Uh, you can actually see that, for instance, here I have an open curly brace; here I don't. Here, I use at signs, and here I use this dot. And you can see, uh, the Java actually is a lot wordier. There's a lot more—like this line is just straight up longer than this line.

Uh, and that's because different languages are more verbose than others, and, uh, it has performance trade-offs as well, but we're going to get into that and we're going to talk about that a lot. So the first thing I'm going to talk about—uh, this is like a light note—it's really visually obvious the difference, and, uh, so it's really easy to talk about. As you can see here, the Ruby code, uh, each line is just a line, and in the Java code, most of the lines actually end with a semicolon. You can see there they are. Um, so this is actually, uh, you might think it's weird if you're not a programmer, and it is weird; even though I am a programmer, I can look at it.

A lot of programming languages actually have semicolons at the end of every line, and a lot of programming languages don't. So on the left here, you can see ones that do, and on the right, you can see ones that don't. That's just a really concrete comparison; it's actually a pretty even divide with the languages I've chosen to look at. Um, so that's something interesting to look at.

Another thing is how, uh, sections of code are indicated. So if I look back here, you can see that, uh, in the Ruby code, there's the word end, and in the Java code, there's a closed curly brace, and here there's nothing and here there's an open curly brace. Basically, this is because, uh, in Java, this section of code is, uh, surrounded by, by curly braces, and then Ruby uses these keywords def and end to surround sections of code. So a lot of programming languages use curly braces, and some—like, uh, Python, Ruby, and CoffeeScript—do not use curly braces. So this is actually another pretty clear-cut way to compare the appearance of the programming languages.

Next, I'm going to talk about types. This is something that is a little less clear from the code, but it's actually still noticeable. Here you can see I actually just say x, y, and here it a double a, comma, double b. Uh, and you can see here I don't say Vector once on this line, but here in the Java code, I say Vector twice. That's because, uh, in Java, I have to explicitly state the kind of data, uh, that I am manipulating. Wherever I manipulate data, I have to explicitly say what kind of data it is, and in, um, weakly typed languages, I don't have to do that.

So, uh, in for instance, in Ruby we just saw, I don't have to state the kind of data I'm working on every time, but in a language like Java, which is strongly typed, I actually do have to say. And of course, people might fight me over this because, uh, there are tricks you can get around—like in Java, for instance, you can just say, "Oh, the kind of data I'm operating on is an object," and anything is an object, so—or pretty much anything is an object, so you can get around having to explicitly state what you're doing, but it's kind of a hack, and the language still, you know, the syntax still has types in it. So types are another way that you can visually compare two different languages.

And this object is a little harder to get at the core of because it's a little more complicated. And the two—the Ruby and Java examples I gave are both objects, so I can't really compare them, but basically, uh, many years ago some programmers realized that pretty much every program they wrote was, you know, it had the notion that there's an object, you know, whether it's a page like a web page or it's a car or something like that; there's objects and then there's actions you can do on the objects.

So they decided to make their programming languages kind of resemble this, um, to make them object-oriented—that's what it's called. Um, and most languages you can see that I'm comparing are object-oriented languages, and there's a few that are not strictly object-oriented; they don't have object-oriented syntax, they don't have it built into the syntax of the language. Um, you can still achieve, you know, that kind of thing; you can still have objects and have actions; it's just not necessarily as built into the language, uh, for these on the right as it is for them on the left.

Okay, the next thing I'm going to talk about is anonymous functions, and this is something that maybe isn't visually clear from many code examples, but it's actually really, uh, important for me at least, and I find without anonymous functions, I just really can't stand a programming language most of the time.

So basically, uh, what they are—I just talked about objects a lot, and a lot of programming languages have a specific kind of object, which is a piece of code, you know, an action. So I could hand you an object and say, you know, "Run this code when you're done something," and it would run the code. So I could get basically notified when that action's done; that's an example of how I would use an anonymous function. I can pass, you know, I can give someone a piece of code as an object—that's the gist of it—and all of these languages now have this functionality. You can pass an object, uh, that is a piece of code.

Languages on the right, um, they don't really have it. Java kind of has it, and I think in Java 8, um, it does have it fully, so that'll be nice. Um, Python has something called lambdas, which are kind of like this, but it's kind of a cop-out; they don't—they don't—they're not really big chunks; you can't have an anonymous function; you can have, like, a crappy anonymous function. I don't want to go into it, but that's just how I feel; I don't like it. And C will probably never have anonymous functions, or if it does, uh, no one will use them.

So now finally, I'm going to talk about how the code actually executes, how it works. Um, this is not, like I said, specific to a language. Uh, for instance, I'm trying to think of a parallel; I can't really think of one, but the idea that I'm trying to convey is that a language is different from the implementation of the language. Um, you know, how I use a language is different than the code written in it, but this is going to be talking about just the basically how the programs are run.

Uh, today, you know, um, there's multiple ways to run, for instance, Python programs; there's different programs that can run Python, uh, and some are faster than others, but I'm going to be talking about, like, the mainstream way of running each language.

So the first thing I'm going to talk about, and this is a really, uh, important thing to grasp, is whether a language is compiled, interpreted, or just-in-time compiled. So when a language is interpreted, uh, I have it stored as source code. So I just save a file that has my code in it, my, my Python code or whatever, and then I run that file. So for instance, I might write a line, you know, a couple lines of Python, save it to a file, and then I would run the file. A program would come up and it would go through each line in the file and see, you know, what that line is supposed to do, and it would run it—that's called an interpreted language. It's, uh, you know, figuring out what the program means when it's actually getting run. And I threw on AppleScript even though it's not an official one of the things I'm comparing just because some of you might know it; that's also interpreted.

Uh, for compiled languages, what happens instead is I have the code and, at some point, I compile the code, which turns it into an executable that's directly in machine code the computer can just run it straight on the processor, and it doesn't have to get interpreted, it's just run directly on the processor. So apps you download from the App Store on an iPhone or something like that, they're precompiled. You're downloading machine code; you're not downloading the code that the developer wrote; you're downloading the code that the compiler generated, uh, that can run directly on your processor.

There's also something which is between these two where either you have, uh, some code or you have some kind of bytecode—it's not really machine code—and what happens is, uh, the—as it's running, a program will turn it into machine code and then run it that way. It's faster, but it's also stored as, uh, as source code, not as an executable. It's advantageous to have code be interpreted or just-in-time compiled because, uh, it means that I can have the source code, send it to anyone on any operating system, and they can run it even if they're on different hardware, whereas if I compile the code, um, I've made it for a specific kind of processor, and if they don't have that kind of processor, they're out of luck; they can't run it.

So just-in-time compiled languages actually, I think, are probably my favorite just because it's cool and it's like the best of both worlds. Um, so here's just the list, and I'm going to go on to memory management. So basically, uh, a computer has memory, and, um, the memory is, if you think about it, it's like a giant pie, and if your program needs some memory to store information, it has to take a slice out of that pie. And let's say it doesn't need that slice of pie anymore because it doesn't need to store information anymore; it has to somehow put that pie back in the, uh—I'm trying to think, like, the plate, you know? It's kind of gross. I—I don't—the pie example wasn't as good as I thought it would be because you can't uneat pie and put it back.

But basically, the idea is you can take some memory to use it and then give it back, and there's different ways of managing your memory; uh, that's why it's called memory management. You can have—there're some languages where you have to explicitly say, "I want a slice of this pie," and when you're done with the slice, you explicitly say, "I want to put the slice back." Um, so for instance, C and C++, I would have to do that, and with Objective-C, you kind of used to have to do that; you don't anymore. Um, but then there's also things—uh, other languages like the ones on the left here, which are garbage collected, where I might say I want a slice of pie, and it would give me the slice of pie, but then it automatically detects when I'm done using it and it puts it back. So that's garbage collection; it basically just, uh, looks at things I'm not using anymore and releases them back to the system.

Uh, and then there's a weird, uh, combination which Apple seems to be the only one who's really, uh, using it—it's automatic reference counting, which is, uh, when you compile your code, it basically looks at, um, where things are referenced and figures out how to manage it. It's hard to explain what this does; if you program in one of these languages, you probably understand it. It's not quite as powerful as garbage collection, uh, because there are some things that it can't do; there's some limitations of ARC that garbage collection doesn't have, but it probably performs a little bit better.

Uh, but with modern garbage collectors, it's actually not—performance isn't that much of an issue; speed isn't that much of an issue. So that's pretty much all I had to say. I was really just comparing a bunch of different ways—uh, looking at a bunch of different ways in which, uh, different programming languages differ. Uh, I'm not saying that any language is better than any other language or that any one language is good for everything or that any one language is the best for anything. But what I was really looking at was, um, why are different languages good for different things?

So thanks for watching Maads 101! Subscribe and goodbye!