Layers of Distraction

Posted on 2015-01-04 by Graham

A discussion I was involved in over on Facebook reminded me of some other issues I’d already drafted for this blog, so I stuck the two together and here we are.

Software systems can often be seen as aggregations of strata, with higher layers making use of the services in the lower layers. You’ll often see a layered architecture diagram looking like a flat and well-organised collection of boiled sweets.

As usual, it’s the interstices rather than the objects themselves that are of interest. Where two layers come together, there’s usually one of a very small number of different transformations taking place. The first is that components above the boundary can express instructions that any computer could run, and they are transformed into instructions suitable for this computer. That’s what the C compiler does, it’s what the x86 processor does (it takes IA-32 instructions, which any computer could run, and turns them into the microcode which it can run), it’s what device drivers do.

The second is that it turns one set of instructions any computer could run into another set that any computer could run. If you promise not to look too closely the Smalltalk virtual machine does this, by turning instructions in the Smalltalk bytecode into instructions in the host machine language.

The third is that it turns a set of computer instructions in a specific domain into the general-purpose instructions that can run on the computer (sometimes this computer, sometimes any computer). A function library turns requests to do particular things into the machine instructions that will do them. A GUI toolkit takes requests to draw buttons and widgets and turns them into requests to draw lines and rectangles. The UNIX shell turns an ordered sequence of suggestions to run programs into the collection of C library calls and machine instructions implied by the sequence.

The fourth is turning a model of a problem I might want solving into a collection of instructions in various computer domains. Domain-specific languages sit here, but usually this transition is handled by expensive humans.

Many transitions can be found in the second and third layers, so that we can turn this computer into any computer, and then build libraries on any computer, then build a virtual machine atop those libraries, then build libraries for the virtual machine, then build again in that virtual machine, then finally put the DOM and JavaScript on top of that creaking mess. Whether we can solve anybody’s problems from the top of the house of cards is a problem to be dealt with later.

You’d hope that from the outside of one boundary, you don’t need to know anything about the inside: you can use the networking library without needing to know what device is doing the networking, you can draw a button without needing to know how the lines get onto the screen, you can use your stock-trading language without needing know what Java byte codes are generated. In other words, both abstractions and refinements do not leak.

As I’ve gone through my computing career, I’ve cared to different extents about different levels of abstraction and refinement. That’s where the Facebook discussion came in: there are many different ways that a Unix system can start up. But when I’m on a desktop computer, I not only don’t care which way the desktop starts up, I don’t want to have to deal with it. Whatever the relative merits of SMF, launchd, SysV init, /etc/rc, SystemStarter, systemd or some other system, the moment I need to even know which is in play is the moment that I no longer want to use this desktop system.

I have books here on processor instruction sets, but the most recent (and indeed numerous) are for the Motorola 68k family. Later than that and I’ll get away with mostly not knowing, looking up the bits I do need ad hoc, and cursing your eyes if your debugger drops me into a disassembly.

So death to the trope that you can’t understand one level of abstraction (or refinement) without understanding the layers below it. That’s only true when the lower layers are broken, though I accept that that is probably the case.

Posted in architecture of sorts, launchd, software-engineering | Leave a comment

I imagine many of you are familiar with the difference between Ruby (a beautiful language representing the best pragmatic balance between Smalltalk’s elegance and C’s ubiquity) and Rubby (a horrendous mishmash of abominations in the style of all scripting languages, glommed together by finding nearly-compatible corner cases).

I also make the same distinction between Open Source (an attempt to get the same exploitation of labour as Free Software but without the principles) and Open Sores (the disturbingly wobbly house of cards that arises when collections of developers, none of whom feels empowered to make big changes, individually attach small pieces of mud to the collectively-constructed big ball).

Neither is fair, but both are useful shorthands.

Posted on 2014-12-31 by Graham | Leave a comment

In which I resolve

Posted on 2014-12-28 by Graham

When I was a student I got deeply into GNU and Linux. This has been covered elsewhere on this blog, along with the story that as Apple made the best UNIX, and the lab had NeXT computers, I went down the path of Objective-C and OS X.

