macrakis@harvard.ARPA (Stavros Macrakis) (12/29/84)
> > ... (really, now, is C much higher level than assembly language?). > (No, but it's a higher-level language than most of its competitors. :-) > Come now, what does it mean to say that language X is "higher-level" > than language Y? What is a "high-level" language? Chambers proposes: > X [is] "higher-level" than Y if it is generally possible to express > concepts (data structures, operations, flow of control, etc.) in fewer > symbols in X than in Y. The expression of concepts is surely the crucial idea. But counting symbols misses the mark. Leaving aside the problem of definition of symbols (characters? lexical elements? syntactic productions?), what on earth does their number MEAN? Perhaps it's a measure of the conciseness of a language, but conciseness is not high level. Perhaps Chambers will agree to: A high-level language expresses high-level concepts WELL. Which leaves us with the definition of "high-level concepts" and, for that matter, "expressing well", while disposing of pseudo-quantitativeness. High-level concepts do not seem to be much in dispute--of course they change over time, and vary by application area, but operations on mathematical objects (Setl sets, Sequel relations) are generally agreed to be higher level than operations on computer memory (PL/I based variables, C offsets); control structures induced by the problem (Prolog backtracking, Simula processes (maybe)), higher level than control induced by the program counter (goto's); object lifetimes based on usage (Lisp GC), higher level than lifetimes based on explicit deallocation (PL/I or C); and definition mechanisms allowing the behavior of an object to be defined independently of its internal structure (Simula classes), higher level than definition mechanisms allowing only a fixed repertoire of operations (Cobol records). Between these extremes we find: operations such as ordinary arithmetic (not really mathematical arithmetic), record field selection, and array subscripting; control structures such as procedures and while-loops; lifetimes based on lexical structure (Algol); and definition mechanisms allowing certain operations to be redefined (EL/1 user defined functions). The "Turing tarpit" makes "expressing well" tough to define. The definition must include the convenience of expressing something (Agreed?), which includes both the ease of writing and the ease of reading. Conciseness plays some (smallish) part in this. The crux, though, is the directness of expression, the point where I appear to part company with the Lisp, APL, and C enthusiasts. Does the language express a concept, or only allow it to be implemented? Expressing a concept directly means having a notation that MEANS something, not a notation that DOES something. When the notation means something, the human reader can reason about its meaning; mechanical processors can process the notation and determine such things as consistency (at a trivial level, this means type checking) or change the implementation for better efficiency (e.g. some sets can be better implemented as bit-vectors, others as linked lists). Finally, keep in mind that level is not the only property of a language, nor even the only important property for evaluating a language. By describing C as low level, I do not mean to say it is useless or bad. It is, however, overrated; and on this net, at least, Ada is grossly underrated. > [My] definition sounds intuitively like a useful one, but it sometime > has results that partisans of various languages might find surprising. > For example, Cobol is lower than assembly language. ... Forth ... > come[s] out much higher (around 10-20 for certain application areas....) Chambers' 'surprising' conclusions about language level pretty much destroy his argument anyway. Much as you may dislike Cobol or like Forth, any metric that makes Cobol lower level than assembler, and Forth much higher than Pascal, has some pretty deep flaws. No doubt Teco would come out even higher, and surely Trac is close behind. -s