]> Lady’s Gitweb - Blog/commitdiff
[2023-12-17] programming_resolutions_24
authorLady <redacted>
Mon, 18 Dec 2023 04:48:33 +0000 (23:48 -0500)
committerLady <redacted>
Mon, 18 Dec 2023 04:49:30 +0000 (23:49 -0500)
2023-12-17/programming_resolutions_24/#entry.rdf [new file with mode: 0644]

diff --git a/2023-12-17/programming_resolutions_24/#entry.rdf b/2023-12-17/programming_resolutions_24/#entry.rdf
new file mode 100644 (file)
index 0000000..5c7802d
--- /dev/null
@@ -0,0 +1,313 @@
+<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>
This page took 0.025051 seconds and 4 git commands to generate.