KludgeCode

is Ben Rudgers

Remarks: Epigram 8

This is part of a writing exercise around Alan Perlis‘s Epigrams in Programming.

A programming language is low level when its programs require attention to the irrelevant.

Perlis is treating languages as cultural artifacts that change rather than a technology which develops – low and high are relative values assigned by individuals in light of their work not within a great chain of taxonomy. Languages evolve by adaptation. They are not trees growing as a function of light and air.

Low and high depend on state. C++ is high level if one needs to manage memory directly. But low if garbage collection is good enough – Rich Hickey observes that programmers adopted Java over C++ because managing memory was incidental complexity. Each workday they had business problems to solve plus memory to manage. High level languages reduce the swamp’s alligator population.

>"hello world"
HELLO WORLD

In this sense, object oriented languages like Java may be seen as low level because they require implementing objects all the way down to Hello World. What makes a language low level is not missing features, but the amount of work a particular language requires of a particular programmer for a particular project at a particular time.

By extension, any software is low level when it leaves the user dealing with irrelevancies regularly. Ignorance plays a role. Ubuntu defaults to manually approving updates, then requires a password. There is a setting somewhere, but looking for it is not what I am trying to do, updating is not what I’m trying to do either. The irrelevancies pile up. This is not unique to Ubuntu. The same could be said of any OS.

The way in which the low level can be raised to high level in software is by providing fine grained configuration control. Sometimes I may need to allocate disk sectors directly. Usually I don’t. The ideal high level program hides and displays features at the appropriate time [I am reminded of the Ribbon interface].

In this analysis, configuration options become a domain specific language. The more powerful and flexible the configuration options are the more powerful and flexible the software can be. Because everything in the configuration options is relevant to the program, one could begin designing a program with them. It would be an interesting exercise; one based on the question, “What power am I going to give the user?”

This seems to me to be the story of Emacs and its evolution. Emacs is little more than a text editor with extremely fine grained configuration options – so fine grained that the configuration options have their own Lisp. Then again, between the keyboard and the screen what else should there be? The same could be said of AutoCad. Configuration -> Automation.

Over time, what is irrelevant changes as technology evolves. Memory management has become less relevant (from the perspective of the typical programmer) as more transistors can be placed on a chip. Type safety has become more relevant as larger and larger programs move onto more diverse machines. We don’t want javascript controlling the brakes on a truck.

By Perlis, Javascript is more high level than Java much of the time precisely because it doesn’t require explicitly creating classes or impose type safety and the applications it is used for don’t require either. One might say that the more idiomatic the requirements of a language the lower level it is.  Lisp and Javascript have idioms, but a programmer doesn’t have to use them. C++ has idioms that cannot be avoided. Required idioms are imposed by syntax.