Practical Matters

This document is a collection of notes I've made over the years about the practical matters of production programming languages — usually stemming from being irked by some existing programming language's lack of adequate (in my opinion) support for them. As such, these thoughts may be overblown and sophistry-laden. But it is nice to have a place to put them.

Fundamental Abstractions

The following facilities should be either built-in to the language, or part of the standard (highly standardized) libraries:

• Tracing. Ideally, the programmer should be able to easily browse all the relevant reduction steps, and the relevant data being manipulated therein, in the part of the program's execution that interests them. In addition, this should be something that can be enabled without polluting the source code (overmuch).

This could be done, and fairly well, with techniques from aspect-oriented programming. The rules to describe what to trace (or to highlight in a full trace) could be specified in what amounts to a configuration file, and thus be an implementation issue rather than a language issue.

Unfortunately, this ideal is hard to achieve, so the system should also support...

• Logging. Logging is basically an ad-hoc way to explicitly achieve selective tracing: the programmer knows what points in the program, and what data, are of interest to them, and outputs that data to the log at those points.

Whether this is "debug logging" during development, or to support post- mortem analysis of issues in production, it amounts to the same thing: debugging, just on different time scales.

The use of a "log level" is mostly just a way to filter the trace built up in the log files. This is not necessarily a bad idea, but it should probably not be linear; information should be logged based on the reason that it is being logged, probably in the form of some sort of "tag", and filterable on that (whether at the time the log is being recorded, or being read.)

Logging should not count as a side-effect.

The logging function itself should have some properties:

• Should not have side-effects (for example from evaluating its arguments), so that if it is not executed (because we are not interested in that part of the execution trace) the behaviour of the program is not changed.

• In fact, should ensure that its arguments have no side-effects, and ideally, be total, with no chance of hanging or crashing.

• Should pretty-print the relevant values, include the type and other metadata of the values, and put clearly visible delimeters around the values so printed.

• Should include the source filename and line number.

• Should not be overridable (shadowed? not sure what I meant here.)

• History. This is more relevant in a language with mutable values, but as part of tracing, it is useful to know the history of mutations of a value. With immutable values, it would be useful to be able to view all the reductions which fed into the computation of the value at a point. Either way, however, this is expensive, so should be specified selectively. Again, an external, aspect-like configuration language for specifying which values to watch makes this an implementation issue.

• Command-line option parsing. This should not rely on the Unix or DOS idea of a command line, and it should be unified with parameter passing in the language itself; calling an executable built in the language with arguments a b c should be no different from calling a function from within the language with the arguments a b c (probably as string values.)

Reflection

• First-class tracebacks. When a program, for example, encounters an error parsing an external file such as a configuration file, it should be able to report the position in that file that caused the error as part of the traceback, for consistency. Java has some limited facilities for this, and some Python libraries do this (Jinja2? werkzeug?) using frame hacks, but a less clumsy solution would be nice.

• Tracebacks are not a special case of logging, or an artefact of throwing exceptions. Since the traceback is basically a formatted version of the current continuation, this suggests the two facilities should be unified, perhaps not totally, but to a high degree.

Abstractions, not Wrappers

