It doesn't. No one should be relying on archive.is to fill this role today. It's like never putting a passcode on your phone and just treating it accordingly—as an insecure/untrustworthy device—or proactively working to revoke a leaked API key as soon as you discover that it has been leaked and just assuming that a malicious actor has already come across it and is planning to put it to use even if they haven't already done anything.

Pre-emptive note: it seems logical that the very next paragraph references Paul Graham directly; my very next move was going to be to connect the writer's self-reported experiences here with Graham on writing, had it not been the case that that job was already done.

As I've said before: I'm not in the same boat with Graham on the writing-is-thinking stance. The difficulty with seeing my own thoughts fixed in words after an initial pass is not in their inadequacy or their being a source of illusory and fleeting comfort with said illusion now made stark for everyone to see, but a mixture of (a) a lack of "punch", and/or (b) the places where a dishonest broker could exploit the yet-to-be shored up wording to suggest/assert the presence of some weakness in thought regarding the thing being argued for, where such purported weakness would be the real illusion.

The lack of satisfaction I feel when trying to capture my thoughts in English (my first language) isn't too far off from the lack of satisfaction at being able to comprehensively express a simple declarative in another language only because of the fact that don't know, say, the right word for the noun in that language. It doesn't lead me to agonize about how well-supported my observations about a backhoe are just because I've never been introduced to the word for backhoe in that language.

