It's hard even it's more ideal forms (for different reasons). I outlined the antidote a year (or maybe two? geez) ago—the fanclub economy. Posted originally to socii, but it's dead now, so all I have is the local JSON dump, which I haven't fixed up and put online myself.

"will resemble"? What year was this written?

Is it? Who calls it that? Sounds like Pournelle's iron law of bureaucracy.

You're looking for https://nadia.xyz/creator-economy

We should be able to track down the source here just as easily as we can see verbatim quotes' original place.

citation needed

This is a popular way to describe it, but I don't believe it is actually helpful to people who don't already understand.

Obscurantism isn't a virtue.

Accessibility is more important, after all, than Kartik says it is (elsewhere; cf recent Mastodon posts).

Looks like it's dead. The link goes nowhere.

Apple is going to ditch TSMC for Intel—or rather, what will be the Apple-owned fabs formerly operated by Intel. After the acquisition, Apple will become a major champion for USG "investment" in US-based fabs, and they'll get what they want. They'll achieve parity with or surpass TSMC.

Two important things to be aware of:

1. Projections of semiconductor advancements hitting a wall, if they turn out to be valid and true, describe a set of circumstances that are actually beneficial to anyone trying to catch up to the tech leader.

2. There's a lot of low-hanging fruit to be had in fab operations. A lot. Given sufficiently mature/advanced (i.e. adequate) tech to start with, Apple can make leaps and bounds over, say, Samsung by business process improvements alone.