The basic principle here is that the existing APIs of most libraries are (let's be polite) less than ideal, especially when they were designed for some other language (such as C), and instead of blindly wrapping them in a new language, the designer should at least try to make something nicer.

The abstractions should also recognize that modern computer systems are generally not resource-starved (or at least that truly high-level programming languages should not treat them that way.)

This applies to very basic facilities as well as what are usually thought of as external libraries. Specifically,

• Date and time: We can do better than simply copycatting interfaces like strftime. All time data should be stored consistently, in GMT, always with a time zone.

• String formatting: We can do better than simply copycatting interfaces like printf. We can use visual formatting strings, where fixed-size slots appear as fixed-sized placeholders (of the same size) in the formatting string. (See also the scathing prog21 criticism of the vertical tab character.)

• Line-oriented communication: We can look at line-oriented communication more generally, as a form of record-oriented communication where the "delimiter set" for each record is {LF, CR, CRLF}.

The programmer who really wants atavistic interfaces like those mentioned above can always implement them as "compatibility modules" if they wish.

Seperation from the Implementation

This is just a repeat of the above section in slightly different terms.

A language should avoid tying any language construct (e.g. imports, include files) to the file system or the operating system. Instead, have mappings between e.g. module names and where they live in the file system, and between our model of a running computer and a real OS. These mapping could be specified in configuration files which are in the domain of the implementation and outside the domain of the language, i.e. they never appear in programs.

Standard modules supplied with the language should expose models of commonplace artefacts out in the world, for example operating systems. The models are similar to the artefacts, in order that the burden of implementing an interface from the model to any given artefact is not too great. However, the models are not the artefacts. Programs should be written to the model, not to the artefact.

People who construct bindings to the language should be encouraged (only because they can't effectively be required) to create models more abstract than the libraries that they are binding.

Insofar as possible, we can have a compiler optimize things so that they match the underlying architecture. The language should allows and even encourage definitions in the most general sense; special cases are to be detected and optimized when they occur, instead of instituting those special cases into the language itself.

Another aspect of this point of philosophy is that it should be possible to specify and change the performance characteristics of the program (but ideally not its behaviour) from outside the program, using configuration files.

This counts as a practical matter because maintaining code which is cluttered with implementation-specific artefacts is burdensome.

Serialization

(This section needs to be rewritten)

• All primitive values must be serializable
• All primitive values must be round-trippable
• All primitive values must thus have an order to them (like Ruby 1.9's hashes) because in this world of representations, orderless things don't really exist
• When building user-defined values from primitive values it must be easy to retain these serialization properties in the composite value
• This is actually fairly agnostic of the particular serialization format (yaml, xml, binary, etc)
• S-expressions are trivially serializable, except for functions

Formatting

Closely related to serialization.

Many languages support a "standard" operation to convert an arbitrary value to a string. Some even have two (e.g. Python's str and repr).

But in reality, there are any number of ways to convert a value to a string. Why should the string representation of 16 necessarily be "16" — why not "0xf" or "XVI"? "16" is fine, but it should be explicitly noted to be the default for the reason that it's the most convenient for the audience of humans who use the decimal Arabic notation when dealing with numbers.

How can we support both a reasonable (and possibly configurable) default formatting, as well as any number of other ways to format values which would be more appropriate in different contexts?

Can we pass a "style" argument to the string-conversion function?

Should we establish a "design pattern" for writing formatting functions, and provide support for implementing such patterns?

(Also, format is probably a better name for this function than str.)

Multiple Environments

(This section needs to be rewritten)

• Lots of software runs in multiple environments - "development", "qa", "production"
• Inherently support that idea

Assertions

(This section needs to be rewritten)

• Software engineering is more about defining invariants than writing code.
• An "assert" command which produces details errors in development, but only logs warnings in production environments
• Very lightweight so that programmers use it without thinking (Python's self.assertEqual() is not lightweight) (Erlang's A = {foo,B} IS lightweight)
• So a conditional, by itself, is an assertion. (?)

Interfaces

(This section needs to be rewritten)

One way or another, it should be possible to discover (programmatically, through reflection of some sort) the set of operations that a value supports — its interface. Each operation has a name and a signature of some sort.

Collections are interfaces.

Some parts of an interface might be "private". This — information hiding — is obviously a somewhat complex topic. The obvious bit is that information hiding is useful to prevent unintended changes to program state, but it also hinders debugging and testing.

Usability

Memorization is not a good thing to make programmers do. This can be addressed by either copying things from an existing language that the programmer base can be expected to already have memorized, or by providing a more orthogonal set of things which maps to the culture which programmers, as people, already live in. (For example, few people in the Western world do not know that & means "and".)

Non-alphabetic symbols should, idealy, have the same meaning regardless of the context they're used in — in other words, the language should avoid using the same symbol for different purposes in different contexts.

(Lots of languages are lacking here. In C, * is both multiplication and dereferencing. In Python, . is both object attribute access and package hierarchy — although packages are, at least, kind of like objects. In Lua, = is both assignment and key value association.)

Programming Languages vs. Operating Systems

(this section needs to be cleaned up — not sure where to put it, and it arguably doesn't belong here)

What you see before you in this distribution can be described as a programming language, but many of the ideas took root while thinking about operating systems.

What's the difference between a programming language and an operating system?

Well, maybe less than you think.

Programming languages do need to define the environment in which they can express programs. Sometimes this is a specific OS (like early C on Unix) -- or they claim to be "portable", but then they're really just defining an abstraction against all the possible OS'es they think they'll run on. Often this abstract is clumsy, but some languages put a lot of thought into it, like Smalltalk.

Operating systems, on the other hand, don't tell you what programming language to use -- or do they? A modern OS insists everything is, at some point, in native machine language, and a running instance will almost always be limited to a single machine language of a single architecture. Somewhat more alternative OS'es define a virtual machine language to abstract away from the concrete machine language. Usually this virtual machine language looks like a machine language, but sometimes it's a tad more high-level, like Lisp. Any way you slice it, the OS does sanction a particular, albeit usually low-level, programming language.

Where PL's and OS's seem to meet more-or-less neatly is in the idea of the VM, so let's examine that.

Most modern virtual machines are designed to implement high-level languages in a modern operating system environment. The JVM was specifically designed for running Java, and while .NET was ostensibly designed for multiple languages, the bytecode is pretty closely tuned to C#.

What these VMs were not designed to do, but what a VM "should really" be designed to do (if it, at least, wants to live up to the name "virtual machine") is to abstract the hardware and provide virtualizations (abstractions) of the available devices.

An environment contains zero or more devices. A device exposes zero or more services. Each service conforms to one or more interfaces. Each service may additionally require one or more services be available (by interface).

At one point I was calling this place where programming language and operating system meet a "CE" (Computational Environment) because "operating system" is far too generic-sounding and "programming language" doesn't address the important environmental aspect here. Whether I would continue to use the term CE or not, I'm not sure — it could just add to the confusion.

How do most programming languages deal with the abstraction of available (or virtual) devices? Terribly, I would say. Take, as a simple example, an addressable character screen device. Someone writes a library, in C, to access it (e.g. ncurses,) providing an API comprising C functions and C structs. Someone then writes a binding or a wrapper (e.g. using swig) or otherwise foreign-function interfaces it to the language, usually exposing the exact same C-level API naively adapted to the programming language. Then you, the programmer in this language, wrestle with working with the device almost exactly as a C programmer would, initializing and releasing it as a C programmer would, with limitations on how you may or may not use it from multithreaded code like a C programmer would (which might be brutally different from how the runtime for your programming language implementation assumes that its world works.) All this, with the added hassle of having to make sure you have all these bindings for the device for your chosen implementation of your language built and installed correctly.