 There are basically two reasons why one language might be more efficient than another. The first reason is that some languages provide more direct control over what precisely goes on in the machine. Having precise control is certainly no guarantee that the programmer will find optimal solutions, but with enough time and effort, good programmers can generally optimize more than even the best compilers and interpreters. The second reason the language might be more efficient than another is that it introduces less overhead. Automatic memory management, for example, requires work, work which must be intermingled amongst the programmer's own code, and hence introduces overhead. Interpretation itself also introduces overhead, as the instructions which read and execute the program source code themselves consume time and memory. Dynamic strongly typed languages also introduce overhead, because every time an operation is performed, the types of the operands must be checked. So high-level languages which use automatic memory management, interpretation, and dynamic typing all introduce overhead, and so generally perform worse than languages which use manual memory management, compilation, and static typing. So code written in Perl, Python, Ruby, and JavaScript generally performs worse than the functionally equivalent code written in C++ and Objective-C. In the middle, we have languages like Java and C-Sharp, which both feature automatic memory management, but use a hybrid of static and dynamic typing, and a combination of compilation and interpretation. So what kind of performance differences are we talking about? Well, that varies greatly depending upon what the code does, and of course depending upon how well we write the code. In the average case, code written in the slower languages like JavaScript or Python runs probably 10 to 100 times slower than the equivalent code written in C or C++. In many cases, however, the performance difference may be negligible. For tasks in which the CPU spends much of its time waiting for input-output devices, like when reading data off a hard drive, the time the CPU spends actually executing code may account for a trivial part of the overall performance. By analogy, if it takes 16 hours to fly to Australia, a 40-minute walk to the hotel doesn't really add much travel time compared to a 10-minute drive. As for memory usage, again, overhead is added by automatic memory management, interpretation, and dynamic typing. The interpreter itself, of course, consumes memory as the program runs, and garbage collection and dynamic typing both require storing additional metadata about the objects in our code. Garbage collectors, for example, usually work by counting the number of references to each object, and these reference counts take up some amount of memory. Aside from this overhead, the more direct control of memory which programmers exercise in languages like C and C++ allows programmers to minimize their usage of memory in ways they simply can't using languages like Python or JavaScript. Now, what about portability? What is it about a language that allows you to run your code on different platforms without extra work for each platform? Portability comes down to basically four issues. First, different makes-it-processor generally have different instruction sets, and the machine code written for one instruction set doesn't work for another, so the assembly program written for an x86 processor, of course, doesn't run on an ARM processor. Second, different operating systems have different system calls and different APIs for invoking those system calls. Third, not all computers have processors, operating systems, and input output devices with the same capabilities. Obviously then, our code cannot make use of capabilities which a system we wish to run it on doesn't have. And fourth, because of the first three reasons, library code doesn't necessarily run on all platforms. If a library which our code needs doesn't work on a platform, then our code won't work on that platform either. So now, how do we write a program to run on different platforms without writing separate versions of the program for each platform? Well, the first issue, differing instruction sets, is pretty much solved by using any language other than assembly. To run on multiple operating systems, we can avoid invoking system calls directly and instead use a library as intermediary. Instead of directly invoking system calls, we invoke library code which invokes those system calls for us, and so it's left up to the library to make the right calls. The library itself, of course, must have different code for each operating system, but by using the library, our own code can be the same for all platforms. Differences in capabilities, however, quite often, simply have no workaround. For example, if a target platform doesn't support a hardware device, there's simply no way your program can use that device on that platform. In other cases though, your target platform's capabilities diverge only in non-essential details. For example, the file system on Windows broadly resembles the file system on Unix, but some details differ, such as their support for file locks. Your program might then work around these differences by simply avoiding the capabilities which both systems do not share in common. Alternatively, program features which rely upon certain capabilities might simply be emitted on the target platforms which do not support them. A so-called functional language is a language geared for programming in the functional style. The category includes several well-known but not very popular languages, including Scheme, Haskell, Scala, and ML. Another language, Prologue, belongs to an entirely separate paradigm which we didn't mention, called logic programming. To give you an idea of how unpopular logic programming is, Prologue is the only logic programming language anyone's ever heard of, and even it has hardly ever been used outside of academia. A shell language is any language which runs interactively as a command prompt. The user types one line, they hit Enter, and then that line is executed. While shell languages do typically have control flow of functions and variables, the stuff that usually makes up a general purpose programming language, shell languages allow the user to run programs by simply typing their name, and then everything else about the language's syntax and semantics is built around that design decision. The result is that shell languages tend to be awkward and ugly for general purpose use. The Windows shell language is usually just called Windows command prompt. On Unix systems there's a wide variety of shells, though the default on most Linux systems is called bash, which we'll cover in a later unit. Though shell languages are oriented around interactively entering and running commands line by line, shells can be made to execute files of sequential commands. Such a file is called a shell script. The term script in programming has come to mean a program in which most of the real work is farmed out to other programs. The program is a script in the sense that it is giving high level directions, but then the real work is being done by all the other actors. You might occasionally hear some languages described as scripting languages. For instance, using Perl and Python became popular alternatives to writing shell scripts, so many people started calling Perl and Python scripting languages. In recent years, however, Perl, Python, and other dynamic languages have come to be used more and more in the writing of complete programs rather than just small scripts, so in truth the term scripting language is kind of outmoded. So far, every language I've described is a general purpose programming language, which means that you can write code in these languages that does anything code can possibly do. While writing some programs and say bash would be very impractical, it is in principle possible. In contrast, what are sometimes called data languages are not programming languages at all, even though they are forms of code heavily used by programmers. Webpages, for example, are ultimately documents expressed as text in the data language called HTML. XML is another data language. It's pretty much a standard syntax for representing hierarchical data in textual form. By using the common syntax of XML to represent their data, programmers can save themselves a lot of grunt work when reading and writing their data because they can use library code that deals with the XML format. A query language is used to make requests of a database. A database, as we'll discuss in a later unit, is basically a program for storing and organizing large quantities of data. When we write a program that needs to deal with a lot of data, it often makes sense to farm this job out to a database. To then communicate with a database, our program would use a query language like SQL, spelled SQL, which stands for Structured Query Language. A domain-specific language, as the name implies, is designed to solve one particular problem in one specific domain. The term is sometimes applied to anything which isn't primarily meant to be a general-purpose language. So the term can be applied to SQL, HTML, XML, and even shell languages like Bash. Lastly, a graphical language is any language where the code is not expressed as text, but rather as graphics, as something visual, either wholly or in part. There aren't many examples of graphical languages, or at least those examples which do exist often aren't recognized as programming languages. For instance, there are programs which allow you to create a graphical user interface visually rather than having to write all the code by hand. These GUI builders, as they're called, usually generate, from the visual representation, actual code of some programming language, like, say, Java. Still, the graphical representation itself is like a kind of language. So the graphical languages which do exist are data languages, or otherwise domain-specific. While a general-purpose graphical language is conceivable, no one has yet demonstrated that such a thing would be a good idea. It might sound very appealing to get away from just boring text, but the disadvantage is very quickly outweigh the potential merits.