A few weeks ago I got an email from my brother asking about some programming tools for a project he wanted to try. He’s a fairly technically savvy guy, but has very little experience programming. He had asked a couple of questions which made assumptions about the lineage of some modern programming languages — assumptions which are totally reasonable given the names, but which didn’t reflect the actual nature of the languages.
This post is based on the email response I sent him.
Disclaimer: I realize that I have glossed over a number of technical details, and even introduced some of the concepts in a way which may even have some technical inaccuracies. This is not intended to be a technical manual, simply an introduction to a technical topic in terms that most non-programmers should be able to figure out.
Typically there have been two primary types of programming languages, compiled and interpreted. The source code of a compiled language is read by a lexer, parsed and then re-written into low-level machine instructions which can be executed directly on the hardware involved. Compiled languages almost always need to be recompiled for each individual platform because the physical instruction sets of Intel (x86), SPARC, ARM and other processors are all different. Operating system calls are also different. This means that code compiled to run on an Windows-based Intel machine won’t run on a Solaris-based SPARC machine.
Interpreted languages are not compiled. They are executed as they are read by some other process. These are sometimes called “hosted” programs since they don’t execute natively on the computer which is running them. The host process (web browser, game, or other runtime environment) reads the script line by line and then takes the appropriate action. So it’s the host process which actually reads files, communicates with the Internet or displays graphics on the screen. The interpreted language (script) is little more than a recipe. This is why differences in the implementation of the specification behind the script can cause such big problems. When you have 5 different web browsers which don’t quite agree on how to execute a particular construct of JavaScript it’s like the chef’s at 5 different restaurants having a different idea of what a medium-rare steak is. Sure it’s nice if one happens to do things the way you want, but you’ll never know until you try them all.
C is like the grand-daddy of modern languages. It’s curly-brace syntax pervades many modern languages (C++, Java, C#, JavaScript and many others). It is, however, a much lower-level language providing direct control of many system resources. C can also be optimized for speed and does not explicitly require any external frameworks or libraries to work. It’s a good language to have a grasp on, but may not be one you would ever use on a day-to-day basis.
JavaScript (a variant of and predecessor to the ECMAScript standard) was a language developed by Netscape in the 1990s to be a part of its web browser. Aside from the curly-brace design and the name, JS has absolutely nothing to do with Java. Until very recently, JS was purely an interpreted language. Its domain was to live inside the browser and help animate funny little things on screen or possibly display messages as you filled out a form. It’s only in the past few years that JS has really taken on a more leading role as massive libraries of complex JavaScript (jQuery) and people doing some seriously cool stuff with the language have led to uses of JS outside the browser. The node.js project is a perfect example. Node (whose executable is written in C) will serve as an engine for running JavaScript from the command-line much in the same way as Python, Perl and PHP do.
Just as most rules are made to be broken, so is the rule about a language being either compiled or interpreted. There are some languages which are a strange (and powerful) hybrid of both. Java and C# are both compiled languages. The thing is, they don’t compile down to natively executable machine code. They compile down to an intermediate format which is then interpreted when the code is executed. This provides a mechanism for the compiler to optimize the code for faster execution, while also providing a mechanism for the code to be ported to other platforms with minimal modifications.
From a language perspective C# and Java are like half-siblings… both members of a generation of languages designed to help build large cross-platform enterprise business systems, which have been drawn out into other areas due to sheer popularity. Visually the two languages look almost identical, with similar features and a “C-like” syntax, but due to each one being built to operate primarily with it’s own native framework (.NET for C# and J2SE for Java) the source code is essentially incompatible with the exception of a few trivial examples.
This all brings me to HTML5. This term has to be one of the most overused, over-hyped and poorly understood technological terms of the past decade. The name would imply that HTML5 is a new version of the HTML specification, designed to replace the rather aged HTML 4 specification in use on most websites today. And technically, that’s exactly what it is. There is a new version of HTML with some new tags (like <;video>; and <;canvas>;) which will provide web developers with some new tools to create compelling website experiences. The problem is that there are a lot more things behind the scenes that really make the next generation of web platforms powerful. A new version of HTML is just the start.
The new additions to the HTML DOM (Document Object Model) bring with them more powerful capabilities for JavaScript and CSS to help code and style the way web applications work. The <;canvas>; element is great, but it doesn’t do much without some fabulous JavaScript code to do the heavy lifting.
The next iteration of the CSS will provide more versatile styling for websites, allowing designs to function both for the desktop as well as the dozens or hundreds of combinations of screen sizes and browser capabilities on modern mobile devices. There’s a big difference between the kinds of things an iPhone 4S can display compared to a 3-year old BlackBerry Bold — both of which I have on the desk in front of me.
To wrap this up I really wanted to thank my brother for asking the question and giving me the opportunity to examine this question in detail. It isn’t something that I think about in my day-to-day work with software, but it’s still something important that bears examining from time to time.