I now think that this was because, as an impressionable twenty-something-year-old, I thought that the most important part of the technology was, well, the technology. But I realise now that I want to have taken the other path, and now need to beat across toward it.

The other path I’m talking about is the one where I notice that it’s not programs like those in Debian that are so great, but the licences under which they are distributed. Much of the software in a GNU/Linux distribution is not so good. That makes it much like using software on every other platform. The difference is that I have the right-and hopefully, after a decade of practice, the ability-to do something about it in the case of free software.

I’m certain that GNU is not the best of all systems, though, because the focus has been on the right to make changes, not the capability of making changes. A quick review of the components I can remember in the installation on my MacBook shows that I’d need to understand at least nine different programming languages in order to be able to dive in and address bugs or missing features in the system, holistically speaking. If they’ve given me permission to change how my computer works, they haven’t made it easy.

But as someone who can change software and wants software to be less broken for me and for others, that permission is important. Next year I’ll be looking for more opportunities to work with free software and to make things less broken.

Posted in futurology, Responsibility | Leave a comment

Derek Jones, from the PL advent calendar ‘J’ entry:

Javascript would not have existed without the Internet and its ‘design’ must be a contender for the most costly software mistake [ever] made.

Me, 14 months ago:

Fundamentally I fear a world in which programmers think JavaScript is acceptable. Partly because JavaScript, but mostly because when a language is introduced and people avoid it for ages, then just because some CEO says all future websites must use it they start using it, that’s not healthy. Objective-C was introduced and people avoided it for ages, then just because some CEO said all future apps must use it they started using it.

Clearly JavaScript is good enough for a broad set of uses. But then we should ask whether ‘good enough’ means unfurling the Mission Accomplished flag and calling it done. Apparently some people have similar feelings, but also the skill and inclination to do something about it.

Posted on 2014-12-10 by Graham | Leave a comment

Object-Oriented Programming in 1714

Posted on 2014-12-07 by Graham

Here are some excerpts from Leibniz’s La Monadologie (specifically from Daniel Garber and Roger Arlew’s English translation in Discourse on Metaphysics and Other Essays).

THE MONAD, which we shall discuss here, is nothing but a simple substance that enters into composites – simple, that is, without parts.

Thus, one can say that monads can only begin or end all at once, that is, they can only begin by creation and end by annihilation, whereas composites begin or end through their parts.

The monads have no windows through which something can enter or leave. […] Thus, neither substance nor accident can enter a monad from without.

From this we see that if, in our perceptions, we had nothing distinct or, so to speak, in relief and stronger in flavour, we would always be in a stupor. And this is the state of bare monads.

Thus we attribute action to a monad insofar as it has distinct perceptions, and passion, insofar as it has confused perceptions.

But in simple substances the influence of one monad over another can only be ideal, and can only produce its effect through God’s intervention, when in the ideas of God a monad rightly demands that God take it into account in regulating the others from the beginning of things. For, since a created monad cannot have an internal physical influence upon another, this is the only way in which one can depend on another.

But natural machines, that is, living bodies, are still machines in their least parts, to infinity.

And the author of nature has been able to practice this divine and infinitely marvellous art, because each portion of matter is not only divisible to infinity, as the ancients have recognized, but is also actually subdivided without end, each part divided into parts having some motion of their own;

This we see that each living body has a dominant entelechy, which in the animal is the soul; but the limbs of this living body are full of other living beings, plants, animals, each of which also has its entelechy, or its dominant soul.

That’s a small fraction of the complete essay but it’s clear from these extracts that Leibniz saw both the benefit and the drawback to Object-Oriented Programming, and that they were one and the same.

Objects are indivisible atoms, which cannot mess with each other’s insides nor have their own insides messed with. Rather, they have independent existences, unless one of them sends a message to another via the universal actor willing the two into some correlation.

Something appears to be an object in the first instance, because it is an indivisible thing with its own whole definition and purpose. It is actually both a composite, that can be subdivided into other objects with their own definitions and purposes; and it is a component that contributes toward a larger object that has its own definition and purpose.

