Jargons and High Level Languages

By Xah Lee. Date:

[This essay is originally posted to comp.lang.lisp in discussion of a ideal high level language.]

Adding to Ray Dillinger and Joh Harrop's post about a ideal functional language system, my wishes are:

The language will be absolutely high-level, meaning in particular:

• The language's documentation, will not need to have mentioning any of the following words: pointer, reference, memory allocation, stacks, hash, cons cells, linked list, circular list.

• The language will not have concept of binary bits, bit operator, bytes, etc. (see the optimization section below) (However, the language can (and should) support computing with arbitrary number basis, and when the basis is 2, the compiler should of course automatically map it to bits on a chip as its method to achieve speed)

• The language's computational model should be simple, high-level, mathematics based as possible, as opposed to being a model of some abstract machine, implementation, or computational model (For example, OOP, Lisp Machine). In particular: the language will not have concepts of “reference” or “object” as in Java, or “object” as in lisp. (Here, few of today's language that qualify includes: Mathematica, PHP, JavaScript)

The language's syntax and semantics should be as much as consistent and regular as possible. For example lisp's syntax would be considered not acceptable here. (it has “' # ;” and various ad hoc irregularities) As another example, Common Lisp's multi-meaning names would be considered ah hoc irregular semantics here. (i.e. a symbol can be a variable as well as a function).

• The language's variables must not have types. Its values can have types. And, these types must be mathematics, not computer engineering byproducts. Specifically: The language will not have any concepts or terms of: float, double, int, long, etc. (it can, however, have concepts like exact number, n-bit approximate number aka machine-precision number (See below on optimization declaration).)

• The numbers in the language can have the following types: integer, rational, real, complex number. (and possibly extension from these, such as algebraic number, etc.)

• The language will not use extraneous jargons that came from computer-engineering. (these jargons in part exist as a side-effect of human animal's power struggle in academia) More specifically, the language will not have anything named “lambda”. (name it “Function” or simply “Subroutine”) It should not have anything named or documented as “Currying”. (when appropriate, explain with precision such as: applying a function to a function, or decompose multi-valued function, etc as appropriate. If necessary, invent new terms that is communicative. e.g. Function Arity Reduction Mechanism) The language should not have a name or doc about tail-recursion. (if necessary, use something like this: “the compiler does automatic optimization of recursions when …” ). Similarly, it should not use or even mention jargons of “closure”, “higher order function”, “first class citizen”, “hygienic macro”, “referential transparency”, etc. (The language, as a ideal high-level language, should, however, support these features by default by a simple principle of consistency and regularity of semantics (and syntax). It should not have the need to mention or discuss them in anyway, in particular not using these terminologies.)

The language can have many implementation/compiling necessitated/related concepts. (which are exemplified in the above occurring in other languages which we forbid here) However, these concepts, must be designed as special declaration constructs, whose purpose to the programer is _clearly_ understood as instructions/hints for the compiler that will create fast code, yet has no purpose what-so-ever as far as his program is concerned. So, for example, let's say the typical concept of “int” in most langs. In our ideal lang, it would be like this:

myNumber= 123
DeclareForOptimization(myNumber, (number, (8-bits,no-decimals)))

For another example, suppose you need a hash table. But in our high level concept there is no such stupid computer-engineering concept, nor such a stupid term “hash”. However, because we are great mathematicians, we know that compilers cannot in theory 100% determine user's use of lists for the purpose of optimization. e.g. hash table. So, the language will have a usage-declaration for the purpose of compiling/optimization, something like this:

myKeydList= ((k1 v1) (k2 v2) …)
DeclareForOptimization(myKeydList,
  (list, ((fastLookup true),(beginNumOfSlots 4000),(extendBy, 500), etc.)))

Languages are Getting Higher Level

The above criterions are basically all satisfied by Mathematica, except the last item about a complete, systematic, declarative statements for the purpose of optimization/compiling.

In general, the above criterions are more and more satisfied by modern high-level languages, in particular PHP and JavaScript. (except in places where they can't help, such as the widely-established int, long, double, bit operator, created (or propagated) by the unix/C faakheads.)

Languages in the past 2 decades are already more and more observing the above criterions. Roughly in order of history and high-level-ness: C, C++, Java, Perl, Python, Ruby, JavaScript, PHP.

2 major exceptions to this progression are lisp and Mathematica. Lisp is extremely high-level, however, due to its 40-years-old age, inevitably today it has many socially un-fixable baggage. (such as the cons business) Mathematica, which was born about the same time Perl was, is simply well designed, by a certified genius, who happens to be a rich kid too to boot, and happens to be a not a tech-geeking moron and in fact is a gifted entrepreneur and started a exceedingly successful company, whose social contributions to the world has made revolutionary impact. (besides his scientific contributions, for example, in physics.)

There is a common conception among lispers that modern languages are just more and more converging to lisp. No, they are no converging to no lisp. They are simply getting higher-level, which lisp is the grand-daddy of high-level, intelligent, computing and design.

Jargons and Sapir-Whorf

Many functional programers are acquainted with the idea, that language influence thought. (tech geekers will invariably invoke the Sapir-Whorf.) However, these average people (arbeit elite), do not have the independent thinking to realize that, terminology, or, the naming of things, has a major impact on the thing and the social aspects of the thing. More concretely, how is a thing/concept named, has major impact on education, communication, social adaption, and actual use of the thing/concept. As a actual example, many high-level functional languages are invented by academicians, who, in general, do not have much social-science related knowledge or understanding of its practicality. And, being high-powered computer engineers, are conditioned in their thought patterns around dense, stupid, computer jargons. And thus in their languages, these jargons permeate throughout the language. The practical effect is that, these languages, are perpetually swirling around these academic communities with a viral transmission so powerful that sucks in anyone who tried to touch/study/use the language into mumble jumble. (most exemplary: Scheme, Haskell) This basically seals the fate of these languages.

(of course, the one notable exception, is Mathematica. It is still to be seen, if Microsoft's f#'s team will avoid stupid jargons.)