# Programming as expression

Every computer program is also a persuasive essay & a work of interactive
performance art, and if you don’t consider it through those…

* * *

### Programming as expression

Every computer program is also a persuasive essay & a work of interactive
performance art, and if you don’t consider it through those lenses when
writing it you run the risk of persuading people of something you don’t agree
with. A lot of my criticisms of Medium & Mastodon basically come down to this:
there’s an admirable and explicitly-stated philosophy that hasn’t really been
allowed to transform deeper technical decisions, resulting in a contradiction
between intent and function, because certain things are assumed to be ‘the way
things are’ instead of a decision.

In computing, nothing is ‘the way things are’ (save the halting problem, NP-
completeness, & other similar mathematical restrictions taught to every
freshman CS student). Not only that, but doing things the right way yourself
is usually _actually_ easier than using pre-made components that are a poor
fit for the problem — standard components actually waste more time in many
cases. Some baseline willingness to expand the mind is a necessary skill for
anyone who identifies as ‘technical’, and with this baseline, use of poor
tooling is rarely justified on the grounds of engineer-time: it creates the
kind of technical debt that reliably produces technical bankruptcy (as the
resulting code must inevitably be torn down to minimize damage).

The two key components to this kind of failure are an emphasis on sunk cost
(manifesting as an unwillingness to reinvent the wheel or an exaggerated sense
of the value of existing third party tools) and a lack of imagination
(manifesting as an expectation that even if familiar tools are a poor fit,
unfamiliar tools can be no better). We ought to be very alert to opportunities
to usefully reinvent the wheel, as developers: every time we do, we find new
ways to improve it. Somebody clever once said “the great thing about
reinventing the wheel is you get to make a round one”. This is evocative, but
I think most of the time we get so focused on the wheel that we don’t notice
that in our target environment we’d have a lot fewer problems if we used skis.

Framing our projects as expressions of an underlying philosophy highlights
instances where decisions we would otherwise make without consideration
actually work against us.

To give an example — web standards assume but do not enforce that all
addresses refer permanently to an immutable piece of information, but the use
of hostnames in URLs (as opposed to content hashes) makes traffic-based
outages (like slashdotting & DoS attacks) unavoidable and broken links in the
case of the loss of a host inevitable, while encouraging domain squatting &
the use of CGI to serve uncacheable dynamic content; ultimately, permanent
addresses & immutable objects are not functionally an attribute of the web,
and we have all sorts of facilities to work around that (like large data
centers, services like cloudflare, and the 3xx, 4xx, and 5xx HTTP error codes)
and all sorts of early web features that simply cannot be expected to work as
intended (like the 3xx error codes, partial fetches, and hyperlinks
themselves). The technology necessary for permanent addressing & immutable
content without centralized control was available to Tim Berners-Lee in 1989
(and should have been familiar to him), so had he considered the risks to the
conceptual integrity of hypertext, he would not have built the system this
way.

Framing our projects as expressions of an underlying philosophy also makes
behavior more easily predicted and understood: a philosophically internally-
consistent system will behave in ways that can be derived a priori from the
philosophy in most cases, and will not behave in ways that conflict with that
philosophy in cases when the most ‘right’ solution is unclear but there are
many obvious ‘wrong’ ones.

By [John Ohno](https://medium.com/@enkiv2) on [November 14,
2018](https://medium.com/p/b7aa204851b).

[Canonical link](https://medium.com/@enkiv2/programming-as-
expression-b7aa204851b)

Exported from [Medium](https://medium.com) on September 18, 2020.

