The HOW and the WHAT
No, a low-level programming language is not defined by being closer to the metal. And high-level programming is not defined for being closer to English. Heck, BASIC was probably the closest to English, and you’d be hard pressed to defend that it’s higher-level than Haskell. Which is probably as difficult to understand for a native English speaker as any real programming language can get, with the sole exception of APL.
Anyway, indeed, some of those things are true. But they are only secondary attributes. They are like the fact that vi allows you to do much more in less keystrokes than any other editor: the core reason is that vi was designed to work over 300 baud phone lines, and this involved, among many other things, reducing keystrokes – but this was not the goal, but a side-effect.
But even if the driving force is
improving the life of programmers reducing the cost of software development, the real way this is achieved is not by getting further away from the proverbial metal, but by allowing you to describe processes better. A higher level language allows you to describe things more succinctly, without having to get into the nitty-gritty details of every single excruciating little step. See a sample in assembly language:
This calculates and stores the sum of two values. In three steps. Read the first value into EAX. Add the second value into EAX. And store the value of EAX in the result variable. Kids, this is how we did things back in the day.
And see this in C:
Thanks progress exists.
But still, even if this shows real evolution in programming, from a decidedly lower-level language to a higher-level one, it doesn’t show what the underlying key is. Removing the references to specific CPU registers and instructions is one step, but if we don’t understand the core, we can’t further this process and create even more useful programming languages. So, what is it?
In Turing’s spirit, all programming languages are equivalent in what you can do with them. But the truth is that they are not the same at all. Something like the SKI combinators are fully capable of any computation, and what’s more, it’s just three combinators, and one of them is redundant. See a sample program:
(This piece above is number 2. Imagine how an XML parser written using the SKI combinators must look like.)
You could say SKI combinators are as far from the metal as you can imagine. Functional combinator application. Rewriting rules. Church numerals. No conventions, only a couple of basic core definitions. What not.
But even with this, I doubt anyone would dare call SKI combinators a high-level programming language. It’s about as low-level as it gets, similarly to assembly language. Ok, let’s cut SKI calculus some slack, at the very least, it’s probably the only calculus with its own Facebook page (http://www.facebook.com/pages/SKI-combinator-calculus/138648626160295 – and all of 6 people worldwide like it).
So, if closeness to the metal does not define the high/low level distinction, what does? Because it’s obvious that C and Java Fortran and Haskell share something useful and valuable that assembly language and the SKI combinatory calculus don’t. (Sorry, just kidding about Java.)
And here is the key: if you compare assembly and SKI, you see that most of the code you write deals with the nasty details of each step of doing something: reading a value into a register, or substituting a combinatory parameter in some way to rearrange information. While, on the other hand, the sample C code above depends on the underlying infrastructure, and the C code just lists WHAT the end goal is.
And this is the key: lower-level programming languages make you worry about HOW each thing is done. While a higher-level language allows you to get busy with WHAT to do, while letting the tools worry about how that goal is achieved.