nope

Is this not just a new name for what was already described in the 1960s as the "software crisis"?

There's a fundamental misunderstanding (alternatively, misdirection) about what the source of breakage is. JS is not an SDK, and neither is the Web platform. Whatever worked in the old "JavaScript version" will work in the new one.

See http://silverspaceship.com/inner/imgui/

Now imagine, as a performance optimization, a lib where you can write in IMGUI style, so you write the same amount of code, but behind the scenes, the lib is managing things, so it's actually free to do all the retained mode heavy lifting.

We just invented declarative programming.

Interesting remarks, given the Muratori school on profligate misuse of computing resources by modern developers.

Game Developer. September 2005.

This describes one of the most pleasing hacks I've ever come across. I just now tracked it down and added it to my bookmarks. (Not sure why it wasn't already there.)

You could also conceive of going one step further. When your app (doesn't actually have to be a game, though admittedly it's much easier for you if it is) is compiled with tweak.h, it gives it the power to paint the source file on the screen—so you don't actually have to switch over to your text editor to save it, etc. Suppose you want to provide custom inputs like Bret Victor-style sliders for numeric values. You could edit it in your text editor, or you could derp around with it in-app. Tweaking the value in-app should of course both update it wrt the app runtime but also still write the file to disk, too, so if live reloading is turned on in your text editor, whatever changes you make inside the live process image gets synced out.

Hey, traveller. You're looking for https://web.archive.org/web/20070824202955/http://www.mollyrocket.com:80/forums/viewtopic.php?t=159&sid=cb913629aa8310947c0476848a8824dd

See Too DRY - The Grep Test.

But even allowing for grep is too lax, in my view. It's too high a cost. If I've got some file open and am looking at some Identifier X, I should be able to both deterministically and easily figure out exactly which file X lives in.

Violating this is what sucks about C's text-pasting anti-module system, and it's annoying that Go's "package" system ends up causing similar problems. I shouldn't have to have a whole-project view. I should be able to just follow my nose.

I think it is the beneficiary of a network effect—it's just driven by a professional class, and not end users.

Also: ho-hoism; see McCarthy to Russell on eval

Ah! This remark highlights a fundamental difference in understanding between two camps, which I have been (painfully) aware of, but the source of this confusion has eluded me until only just right now. (Really, this is a source of frustration going back years.)

In one camp, the advice "don't use global variables" is a way of attacking a bunch of things endemic to their use, most notably unnecessary coupling to spooky state. In another camp "no global variables" is understood to mean literally that and taken no further—so you can have as much spookiness as you like, and so long as the value is not directly accessible (visible) from, say, another given piece of code appearing at the top-level ("global") context, as with the way i is bound to the activation record in this example but is not accessible outside the scope of getGetNext, then you're good.

That is, there are two aspects to variables: visibility and extent, and the first interpretation seeks to avoid the negative effects on both dimensions, while the second is satisfied by narrowly prohibiting direct visibility across boundaries.

I find the latter interpretation bizarre and completely at odds with the spirit of the exhortation for avoiding globals in the first place.

