Programming

python -c "
import sys, json
with open('$OUTPUT') as f:
   output = json.load(f)
sys.stdout.write(output['upload']['links']['original'])
" | pbcopy

Good example of the ugly side of programming. Gist 3082977

Structure

Fundamental elements

Contemporary programs consist of the following parts:

• Variables — names or placeholders for other things
• Atoms — numbers, strings, some special objects like booleans
• ADTs — arrays and hashtables, also things like sets
• Verbs — functions, also called methods in some contexts
• Control flow — conditionals and loops especially

There isn't much that doesn't fit into this scheme somewhere:

• Modules are just organisations of mostly verbs
• Objects are syntactic sugar over hashtables that map names to verbs, with an implicit first argument to the verb being the hashtable itself
• Arguments are just ADTs: regular arguments are an arrays of stuff passed to the verb, and named arguments are hashtables
• Pipes are stream-object-typed arguments to a verb
• Even unix commands follow a similar pattern: flags are named arguments, which map to hashes; the rest of the arguments form an array

It seems amazing that we can get so much done with such simple parts. When I was investigating code visualisation, I was surprised to find just how much of my code was essentially messing with structures. Most programming seems to be a case of setting up control flow used in conjunction with verbs to modify some ADTs. At a higher level, you break this into verbs in order to make it readable and to avoid redundancy.

Often when I'm programming I would like to use some verb from Python, run it through a bash command, do some DOM display with it like you would in JavaScript, and I wonder why it's not possible to link together these languages so easily when they use mostly the same kind of parts.

Exercise: Bootstrap a language containing all the fundamental elements of programming from x86 assembly, in as minimal a way as possible.

Special elements

There are some elements that do conform to the fundamental element patterns, but have some aspect to them that distinguishes them orthogonally. Examples include:

• Verbs to get user input
• Sockets
• Device file interfaces
• Threads and processes
• IPC objects
• Timers
• Databases

The orthogonality here is something like side-effects. These are non-idempotent, not very functional-programming safe things. Databases can be seen as persisted ADTs of course.

Notes

List of desirable features in a modern programming language, from logs: "small installation, well tested, portable, good standard library, good maintenance community". Also, no surprises in the syntax; a very boring syntax. Might be some more in the logs too.

FAQ

Q. (​dpk​) When you say a "boring syntax", how do you mean? Regular, in the way that HTML syntax is compared to Markdown? Or familiar, in the other way round? And, programming being what it is, what is “familiar” varies greatly from person to person.

A. (​sbp​) Familiar and regular. Yes, the nature of familiarity changes, but you'll notice that languages do tend to coalesce around certain syntactic feature sets, especially these days. There is an art to choosing a set of features that works well together, that is true.

For example, in python you use paren(calls), but in CoffeeScript you use command calls, and not many people would argue that paren calls are unexpected. But the CoffeeScript way does really feel better. Admittedly, it causes some problems sometimes too. Perhaps that's a problem which can be fixed using enforced style, a bit like how Go has a standard code style formatting tool to make sure that everybody is on the same page.

Lisp

Lisp sort of inverts CoffeeScript. Consider this CoffeeScript-a-like block of pseudo-code:

chocolate orange
  chamomile a, b, c cloves
  garlic spinach (d, e, f), g, h, i

Which becomes:

(chocolate orange
  (chamomile a b (c cloves))
  (garlic (spinach (d e f) g h i)))

Or perhaps:

(chocolate orange
  ((chamomile a b (c cloves))
   (garlic (spinach (d e f) g h i))))

Lisp thinks that we use long argument lists and few calls or nesting, and optimises as such. Obviously that's the exact opposite of what we tend to find: separating arguments is one of the least common things, and we don't mind using commas for that.

Note also that (a b) is a valid CoffeeScript synonym for a(b), though discouraged.