Following the demise of botsin.space (cf https://muffinlabs.com/posts/2024/10/29/10-29-rip-botsin-space/), the author evidently has the bot now posting to https://mas.to/@SecretlyPublicDomain instead.

Traveller:

You are looking for https://mas.to/@SecretlyPublicDomain.

I find it strange that this number differs from the one given on the previous page ("Totals...[…] 21,533").

Point 4.c. does indicate that "102 claims were rejected", but this is not the same the difference observed (which is 92), and it's stated that the 102 rejected claims come from "a survey [i.e. sample] of some 10,000 renewal applications".

This is a curious claim that I cannot substantiate. After looking around, I see the same claim in Wikipedia's article for Copyright renewal in the United States, but the cited source (Fishman, Stephen; 2010. The Public Domain: How to Find & Use Copyright-Free Writings, Music, Art & More) doesn't appear to provide a robust citation. (On page 287 in Chapter 15, Fishman writes, "The Copyright Office estimates that only about 15% of pre-1964 published works were ever renewed", unaccompanied by a footnote.) One also notices that 1961 and 1964 are not the same year.

I stumble across a similar claim ("a 1961 report from the U.S. Copyright Office estimates that 85% of the books never had the copyrights renewed") on lcgsco.org, which disappointingly turns out to be the website for "Larimer County Genealogical Society", with no link to the report in question.

The Copyright Office does make available its historical archive of annual reports at https://www.copyright.gov/history/annual_reports.html. Could its annual report be the one referred to? Searching for the string "renewal" in the 1961 annual report turns up two noteworthy occurrences (out of a reported nine):

1. on page 2, a claim related to renewals mentioning a "15 percent" figure

2. on page 16, a description of "Studies 29–31 [… including …] 31. Renewal of Copyright"

The full sentence on page 2 where the "15 percent" figure appears is actually that "The year's increase in registrations was nearly 3 percent, this was counting a 15 percent decrease in renewal registrations, the result of the corresponding decrease in original regisrations 28 years previously." This is, troublingly, not the same thing as fewer than 15% of copyright registrations until 1961 being renewed. (It is not even the same as only 15% of registrations up for renewal in 1961 being renewed.) It is a 15% decrease in renewals relative to the prior year, i.e., number of renewals in 1961 compared to the number of renewals in 1960. If this is the report that the is meant to be the source for those claims of 85% non-renewal, it then it fails verification.

I have also come across a reference for renewal figures in a 2008 article in D-Lib Magazine (Peter B. Hirtle, "Copyright Renewal, Copyright Restoration, and the Difficulty of Determining Copyright Status"). Footnote 4 there cites the same Study 31 (attributed to a Barbara Ringer). Interestingly, it is not cited as a way to substantiate the 15% claim, but instead that "only 7% of registered copyrighted books" were renewed. It's not clear from context whether that claim is meant to be about the full range of potential renewals up to 1961, or merely the subset of works up for renewal in 1961.

At the time of this comment, I have not yet looked into Study 31 itself. I expect it to contain answers.

I've come across lots of claims online (e.g. https://lcgsco.org/the-majority-of-books-published-before-1964-are-free-of-copyrights/ and the current revision of the Wikipedia article on copyright renewal in the United States) that "A US Copyright Office study in 1961 found that fewer than 15% of registered copyrights had been renewed". I haven't been able to substantiate this claim, however.

Could this passage be the source? It clearly doesn't line up with the claim.

It's nuts that this has to be said.

/u/Choperollo describes something for which we have no name and would not be accurately described as a dogwhistle but still shares some similarities and is now common/prevalent enough that we would perhaps benefit from being able to refer to it by name to discuss it.

This is belied by earlier admission about how he's putting the library to work, at his work (and which even uses the word "professional"!).

I have not come across that. I have only come across an allergy to GPLv3 in particular. And all those companies are seemingly happy to continue shipping GPLv2(+), as the next sentence indicates re Apple.

I dunno. "Is this licensed as GPLv2-or-later (or compatible)?" still works (and is really the same question that was being asked all along)—nothing really has changed (except for the proliferation of projects that are a GPL for which the relevant answer is "no"—but, still, the question didn't change).

This page is a great example of why I don't use GitLab.

WTF.

"settlement"?

Why shouldn't the resolution be available for reading at archive.org?

From an optimistic perspective:

~10 articles per month sounds like the perfect publishing pace for a blog, and more academics should be blogging.

What if the submissions to the aforementioned low-quality journals were just a bunch of 6 pagers that were actually originally intended for syndication to the author's website and also just happened to also get wider distribution in those suck journals?

And a separate question: might it be conceivable that this could turn out to be an effective way to actually bootstrap high-quality research output and a healthy ecosystem of professional/academic blogs (in the vein of the parable of the pottery class https://austinkleon.com/2020/12/10/quantity-leads-to-quality-the-origin-of-a-parable/)?

It would be nice to be able to have good subject lines. I'm thinking that if you register your form, then you should also be able to register a template string that can be used to build a good subject line (like "Riku key request for riku@x.colbyrussell.com"—built from Riku key request for ${email}).

What many analyses fail to highlight is that NPM has been sending a lot of really pushy emails about two-factor authentication settings over the last couple years.

Perversely, this cargo culted best practice led to worse security.

Perhaps the most irresponsible thing of the last week is that among possible mitigations, to give priority to exercising even more features of the poorly conceived package.json-based system, especially where it is redundant (but inferior) to a mitigation scheme that consists of checking the given source code revision into the revision control system.

This omission is especially absurd in relation to stuff like the has-ansi package, which hasn't had a substantial change in years.

The author also keeps saying "operating system" like this as a euphemism for "desktop environment" or "graphical shell", which is kind of annoying.

The absolute last thing I want here is to delegate decisions about interaction style and the implementation of application-level affordances to the person supplying the content.

Is there a word/encyclopedia entry for this? We need it.

It's strange how much appeal "the lexer hack" has for being such a bad solution to the problem.

The most reasonable thing is to just not care about whether your lexer can distinguish between whether an identifier refers to a type or to another sort of identifier. Just report that it's an identifier. In practice, this doesn't very much change how you have to implement the parser, and the symbol table can remain local to the higher-level parser machinery where it was always going to be anyway.

The lexer hack sucks.

This isn't subtle. It's intuitive and obvious, being presented as if it's non-obvious. I kept waiting for the punchline.

I guess you can get here if your main mode of thinking is dealing in opaque "best practices" like "use references because it makes your code faster".

This struck me as an obviously good idea the first time I came across something similar where Wikileaks published their recording of an interview of Julian Assange by some large news organization (who published their own copy that they owned the rights to).

Ideally, one would (above all) maintain compatibility with at least ISO/IEC 21320-1:2015 and, as a baseline concern, follow the lead of the design of PNG and specify a means by which to identify definitively (a) whether a data block at a given offset is a ZIP-level "chunk" versus random noise, and if so (b) the extent—i.e. size—of said chunk, so that implementations know how to confidently determine the chunk boundaries to skip over them, even if they don't have intrinsic knowledge the offsets and bitwidths of the fields in that struct.

This really seems like the best strategy—to ensure that Parser2 sees content the same way that Parser1 sees it, you can effectively give Parser2 Parser1's powers by having Parser1 "talk" to Parser2 by way of a specially prepared input. (It just happens to be the case that that input also looks like a ZIP archive.)

This does require some validation of the suitability for Parser1 and Parser2 to work together, but it's not any more difficult than the previous task at hand whereby you expect/require Parser1 and Parser2 to behave exactly the same for all inputs. The task is made slightly easier. And to this end, a test suite (derived from the work from this paper) could be distributed for the purpose of benchmarking implementations for compatibility matches.

This could be facilitated by the appropriate libraries/packages all being patched to support a "normalize" (i.e. "repack") operation (and for this to be the norm among all implementations) explicitly for this purpose.

This is simply not true. The de facto standard is "the behavior of PKZIP, circa 30 years ago". Conveniently, PKZIP happens to be shareware (at least the versions of interest here). One confounding factor, as documented by Jason Summers's blog, is the difficulty of getting your hands on bonafide PKZIP originals. https://entropymine.wordpress.com/2019/07/27/will-the-real-pkz110-exe-please-stand-up/

Dear wanderer:

You are looking for https://support.pkware.com/pkzip/application-note-archives.

The purported ambiguity in the implementor's notes is overstated. With exactly one exception, all of the concrete criticisms I've ever come across (including, unfortunately, some of the specific ones woodruffw echoed in the Astral blog post earlier this month) come down to implementors just flat-out doing the wrong thing (e.g. disregarding the central directory entirely), or, when presented with the choice of:

1. doing the obviously correct thing, versus

2. taking a really, really, really obtuse position that a particularly strained reading justifies an implementor's decision to do certain things (like trying to infer the position of the central directory instead of just using the field that is explicitly labeled for that purpose—bonus points if accompanied by complaints that the field is "redundant")

... they go for the latter, out of a seeming inability to say, "Whoops, how silly of me," and just fixing their damn (mental model and corresponding) implementation.

Not really. The correct behavior is, well, correct. There are just a lot of people who either succumb to taking (frankly bizarre) shortcuts or stubbornly insist on reading the spec the wrong way.

This surely means "multiple End of Central Directory records". To reject archives with multiple headers would mean accepting only archives that contain a single file.

It's here: https://news.ycombinator.com/item?id=44955771

(NB: there is no more detail in the referenced comment than what is stated here.)

If only full-stack developers actually cared about the user who is sitting in front of a Web browser (i.e. end users) as much as they cared about the "users" of their APIs who are sitting in front of a text editor (i.e., programmers).

What until you're motivated to articulate what you thought the value proposition of NPM-style build-time package fetchers actually ever was and then eventually settle into the realization of how little disk space has been saved in the whole scheme, how much bandwidth has been wasted on thousands of redundant package fetches, and the immeasurable amount of human toil and the resulting hit to the world's creative output from overlay version control systems instead of just leaving the version control to the DVCS that you're using.

Of course, this is another example where people say "JavaScript" and mean "NPM".

The last time I looked, around 8 years ago, of the multiple settings that Git offers wrt line endings, there was no combination of any of any of them that would do the most reasonable thing, and all of the advice and documentation around use of these settings were wrong. The best course of action was to use the defaults and just deal with it.

It's strange that EXIF even includes such properties—what's wrong with the image's existing dimension fields?

This section doesn't appear in all revisions of the APPNOTE. Notably, it doesn't appear in revision 1.0, nor does it appear in 6.2.0, which is the basis for the ISO standardized ZIP spec.

Huh? For the reasons above, I would be very, very surprised if this were true and Woodruff isn't just confused. This would make it incompatible with the vast majority (virtually all) ZIP-producing software. (Is there any implementation which actually works this way?)

It would take a very strained reading to end up with a misunderstanding aligning with the latter behavior (and it's very unfortunate that the "relative"/"absolute" terminology was chosen here, as where "relative" appears in the spec, it is used to mean almost the exact opposite of how it's used here—the relativity of the "relative offsets" mentioned in the spec are explicitly described as being relative to the start of the "disk" (which in almost all cases constitutes the only "disk" comprising the archive—i.e. it's the offset from the start of the file).

Here, or in general?

I do think about this a lot. This is a nice, succinct way to put it. (Critique, though: "classism" is not the best way to put it. For better or worse, "privilege" is probably one of the best words we have for this. Separately: Since "privilege" became a staple of common rhetoric, I've mused a lot about trying to convince people to minimize the focus on "privilege" (to avoid the familiar kneejerk reactions from those hearing it who have associated it with overuse), with the intent to be to sway people instead by speaking about privilege without actually using the word "privilege" and speaking exclusively in terms of affordances*.)

See: https://hypothes.is/a/TCB5zClKEeyrIOu9mp-5TA and tag:"privilege vs affordance". (NB: Hypothes.is doesn't linkify the tag in the preceding annotation correctly.)

I've tried using a hiking metaphor to describe a similar phenomenon (specifically, and perversely, as a preface when trying to explain second panel syndrome.

It's not. It assumes that if you have your own domain, you're also able to configure/patch the server to be an active participant in the Webfinger protocol—you can't do anything to add Webfinger support to your static site, for example. This is one reason that makes Webfinger a bad protocol.

I explained in a post to Mastodon somewhere that the issue lies in trying to sell, to users, the infrastructure.

For Solid to succeed, it needs to get into the hands of people, and to get into the hands of people, it needs an app that incidentally uses Solid—you're never going to convince the majority of end users to adopt Solid on its merits. They need to experience it—something that TBL should be acutely aware of, since this is what drop adoption of the WWW.

Speaking (or typing, as in the case of transcription) has a substantially negative effect on my ability to process the same amount of information as silent reading.

Later, the authors of this paper state that subjects who were "uncomfortable" with reading out loud had the option to read silently.

I don't doubt the conclusions of the paper, but I suspect that reading aloud actually has a deleterious effect, especially for those who are performing the act of reading without showing signs of having achieved the comprehension desired.

This is at the root of the infamous "Blogging vs. blog setups" comic https://rakhim.org/honestly-undefined/19/.

The fact that this is true is also the entire basis for wikis. It is reasonable to find it irksome that people, perversely, refer to Git repos full of Markdown documentation as "wikis"—which they aren't. They are fully the opposite.

You should. It is.

See also lkesteloot's Java for Everything.

Note that while this isn't true now in 2025, it wasn't exactly true in 2013 when this post was written, either. Eclipse, IntelliJ, and NetBeans are all popular IDEs that were free and (in both senses) at the time this post was written.

This is:

Guo, Phillip. 2013. “The Two Cultures of Computing.” Blog. December. http://pgbovine.net/two-cultures-of-computing.htm.

That's a strange way to put it. Surely this makes lines refer to the Select element—and the properties (such as lines.value below) are just natural, first-class properties of that element?

If not, and there's something else going on here, that's an unforgivable overloading of the "id" attribute, which is already intrinsically significant in XML for orthogonal purposes. This needs to go.

Yeah. Web authoring is really just desktop publishing—except in its current state, foiled by the JavaScript industrial complex.

Great turn of phrase, but it's weakened by the choice to shoehorn React in as a dependency.

These annotations com from the use of https://github.com/dwhly-proj/DailyJournal which sends you an email, waits for your reply, then posts it as a top-level annotation targeting the dummy URL http://my.journal and tagged with DailyJournal.

@dwhly docdrop.org is broken.

Maybe, this is true, but it's not a conclusion we can draw from these tests. In choosing programs to benchmark, he selected notorious behemoths to pit against the IMGUI set—which, it should be noted contains stuff like Dear ImGui and EGUI, which aren't even apps.

And later, in the Windows benchmarks, he shows that the two apps—the only apps—in the IMGUI set actually perform worse than the others. The fact that RAD Debugger has a heavier power draw than clunky Electron apps of all thinks like VSCode should be considered evidence conclusive in the other direction.

@58:18

I'm very anti- this whole, like, NPM thing that happened where all these web people like— not only is their program like not a mathematical object, it's like defined by things not even on their computer—out in the world that might change at some point or go away. That's the worse possible reality, and so I think you want in source control, ideally, everything that you're using.

Kay has certainly spoken about such things (albeit not to my knowledge in any way that illuminates a generalizable approach that solves the problem). I'll elide a reference to anything specific (and the prerequisite side quest to track it down), and instead include a reference to Sussman at Strange Loop: We Really Don't Know How To Compute

NB: Unpleasant restrictions consist of things like, "You cannot read files from the user's local disk outside the file(s)/folder(s) that the user has given the software permission to access, and the person who authored it can't write to arbitrary locations on the user's disk"—both of which are imminently reasonable (and relate to things which you would hope would go one to be addressed (and the quicker, the better) if it were the case that the environment didn't already provide protection against these sorts of things).

Relatedly, Brad Cox quibbles about the inappropriate application of the word "maintenance" to these situations.

See https://hypothes.is/a/jH9HWDgREfCabIfIFCE5Ow

Third option: acknowledge that you chose the wrong foundations to build upon, and just because the present structures have proven to be (what I'd have argued was a predictable) failure, that that doesn't mean that there is no foundation upon which these things can be built while delivering the sort of stability desired.

Assuming the "common platform" is something reasonable (i.e. depends only a runtime that can be expected to be present on all machines) this is as straightforward as zip -r ./package.zip research/.

(The problem isn't figuring out how to do it. It's getting people to stop sleepwalking along with all the "best practices" that are outright inimical to the reproducibility/replicability goals. Almost everyone—including to an extent the author of this post—is unwilling to cast aside their attachments.)

Even before class declaration statements appeared in ES6, this was the wrong way to define methods.

Sure it does.

Yeah. It's a major social problem. Not so much a technical one.

Imagine if there were a readily accessible World Wide Wruntime that anyone with any commodity computing device could use to run arbitrary code (and its corresponding documentation) written by other people...

Proposal for a much more interesting piece of writing: "The Sacrifices We Choose Not To Make"; cf:

1. The Handwriting on the Wall
2. New Christianity

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.