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.

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.

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...

I find myself revisiting now due to buggy behavior observed in jszip (discovered through Darius Kazemi's reliance on it for his Twitter archiver project).

The problem is that jszip when given a ZIP with Zip64 data in the end of central directory record handles it poorly (presumably jszip simply doesn't have support for Zip64 despite being advertised as such)—except that that's even really the problem.

The fundamental problem with jszip is that it doesn't support Zip64 (whether it says it does or not) and it makes an assumption that the last file header record in the central directory will be immediately followed by the end of central directory signature and when it encounters a file that violates this assumption its attempts to recover are odd. There's no good reason for jszip or any other software to make that assumption, though, since depending on it is in no way necessary to go ahead and successfully work with the files that are present.

From an earlier private note (from 2021 July 20):

A better way to phrase it: "What if there is some byte sequence that coincides with the sequence used for the local file header signature, but nonetheless does not comprise some part of a file record (i.e., one "referenced by the central directory")?

And the answer, of course, is right there; it is not UB—that isn't a file record.

Some block of data within the ZIP can only be considered to comprise a local file header iff it is referenced by the central directory. A byte sequence appearing elsewhere that collides with the file header signature is just noise.

What happened to the central directory offset not being allowed to be located there?

The silliness of method overloading. The problem this is trying to solve can be solved by the publisher providing a consistent interface no matter what the input parameter and the consumer choosing the right module to import.

This is an interesting comment, because the same logic can be applied to the author's criticism of the APPNOTE spec and his question of whether ZIP can be streamed or not.

In that case, your Web pages are changing more than they probably should be, anyway.

Traveler:

You're looking for https://www.w3.org/Administration/DataModel.html

samsquire is /u/plentifulfuture.

I do not follow the author's train of thought in this piece.

Wikipedia has an article about intentional communities.

It's a little perverse to link to an inaccessible Twitter/X.Com post here in a post about this topic.

~50 people and "a tiny percentage of the overall staff" are such bad estimates that it's something you'd expect from the least clued-in segments of the peanut gallery, not someone on payroll. I struggle to come up with words to even react (let alone respond) to it, even in the written medium of online comment threads where you have time to compose your thoughts. It breaks my brain.

Gecko? XUL?

This is:

Bogart, Christopher, Margaret Burnett, Allen Cypher, and Christopher Scaffidi. “End-User Programming in the Wild: A Field Study of CoScripter Scripts.” In 2008 IEEE Symposium on Visual Languages and Human-Centric Computing, 39–46. Herrsching am Ammersee: IEEE, 2008. https://doi.org/10.1109/VLHCC.2008.4639056

UT says they have (some parts of) 47 and 48. I have confirmed it exists, but not totally clear on the completeness.

This can't be right. Sure, by this definition the relation "B overlaps-start R" holds, but so does "A overlaps-start R".

Missing March pages:

2, 3, 6, 7, 10, 11, 27, 28

PCL has some not listed here (or on HathiTrust):

https://search.lib.utexas.edu/permalink/01UTAU_INST/19i7hhk/alma991029833209706011

All right, so it doesn't say here, but UT's physical copies at PCL include what I think is the whole series.

HathiTrust's scans from the University of Michigan's collections go from volume 1 up to volume 13, but PCL has also vols. 14–17.

I don't see that Hathitrust or Google Books has "The Illustrated News of the World".

(Does this periodical have any relationship to "The Illustrated London News"?)

I've thought about and would really appreciate a platform like Lulu that would allow you to pay, say, 99¢ each to get printed copies of your favorite blog posts (standalone, not necessarily in book form), where a portion goes to the author. It shouldn't require creators to sign up for e.g. Patreon and consciously designate a priori what is and isn't "subscriber-only" content.

Like, "I just like this thing that you wrote, dude. Let me get a print copy and also make sure you get a few nickels for it."

NB: This is NOT the same as Ballou's Pictorial.

Okay, seemingly missing from here, and not made up by any of the other sources listed here are volumes:

• 61
• 62
• 69
• 73
• and 77(?)

Anything else? (It doesn't say exactly when it stopped in 1893. Vol 76 was December 1892.)

This scan has v19n3, which isn't an extant issue listed on HathiTrust (or Ockerbloom's Online Books page): https://catalog.hathitrust.org/Record/009793643

https://hypothes.is/users/mrcolbyrussell?q=%22open%20source%20is%20not%20enough%22

NOT mentioned here, according to http://www.philsp.com/mags/mcclures.html, there are seven phantom issues v56n6 and v57n1–v57n6 covering June through December 1926.

I'm not sure what happened to v56n5 or what's with the overlap of volume/issue numbers for v57n1–v57n4 (May through August 1924 and July through October 1926.)

It looks like based on what's here we are missing issue 58. According to http://www.philsp.com/mags/mcclures.html, this covers January through June 1927 (6 issues).

Does SQLite even need to construct an AST? It's just SQL. Can't it just emit the bytecode directly?

I've been critical of some of the projects/standards that the author has been involved with and adjacent efforts, precisely because of the tendency of proposals to violate the Principle of Least Power. We'd be a lot better off if more people in that cohort appreciated the architectural style of RSS- and Atom-based Web feeds and how much that impacts adoption.

Even if it is several years late, it's good that he's starting to ask questions like "is it possible to avoid using a database?" and contemplating things like the ramifications of trying to capture something in static HTML so that it can be relayed by a dumb server whereas in its original design it required, sometimes for a no good reason, an application server with smarts that enabled it to be an active participant.

This is one of those weird positions like, "It doesn't matter who you vote for. Just vote!" that people are sure to regret when faced with the right unforeseen counterexample.

This principle is behind good documentation, too. Too often programmers describe what their solution does and how it does it, but not why. Part of the why is just describing the problem that the solution is meant to address.

I found this really hard to read on archive.is (https://archive.is/YkIyW).

I used this snippet to reformat the article to manually float the "annotations" (pull-outs) to the margins:

```` javascript document.getElementById("CONTENT").style.width = "1720px";

([ ...document.querySelectorAll("[id^=annotation]") ]).forEach((x, i) => { if (i % 2) { x.style.left = ""; x.style.right = "-44ch"; } else { x.style.left = "-44ch"; x.style.right = ""; } }); ````

I'm amazed at the lack of thoughtfulness in the original post that this change of heart refers to. From http://rachelbythebay.com/w/2011/11/16/onfire/:

I assigned arbitrary "point values" to actions taken in the ticketing system. The exact details are lost to the sands of time, but this is an approximate idea. You'd get 16 points for logging into the ticketing system at the beginning of your shift, 8 for a public comment to the customer, 4 for an internal private comment, and 2 for changing status on a ticket. [...] The whole point of writing this was to see who was actually working and who was just being a lazy slacker. This tool made it painfully obvious [...]

This is, uh, amazingly bad. It goes on, and in a way that makes it sound like self-aware irony, but it's clear by the end that it's not parody.

The worst support experiences I've had were where it felt like this sort of pressure to conspicuously "perform" was going on behind the scenes, which was directly responsible for the shoddy experience—perfect case studies for Goodhart's Law.

The author says they've had a change of heart, so surely they've realized this, right? That's what led to the change of heart? Nope. Reading this post, it's this: "my new position on that sort of thing is: fuck them." As in, fuck them for not appreciating the value of this work and needing it to be done for them in the first place. The latter is described at length where they describe the jobs of the managers to already know these things—that is, the stuff that these metrics would say, if the data were being crunched. "Make them do their own damn jobs", the author says.

(I often see this blog appear on HN, and I've read plenty of the posts that were submitted to HN but have never exactly grokked what was so appealing about any of it. I think with this series of posts, it's a good signal that I can write it off and stop trying to "get" it, because there's nothing to get—just middling observations and, occasionally, bad conclusions.)

According to this catalog https://www.waverlybooks.com/home/list137.pdf, the June issue is the one that contains the poem "Goodbye to a Lady".

I don't see this on Hathitrust or Ockerbloom's Online Books Page.

Notable for publishing two poems by Dashiell Hammett.

https://storyoftheweek.loa.org/2023/05/the-main-death.html

This is:

Klosterman, Chuck. The Nineties: A Book. New York: Penguin Press, 2022. https://n2t.net/isbn:/9780735217959

To get a list of all the public domain scans, as of this writing:

```` javascript ([ ...document.querySelectorAll("table.auto-style21 a") ]). filter((x) => ( x.textContent.includes("19") && !x.textContent.includes("1929") && !x.textContent.includes("193") && !x.textContent.includes("194"))). map((x) => { let when = x.textContent; if (!when.includes(",")) when = when.split().reverse().join(" ") + " 01";

try {
  var result = (new Date(when)).toISOString().substr(0, ("1928-10-29T...").indexOf("T"));
} catch (ex) {
  console.log(x.textContent, when, ex);
}

if (when != x.textContent) {
  result = result.substr(0, ("1987-12-09").length - ("-09").length);
}
return result;

}) ````

This and the other new additions listed at https://onlinebooks.library.upenn.edu/new.html aren't listed on Wikisource and need to be added.

Hmm. I can't find anything about this! It would be nice if we had a scan.

(Since philsp.com links are unstable, this is cited as "Best Stories of All Time [v1 #6, November 1925]")

Whoa, are the 1920s issues really not that widely available?

It's also, you know, way more grokkable.

Or <label>, even...

Not quite! Your typechecker just isn't powerful enough.

Filter all lists to include just the ones with partial serials:

([ ...document.querySelectorAll("li") ]).filter((x) => (!!x.querySelector("img.info"))).filter((x) => (!x.textContent.trim().endsWith("(partial serial archives)"))).forEach((x) => (x.parentNode.removeChild(x)))

PCL has fairly complete archives: https://search.lib.utexas.edu/permalink/01UTAU_INST/vu6c1o/alma991031921079706011

This isn't made clear in enough sources.

This is:

Noseworthy, Theodore J., Fabrizio Di Muro, and Kyle B. Murray. “The Role of Arousal in Congruity-Based Product Evaluation.” Journal of Consumer Research 41, no. 4 (2014): 1108–26. https://doi.org/10.1086/678301

Meanwhile, Hypothesis (and Apache Annotator; related prior art) are both free software.

It's here: https://time.com/archive/6735152/the-selfish-meme/

I was wrong https://hypothes.is/a/p1dohn89Ee-QDVdC-4Z0oA.

Notice how bad, as of this writing, the typography is on this page.

Use this as an example of the weirdness of the difference in creator agency and consumer expectations about presentation of the written word when it comes to print vs Web.

I thought I was parsing this, but I don't understand it.

Ibid

Similarly, a few years ago I was running into a bunch of people saying stuff like, "Every programmer uses Stack Overflow. Everyone." Which is weird because it definitely had the feel of a sort of proactive defensiveness every time it came up, plus there's the fact that it's not true that every programmer uses Stack Overflow. At the time I kept running into this kind of thing, I had basically never used it, but not for lack of trying or any sense of superiority. Every time I'd landed there the only thing I encountered was low-quality answers and a realization that Stack Overflow just doesn't specialize in the kind of stuff that's useful to me. (In the years since, I've landed there quite a bit more than before, and I have found it useful—but almost never for actual programming...)

I don't think I've ever seen this in a technical discussion. Credentialism in the form of "X years experience with Y" or someone trying to flex other parts of their résumé (e.g. previous employers)? Definitely.

Most often, though, I just run into Ra + a fuckton of ho-hoism. This is never tinged by academic credentials, even a little bit.

I'm curious where this comes from. As the archives below indicate, Hathitrust only has volumes up to volume 24 (1898). UT PCL stops also at volume 24. Everything available seems to stop there.

I did chase down the Mott reference from the Wikipedia article that says it ran until 1900, but I don't remember seeing a volume count. I wonder if 1900 is substantiated anywhere else and whether the volume count is an independent claim or a derivative of the claim of cessation in 1900.

(Maybe the copyright records indicate two more volumes?)

This is listed at https://onlinebooks.library.upenn.edu/new.html, so I'm not sure why there are no volumes listed.

Hathitrust has part of the magazine under the title The New Monthly Magazine and Universal Register (1814–1820; missing vols 3, 5, 7, 9, and 10), but under the title The New Monthly Magazine, all these volumes are represented. There are at least some under the name The New Monthly Magazine and Literary Journal (1821–1836), and also some under the name The New Monthly Magazine and Humorist (1837–1852). It has the final volume in 1882 under the name The New Monthly.

So that means we won't see a classification/subclass with a range like AZ57482. But is there a limit on the number of digits after the decimal?

(Also, the literal reading of the statement here means that the range in EG9999.293 is invalid—because 9999.293 is greater than 9999.)

It doesn't look like this happened.