--- /dev/null
+<awol:Entry
+ xml:lang="en"
+ xmlns:awol="http://bblfish.net/work/atom-owl/2006-06-06/"
+ xmlns:dc11="http://purl.org/dc/elements/1.1/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:sioc="http://rdfs.org/sioc/ns#"
+>
+ <dc11:title>Programming Resolutions for 2024</dc11:title>
+ <dc11:date>2023-12-17T23:48:33-05:00</dc11:date>
+ <dc11:abstract rdf:parseType="Markdown"><![CDATA[
+A set of resolutions for the upcoming year which I think are important
+ to ensure that the output of the work that I do is humane, use·ful,
+ and generally in·line with my ethical and esthetic sensibilities.
+Many of these stand in sharp contrast to current trends within
+ computing, and the resolutions would hardly be meaningful otherwise.
+]]></dc11:abstract>
+ <sioc:content rdf:parseType="Markdown"><![CDATA[
+The following are a set of resolutions for the upcoming year which I
+ think are important to ensure that the output of the work that I do
+ is humane, use·ful, and generally in·line with my ethical and
+ esthetic sensibilities.
+(I some·times use the spelling <i>prrgrrmmng</i> to distinguish
+ programming of this form from other kinds.)
+Many of them stand in sharp contrast to current trends within
+ computing, and the resolutions would hardly be meaningful otherwise.
+
+It is also worth noting that many of these are things that I am already
+ doing, but I’m recording them here in the hopes that others might
+ find them use·ful as well.
+
+## Resolution ①: Commit to Unix Philosophy
+
+This resolution comes first because it is foundational to the approach
+ I take with software projects.
+Different people have different understandings of what “Unix
+ philosophy” means, so I want to be clear about it here :—
+
+01. **Programs should be scoped as tightly as possible;** they should
+ do as few things as possible while still providing the necessary
+ flexibility for complex operations.
+
+02. **Programs should read from `stdin` and write to `stdout`.**
+ How this happens may be adjusted with commandline flags, but the
+ vast majority of information should be provided in‐band through
+ `stdin`/`stdout`/`stderr` and not through some other mechanism.
+
+03. **The input and output of programs should follow common conventions
+ and standards,** so that both are easy for other programs to
+ replicate and process.
+
+04. **Programs should be built to combine with other programs** in ways
+ that significantly increase their potential.
+
+05. **Programs which aren’t broken should not be fixed.**
+ Instead, new programs should be written which provide missing
+ features.
+
+What Unix philosophy brings to the table, to my eye, is really _a
+ different mindset around dependency management_.
+In contemporary programming, dependency management is typically thought
+ of in terms of Semver‐versioned package sources and a package manager
+ which resolves them appropriately.
+These packages are then included in the project which makes use of
+ them.
+
+Under the Unix philosophy, in contrast, dependencies come not in the
+ form of packages but a·p·i’s.
+This means :—
+
+- **The burden is on users to provide programs** which support the
+ necessary a·p·i’s, but in contrast, **any program which supports
+ the necessary a·p·i’s can be used** (e·g Free·B·S·D _or_ F·S·F).
+
+- **Dependencies are replace·able piece·meal** as new versions come
+ along, and conversely, **dependencies which “just work” can remain
+ in place** for years.
+
+- **Newer programs and implementations can be easily turned into a
+ replacement for older programs and implementations** by just
+ applying appropriate transforms on the input and output (and,
+ potentially, vice·versa).
+
+- Instead of needing to manage one dependency tree for programs
+ written in Ruby and another for programs written in Swift, **the
+ same dependency can be used in all applications across languages,**
+ because all languages provide the ability to read from `stdin` and
+ write to `stdout`.
+
+I don’t want to criticize package managers too harshly, but I don’t
+ think that language‐specific package managers are a good solution for
+ personal computing, and I don’t think learning five different a·p·i’s
+ across five different programming languages is helping any·one.
+People writing personal scripts or doing highly‐individualized
+ computing cannot afford to constantly be interfacing with package
+ managers to ensure that every one of the dependencies for every one
+ of their scripts is up·to·date.
+**Make small, reliable programs with common interfaces that any·one can
+ use,** and **depend on existing a·p·i’s with multiple
+ implementations,** not strictly‐versioned, single‐language packages
+ where possible.
+
+## Resolution ②: Commit, Also, to the Web
+
+The Unix philosophy works well for programs being run on one’s own
+ personal computer, but it doesn’t necessarily map well to networked
+ technologies over the internet.
+For these, thankfully, we have the [philosophy of the
+ Web][WEBARCH] :—
+
+01. **The Web is a network of _resources_, named via _global
+ identifiers_ and accessible via _U·R·L’s_.**
+
+ - The global identifiers should have the form of I·R·I’s and,
+ ideally, should be persistent and unique across space and time.
+
+ - U·R·L’s and I·R·I’s should be human‐readable and transcribable,
+ but should not encode unnecessary information or information
+ which is liable to change.
+
+ - U·R·L’s should not change unnecessarily.
+ When they do change, having separate, persistent identifiers
+ helps to rediscover the resource at its new location.
+
+02. **Resources should be retrievable in common formats using common
+ protocols.**
+
+ - Common formats include H·T·M·L, X·M·L, and Json.
+ Specialized forms of resource may allow other formats, for
+ example N·Triples or Turtle for metadata resources, in line
+ with community practice.
+
+ - Plain, stateless H·T·T·P(·S) requests should be used to access
+ resources when·ever possible.
+
+03. **Resources should be designed in a way so as to maximize their
+ utility to the person accessing it.**
+ They should be readable and processable without any specialized
+ tools.
+ They should conform to community standards for information
+ representation.
+
+04. **Resources should link to other, related resources by U·R·L.**
+ Put together, linking, common formats and protocols, and U·R·L’s
+ provide a similar level of functionality to that of reading and
+ writing from standard input in Unix.
+ They enable the creation of complex user‐agents which operate by
+ processing and combining a number of simpler resources.
+
+**Follow web philosophy whenever publishing documents or data.**
+This is often the easiest, and most boring, solution to online
+ publishing.
+**[Be boring.][CPM]**
+**Shift the focus from making interesting protocols to making
+ interesting _tools_** which _use_ those protocols.
+
+## Resolution ③: Write for the Future
+
+If what was popular in technology never changed, it would mean that
+ technology culture had reached a stale·mate, which would probably be
+ a bad thing.
+Instead, **assume that what is popular today may not be popular
+ tomorrow.**
+This probably means that popularity is not actually a very good
+ indicator of which technology a person should use, unless that person
+ is very committed to redoing all of their work every five‐or‐so
+ years.
+
+Popular technologies change, but old data remains, and if one wants
+ that data to remain accessible and useful, that means one needs to
+ construct it in such a way so as to not break in the absence of the
+ current technological fads.
+**Use formats which can be analysed with tools that are proven to be
+ durable,** and converted from there to more contemporary formats as
+ necessary.
+**Write programs which can be run in the absence of current
+ technological infrastructure,** for example specific iterations of a
+ particular package manager or versioning scheme.
+
+If everything new eventually becomes old, then in five years it will
+ not matter whether a program was written using new technologies or
+ not.
+However, what _will_ matter is whether the program still runs and is
+ useful.
+**Use that perspective as a baseline** when making decisions regarding
+ program architecture and a·p·i.
+Contemporary problems will persist for as long as there is
+ contemporaneous data, so **build solutions for contemporary problems
+ and contemporary data which can persist alongside them.**
+
+## Resolution ④: Capture the Current Moment
+
+A good program might remain useful for many years.
+That makes programs, in a sense, transmitters of history (a fact which
+ any·one who has ever read the phrase <i>for historical reasons</i>
+ knows well).
+How·ever, programs rarely bother to encode their _social_ history
+ alongside the technical.
+
+I think this is a loss of radical potential, but also a loss of a
+ chance to invest in programs as a site of human connection and
+ understanding.
+For all of history, humans have decorated the tools they use with
+ symbols and meaning; tools are in fact, generally, an important part
+ of material culture.
+But despite this, computer tools have typically only been decorated in
+ the most banal of ways (branding).
+The _internals_ of programs (their structures, variable names, source
+ code comments) could be records of much more than just a dry series
+ of technical decisions—if we were willing to invest in them as
+ social objects and not merely objects of science.
+
+**Don’t write “timeless” programs, write programs which can be
+ understood in any time** because they encode the human
+ particularities of living in the world in the year and place in which
+ they were written.
+**View programs as instances of instrumental culture** which _not only
+ might be decorated_ (the same as one might carve an image into a
+ bench, or embroider a picture onto a pillow) but whose _very
+ construction is social_ (akin to choosing fabric patterns and designs
+ for a quilt).
+**Recognize these aspects of programs as not merely “esthetic”, but
+ also conveyors of historical, cultural, or political meaning;**
+ endow them with symbols accordingly.
+
+## Resolution ⑤: Compute Less, Transform More
+
+There are times when computers actually need to do computing.
+But much of the time, computers are used simply to access and present
+ data.
+If data is accessible in form $A and simply needs to be presented in
+ form $B, this is a problem of _data transformation_ not a problem of
+ _computing_ per·se.
+
+Json is a good data structure for accessing information for computing
+ but it is a bad data structure for accessing information with the
+ intent to transform it into something human‐readable.
+X·M·L and s·expressions, on the other hand, are trivially
+ transformable, and X·M·L in particular is home to a variety of
+ human‐friendly destination formats.
+Consequenty, for data which is intended for human consumption, **use
+ X·M·L, or use a language with a straightforward transformation into
+ X·M·L.**
+**Do not use bespoke Json syntaxes** which require specialized tools
+ to process or display.
+**Do not use abbreviated, context‐specific formats** which are easily
+ separated from the contexts needed to interpret them correctly.
+
+**Assume all data is intended for human consumption** because all
+ programs should be written by humans and for the benefit of humans.
+**Always have a plan for formatting data** in a human‐readable manner.
+
+## Resolution ⑥: Collaborate Socially or Not at All
+
+Much of the current open‐source tech world is currently focused on the
+ problem of how to drop the social barrier for software collaboration
+ to be as low as possible.
+Personally, I think that asocial collaboration leads to asocial
+ software.
+And in my experience, [typically these sorts of “open” projects are in
+ fact entirely closed][TYRANNY] to ideas and contributions which do
+ not align with their pre·existing agendas, because there is no social
+ structure by which needs can be negotiated or meaningful pressure
+ applied.
+
+**_Require_ social interaction** for collaboration with one’s software.
+**Make it clear from the outset who is responsible** for addressing
+ public concerns, and **require that the public address _that person_
+ or _those people_** specifically.
+**Have communication channels** for frequent collaborators, and **put
+ those channels in a place where those collaborators feel welcome**
+ and able to contribute.
+**Have an onramp** for interested persons to get more involved;
+ **invite people who give a shit** to give a shit formally.
+
+**Don’t use faceless ticketing platforms** where strangers shout into
+ the void in the hopes that some·one with power will see their post
+ and agree.
+**Don’t erase power differences** between maintainers, leads,
+ collaborators, and the general public.
+**Stop participating in spaces** which don’t know how to manage their
+ communities or don’t perceive themselves as having communities _to_
+ manage.
+**Make a hard exit** when projects respond to suggestions only with
+ opinions, and never questions.
+
+## Conclusion
+
+Obviously, the resolutions in this post are probably impossible to
+ fully implement with every program I work on or every line of code I
+ make—especially when those programs or code are being written within
+ constraints set by somebody else.
+However, I think they are a useful aspiration and yardstick against
+ which to measure the things I make.
+These yardsticks are use·ful, of course, as people who make things and
+ want to make things better.
+If you also write computer programs, I’d be interested in hearing how
+ yours compare.
+
+[CPM]: <https://www.aaronland.info/weblog/2021/11/12/continuous/> "Continuous Partial Mythologies"
+[TYRANNY]: <https://www.jofreeman.com/joreen/tyranny.htm> "The Tyranny of Structurelessness"
+[WEBARCH]: <https://www.w3.org/TR/webarch/> "Architecture of the World Wide Web, Volume One"
+]]></sioc:content>
+ <dc11:rights rdf:parseType="Markdown"><![CDATA[
+Copyright © 2023
+<a href="https://www.ladys.computer/about/#lady">Lady</a>
+<small>[Prrgrrmmrr; Grrl]</small>.
+Some rights reserved.
+
+This blogpost is licensed under a <a rel="license"
+href="http://creativecommons.org/licenses/by/4.0/"><cite>Creative
+Commons Attribution 4.0 International License</cite></a>.
+]]></dc11:rights>
+</awol:Entry>
Lady’s Gitweb / Blog / commitdiff