Arnt Gulbrandsen
About meAbout this blog
2016-07-29

Morbid bindings

The first thing I learned about programming in-person (not from a book or from code) was morbid bindings, a strangely unused term.

I learned it from a university employee called Eric Monteiro, who was oddly clueful in a generally sparsely beclued environment. Can't remember his title, or what he taught.

I had just listened to Eric answer someone else about multiple inheritance, and asked a followup question, which he answered, and then he digressed into relationships in general: When two things are connected in a program, the binding is always one of three: A kind, a belonging, or else it's morbid, and morbid bindings always turn out to be bad in one way or another. He gave me a quick example: This number in this file has to be at the same as that number in that file and I think I answered, such as maximum line length in two functions that read/write the same file?

Kind: This one's well-known. In java a List is-a Collection, which ties the List to the Collection because it's a kind of Collection. An object is an instance of a class (in most OO languages), which ties the object to the class in a similar way. Some of these can be argued. Is an integer a number? Mostly I would say yes, even though a+1>a is true for numbers but not necessarily for integers in programming languages.

Belonging: A java member function belongs to its class. (It also is an instance of another class.) A member variable generally belongs to an object/instance, or sometimes to a class. A server belongs to its client(s) (or in some designs the other way around). In many cluster designs, nodes belong to the cluster. The keys in a hash map belong to the hash map (NB: to the instance, not to the class). A unit test belongs to the code it tests. A called function belongs to the calling function for the duration of the function call.

Morbid bindings: The rest, by definition. I'll give three examples and argue that turning the morbid binding into something else makes the program better in each case.

These have to be the same. Locking order is often a matter of morbid binding, but does not have to be. There can be a definition of truth and each locking regions can belong to it.

For example, the locking API could enforce the locking order, or a static analysis tool could check the locking regions and block those that cannot be verified. In these cases each locking region has a belonging relationship with either the locking API or the static analysis tool, and because of that the binding between two locking regions is not morbid.

When there is no such relationship, then each code site that locks is morbidly bound to the others.

These have to be different. String is a ruby system class and rails adds new functions to it, such as pluralize and singularize, a practice known as monkeypatching. If several classes monkeypatch e.g. String, they are morbidly bound to each other, because their sets of extensions cannot overlap. By using e.g. static analysis to avoid monkeypatching conflicts, one binds the monkeypatchers to the analyser, and coincidentally improves the program by making each subsystem's unit test test the actual program. (Quite often each subsystem sees only its own monkeypatches because that's the last subsystem initialised before the test runs, so the tests show 100% green but in reality there's subtle breakage.)

X' input and Y's input/output must match. Sometimes two functions have to cover all the same cases, e.g. to allow equivalent input from two sources, or to ensure input/output correspondence.

Java's Serializable interface requires the caller to implement two functions, one to read and one to write the object. Nothing in java ensures that the reader can read everything the writer can write, therefore your readObject() and your writeObject() are morbidly bound to each other unless you take steps to prevent that. You could, for example, write writeObject() in such a way that you can also write a script that converts your writeObject() source into unit tests for readObject(). The act of binding readObject() to writeObject() via its tests converts a morbid binding into an indirect belonging and also ensures that your class really is Serializable.

2016-07-21

Open source is succeeding, and rms is unhappy

This summer Dropbox released an image compression thing called Lepton, effectively a better way to encode JPEG (same principles, same pixel results, considerably better execution of various implementation aspects). Dropbox didn't have to do that. But one does nowadays, it's become part of modern programming culture. Using and releasing open source is a best practice, as the buzzword goes.

Around the same time Richard M. Stallman posted a condemnation of companies that both support free software and teach classes in use of nonfree software. Condemnation is the word he chooses, not my choice. No fraternisation with the enemy!

That enemy is us, now. The enemy is those who follow today's conventional best practices. A stealth-mode startup I am talking to has ten projects on github, because the CTO there has decided that whatever good programmers consider good is what shall be done in his realm. Most of the projects are forks, some with PRs for upstream, others described as the code in this fork isn't really suitable for upstream, but take it if you want. Good, polite behaviour, best practice indeed, and very different from the GNU purity that rms requires.

What is left of rms' following if the good programmers are declared to be enemies? The outlook for the GNU project is poor.

2016-07-19

It's the attitude, not the wording

Once upon a time, a clever young programmer submitted a middling patch to the linux kernel. Not directly, it went to a subsystem maintainer who merged it with other code of his own and perhaps from other people, put his name on it and sent it to Linus. The young programmer's name was not visible. That was a bit of luck, because there was a bad bug in the code, the kind of bug that causes blaming, finger-pointing and angry email.

Only Linus, that maintainer and I knew that the young programmer was myself, and Linus never said an unkind word and didn't tell anyone who wrote the code either, so noone could email me and tell me their thoughts.

Fast forward twenty years, to when Sarah Sharp decided to stop contributing to the linux kernel. Sarah wrote good code for the kernel. I was sad to hear that she left, sadder about the reasons.

A lot of people blame Linus and his swearing for her leaving. I think that's unfair to Sarah, unfair to Linus, and worst of all, I think that we in the open source community hurt our community when we do that. Even if Linus' swearing hurt Sarah.

Linus has his faults. For example. when someone from Redhat wanted kdbus into the kernel, Linus' response showed good technical judgement, but it was also heated, loud and negative. Certainly not ideal. However, the fair comparison is not against an ideal. Linus' response ought to be compared to a standard professional response, plausibly something like oh, this code is poor, on the other hand that major stakeholder wants it merged. After a few rounds of squabbling and some cleanup the code is accepted.

That would be professional behaviour. That sort of professionalism is how a good, clueful CTO ends up with 22,000 messy lines of PHP despite a clear mandate from the board to prioritise quality. How teams end up selecting MongoDB over PostgreSQL. Possibly that's how Windows NT got graphics drivers in the kernel.

Linus won't tolerate that sort of professionalism, instead he'll swear and scream. Is that worse? I think not. It may or may not be better, but it's not worse. But because Linus behaves that way and attracts criticism for his loud swearing, some of the less notable opensource contributors escape criticism, and some of them are mean and spiteful as well as loud.

Saying fuck isn't that bad. In my opinion it's about as bad as being late for a meeting. A mean attitude is worse, much worse.

Since people focus on Linus' swearing, though, Linus' swearing opens the door to meanness and spite. A minor fault enables a major.

2016-07-18

Animated art

People have started making art using animations on the internet, mostly on tumblr. Great. Most of what I've seen is abstract, some not. All of it is art in a new domain and such a joy. Some examples I like (note that the last one of these probably shows a nude): 1 2 3 4 5 6 7. Several of these are by Florian de Looij, who also makes interesting inanimate art. (Neat word!)