So I would say "higher-level languages" provide less-leaky abstractions. One can specify 'what' without specifying 'how', and one can make assumptions about the way exceptional cases are handled. The ideal language would provide leak-free abstractions but still allow the programmer to dive into any level.

There is probably a lot more to say than that.

So one way to say it is that high-level languages are like porno, "I know it when I see it." Another way to say it is that there's machine language... and everything else. Or fill in the blank for machine language, "C is the last low-level language, everything more abstract is a high-level language".

It's tempting to think of memory-managed languages as high-level languages, but then there's Java...

Ratio of code size to payload is of course another metric.

http://paulgraham.com/power.html

Maybe it's the functional languages.

Why do you ask?

For example if your problem is to allow a doctor to find the best treatment for a patient with a given disease, you would say an expert system that allows said doctor to express the medical facts and reason about them is higher level than something like Lisp and a raw REPL because the last thing the doctor presumably wants to worry about is something like how a given data structure is implemented.

A "level" of a language is a very relative concept, but you can approximately define a hierarchy of languages relating the level of one language to another using some arbitrary comparison.

Since my background is in operating systems and some compilers, I'd say anything C and anything higher level is "high level," but then again, that can mean anything :)

I don't think anyone ever set out to create a "low level" language. There was simply "coding the machine directly" and then "high level language".

Now it is tempting to draw a multidimensional line in the features of languages and partition it into "high" and "low", but I don't think that is where the term originates. It is a one hand clapping sort of adjective.

further, aren't all lines multidimensional? ;P

Then there was assembler/assembly. This is similar to the aforementioned, except easier to read. Assembly is a 1:1 mapping between symbols and their machine-understandable counterparts. This is the first step in the abstracting of programming code from executable code ( http://en.wikipedia.org/wiki/Second-generation_programming_l... )

Then, there are so-called 3GL. These let you do fancy things like having named variables, symbolic manipulation, function calls, abstract (arbitrary) syntax. This encompasses many of the languages people use at work today (c/c++/java) ( http://en.wikipedia.org/wiki/Third-generation_programming_la... ) It is important to note that the purpose of 3GL, like assembly before it, was to create a separation between what the programmer typed and what the machine ran. The latter being derived from the former according to its rules.

( http://en.wikipedia.org/wiki/Fourth-generation_programming_l... ) 4GL are the next step along this line. The focus of 4GL is to make it that the code entered is as focused on the domain logic as possible, hiding the implementation details.

The phrase "further from the machine and closer to the domain"in the wikipedia 4GL page sums it up nicely.

To a chip designer, machine code is a high level language (it is an abstraction of the machine itself.) To an assembly programmer (nobody programs in machine code AFAIK,) c is a high-level language. To a c programmer, java is a high-level language. To a java programer, ruby is a high-level language. To a ruby programmer, RSpec is a high-level language.

Essentially, the further you get from the machine, the higher the level.

As far as the implementation of languages, well that depends. You can very well implement any language in assembly or machine code (given enough time, patience, and self-loathing.)

Usual strategies for the development of high-level languages are to either a) translate to a lower-level language that then gets compiled to machine code b) translate to a lower-level language that targets a virtual machine that eventually translates these lower-level instructions to machine code or c) some combination of a & b until enough of your new language has been written so that it can translate itself to machine-code or vm bytecode (known as self-hosting.) high-level languages can sometimes be seen as collections of cool libraries that translate your code into lower-level languages, on and on until you eventually get to machine code. of course, people who write these translators are smart folk, and sometimes manipulate what you have written to make it run faster.

but yes, eventually, almost all languages become machine code in order to be executed (or are converted into control flags that configure the operation of existing machine code / configure an fpga or other type of bendy silicon.)

now, were lisp machines self-hosted? i dunno.

the implementation of Ruby is open-source, and mostly-readable C. watch a movie about ruby from the inside (some knowledge of c is useful)

http://mtnwestrubyconf2008.confreaks.com/11farley.html

read more about the same:

http://eigenclass.org/hiki.rb?ruby+internals+guide

---

5GLs are even more abstract. instead of solving the problem in the domain space, you merely specify the constraints on the possible solutions and the computer provides you with solutions that satisfy all constraints. this offloads the work of figuring out how to solve the problem to a bit of problem-solving code. Programming a generic problem-solver that finishes in an acceptable amount of time on existing hardware in most cases is EXTREMELY difficult to do, so you need to let the consumer of the 5gl specify some control logic and provide hints to the problem solver. How to make this all work right, fast and make it more palatable than having a nice 4GL is not a solved problem.

Rumor has it that there are members of the cult of Logic Programming planning a re-emergence from the shadows and sewers. ( http://www.cs.kuleuven.ac.be/~dtai/projects/ALP/newsletter/f... )

Yes. However, I'm not sure why that's relevant.

Basically, low levels of abstraction are closer to the underlying mechanics. Higher levels of abstraction allow you to think about what happens without having to worry about the fiddly little details. It's like the difference between neurology (comparatively low-level) and psychology (higher level).