Kurious K

So I was searching for appropriate libraries and styles to implement a Deep Learning training pipeline ¹. Earlier I had stumbled upon Flow Based Programming and Luigi. However that’s not what I was looking for.

So I decided to scour the wiki page for programming paradigms and saw Aspect Oriented Programming which seems quite familiar to me having used Emacs for a while, although I haven’t used its advice system myself.

However, while browsing I came across so many programming paradigms which I’m not familiar with. And I am a sucker for novelty!

What’s Function-Level?

On the other hand I am familiar with the Functional Programming paradigm having used Emacs Lisp for a long time and dabbled in introductory Haskell a bit. However, for the first time I came across the term Function-Level Programming.

On its wiki page there’s a quote by John Backus, claiming that programming languages aren’t really doing anything novel. In another paper (Backus 1978), he rails against the Von Neumann style of computation (a complex topic for another time) and laments:

1. Their close coupling of semantics
2. Their division of programming into a “world of statements” and “a world of expressions”.
3. Their lack of useful mathematical properties for reasoning about programs.

And he calls for an “alternative functional style of programming”.

However, he did not really have in mind Lisp, OCaml, Haskell et. al. style of functional programming languages which are popular today and called them Applicative Style (See section 2.2.2 of (Backus 1978)).

I’ll post notes on that paper in a separate post. However, simply put, he proposed a language called FP (see also (Backus 1978)). It’s inspired by APL which he mentions in the paper. Essentially it’s a set of primitives for operations on finite sets. Any program in FP consists of those primitives and compositions of those.

APL and K

However, FP as the wiki page notes, didn’t really become popular outside of academia. There were extensions with FFP, FP84 and FL but nothing substantial.

APL however is an interesting language founded in the sixties for array processing, which requires special symbols and usually a special keyboard!

But! That’s not all. Iverson recognized the difficulty of adoption of APL and continued to work until he developed J, which looks fairly interesting. The reason for spare notation and succinctness of syntax can be found in his paper Notation as a Tool of Though (which I’m yet to read).

However, it reminds me of Shakespeare’s “Brevity is the soul of wit” being uttered by a rambling idiot. Or the fact that a concise syntax may sometimes require a lot of explanations.

A very interesting adaption of APL is K. Developed by Arthur Whitney it uses lists instead of arrays as the primary data structure and ASCII for ease of use. A brief homage to K exists in https://github.com/kevinlawler/kona.

The page mentions that “People can and do create network trading platforms in hours.” The page also links to an original source file by Arthur Whitney to https://github.com/tavmem/buddy/blob/master/a/b.c. The source file itself refers to k.h which is there in k.h and describes the various definitions used in the previous one. k.c is an interesting skim. Extremely unreadable.

It appears that these are highly concise, primarily functional languages written with data processing in mind.

Notation of Thought

What Whitney did was create an APL like dialect from C and used it to code other parts of the system. Such practices would be unheard of today as these programs read like minified versions of source code. In fact, much after APL, and alongside K a parallel movement of literate programming had begun to take hold which propounded blurting out all that was going inside the programmer’s head while writing code (See web, noweb). The comments in that weren’t separate from the code but in fact, part of the software.

Such processes have evolved into maintaining extensive documentation and testing today where the need for explainability outweighs the need for performance or speed of coding.

However, I do wonder (although without having read Iverson’s paper) that if that’s the best way to go about things. Wouldn’t we read and write much faster if the code was indeed more succinct? It does involve learning an entirely new language I admit. Perhaps a bit like learning Mandarin. But it is an idea worth exploring more.

References