(What's worse is the the second interpretation usually goes hand in hand with the practice of making extensive use of closures, which because they are propped up as being closely associated with functions, then leads people to regretfully refer to this style as functional programming. This is a grave error—and, to repeat, totally at odds with the spirit of the thing.)

• The Web has suffered bloating
• This page, therefore, is simple:
• All that's involved here is a de novo language that was created in such a way that this page has to be generated from a separate, canonical source file written in that format

This is silly set of statements to make in series.

Just make the published form of this document the canonical representation—treat it as suitable for reading and editing alike (since it is).

A similar mistake is being made here as the one that precedes the reminder that there is no such thing as a fast programming language—only a given implementation can be called fast.

There's a weird (read: "weirdly obvious") category error here. NodeJS is not a language. (This wouldn't be so notable if the comment didn't go on to say "The key point is writing to an interface and not an implementation.")

The puzzle piece that fits the shape of the hole here is "JS". JS is the language, NodeJS is one of its implementations—and chubot knew both of these things already, so it's odd that it was expressed this way. Plus, there's a lot more diversity of JS implementations than exist for e.g. Python...

I don't see how avoiding Python "will just make your site worse"—whether right now, or ever. Is there supposed to be something inevitable about Python?

I'm having trouble parsing this.

Suppose that instead of shell commands, the snippets were JS, and the README, rather than being named README.markdown or README.txt, were actually named e.g. README.txt.htm. it wouldn't be basically like an executable README—it would actually be executable. You could double click it to open, and then read through it and use it to actually do the stuff that the README is documenting (like build the project in question).

See https://discuss.write.as/t/only-30-users-listed-in-users/6317 ("My site has 37 users now, but only 30 users are displayed[...]"; later: "Well. the 2nd page displayed when users got 60").

Huh? Modules are ES6 aka ES2015.

Even most ostensible FP practitioners who swear they don't.

Walter Bright described similar issues with the Digital Mars compiler in a recent NWCPP talk "Adding Modules to C in 10 Lines of Code", albeit Walter's compiler sounds like it was far easier to fix.

It's funny that this happens with compilers. Wirth's Oberon compiler (module ORP) also depends on static state. But compilers seem natural to me to be something that you want to allow multiple instances of—it's not even among the list of things I'd expect people to make excuses for (cf https://kentonshouse.com/singletons).

RSS may not have been "designed to work with comments in mind", but Atom supports them: https://www.xml.com/pub/a/2004/06/16/dive.html

This is an excellent property. It's not a weakness.

• https://www.object-oriented-security.org/lets-argue/singletons
• https://dl.acm.org/doi/pdf/10.1145/62084.62095
• https://gbracha.blogspot.com/2008/02/cutting-out-static.html
• http://www.erights.org/

Worth noting that almost every C program is impaired by a similar limitation in the C language (despite the disclaimer that follows this passage about the use of the preproccessor), and many programmers' thought processes suffer because of it—no consideration for the presentability of code (even when not in languages that are affected by this limitation!)

This is a 404.

That's bug 442099, comment 19, i.e. trying to substantiate the opinionated claim that "an operator at the front" is better for human factors.

The problem of multiple import forms plagues ECMAScript today. Additionally the lack of "immediate" visibility of "where an imported identifier was declared" continues to plague Golang, to an extent even worse than described here for Modula-2 (because at least when you're iteratively jumping through the file with naive text search, you'll eventually reach the Modula-2 import statement, even though it involves wrapping around after reaching the bottom). It's explicit at some point. With Golang, on the other hand, having not been sufficiently wounded by the problems of C, the team designed it such that it has magical name resolution, making it tedious to carry out (as a human) the process that the compiler uses.

the problem with Golang that I described

Dissent: On Understanding Data Abstraction, Revisited

This is the dirty secret of the neo-OSS era—that it's mostly devops shovelware (to a degree that makes it look like Sturgeon was being conservative)

But having commit access and the having ability to fiddle with bugs are two orthogonal sets of privileges...

Surprise: going all in on GitHub—including abandoning traditional practices governing bugtrackers in favor of GitHub's anemic project management tools—has a negative impact.

What even is a locked wiki insofar as the ways it differs from traditional (pre-wiki) content publishing pipelines? Where's the wiki part of it?

Wirth pithily makes some of the same points in his HOPL III paper on the history of Modula-2 and Oberon

Related: much of functional programming is not even functional. Closures end up doing a lot of heavy lifting, despite being at odds with what FP claims to be.

There's a lot to be gained by reflecting on pre-Web paradigms and hewing to similar approaches—electing to be bound by the constraints. Print is a discipline, and the practices surrounding the print-based publishing industry comprises a form of technology itself.

Related: lineality is a virtue.

Another PDF from CERN, but this one what looks like a PDF of the original as a first-class digital document, i.e., not a scan of a paper copy: https://cds.cern.ch/record/369245/files/dd-89-001.pdf

This looks like a PDF created from the RTF version described at https://www.w3.org/History/1989/proposal.html

I'm not sure the argument of chilling effect holds up in light of the high price. A high-priced incumbent should be easier to dislodge than one priced reasonably.

gross

Readable how? I think the better approach over what we do now, where we run source code through what are essentially compilers for making websites and then treat the output similar to object files—i.e. opaque blobs that are unsuitable for anything other than either (a) executing/experiencing, or (b) publishing to others—would be to pursue non-destructive compilation. So after the Markdown is compiled (if there is any compilation step at all), you don't have to keep the original sources around. The tooling should be sufficiently advanced to work with the publishable form as input, too, and not demand only Markdown. In instances where the Markdown files are kept around because the spartan experience of opening a plain text file where the content is almost entirely unadorned by formatting concerns is the preferred way to get things done, the tooling should be able to derive the original Markdown (or a good enough rendition) from the output itself. HTML is rich enough to be able to encode the necessary structure for this on the first Markdown-to-HTML pass. Systems that implement this kind of thing could be said to support a sort of "reversible Markdown", making the publishable form a suitable source of truth—a treatment that is right now reserved only for the originals that are collected and kept off-site.

Make the writing and editing experience more like Word or Google Docs and less like LaTeX.

Another solution, in two steps:

1. make your SOPs executable
2. give them a promotion; make them first-class content (they should live on the site that you're publishing—although not necessarily front-and-center—not hidden away in the README of some ghost repo)

See also: A New Publishing Discipline.

Mentioned above; also:

https://tomcritchlow.com/2022/04/27/triple-entry-blogging/

From a former Mozillian's perspective, Mozilla would be a terrible steward for this. They would be a terrible steward now, and they'd have been a terrible steward in 2018.

Sounds like write.as.

Did this require a new term ("hollow man")? Isn't "ad hominem" sufficient?

Think about the irony of this.

See also: "Avoid using language extensions and libraries that do not play well[...] without an IDE"

What always gets me when people bring this up is that none of those repeating it ever seem to have thought of shamelessly copying the superior libraries they have in mind, rather than buying in to the purportedly lower quality system.

Should be able to separate storage balance and credits for servicing traffic.

I'm continually surprised when someone posts and HN fails to understand even very basic points in a piece of writing, even when they're very clearly made like they were here. PragmaticPulp's top comment (and the fact that is the top comment) is completely mystifying, for example.

Until those things go away.

A case study: DuckDuckHack used Codio, which "worked" until DDG decided to call it a wrap on accepting outside contributions. DDG stopped paying for Codio, and because of that, there was no longer an easy way to replicate the development environment—the DuckDuckHack repos remained available (still do), but you can't pop over into Codio and play around with it. Furthermore, because Codio had been functioning as a sort of crutch to paper over the shortcomings in the onboarding/startup process for DuckDuckHack, there was never any pressure to make sure that contributors could easily get up and running without access to a Codio-based development environment.

It's interesting that, no matter how many times cloud-based Web IDEs have been attempted and failed to displace traditional, local development, people keep getting suckered into it, despite the history of observable downsides.

What's also interesting is the conflation of two things:

1. software that works by treating the Web browser as a ubiquitous, reliable interpreter (in a way that neither /usr/local/bin/node nor /usr/bin/python3 are reliably ubiquitous)—NB: and running locally, just like Node or Python (or go build or make run or...)—and

2. the idea that development toolchains aiming for "zero configuration and setup" should defer to and depend upon the continued operation of third-party servers

That is, even though the Web browser is an attractive target for its consistency (in behavior and availability), most Web IDE advocates aren't actually leveraging its benefits—they still end up targeting (e.g.) /usr/local/bin/node and /usr/local/python3—except the executables in question are expected to run on some server(s) instead of the contributor's own machine. These browser-based IDEs aren't so browser-based after all, since they're just shelling out to some non-browser process (over RPC over HTTP). The "World Wide Wruntime" is relegated to merely interpreting the code for a thin client that handles its half of the transactions to/from said remote processes, which end up handling the bulk of the computing (even if that computing isn't heavyweight and/or the client code on its own is full of bloat, owing to the modern trends in Web design).

It's sort of crazy how common it is to encounter this "mental slippery slope": "We can lean on the Web browser, since it's available everywhere!" → "That involves offloading it to the cloud (because that's how you 'do' stuff for the browser, right?)".

So: want to see an actual boom in collaborative development spurred by zero-configuration dev environments? The prescription is straightforward: make all these tools truly run in the browser. The experience we should all be shooting for resemble something like this: Step 1: clone the repo Step 2: double click README.html Step 3: you're off to the races—because project upstream has given you all the tools you need to nurture your desire to contribute

You can also watch this space for more examples of the need for an alternative take on working to actually manage to achieve the promise of increased collaboration through friction-free (or at least friction-reduced) development: * https://hypothes.is/search?q=%22the+repo+is+the+IDE%22 * https://hypothes.is/search?q=%22builds+and+burdens%22

This presupposes something; is this step #1 or not? (In other words, "Where did those people come from?")

I see lots of handwaving on this part—which is silly, because for the people who are the main audience for pieces like this, this is the part that's most interesting. It's easy to see their frustration.

The thing I really admired about Chris Lattner in an interview I listened to during lockdown was the fact that (one of?) the first things he mentioned about success was the role that luck played in his life. There's a tacit admission there that, although he's Chris Lattner and a really smart guy and clearly deserving of his success because of the facts from our now-foregone past that serve as proof, if you reset and tried to "replay' it all, then things might not actually work out like they did the first time. It's a tacit admission that replicability is not guaranteed.

This polemic identifies CS as the culprit. That seems empirically wrong. As stated, it's "not a prerequisite for most programming" even in theory, and in practice, there are mountains of GitHub programmers, at least, who don't have CS backgrounds. Non-CS folks probably account for most of the "frontend"/"full stack" development today. This has exacerbated the Tower of Babel, not improved it.

HCI is CS—and that's what we should focus on. There's a fair bit of emphasis on engineering due, too. To be able to look at a problem and ask, "What should it take?" and ocnversely, "What isn't required here (contra cultural imperatives)?"

This is what people refer to when they say something was "ahead of its time".

Wait, what? At this point, I'm not sure these are accurately being scored against the given rubric.

Huh? Again—is it? I don't think I've seen anyone put Bootstrap to serious use and not use the preprocessed version.

These concerns also exist if you're using frameworks.

I also see people regard libraries like DOMPurify as magic. There is no magic. Even using these libraries, you have to know what you're doing; you have to make sure DOMPurify is configured correctly in order to carry out your intent. You can be just as vulnerable if you're not paying attention with a library as you are when using one.

Does it? Most jQuery is served minified. Even if not, the "full fat" version is not especially readable.

There are bad reasons to despise jQuery (e.g. because it's old). But there are good reasons, too (because it's bloated and just not very good).

See algorithmic languages.

Feels like Tales From The Loop-y era Simon Stålenhag. Previously.

@6:15

An engraving (as shown here) was published in at least one place with the caption "The Battle of Omdurman: The Defence of the Khalifa's Black Flag".

The watercolor(?) of this appeared in the 1898 September 24 print of The Graphic, on page 406. It is captioned "The Battle of Omdurman: The Fight for the Khalifa's Standard". It is signed "C. Hentschel", but attributed "Drawn by J. Gulich, R.I."

@8:02

This is "Return of the Grand Cordon of the Legion of Honour to the New Khedive of Egypt" by Henri Meyer, 1892. https://www.art.com/products/p55962177457-sa-i9361182/henri-meyer-return-of-the-grand-cordon-of-the-legion-of-honour-to-the-new-khedive-of-egypt-1892.htm

Git as He Is Poke(d)

I've come around to preferring the term "strawchild".

• It de-genders the term (important for some people)
• It evokes the imagery of the kind of loser* who is only willing to engage in battle with children and/or is perhaps prone to striking them
• It conveniently sidesteps the cliche/fatigue associated with invocations of the term "strawman"

* Is this aspect of "strawchild" an instance of failure to elevate the other (i.e. steelman/starman them)? Yes.

Used for https://github.com/judell/HelloWorldAnnotated.

See https://jonudell.info/h/HelloWorldAnnotated/gather.js

Good use case for an LP doc.

This I disagree with. Even Fielding's "... must be hypertext driven" rant (which is great and in my bookmarks) is sabotaged by the curse of knowledge. If you know what REST is—and how most "REST" isn't REST (including the things that try to stand out as doing REST right and still just doing it wrong, but with nuance) then "REST APIs must[...]" makes sense. If you don't already get it, though, then it's nigh impenetrable—funnily enough, you need an a priori understanding of REST to be able to understand these attempts to explain REST and what Fielding is trying to communicate about REST not requiring *a priori" knowledge!

What the re-education around REST needs is a catchy label for what people call REST that works well as a light pejorative. Two-Bit History gave it a shot, coining the ad hoc acronym "FIOH", but it doesn't have the desired properties.

Why the name, though?

@54:25:

There's this debate about whether those games are truly interactive, because there's no way to actually transcend the intent of the designer (other than with, like, glitches or that sort of thing)

They're talking about video games—"authored experience[s]"—but it's relevant of other types of games (boardgames, like chess), too.

cf Carse:

Finite players play within boundaries; infinite players play with boundaries

something something declarative effects

This is Corecursive #78: The History and Mystery of Eliza

@2:10

They didn't publish the code. They published the algorithm. And they prided themselves on—the computer scientists at the time—of describing the algorithm, not GitHubbing the code. These days we don't—we GitHub the code. You want the algorithm? Here's the code.

This is not always reliable. There are some non-highly-mathematical things that you'd prefer to have the algorithm explained rather than slog through the code, which is probably adulterated with hacks for e.g. platform gotchas, etc.

There is a better way, though, which is to publish a high-level description of the workings as runnable code that you can simulate in a Web browser. Too many people have misconceptions about the stability of the Web browser as a platform for simulations, however. We need to work on this.

This reads like a (fairly raw) transcript of a spoken-word interview. Hard to read.

too many "to"s; make this "for"

I'm surprised that this is the exemplar, and not the Allen–Gates relationship.

In fs.blog #129, Andreessen spends a bunch of time talking about this—probabilistic vs deterministic work

This approaches it backwards. Consider a TypeScript-free codebase where the type annotations live in the documentation—which isn't generated. Your "compiler" then is really just a program verifier. Given the JS program text and the availability of docs, it takes the fusion as input and runs the verifier on that. No source-to-source compilation or mangling. The code that runs is the code you write—not some intermediate file output by tsc.

See also http://cr.yp.to/qhasm/literature.html

See: Oberon

See also the discussion (in the comments) about optimization-after-the-fact in http://akkartik.name/post/mu-2019-2

@52:20

We know it will happen, barring some radical change in human psychology, because that is what we're living with now. Everyone is walking around with a smartphone in their pocket that not even the president of the United States could have gotten his hands on in, you know, the year 2000. It's pure science fiction. And yet now it's just a basic necessity of life [...] we reset to the new level, and again, we keep comparing ourselves to others

There's a submarine counterargument to the overall point here (and the last half of the sentence quoted here), and it lies in the words "necessity" and "new level". (I realize that when it was spoken, "necessity" was chosen for effect and meant as a slight exaggeration, but it's not as exaggerated as it would need to be in order to erase the force behind of the counterargument.)

In other discussions like these, you can often find people bringing up the argument that Keynes's remark about 15-hour work weeks wasn't wrong, provided that you're willing to accept the standards of living that existed at the time when Keynes was saying it. But that's not exactly true, because it doesn't really ever come down to a true choice of deciding whether you'd like to opt in or not.

You could take the argument about smartphones and make the same one by swapping out automobiles instead. The problem is that even if you did desire to opt out of the higher standards, the difficulty lies in the fact that the society that exists around you will re-orient itself such that access to a car is a baked-in requirement—because it's taken as a given in others' own lives, it gets absorbed into their baseline of what affordances they expect to be available to people who are not them ("new level"). This continual creation of new requirements ("necessities") is the other culprit in the pair that never gets talked about in these conversations. Everyone focuses on the personal happiness and satisfaction component wrt comparison to others.

Surprise! The point of technology is that it's supposed to make things easier. Why not make sure it's easy to make things easy while you're at it?

@3:07:14:

Blow: A lot of time I get a lot of questions these days by people who are asking, "How do you do a lot of work?", or, "How do you get started?" and all that. And very often these questions are themselves a procrastination, right? It's like, "Obviously, I'm in the state where I can't do a lot of work right now. So I need somebody to give me the answer before I can." And actually the secret is you sit down and decide to do it. That's all it is, right?

Jaimungal: Seinfeld is like that. That's his famous advice to comics, to comedians.

Blow: Mmm. Yeah. I mean—

Jaimungal: Comedians always want to know what's the secret. He says, "Just work. Stop talking about it."

Blow: Yeah. [...] Because that's an exc— it's like, "Oh, someday— I have permission to not actually do this work until someday somebody bestows upon me the magical[...] baton[...]"

@03:06:54:

Blow: I mean I have a whole speech about that that I can link you to as well.

Should that be necessary? "Links" (URLs) are just a mechanical way to follow a citation to the source. So to "link you" to it is as easy as giving it a name and then saying that name. In this case, the names are URLs. Naming things is said to be hard, but it's (probably) not as hard as advertised. It turns out that the hard part is getting people to actually do it.

The actual phrasing here (@39:03):

maybe people today are more complacent about emergencies because at some implicit level they see there's more division of labor and they think someone will come along and save the day

(No idea what's up with the transcript here. It omits some crucial wording/context.)

@18:08:

The interesting thing is when you read, say, extremely foreign fiction—so fiction that's very alien to you in terms of mental models—the author may assume you understand the mental models, but you may not. So for example Japanese comic books—the couple of times I've tried to read them, they just feel so bizarre to me—the sort of conventions for indicating, you know, emotions and actions and so forth. They're just so unintuitive to me that the world[...] that should be in the background and implicit and I should just be able to reference it like an operating system, it sort of becomes a little too visible for me to read the fiction seamlessly.

This is The Knowledge Project Ep. #7 — Venkatesh Rao: The Three Types of Decision Makers

@47:58 audible gasps at the mention of standards

@37:52:

Again, when I was traveling around in 2004 giving talks, the predominant attitude I had was a misconception about Darwinian processes that—most people I talked to thought that we must be at the best place that we could be because look at how many millions of people are participating in this thing. And if you know about Darwinian processes, they aren't optimizers at all. They're "satisficers"—a term made up by one of the most famous professors ever to be at Carnegie—and satisficing is not the same as designing something great.

@18:09:

So the real question is not whether we can improve on this but "what is the actual level of improvement?", which is tantamount to asking, "how complex is the actual problems we're trying to solve compared to the complexity we're creating by just bumbling around?"

One thing that I didn't hear considered is to kill modelessness by allowing selection anytime. If you want to select something, then just draw the shape that you want using whatever tool you already have, and then invoke some action that transforms it after the fact.

This falls in line with the principle of preferring to make it easy to undo something rather than making it difficult to do in the first place.

The relevant analogy is that if you were in your office in dialogue with someone and you had a printout of your WIP, then in order to communicate your intent, the most likely course of action would be to mark up the work in its current state using whatever tool is handy, explaining what it is you want to happen, passing it to your partner in dialogue, and then trust that they'll return to the source and get to it wrt to carrying out your desire.

This is Metamuse Episode 1: Tool-switching

The thing that bugs me when I listen to the Muse podcast—it's something that's present here along with the episode with gklitt—is that there's this overarching suggestion that the solution to this is elusive or that there are platform constraints (especially re the Web) that keep any of these things from being made. But lots of what gets talked about here is possible today, it's just that no one's doing it, because the software development practices that have captured the attention of e.g. GitHub and Programmer Twitter value things that go against the grain of these desires. This is especially obvious in the parts that mention dealing with files. You could write your Web app to do that. So go do it! Even where problems exist, like with mobile OSes (esp. iOS), there're things like remoteStorage. Think remoteStorage sucks? Fine! Go embrace and extend it and make it work. It's not actually a technical problem at this point.

@18:52:

I wanna also dig a little more into the kind of... dynamism, ease-of-making-changes thing, because I think there's actually two ways to look at the ease of making changes when you solve a problem with software. One way is to make software sufficiency sophisticated so that you can swap any arbitrary part out and you can keep making changes. The other is to make the software so simple that it's easy to rewrite and you can just rewrite it when the constraints change.

@14:18:

So, for example, if you want to make a very basic static site: well, okay, now you need the static site generator, and now you need a library system, you need a package manager, you need a way to install the package manager, you need a way to check for security vulnerabilities in all the packages, you need a web server, you need a place to run the app. It's a whole thing, right?

This is Metamuse Episode 42: Self-made tools with Linus Lee

No, it still makes sense.

Insisting that everyone use === everywhere, on the other hands, makes as much sense as disallowing method declarations that accept a parameter that implements an interface (in favor of formal parameters that insist on a certain class or a derivative), or injecting a bunch of instanceof checks for no good reason...

Stupid myth.

I've mentioned this elsewhere, but I'm skeptical of this popularly recurring take that says writing is thinking, or that thinking without writing really isn't thinking. If writing helps you think, it's better for you to know that than the alternative. But thinking is thinking, and writing is writing.

I worry with all the insistence around this view of writing as a precondition to real thinking that people who are thinking at or near capacity without writing will believe they're somehow missing something and waste a lot of cycles in frustration as they attempt to write and find that it doesn't do anything for them thoughtwise that they weren't already getting before.

I'm not sure that's the correct diagnosis.

Alternative take: you were not, at that point in your life, equipped to understand that you could be generating new ideas and that you should walk away from that writing course with an appreciation for writing as a vehicle for what you'd like to accomplish with a given subject/format. It's fine that you didn't—many people don't—and your instructors, institution, parents, community, etc. probably could have done a better job at communicating this to you, but it was there, and it was the point all along.

The presence of an itemtype attribute should imply the existence of an item, and thus make the presence of itemscope optional—itemscope should be required only when there is no explicit itemtype declared.

Wait, really? That's unfortunate. It seems plainly useful to be able in e.g. the datetime example to correlate the text content of the element with the datetime property with the datetime value.

There is no inherent virtue in insisting that paths continue to use backslash even though we're well past the days of CP/M and DOS. There are good reasons not to use it, however.

I do recognize that it provides a source of the type of obscurantism that Windows users take delight in. At this point, though, backslash-as-path-separator is a liability, and application authors should work to eradicate it from every UI surface that users come in contact with. Microsoft themselves should scrub their own apps so that e.g. even Windows Explorer favors the common solidus in any displayed path name.

Consider this to be a straw proposal for an "are we slash yet?" movement.

Suppose these were inverted.

What does this mean?

I think this satisfies the threshold of "minimum viable publication". So write this up and reference it here.

Full impl.:

getLineStart(tokenPosition, anteTerminators = null) {
  if (tokenPosition > this._edge && tokenPosition != this.length) {
    throw new Error("random access too far out"); // XXX
  }

  // NB: Since line terminators can be the multibyte CRLF sequence, care
  // must be taken to ensure we work for calls where `tokenPosition` is some
  // start minus 1, where that "start" is some line start itself.
  for (let i = this._lineTerminators.length - 1; i >= 0; --i) {
    let current = this._lineTerminators[i];
    if (tokenPosition >= current.position + current.content.length) {
      if (anteTerminators) {
        anteTerminators.push(...this._lineTerminators.slice(0, i));
      }
      return current.position + current.content.length;
    }
  }

  return 0;
}

(Inlined for posterity, since this comes from an uncommitted working directory.)

See also: wikis[1] vs anti-wikis

1. https://www.colbyrussell.com/2020/05/13/psa-wikis.html

Previously: Open Source Is Not Enough and Free software is not enough: on practical user freedom.

See also: "Even GNU's philosophy has a few puzzle pieces missing from the box."

This directly contradicts the earlier claim that irreducible complexity is the culprit behind the size of the node_modules directory.

35 MB → "a couple hundred kilobytes"? Clear evidence of not just reducibility but a case of actual reduction...

the illusion of preference-revealing actions

Imagine if this were just the format that the source document itself used...

It's worth introspecting on why any given person might hesitate to feel that they can commit. This is almost always comes down to "maintainability"—websites are, like many computer-based endeavors, thought of as projects that have to be maintained. This is a failure of the native Web formats to appreciably make inroads as a viable alternative to traditional document formats like PDF and Word's .doc/.docx (or even the ODF black sheep). Many people involved with Web tech have difficulty themselves conceptualizing Web documents in these terms, which is unfortunate.

If you can be confident that you can, today, bang out something in LibreOffice, optionally export to PDF, and then dump the result at a stable URL, then you should feel similarly confident about HTML. Too many people have mental guardrails preventing them from grappling with the relevant tech in this way.

I've noted elsewhere that NearlyFreeSpeech.Net has a billing system where anyone can deposit funds for a hosted account. That still leaves the matter of dealing with breakage, but for static sites, it should work more or less as if on autopilot. In theory, the author could die and the content would remain accessible for decades (or so long as fans have the account ID and are willing to continue to add funds to it), assuming the original registrant is also hosting their domain there and have auto-renewal turned on.

As above, I think this is more a consequence of struggling against the nature of the specific publishing pipelines that most people opt for. Many (most) Web-focused tech stacks are not well-suited to fulfill the original vision of the Web, but people select them as the foundation for their sites, anyway.

Bad example. The way most GitHub-adjacent subjects are handled and the overheads involved is already evidence that most people are not interested in operational efficiency, let alone measuring it to figure out how to do it better.

It's very hard to take this seriously from someone who's main endeavor is making video games. Essentially every CPU cycle ever spent running a game was superfluous.

dubious

nebulous

This is as good an example as any of why I'm not a fan of Casey Muratori.

I'm 25% of the way through this video (a "lecture")—10+ whole minutes—and he's hasn't said anything insightful or of any substance whatsoever. He certainly communicates that he has strong opinions, and expresses them (I guess?) in a very emphatic way, but holy shit, dude. What is your point? Say something that makes sense. Hell, just say anything at all.

Good use case for the application of the principles in A New Publishing Discipline.