... but still harder than it should be. (Isn't this team supposed to be sensitive to stumbling blocks? I thought that was pretty much the entire gestalt of this platform...)

Foolish constraint.

Case study in equivocation.

... which is of course the whole point! We'd probably be better off promulgating "RFC" as a relevant term for more than just tech standards.

That's hardly tight. What it is, like much of Go, though, is "gcod enough". And a lot of JS is the same way, if you—once again—reject the desire to follow-by-example without taking care to make sure you don't pick bad examples—which is what the NodeJS world offers, by and large (which itself makes esbuild's entire raison d'etre part of a somewhat existential paradox).

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

Should have led with this.

Zotero desktop needs an "inbox"—a Dropbox-like directory where you dump stuff into it, and then Zotero adds it to your library.

The same is true for login systems that use cookies, but no one cites that as a downside. There's an asymmetric standard being applied to HTTP native authentication.

How to get remote control over the Hypothesis sidebar (one way, at least):

1. Use the bookmarklet to open the sidebar
2. Click the sidebar's "Help" icon in the top right
3. Right click the "Help topics" link and select "Inspect" in the context menu to open the element in the browser devtools
4. Remove "noopener" from the link (easiest way is to just delete the element's "rel" attribute)
5. Change the link target to something other than "_blank" (e.g. "foobar")
6. In the sidebar, click the now-modified "Help topics" link
7. For good measure, in the new tab that opens, navigate to the same URL loaded in the sidebar (should be something like https://hypothes.is/app.html with a site-specific URL fragment; you can get the actual URL from the devtools JS console with document.documentURI, or right-clicking the sidebar and selecting "View Frame Info")

From the secondary tab ("foobar" opened by click in step #6) you should now have unrestricted, scriptable access to the DOM of the original sidebar iframe, using e.g. the JS console in devtools instance or a bookmarklet applied to the secondary tab—access it as window.opener.

Nope. That was way scummy.

"The greatest performance improvement of all is when a system goes from not-working to working" https://web.stanford.edu/~ouster/cgi-bin/sayings.php

wat

This is stupid.

See Java For Everything. https://www.teamten.com/lawrence/writings/java-for-everything.html

On the other hand, explicit is better than implicit. If you're attaining "no code" via implicit magic, that's not a win.

let id = response.headers.get("X-Request-ID");
if (id) {
  let info = this._pendingRequests.get(id);
  if (info) {

This is unused.

This is not a look-how-great-Webpack-is observation. This is a look-how-bad-the-source-code-is observation.

I keep seeing people say this, and it's one of the dumbest things I've ever heard. It's a WebExtension. There's even less reason to use obfuscators for extensions than there is to use them on the open Web...

... so?

The costs here tend to be overstated (and stated by people without a strong background in either browsers or languages, I've found).

I remember someone mentioning to Boris Zbarsky (and expecting him to agree) that IE compatibility was a source of bloat in Gecko. Of course, he corrected them.

Actual URL: https://www.xml.com/pub/a/w3j/s3.nelson.html

See also http://www.xmlvm.org/

Shame that setting up the Java project itself isn't as simple.

I like this one better than the traditional form, which is clumsy.

A good case study in ho-hoism.

Refer to the previous two notes:

• https://hypothes.is/a/RQgF4md_EeyzTmv5uuVjrg
• https://hypothes.is/a/9zTb-md_Eey_YRtWX7Mtxg

Desired workflow:

1. I navigate to the APL login page https://austin.bibliocommons.com/user/login
2. I invoke a bookmarklet on the login page that opens a new browser window/tab
3. In the second tab, I navigate here—to a locally saved copy of (a facsimile of) my library card
4. I invoke a bookmarklet on my library card to send the relevant details to the APL login page using window.postMessage
5. The bookmarklet set up in step 2 receives the details, fills in the login form, and automatically "garbage collects" the second tab

Some other thoughts: We can maintain a personal watchlist/readlist similarly. This document (patron ID "page") itself is probably not a good place for this. It is, however, a good place to reproduce a convenient copy of the necessary bookmarklets. (With this design, only one browser-managed bookmarklet would be necessary; with both bookmarklets being part of the document contents, the second bookmarklet used for step 4 can just be invoked directly from the page itself—no need to follow through on actually bookmarking it.)

Need to figure out the barcode format used on the actual cards and reproduce it here, too.

In fact, Ideally, this digital facsimile should hew close enough in fidelity to the actual thing that I should be able to print my own (using only the data encoded in this document as input).

Best way to view these in order:

Open the socii JSON export in the browser, defuse the unhelpful JSON viewer by using "View Source" if necessary, and then open a JS console to run the following snippet:

let o = JSON.parse(document.body.textContent)
o.sort((a, b) => (
  String(a["created"]["epoch_time"]) - String(b["created"]["epoch_time"])
))

Other useful snippets:

Easily spot thread chains (look or empty string for thread roots):

o.map((x) => (x["replyTo"]))

Get replies to other accounts:

o.filter((x) => (o.map((y) => (x["replyTo"] && y["id"])).indexOf(x["replyTo"]) < 0))

(It also wouldn't be a bad idea to take Fritter and wire it up to be able to read the export.)

You are looking for https://htmx.org/essays/rest-explained

Should system configuration files be full-fledged documents? I.e., explain to the user—with rich text, even—both the conventions of the configuration format as well as what the given system's actual configuration is?

It's almost as if the WebExtensions design was not very good...

Not so much "On the Web" as it is "In JavaScript". mjs is an invention of runtimes like NodeJS (and the unending toolchain hell that sprang up around it) to paper over NodeJS's non-standard idiosyncrasies that are entirely the closed loop result of their own doing.

The fact that this has infected discussion of JS itself is even more reason to despise Node and its ecosystem.

should be "loving"

missing an "until" here

Yikes.

Disingenuous, or just dumb?

Incomprehensible.

In a world where programmers behave reasonably (i.e., not the one we're living in), this is what the list of GitHub forks would be useful for. You have some need to extend a project, you look at the list of people advertising their forks of the upstream, you see one that could also benefit from the change you're looking to make, and you file a pull request to ask them to accept your changes. After reviewing your changes and accepting them (in the best case), then they can optionally pitch these changes to the original maintainer if they want (e.g. in the case of non-hostile forks).

In the world where we actually live, the list of forks is more or less useless; if you were to suggest that someone take your changes into their "fork", then they'll call you a weirdo and say that's not how any of this works—if they say anything at all.

Should be "compatible"

The distinction between Chesterton's fences and Rhesus ladders defined.

Ra ∋ Rhesus ladders https://hypothes.is/users/mrcolbyrussell?q=rhesus

typo for "exists"

Damn. HN's feedback has been dogshit when responding to Dan's posts. (Or at least I can say that this has been the case for 2 out of 2 of the most recent pieces that I've seen posted and witnessed the reaction in near real-time. They're so bad that I'm not really interested in checking the sentiment on other, older pieces of his that I've read.)

Work on solving it with the fanclub "economy".

From Understanding how killall works using strace https://jvns.ca/blog/2013/12/22/fun-with-strace/

From Ten Great Books https://sites.google.com/site/steveyegge2/ten-great-books

From Great Hackers http://www.paulgraham.com/gh.html?viewfullsite=1

From Architecture astronauts take over https://www.joelonsoftware.com/2008/05/01/architecture-astronauts-take-over/

I used to wince at these posts, but now I encourage them. See A New Publishing Discipline.

Counterargument: nobody's measuring anything.

Counterexample: GitHub.

None of this is really relevant. Of all the apps listed, none are especially relevant to the Web. They'd best be classified as internet apps. Granted, they might be dealing in HTTP(S) at some point as a bodge, but then again, almost everything else does, too, whether it's part of the Web or not.

(re @eric_young_1 https://twitter.com/eric_young_1/status/1470524708730851328—not sure how well the twitter.com client and Hypothesis interact)

The dream is still alive among semweb people (incl. Tim Berners-Lee himself).

The sad state of current norms re webapps created by professional devs leads to what probably seems like a paradox but isn't, which is that the alternate future outlined in this tweet is closer to the ideal of the Web than the "Modern Web".

404

The subtext here is, "that's why i created BeachfrontDigital". But this shows how "apps" (and systems) have poisoned how we conceptualize problems and their solutions.

The simplest solution to the problem described is a document, not a never-finished/never-production-ready app. Bespoke apps have lots of cost overhead. Documents, on the other hand—even documents with rich structure—are cheap.

See also: standardjs.com. The arrogance that it takes to try to pull stuff like this is... hard to describe.

Geez.

"Interoperable", you mean.

... why? Maybe it was only clear in hindsight, but Gruber's lack of response to the request is functionally equivalent to a pocket veto.

No.

The thing about syntax errors is that even if the build takes a long time (project is huge), syntax errors can be detected quickly.

Good way to describe ANPD.

Social barriers important, too, but underappreciated.

It is different. However, they're similar enough to draw lessons from.

I use similar, non-specced canaries all the time. E.g. small fixes for things in projects that are nonetheless obvious errors, or determining whether someone is going to try to frame my attempt to contribute by "upperhanding" me, whether they're hostile to messages attached to a name that they don't recognize, etc.

For example, if it takes too much back and forth to get a typo or link fixed in the docs (or any sort of review process for content on what is purported to be a "wiki"), then odds are, things are messed up at a greater level that are going to be a source of frustration later. At that point, I'm out.

A surprisingly large number of projects fail these, in what we are otherwise expected to consider the present Renaissance of FOSS...

Stanford runs their own archive instance (https://swap.stanford.edu/). Why shouldn't the LOC, too?

Does it? It's pretty much just as easy or easier than doing it the way that everyone else insists is correct. I'm more than half convinced, in fact, that the npm install way being unnatural is the reason why it's sacrosanct. You can't just let things be easy—people dislike any state of affairs where their experience/participation isn't some combination of necessary and valuable.

I've tried making this case. People flip their shit and then for lack of a good argument they start doing that thing where they try to shut you down because of how weird it is—and you don't want anyone thinking you're weird, do you?

It is unusual. It's not a bad thing to do, but it is still, in the literal sense of the word, unusual. That doesn't say anything about the practice itself so much as it says something about how bad the "usual" way of doing things is.

I've noted elsewhere that despite the reputation of WYSIWYG editors' tendencies for handling HTML, modern mainstream Web development practices are so bad today that just typing a bunch of junk into LibreOffice and saving as HTML results in one of the most economical ways to do painless authoring of Web content...

This gets it right. The similar essay "The JavaScript Trap" is anathema. As Richard was later cajoled into clarifying:

to be philosophically clear, the language JavaScript, as such, is not morally better or worse than any other language. What's bad is running code immediately as it arrives from someone else's server

The clarification is needed. With the existence of "The JavaScript Trap", people are under the (silly) impression that JS or programs written for the browser and executed by its JS engine are inherently bad.

Broken link. (And it's an antipattern, anyway.)

In "FactForge: A fast track to the Web of data", Bishop et al give this criterion as, "Use URIs as identifiers for things".

There may need to be a zeroeth step here, which is "don't make the mistake of designing systems in such a way that things can't be identified by name".

Weird statement. WebKit is an element in the set defined as "the 2 major browser engines".

Two things that still need to be addressed in section 7:

• the top module is special
• an uncluttered root directory is good practice

That's not right... should be "./src/LineChecker.src". (The fact that the compiler isn't throwing an error on this is a bug in and of itself...)

Spurious close paren here.

s/.*/Let's discuss an implementation strategy/

Someone should launch a "No regressive GitHub bullshit club".

This loop showcases a UI pattern that I think could be improved. There is an "edit" button visible, which opens the sidebar. The principles should more closely resemble the Hypothesis sidebar. Instead of requiring an explicit edit button which the user clicks, the editor should operate on object selections. Merely clicking any of the displayed values should select it, which should provide a handle to the underlying object, which should reveal the editor sidebar (with, ideally, the relevant field focused).

The current incarnation of the tutorial (https://raw.githubusercontent.com/akkartik/mu/7195a5e88e7657b380c0b410c8701792a5ebad72/tutorial/index.md) starts by describing "Prerequisites[:] You will need[...]", and then goes on to list several things, including various software packages—assuming a Linux system, etc.

This is the idea I'm trying to get across with the self-containedness I've been pursuing (if not with triple scripts then at least with LP docs).

That prerequisites list should be able to replace with two requirements, i.e.:

"You will need: (1) this document, and (2) the ability to read it (assuming you have an appropriate viewer [which in 2021 is nowhere close to the kind of ask of the old world])"

Another way of saying that the use of V8 means that JS isn't actually an "interpreted language" (not that that's even a real thing).

Fielding's MOMspider, one of the very first web tools, does this, albeit not at build time in a static site generator.

Just say no to backslash for path separators, even on Windows.

(I can't believe the Powershell people got this right originally and then chose to fuck it up.)

"burden"

Good example of why leveraging the browser's runtime is better. i wouldn't have guessed that the md2blog creator was using Windows. (And I didn't. I just assume that everyone is using a Mac, even though I'm on neither.)

See also Translating Type Hierarchies: Framework Analysis and a Proposal (Malone 1988) http://hdl.handle.net/1721.1/49308

First(?) published in JEP Vol. 1 Issue 1: https://doi.org/10.3998/3336451.0001.137

Any known previous occurrences to this phrase? It's used today in the Solid Project.

From the WebNet 96 Conference Proceedings (San Francisco, California, October 15-19, 1996). https://eric.ed.gov/?id=ED427649

This paper covers various shades of Semantic Web problems (not yet coined at the time) and several problems being dealt with by the Solid Project folks today.

See Market-like task scheduling in distributed computing environments (Malone, 1987).

Fuck this shit. Would you think it was a good idea to show your appreciation to someone by tipping them -$1?

It's stupidly easy to achieve the intended effect without fucking it up. If you want to send your thanks but there is no obvious way to do that, then congratualations you have found a bug. File a bug report about that instead of subjecting the recipient and everyone else in the project orbit to your public wankery.

Every item filed in a bugtracker should correspond to a defect.

Stop encouraging people to misuse project infrastructure.

The single best piece of advice in a column filled with bad advice.

This should go without saying. The fact that it doesn't is an indicator of a bigger issue that probably calls for a drastically different approach.

"... then consider not".

The problem with lots of these examples is that they read like a robot emulating what they think genuine sentiment sounds like. This example is no different.

Again: maybe modelling your approach off something that is broken is not the best thing to do.

If these techniques are supposed to work and this is the result, maybe consider the possibility that all the advice here is not the way to go about doing things.

Bad execution of mostly acceptable advice, in contrast to much of the earlier stuff, which constitutes bad advice.

Things that you say should be true.

Please, no (unless you're actually writing an email and introducing yourself).

Bugtrackers are not message boards.

On the contrary, this kind of PR speak is a good example of how to piss people off by sounding like you think they're too stupid to recognize this "trick".

"Open source" doesn't make this hard. How you're advocating that open source has to be done is what makes that hard. So stop doing that.

Gross.

You can.

Gross.

If the costs are high, then start charging people for it.

Please, no. This is a big reason why the relevant problems here exist in the first place.

It's almost like the way that GitHub is typically used is an example of how things shouldn't be done!

Because with the rise of GitHub, the behavior of most other bug reporters makes for a plethora of bad role models and a dearth of good ones.

Yeah, and that could certainly use fixing. I'm getting a dreadful sense of foreshadowing here that making contact with this observation has led the author to an entirely different conclusion—e.g., that this is an argument by analogy where what follows is going to be a bunch of suggestions that ultimately make other things worse.

Strong disagree. The tendency to the latter is awful. developer.mozilla.org committed this sin in the early days and then never shook it, despite many opportunities to do so and the many problems it caused.

Guessable URLs for stuff like reference works especially are an amazing affordance on the user end but also a much more economical use of resources on the implementor's end, because it eliminates both the fixed upfront creation cost as well as the recurring cost associated with waffling or bikeshedding about the hierarchy.

Probably one of the best things that any single person or organization can do is to identify stuff that looks like it's productive work but isn't, and then eliminate both it and the conditions that allowed it to occur, made it seem like a good idea, etc.

No. Geez.

Should be "serve".

Should be "their".

Memex began and remained as an ambiguous an not too original concept

I think memex is valued as a touchstone rather than an invention, and that's how it should be treated.

The movie "Moneyball" is a good example of how this can go wrong. People like Philip Seymour Hoffman's character create self-fulfilling prophecies of failure.

Let's go further than this: details matter. It's weird how many people don't get this, despite the fact that we have an aphorism ("the devil is in the details") baked into our language.

Instead of mentioning sha1sum(1) or linking to some seedy third-party service, dding a button right here to do calculate the SHA-1 for a given file would be trivial...

Should be "tld", not "tdl". (But really should be something RFC 2606-compliant like "you@mailhost.example".)

This is a port of Michael Schierl's OberonXref from Java. Instead of requiring a JVM, you can run it directly in the browser.

• Point it at a directory containing a Mod/ subdirectory and a resources/ subdirectory. The latter should be a copy of the directory of the same name from the original repository https://github.com/schierlm/OberonXref/tree/master/src/main/resources. The former should contain the sources for the modules of interest.

Lars Bak makes this point in a Channel 9 interview. I think it was this one (can't tell; dead link): http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine

One of his interlocutors can't wrap his head around it. He makes a "but C# and Java are compiled languages"-type of argument comes off like Limmy's confused protest that "steel is heavier than feathers...".

The rise of non-algorithmic "algorithms".

A question of ontology: Does battling the build system and the various tools mentioned count as "debugging"?

Wrong. Licklider is not an author on this. No one is except for Cawkell. Cawkell mentions the others in his letter.

Missing:

• "An On-Line Information Network" (1965) [from the Project Intrex report]

These are all wrong. Cawkwell is the only author for this. The other names come from a list of others appearing in Cawkwell's letter (a list of the most cited authors, excluding self citations).

Should be "The".

Should be "extension".

Should be "bizarre".

Modern JS development is rampant with this, with the profligate misuse of triple equals (===) almost everywhere where double equals would be appropriate as one example.

"Resist it" might be a better way of putting it.

From p. 145:

I would hope that it would extend in an atmosphere of professional interchange and frankness which is characteristically American.

The metaphor itself is pretty interesting considering that the premise already involves using an iPad. I remember when in the first few years after (capacitive) touchscreen devices became available to the mainstream, someone quipped that tablets are convenient and all until they're not—that trying to get real work done, especially when it requires typing, is like being forced to "think through a straw".

wat. We're starting on page 104! This is running backwards.

The state of the world is worse than what is implied here. The implication, as I understand it, is that it's so difficult to conceive of a world that works any differently from the way Tim considers that it works today—that someone could live in a world without the Web and not know what's missing, and just as easy to exist in a world with the Web and not see it as anything other than obvious—because why would it ever have worked any differently, right? But I know empirically (and painfully) that people (whether millennial types of people or not) exist in a world where we do have this stuff and don't even understand what we have. I've had firsthand dealings with knowledge workers who still have the "I don't get it; so what?" reaction, to an exasperating degree. We are way, way short of Engelbart's vision.

"Library Networks: Should They Deal With Containers or Contents of Knowledge?"

Searching around, it doesn't seem like the outside world (e.g. Google Scholar, bibliographers) are aware that this piece Licklider wrote even exists, despite it being digitized and sitting here in the open.

This piece presages the Internet Archive and, given the juxtaposition of its lofty goals with the piece's own obscurity, there's a perverse irony here.

Licklider writes in section 2:

It is high time that librarians reach out into computer networks to create order and functionality out of what is now chaos. (The author would- estimate that 90 per cent of the computerized information in EDUCOM universities "trickles down" to back-up or dead storage tapes within two years and that less than one per cent ever "perks up" again.)

"Perking up" is more than what I'm talking about here—again, I can't find evidence that this piece is even catalogued anywhere.

Pretty sure it's because the ZIP files were expected to be written to multiple disks (floppies), and as alluded to earlier, if you wanted to delete a file, you could just insert the last disk containing the directory and "delete" it, therefore not requiring you to insert the disk(s) containing the actual file record to null it out (or overwrite with some other file record, potentially requiring 3 disk swaps). Thus, the ZIP format constitutes something like a filesystem implemented in userspace. 30 years ago, this was "obvious" and that's why you were expected to know this. There was no assumption that tradition and path dependencies would lead to ZIP still being widespread for cross-platform data interchange among machines capable of fast writes to local disks that have terabytes (although sometimes "merely" gigabytes) available.

Lots of weird reactions to this post.

In How to Stop Endless Discussion https://candost.blog/how-to-stop-endless-discussions/, the author explains the NABC model—"The model starts with defining the Need, followed by Approach, Benefits, and lastly, Competitors. Separating the Need from the Approach is very smart."

Commenting in support, Simon Willison writes:

We implemented a RFC-style process at a previous employer. [...] One thing that was particularly valuable was ensuring every proposal came with a "alternatives" section (called "competitors" in the NABC model). We also made sure that every proposal included "do nothing" as one of the alternatives

https://news.ycombinator.com/item?id=25623388

I scarcely think that the majority of people who are behaving as if React and/or the NPM-heavy workflow are things that simply must be dealt with have ever done on honest NABC and evaluated the foregone conclusions biased towards their preferred workflow against the do-nothing alternative of just not bringing all the heavyweight NodeJS-centric tooling into the picture.