Terrible pedagogy.

It's trivial for someone who has only a single device to get their hands on a Linux image and run it in a lightweight VM if they're coming from Mac or Windows. The preceding sentence doesn't hold true for any other permutation of { Linux, Mac, Windows }.

Yeesh.

We have a word "pathologize" for this, but the author doesn't use it anywhere in this piece. The general thrust behind the word's existence was an implicit understanding that to pathologize X is generally the wrong approach to trying to explain or address X. Because it doesn't really explain anything—you just sort of bottom out (or hit a wall, pick your metaphor); it operates on the same principle behind the degenerate behavior that Feynman observed and criticized about how people think that knowing the name for something is a substitute for understanding that thing, or, when asked to explain magnets, he asked the questioner what they thought they were asking and explained that there's really not an answer (of the sort they thought they wanted) for anything else that they think they understand better than magnets but didn't ask about.

It's notable that the author left out the canonical implementation (PKZIP).

I'd also expect them to have at least tried to test the ZIP support in Mac OS Finder and the Windows shell.

Not true—they're not redundant; it is not correct to assume that this relation holds.

The only correct way to compute the offset is to use the field with information about the offset. It is not correct to do otherwise.

The URL for this page (https://www.beet.tv/2009/10/webs-inventor-sir-tim-bernerslee-double-backslashes-were-unnecessary.html) betrays the author's (editor's?) inability to grasp what TBL says even while they are the ones trying to piggyback off his comments for attention.

[…] People on the radio are calling it "backslash backslash"[…]

Apart from the formatting characters, this should be easy to do—the simplest OCR to ever implement.

Interesting outcome. Rarely (basically never) do you see "it's more verbose to write in $LANG2 what would be written in fewer lines if you were using $LANG1" touted as a positive.

missing comma here

Ibid.

"Web address" is so awkward as a term. Better to just make it concrete, anyway, by providing a familiar example like "The URLs that appear in the address bar in a Web browser […]".

The syntax highlighting here is very strange. It seems to follow the rule that the first atom inside a set of angle brackets is bold, and the subsequent atoms (if any) are not.

There's probably a better way to put this.

The natural way to phrase this would be "the subject of one triple and the object of two". (There should probably be a "both" thrown in there, too, to make the sentence structure even more predictable.)

This is an underrated (actually undervalued) affordance in any codebase.

Do they emit the same code?

* 1.5504

What are overlay SCMs supposed to actually achieve again?

This is a better, but more verbose way to state what I summarized as "evenly distributing yesterday's future".

This belies the inevitable would-be justifications for the technology choices behind these projects.

Why should the app even know let alone care about which version of the serialization format is in play?

I'm confused about why this namechecks a proprietary clone of Greasemonkey instead of just, you know, mentioning Greasemonkey.

This is a superfluous clarification.

(Maybe if it appeared nearer to the earlier discussion of situated software?)

"Malleable software" implies the opposite, right on its face.

Is "creator" the right word here? There's lots of software that falls outside of what is the subject of this paper that enables creators. Indeed, it has been a common refrain in criticisms of the FOSS movement that for the types of software that creatives need and/or simply desire to use the proprietary apps tend to have no equals.

See situated software.

At this point, when you're writing things like this, it's worth re-examining what in the hell you've got all this stuff underneath that you don't even understand and you're certainly not using correctly.

"It basic reviver with multiple features"? That makes no sense.

Great term of art for e.g. scraping.

Inheritance seems to be the odd item out in this list—inheritance is not essential for OO.

It's strange that there is a ready metaphor that isn't used—

The practice not of manufacturing parts (which is readily automated), but the labor that goes into designing the machines that enable the automation but for which there is no known way to automate the design work itself.

As I mentioned in another annotation, Cox's article in American Programmer was actually published with the title '"No Silver Bullet" Reconsidered'.

Hsu again cites only Mahoney for this, and the passage here is presented as one quote, but it's actually a quote within a quote: first Bemer and then Mahoney. The original Bemer quote ends with the second sentence ("I contend that the production costs are affected far more adversely by the absence of such an environment than by the absence of any tools in the environment…" which ends prematurely here but ends with a parenthetical "e.g. writing a program in PL/1 is using a tool"), and the remainder is Mahoney's commentary.

The Bemer source is:

R.W. Bemer, "Position Paper for Panel Discussion [on] the Economics of Program Production", Information Processing 68, North-Holland Publishing Company, 1969, vol. II, p. 1626.

This is such a strange thing to see in a paper from 2009.

The source cited as support is a book from 1995.

Strong Python vibes.

Specifically, it's:

Gabriel, Richard P. “LISP: Good News, Bad News, How to Win Big.” AI Expert 6, no. 6 (1991): 30–39.

Wikipedia says it was written in 1989. Gabriel says it was published in 1991. Presumably the latter refers narrowly to the actually publication when it was cut down to 9 pages for AI Expert in June 1991.

Ted is referring to the "The Rise of Worse Is Better" section that appears in the version published on Gabriel's site but that was simply called "Worse is better" in the version that AI Expert published.

The header image here doesn't load. But I made sure that it was archived. If and when Medium stops syndicating this article, you can find a copy of the image that was used here:

https://web.archive.org/web/20250614131832/https://miro.medium.com/v2/resize:fit:640/format:webp/1*WmQCEd5vo4ijVXrThaFSlA.png

See this note for the same essay, only qualified by Guo's UCSD subdomain instead of his personal one:

https://hypothes.is/a/22JaWMu5Eey2UvchosEz6Q

This is:

Gabriel, Richard P. “LISP: Good News, Bad News, How to Win Big.” AI Expert 6, no. 6 (1991): 30–39.

... and a copy (in HTML) can be found at https://www.dreamsongs.com/WIB.html

Note that the actual title as it appeared in the American Programmer Journal is «"No Silver Bullet" Reconsidered».

Irony (cf https://hypothes.is/a/BeEXTkk3EfCERutnCr7MPw)

No.

From Ted Nelson's "Computer Lib Pledge":

• The purpose of computers is human freedom.
• I am going to help make people free through computers.
• I will not help the computer priesthood confuse and bully the public.
• I will endeavor to explain patiently what computer systems really do.
• I will not give misleading answers to get people off my back, like "Because that's the way computers work" instead of "Because that's the way I designed it."
• I will stand firm against the forces of evil.
• I will speak up against computer systems that are oppressive, insulting, or unkind, and do the best I can to improve or replace them, if I cannot prevent them from being bought or created in the first place.
• I will fight injustice, complication, and any company that makes things difficult on purpose.
• I will do all I can to further human understanding, especially through the new visualizing tools of interactive computer graphics.
• I will do what I can to make systems easy to understand, interactive wherever possible, and fun for the user.

Guo's addendum (mentioned in an earlier annotation) addresses this: so many readers seem to have come away from Guo's piece with weird assumptions that he's not in the process of trying to teach his student any of this stuff and that he is instead just trying to set things up for them. That's not what he's doing, and that's not what upsets him.

What of the lack of perseverance of "the others"—to contribute their work in a way that can be integrated? Wouldn't it be a lot more productive if everyone aimed their perseverance at dealing with the problems that fall out of their own contributions—work that they are intimately familiar with—rather than trying to grapple with problems in N of the M components that they are building on and don't have the same level of familiarity—and for this effort to be duplicated by everyone else trying to build on top of it, too?

Indeed—which should really cast the norms around scientific computing in stark light as being clearly the wrong way to go about doing things. (Which itself isn't to say that there's anything special about scientific computing here—there are plenty of programmers (working on open source or otherwise) that get things just as wrong. Most of them, even. It's virtually everyone.)

This doesn't nail it either. There are lots of people who are software developers who have (or at least have been told or have convinced themselves) that they have been trained in the best possible procedures. Adar obliquely acknowledges "open-source developers", but in a strange way that seemingly implies software endeavors that aren't FOSS are better "incentivized to keep documentation up to date or the software running".

My initial reaction was to the "This is inevitable" part that follows, before backing up and focusing on this sentence, to which my response was originally going to be, "Is it? No, it isn't." That is, until I skimmed Guo's addendum/update (which I'd never seen before) in one of the two copies I kept of the piece which this piece by Adar is a response to. And indeed, it seemed, based on a surface-level reading of that addendum that Guo largely agreed. But then a close reread of that proves that there isn't any explicit or implicit agreement on Guo's part about the diagnosis offered here. And I don't think the diagnosis is correct.

And now to focus on the next part:

This is inevitable. It is inevitable because

I don't think it is. (If nothing else, it hasn't been proven.) Even from the perspective of the author, this falls squarely in the "accidental complexity" versus "essential complexity" bucket.

(And to pick up a thread of mine from earlier this year, I wonder if we have perhaps made a mistake in focusing too much on the notional of incidental (or "accidental") versus inherent (or "essential") complexity, and whether or not we should be trying to address the fact of incidental versus intentional complexity—which surely exists. And that isn't to say that's the culprit everywhere, but to reiterate: it surely exists and surely accounts for some of what's going on.)

I don't see how the examples offered are helpful in conveying the distinction. The instruction to "type git clone" seems procedural.

Based only on my inference of what is actually intended by "factual" versus "procedural" (without first checking the link here), I'd guess that, "The command for copying a Git repository's contents to the local machine is git clone" would be a real example of a factual (versus a procedural) lesson style.

Too meta, too messy, too personal, and too much detail.

(NB: this actually comes from export of my annotation of Eytan Adar's piece "On the Value of Command-Line “Bullshittery”" originally published on Medium. See https://hypothes.is/a/zmhLwkkqEfCyyo_A6dOGrw for the original annotation. I used the aforementioned export to annotate the annotation—i.e., to add a true, first-class (though perhaps second-rate) annotation, rather than a reply.)

A major purpose of this style is Malleable Software, or software that is more supportive of change, reusability, and enhancement.

Is this the first occurrence of this term?

samsquire is https://www.halfbakery.com/user/chronological.

Does this mean arguments against verbose "boilerplate" languages are going to be given less credence?

So why not just stop doing that? None of the churn was necessary.

Pfft. Lame.

The earlier breakdown involved being dependent on the bus for transportation into the city and relying on the library for entertainment. Is the bus subsidized? Is the library?

Before I got to the end of this sentence I was expecting to see something like $70 per person.

$300 per month on food is "laughably low"? You can eat cheaper in the city!

Quintessential boomer shit.

Interesting problem decomposition with shades of Engelbart re https://dougengelbart.org/pubs/papers/scanned-original/1960-augment-133181-Special-Considerations-Individual-re-Information.pdf.

Hey, traveler. You're looking for https://dl.acm.org/doi/pdf/10.1145/948093.948095.

For example, the syntactic analysis stage builds a conventional expression tree, but this tree is expressed as objects—instances of various classes relevant to compilation: Class, Method, Message, Selector, Argument, etc. […] The code for these operations is encapsulated inside each object, and is not spread throughout the system so changes are easily made. And all these specialized classes rely heavily on reusable code inherited from more primitive classes like Object, HashTable, Symbol, Token, and LinkedList.

This is an interesting claim, given that one of the common criticisms of the classic, inheritance-heavy style of classic OOP is precisely that it leads to code that is indeed "spread throughout". Adele Goldberg commenting on the legacy of Smalltalk made a well-known quip, "In Smalltalk, everything happens somewhere else."

It's notable that although there many common word sequences between this paper and the later, similarly titled one that appeared in IEEE Software (1984), this passage doesn't appear to be present (based on a quick skim—I could be missing something), and the closest corresponding statements are significantly reworded.

This is:

Cox, Brad J. “The Message/Object Programming Model.” In Proceedings of Softfair: A Conference on Software Development Tools, Techniques, and Alternatives, 51–60. Arlington, VA: IEEE Computer Society Press, 1983.

In Hints and Principles for Computer System Design, 2020, Lampson describes his original 1983 paper (https://dl.acm.org/doi/10.1145/800217.806614) as being "[r]eprinted with some changes in IEEE Software".

This is:

Lampson, B.W. “Hints for Computer System Design.” IEEE Software 1, no. 1 (January 1984): 11–28. https://doi.org/10.1109/MS.1984.233391.

This presupposes that you'd settle on opaque sequential blobs of said instructions as the preferred archive format—a consequence of the cultural milieu of the writer, and not the product of careful thinking and logical decisionmaking.

The modern incarnation of the fallacy of bulk-is-better is judging the quality of a project (esp. a component) by being overly concerned with whether it is more or less "active" than some other project.

The question posed here is an obvious response for when you encounter instances of the bulk-is-better mindset (although it's not as easy to automate as Cox suggests here).

I've often mused about the thought of pulling a Reddit* and automating some level of churn within a codebase for a project that's hosted on e.g. GitHub for the sole purpose of making sure that it appears "active".

* A story about the early days of Reddit has become well-known after the creators volunteered some information about the early days when they made use of a bunch of "fake" accounts to submit links that the creators had aggregated/curated for the purpose of seeding the site.

Are they even well-formed hypotheses? That is, are they falsifiable?

It's strange that this basic truth is something that has to be taught/explained. It indicates a failure in analytical thinking, esp. regarding those parts of the question which the quoted passage is supposed to be a response to.

In other words: actually practicing version control.

I'm baffled how much mindshare Matrix was evidently able to gain (and maintain) given how crummy it is as a product and frustrating to use.

This is:

Cox, Brad J. “Message/Object Programming: An Evolutionary Change in Programming Technology.” IEEE Software 1, no. 1 (January 1984): 50–61. https://doi.org/10.1109/MS.1984.233398.

The actual name of the paper referenced here appears to be "Prospects for an Engineering Discipline of Software". "Towards an Engineering Discipline of Software" is the last chapter/section.

Consider a derivative: Slim Source Code—

… in the context of the problem described in "The Cost of Selective Recompilation and Environment Processing" (Adams, Rolf, Walter Tichy, and Annette Weinert. ACM Transactions on Software Engineering and Methodology 3, no. 1 (January 2, 1994): 3–28. https://doi.org/10.1145/174634.174637.)

This is:

Franz, Michael, and Thomas Kistler. “Slim Binaries.” Communications of the ACM 40, no. 12 (December 1, 1997): 87–94. https://doi.org/10.1145/265563.265576.

Infuriatingly, obnoxiously dismissive.

Claims like these need supporting evidence. Are they really "weird limitations"? Or are they actually reasonable limitations—on developers' unending attempt to exercise what they feel as their manifest destiny to control the user's device and experience?

So? To reiterate:

Fuck "developers".

This is a terrible example.

That is 100% a failing of the folks making those decisions at Wikipedia, not HTML.

This flavor of fatigue (cf "JavaScript fatigue") is neither particular to nor an intrinsic consequence of static site generators. It's orthogonal and a product of the milieu.

It can also create pressure to hold your tongue on things that you might otherwise be comfortable expressing were it not for the fact that there was available a meticulously indexed, reverse chronological stream of every sequence of words that you've authored and made ambiently available to the world.

Mmm… half of what's described here is an episode of Black Mirror…

The screenshot here (p. 33) reads:

Introduction

The intent of this paper is to describe a number of studies that we have conducted on the use of a personal computing system, one of which was located in a public junior high school in Palo Alto, California. In general, the purpose of these studies has been to test out our ideas on the design of a computer-based environment for storing, viewing, and changing information in the form of text, pictures, and sound. In particular, we have been looking at the basic information-related methods that should be immediately available to the user of such a system, and at the form of the user interface for accessing these methods. There will undoubtedly be users of a personal computer who will want to do something that can be, but not already done; so we have also been studying methods that allow the user to build his own tools, that is, to write computer programs.

We have adopted the viewpoint that each user is a learner and have approached our user studies with an emphasis on providing introductory materials for users at different levels of expertise. Our initial focus has been on educational applications in which young children are taught how to program and to use personalizable tools for developing ideas in art and music, as well as in science and mathematics.

It is titled "Smalltalk in the Classroom" and attributed to "Adele Goldberg and Alan Kay, Xerox Palo Alto Research Center, Learning Research Group". Searching around indicates that this title was re-used in SSL-77-2, but neither introduction in that report matches the text shown here.

Searching around for distinct phrases doesn't turn anything up. Is this a lost paper? Is there some Smalltalk image around from which this text can be extracted?

Is that actually true? Surely there are examples where people play the game that they're less suited for—where the decision is driven by desire?

I don't think that's right—

My life experiences during the (now bygone) Shirky era and the loose school associated with it really inculcated (in me, at least) the value of small, cumulative improvements contributed by folks on a wide scale. See something wrong? Fix it. Can't fix it (like, say, because you don't have the appropriate authorization)? File a bug so the people who can fix it know that it should be fixed. This matches exactly the description of seeing the "little flaws in everything you see in the world, and focus[ing] on those".

Looking at those flaws and thinking "this thing isn't as good as it could be" is a necessary first step for optimism. That belief and the belief in the possibility of getting it fixed is the optimist approach.

When I think of miserable people (and the ones who make me miserable), it's the ones who take the attitude of resignation that everything is shit and you shouldn't bother trying to change it because of how futile it is.

The at-oddsness of the two things mentioned here—spewing bullshit and private beliefs that someone could correct you about—is hard to skip over.

This is my experience working with other people, generally. Another way to put it besides people not "priortizing the truth" is that they just don't care—about many things, the truth being one of them.

I don't think this is a good definition of liar. The bullshitter described here would be a liar if what they're saying is lie.

Check out https://tinlizzie.org/VPRIPapers/m2004001_power.pdf

Are we sure?

This is:

Bobrow, Daniel G, and Bertram Raphael. “New Programming Languages for AI Research.” Palo Alto, California, August 20, 1973.

An early mention of Smalltalk.

That's interesting. This paper is Copyright 1977 (dated June of that year) and is using the term "message-oriented" rather than "object-oriented".

Rochus maintains that Liskov and Jones are the originators of the term "object-oriented [programming] language".

Here's Goldberg in an early paper (that nonetheless postdates the 1976 paper by Liskov and Jones) writing at length about objects but calling Smalltalk "message-oriented" (in line with what Kay later said OO was really about).

We're at the point in humanity's development of computing infrastructure where the source code for program texts (e.g. a module definition) should be rich text and not just ASCII/UTF-8.

Forget that I said "rich text" for a moment and pretend that I was just narrowly talking about the inclusion of, say, graphical diagrams in source code comments.

Could we do this today? Answer: yes.

"Sure, you could define a format, but what should it look like? You're going to have to deal with lots of competing proposals for how to actually encode those documents, right?" Answer: no, not really. We have a ubiquitous, widely supported format that is capable of encoding this and more: HTML.

Now consider what else we could do with that power. Consider a TypeScript alternative that works not by inserting inline type annotations into the program text, but instead by encoding the type of a given identifier via the HTML class attribute.

Now consider program parametrization where a module includes multiple options for the way that you use it, and you configure it as the programmer by opening up the module definition in your program editor, gesturing at the thing it is that you want to concretely specify, selecting one of those options, and have the program text for the module react accordingly—without erasing or severing the mechanism for configuration, so if another programmer wants to change the module parameters to satisfy some future need—or lift that module from your source tree and use it in another one for a completely different program—then they can reconfigure it with the same mechanism that you used.

I feel no strong urge to disagree, but on one matter I do want to raise a question: Is "accidental" even the right term? (To contrast against "essential complexity", that is.)

A substantial portion of the non-essential complexity in modern software development (granted: something that Brooks definitely wasn't and couldn't have been thinking about when he first came up with his turn of phrase in the 1980s) doesn't seem to be "accidental". It very much seems to be intentional.

So should we therefore* highlight the contrast between "incidental" vs "intentional" complexity?

* i.e. would it better serve us if we did?

In hindsight, this would be a better outcome than what we ended up with instead: very large software systems that, relative to their size—esp. when contrasted with the size of their (often more capable and featureful) forebears—accomplish very little, but demand the resources of extremely powerful computers.

Considering this post is about Swift, describes Lattner's departure, etc., it would have been opportune to mention Graydon Hoare's departure re Mozilla/Rust and his subsequent work at Apple on Swift.

"Pre-RFC" doesn't sound like there's "not going to be an RFC" for it. It rather sounds like the opposite.

I haven't been using LLMs much—my ChatGPT history is scant and filled with the evidence of months going by between the experiments I perform—but I recently had an excellent experience with ChatGPT helping to work out a response that I was incredibly pleased with.

It went like this: one commenter, let's label them Person A posted some opinion, and then I, Person B, followed up with a concurrence. Person C then appeared and either totally misunderstood the entire premise and logical throughline in a way that left me at a loss for how to respond, or was intentionally subverting the fundamental, basic (though not unwritten) rules of conversation. This sort of thing happens every so often, and it breaks my brain, so I sought help from ChatGPT.

First I prompted ChatGPT to tell me what was wrong with Person C's comment. Without my saying so, it discerned exactly what the issue was, and described it correctly: "[…] the issue lies in missing the point of the second commenter's critique […]". I was impressed but still felt like pushing for more detail; the specific issue I was looking for ChatGPT to help explain was how Person C was breaking the conversation (and my brain) by violating Grice's maxims.

It didn't end up getting there on its own within the first few volleys, even with me pressing for more, so I eventually just outright said that "The third comment violates Grice's maxims". ChatGPT responded with the level of sycophantism (and emoji-punctuated bulleted statements) a little too high, but also went on to prove itself capable of being a useful tool in assisting with crafting a response about the matter at hand that I would not have been able to produce on my own and that came across as a lot more substantive than the prompts alone.

Then don't use the word "upload".

This URL is reference from https://ignore.pl/2025/04/a_pair_of_examples_of_simple_interfaces.html

Traveller:

You are looking for https://ignore.pl/2022/01/playing_around_with_simple_interfaces.html.

This is a perfect use for a mostly-single-file browser-based literate program.

Or—get this—it was because despite the fact that he "hasn't been for several years", he used to "ski a lot", and it was the start of ski season.

You don't have to assume any sophisticated conspiracy of ad companies listening in through your device's microphone or location-awareness and user correlation. This is an outcome that could be effected by even the dumbest targeted advertising endeavor with shoddy not-even-up-to-date user data. (Indeed, those would be more likely to produce this outcome.)

Fucking stupid.

It is a tragicomic fact that our proper upbringing has become an ally of the secret police.

This is:

Engelbart, Douglas C. “Special Considerations of the Individual as User, Generator, and Retriever of Information.” American Documentation 12, no. 2 (1961): 121–25. https://dougengelbart.org/pubs/papers/scanned-original/1960-augment-133181-Special-Considerations-Individual-re-Information.pdf

If only there were some sort of highly accessible information system that was designed to make resources available from anywhere in the world without any higher requirement besides relatively simple and ubiquitous client software. Developers might then not be compelled to churn out bespoke programs that effectively lock up the data (and prevent it from being referenced, viewed, and kept within arm's reach of the people that are its intended consumers).

This feels like a sharp left turn, given the way the post started out.

Overspecialization is the root of the problem.

Companies want generalists. This is actually reasonable and good. What's bad is that companies also believe that they need specialists (for things that don't actually require specialization).

I keep seeing people make this move recently—this (implicit, in this case) claim that choosing React or not is a matter of what you could call costliness, and that React is the better option under those circumstances—that it's less costly than, say, vanilla JS.

No one ever has ever substantiated it, though. That's one thing.

The other thing is that, intuitively, I actually know* that the opposite is true—that React and the whole ecosystem around it is more costly. And indeed, perversely the entire post in which the quoted passage is embedded is (seemingly unknowingly, i.e. unselfawarely) making the case against the position of React-as-the-low-cost-option.

* or "know", if the naked assertion raises your hackles otherwise, esp re a comment that immediately follows a complaint about others' lack of evidence

The terms are "copyright" and "copyrighted".

Your Honor, they're fucking queer!

Geez. How clueless can a person be? (Or is feigned cluelessness also a deliberate part of the strategy for increasing engagement?)

Wait, the account URI is a resource? Not the account itself (identified by URI)?

Nope.

This is one of those instances where you can do a search-and-replace on REST to substitute "HTTP" instead.

Given the constitutional underpinnings for copyright law as it exists in the US, this commenter's sense of the laws' spiritual intent isn't just off, it's actually in opposition to what the US is trying to effect.

The very small start-up effort is designed to allow small contributions

It's "parcel". Not "parse".

This is how RSS/Atom should be implemented in every feed reader, but, to my knowledge, never is. That is—

If URL to the feed for alice.example.net can be found at <https://alice.example.net/feed.xml> and it is available via feed autodiscovery, it should not require the user to navigate to alice.example.net obtain the URL to the feed, and then paste that into the feed reader. Rather, when I'm looking at my feed reader, I should be able to merely indicate that I want the feed for alice.example.net. The feed reader's job, then, should be to do BOTH of the following:

• submit a request for / to alice.example.net and use autodiscovery within the reader implementation to obtain the URL for the feed (say, /feed.xml), AND
• store that fact in the user's profile data (that they want "the feed for alice.example.net"—NOT merely the bare URL <https://alice.example.net/feed.xml>

(The URL obtained via autodiscovery can be cached.)

If ever the feed location changes, it should not require the user to then backtrack and go through the process again to obtain the feed URL. With the site alice.example.net itself being kept in the user data store, the feed reader can automate this process. A website could thereby update the URL for its feed whenever it wants—as often as every day, for example, or even multiple times a day—without it being a source of problems for the user.

To make it even better, the Atom and RSS specs can be extended so that if the user actually pastes in the feed URL <https://alice.example.net/feed.xml>, then that's fine—the specs should permit metadata to advertise that it is the alice.example.net feed (which can be verified by any reader), and the client can store that fact and need not bother the user about the overly-specific URL.

Neat. It's basically a browser with deep integration for Fastmail.

(Not that Fastmail is neat—it's evidently got a bunch of jerks in charge—but I wholeheartedly approve of user agents operating in their users' best interests, and this qualifies. The fact that this is a site-specific browser made with no involvement of the site operator? A++++)

I'm kind of bummed that HTML exports don't contain sufficient information to act as a substitute for the JSON.

That's neat, too.

Neat.

Should you, though?

(The author approaches things from a different direction, but it's worth considering this one, too.)

Huh? I think I know what this is supposed to mean, but the problem with it is that it's a different kind of nonsense.

non-sequitur?

This is always how I've valued songs and their lyrics.

I'm aware of it.

please, stop

Forget "value". That's a lateral shift in focus, and therefore a subtle change in subject. This is about costs. So rework the thought:

If a "user"* is the cause of costs, then we should consider getting the user to pay for it—especially when the costs are big enough.

(The answer to this is probably resource-proportionate billing for the accumulated expenses.)

* or "consumer"

And of course this fares poorly if the input ("your bundler's code") is low-quality.

It's important to make an apples-to-apples comparison, so you don't end up with the wrong takeaway, like, "Stuff written in JS is always going to be inherently as bad as e.g. Webpack," which is more or less the idea that this paragraph wants you to get behind.

It shouldn't be surprising that if you reject the way of a bad example, then you avoid the problems that would have naturally followed if you'd have gone ahead and done things the bad way.

Write JS that has the look of Java and broad shape of Objective-C, and feels as boring as Go (i.e. JS as it was intended; I'm never not surprised by NPM programmers' preference to write their programs as if willingly engaging in a continual wrestling match against a language they clearly hate...)

This is really a failure of the NodeJS &co and is not something that's inherent to the essence of JS or any other programming language.

It makes sense for Web browsers to throw away everything and re-JIT every time since the inputs have just streamed in over the network microseconds ago. It doesn't make sense for a runtime that exclusively runs programs that are installed locally and read from disk instead of over the network; the runtime could do one of (or both): - accept AOT-compiled inputs - cache the results of the JITting

"with a text editor, with a web browser, standard stuff"

I just discovered this accidentally, and it's really annoying considering Shift+Left and Shift+Right are existing keyboard shortcuts on almost every platform to change the size of the selection (e.g. with selected text).

I don't see how 2025/01/10/foo-bar.html is any more or less "quirky" than 2025-01-10-foo-bar.html.

What gives you the idea that class is for "contain[ing] styling information"? (This is rhetorical; I know the answer. This remark is a giveaway about the mental model of what HTML classes—NB: not "CSS classes"—are "for".)

Just as a point of fact: many distributions' package repositories don't have a Git package that "ships with built-in tools for collaborating over email", which can be seen in the suggested steps given for the systems in this list—the distros do generally provide packages that back the git send-email command, but it's a separate package.

Intuitively, it makes sense that brute force would win, which should not be a surprising result. (I suppose the surprise could be simply that there was enough computation available.)

Even though my comments elsewhere mention NPM, etc., I myself don't think they quite fit to what McIlroy (and Cox) were talking about. If I recall correctly, both mention configuring components in ways that are not generally seen with modern packages. McIlroy in particular talks about parameterization that suggests to me compile-time (or pre-compile-time) configuration, whereas the junk on NPM traditionally blobs all the behavior together and selects behavior at program runtime.

Tangent: I've likened system designs for Web tech that requires deep control and/or configuration of the server (versus a design that lets someone just dump content onto a static site) to the leap in productivity/malleability of doing something in hardware versus doing it in software.

Compare: Mastodon-compatible, ActivityPub-powered fediverse nodes that are required to implement WebFinger versus RSS-/Atom-based blog feeds (or podcasts—both of which you could in theory you could author by hand if you wanted to).

See also: the trend of an overabundance of triple equals operators (===) in NPM programmers' code.

vague, wishy washy

s/more efficient programming language/programming environments with more efficient implementations/

The author states this like it's prima facie absurd. But, I dunno, why not? It's neither inconceivable nor absurd (no matter the way the author goes about it in this particular post).

And so it goes with programs written for environments with dynamic and loose typing. (In fact, if you swap out the phrase "a type definition" with "this type", then you get what almost amounts to a manifesto for dynamic typing.)

People love to say stuff like this, but then you get things like Jonathan Blow's multi-hour live stream with Casey Muratori where they end up getting bogged down working it all out (while talking about how easy it is and how dumb it is that we even have a term for "recursive descent"). Whereas if they'd just gone with recursive descent, they could have implemented it and re-implemented it four times over by then…

Ugh. "Racked up"?

Hey, traveler. You want

<https://datatracker.ietf.org/doc/draft-kunze-ark/>

Unpopular opinion: all URLs should be "not intended to break". (Or, at the very least, that should be the assumed default unless otherwise specified.)

I like this approach to examination. It bears resemblance to the way that I admonish the public about content "changing". There's no such thing as resources "changing". There are only servers re-using identifiers and lying about their resources' identities.

I like the way TBL put it in <https://www.w3.org/Provider/Style/URI>:

"Most URN schemes I have seen look something like an authority ID followed by either a date and a string you choose, or just a string you choose. This looks very like an HTTP URI. In other words, if you think your organization will be capable of creating URNs which will last, then prove it by doing it now and using them for your HTTP URIs."

This could benefit from further elaboration.

Good description of the widely perceived value proposition of the (conventional, http(s):-based) Web—but as TBL explains, HTTP and HTML are incidental to true intent and purpose of the Web.

Fittingly (or perversely) enough, this URL is referenced by Kunze in the ARK paper. It ends up trying to resolve to an archive.org-hosted URL, after the handoff from OCLC:

<https://purl.archive.org/docs/inet96.html>

Note that the preceding remark that the spec "does not state explicitly be at the physical end of the file" applies as much (and more) to this part. Self-extracting archives have explicit support in PKZIP and other implementations.

OR:

There is a sufficiently high mechanical barrier (in the sense of an imposition from the software itself).

"Chesterton's fence or Rhesus ladder?" is always a good question to have in mind.

This seems like a weird way to put it. By spending even a microsecond on trying to implement automation, there are negative returns by default. It is only with sufficiently effective automation that the lines intersect and you end up on the "positive returns" side.

This is a weird way to put it, since the very first note given in this section is that all fields unless otherwise noted are unsigned...