Scale-variant analogies can get us out of the problem with the object-as-monad. One that has previously been well-explored is Brad Cox’s Software IC, which sees the object take up a position at only one level of abstraction:

  • Component => C instruction.
  • Integrated Circuit => Objective-C Object.
  • Circuit Board => Package or architectural layer.
  • Electronic System => Application.

One that I haven’t yet investigated is the cellular biology analogy introduced by Alan Kay (who also introduced the object-as-monad analogy). He talked about the object as a cell (particularly as a small component of a larger system that has a well-defined boundary across which limited communication occurs), but we can also think about the implications of larger scale order:

  • Cell => Object.
  • Organ => Object.
  • Organism => Object.
  • Society => Object.
  • Population => Object.
  • Biome => Object.

And, as Leibniz said, it’s objects all the way in the other direction: organelles are monads too.

Posted in OOP | 1 Comment

An odd thought: I have written software for a computer whose CPU was used as an I/O controller for a computer that I have programmed, whose CPU was used as an I/O controller for a computer that I have programmed. So far, I’m not aware of the i7 being used as an I/O controller.

Posted on 2014-12-07 by Graham | Leave a comment

Programming language advent

Posted on 2014-12-01 by Graham

http://shape-of-code.coding-guidelines.com/2014/12/01/algol-60-awk-algol-68-ada-apl-and-assembler/

The first article, containing languages beginning with ‘A’, is linked above. I can tell this is going to be a month of reading.

Posted in tool-support | Leave a comment

That can’t possibly work.

Posted on 2014-11-27 by Graham

A while back I was at a Facebook developer event, talking about techniques for analysing Objective-C. My summary of the problem was something like “it’s one of those things that works pretty well in the ivory towers of practice but completely falls apart when you try to use it in theory.”

That’s true of many things in building software, but as people who get paid for removing bugs from things we’re all too good at the situations where the theory doesn’t pan out. Problems arise when we report the overly general conclusion: “that doesn’t work” rather than “there exists a condition in which that doesn’t work”.

Often, the appropriate thing to do is to build the thing anyway and extract value from it in the cases where it does work. Most Ruby code is just Java with different punctuation: if you build a thing that can’t possibly work because of monkey patching then build it anyway and 100% (give or take) of Ruby you actually encounter will work with it.

If it were up to programmers we wouldn’t have paper money. You can’t promise to back 10× as much money as you’ve actually got gold to make good on, in case everyone asks for it back. Ah, but what if they don’t?

And even if you find that the edge situations arise too frequently to make the thing you built worthwhile, you’ll have learned something about the problem. You may find a different approach, or even that solving a slightly (or greatly) different problem is what you really want to do.

When someone tells you the thing you want to build can’t work, build it and work with it. If only for the look on their face.

Posted in learning | Leave a comment

Détournement and Recuperation

Posted on 2014-11-21 by Graham

Letterists International probably invented the ideas behind free software and creative commons. They created the idea of détournement, in which existing mainstream logos and slogans were subverted for anarchist, satirical and other radical political purposes, like the picture of the Queen defaced in the cover of the Sex Pistols single.

The counterpart to détournement is recuperation, in which radical ideas are appropriated by the cultural mainstream to be re-used in safe contexts, like the use of Thunderclap Newman’s “Something in the air” to advertise an airline.

Free Software enables both of these: mainstream software made available under free software licences like the GPL can be put to radical new uses because of the terms of the GPL. But it also enables software built to political ends, and shared under those terms, to be put to mainstream uses.

If anything, open source software is a bigger enabler of recuperation. By relieving receivers of the pay-it-forward obligation, open source licences make it easier for incumbent organisations using traditional software model to make use of ideologically-motivated software publication.

Posted in philosophy after a fashion | Leave a comment

Today’s surprisingly short workflow-improving win

Posted on 2014-11-20 by Graham

When I have a TODO comment (or a #error in code, which is how I frequently do TODOs), I switched to writing the commit message I want to be able to use when I’ve fixed the TODO. Then I write the thing that’s missing, kill the TODO and yank it into the commit command.

Posted in code-level, documentation | Leave a comment