From: Lady Date: Mon, 18 Dec 2023 04:48:33 +0000 (-0500) Subject: [2023-12-17] programming_resolutions_24 X-Git-Url: https://git.ladys.computer/Blog/commitdiff_plain/6a0984aba3202f4566d987fd161b32528fd6e570?ds=sidebyside [2023-12-17] programming_resolutions_24 --- diff --git a/2023-12-17/programming_resolutions_24/#entry.rdf b/2023-12-17/programming_resolutions_24/#entry.rdf new file mode 100644 index 0000000..5c7802d --- /dev/null +++ b/2023-12-17/programming_resolutions_24/#entry.rdf @@ -0,0 +1,313 @@ + + Programming Resolutions for 2024 + 2023-12-17T23:48:33-05:00 + + prrgrrmmng 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 for historical reasons + 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]: "Continuous Partial Mythologies" +[TYRANNY]: "The Tyranny of Structurelessness" +[WEBARCH]: "Architecture of the World Wide Web, Volume One" +]]> + Lady +[Prrgrrmmrr; Grrl]. +Some rights reserved. + +This blogpost is licensed under a Creative +Commons Attribution 4.0 International License. +]]> +