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.

This is sort of a failing of the code-as-content thing that we're going for here. Take a page from GPE.

Okay, so the original source seems to be Proteus (A Journal of Ideas). ~~Specifically, vol. 3, iss. 1.~~ (Thanks to Nikos Katsikis by way of Neil Brenner for helping track this down.)

Also available here under the alternate title "Livingry" from BFI: https://www.bfi.org/about-fuller/big-ideas/livingry/

This whole piece is filled with this, but this story in particular comes across strongly as "I'm happy to impose my habits upon you." It's obnoxious.

This is fatalistic thinking.

Here's what both implementations and debuggers can do together: 1. implementations can document these things 2. debuggers can read the documentation and act accordingly

hammers, nails

Right. Leading to such questions as, "If you're putting all this effort in just to get things wrong and ending up with something that's worse than what you get for free—worse than just doing nothing at all—then what is your actual contribution?"

I've had conversations where I had to walk other people through why garbage collection doesn't mean that memory use is automatically a solved problem—that you still have to be conscious of how your application uses memory and esp. of the ownership graph. They were fully under the illusion that steady growth of memory was just a non-issue, an impossibility in the world of garbage collectors.

not just immediate, but standard

What the linked piece is not: an analysis of the web dev's self-interested perspective on fairness, economic balance, and the implicit societal mandate for their skillset/work product (and the associated subsidies they benefit from and fight to maintain).

an impedance mismatch, between what the Web is (infrastructure for building information services that follow the reference desk model—request a document, and the librarian will come back with it) versus what many Web developers want to be (traditional app developers—specifically, self-styled product designers with near 100% autonomy and creative control over the "experience")—and therefore what they want the Web browser to be (the vehicle that makes that possible, with as little effort as possible on the end of the designer–developer)

need for cheaper throwaway tests

A strength of boring tech that relies on the traditional folders-of-files approach, incl. e.g. the byproducts of using office suites.

That doesn't describe anything. It's a grid of GitHub avatars. What am I supposed to be seeing?

In other words, singletons are harmful.

In saner bugtrackers like e.g. Bugzilla the community is empowered to step in and triage bugs. GitHub infamously chose to go for a "simpler" system with fewer frills, pomp, and circumstance. Perversely, this has the opposite of the intended effect. The net result is that for the community to have these powers, the project owner has to explicitly grant them to individual users, which is considered to be a lot more heavyhanded/ceremonial than how it works on bugzilla.mozilla.org.

I'd have no problem, for example, stepping in and enforcing these things if it weren't the case that it were such a chore to go through the ceremony and getting approval to police this kind of stuff. GitHub's lackluster approach to user privacy, of course, doesn't help.

Signal trades on some other stuff of dubious* merit, like the "guarantees" of SGX, and does other user-hostile stuff: requiring a PIN, doing user data backups without permission, locking out third-party clients... (What's worse is that the latter is excused as being the only way to reliably enable the undesirable "enhancements").

* Even calling it merely "dubious" here is pretty generous.

Nice turn of phrase.

This was tired the second time it occurred in this piece. Three times is def. too much.

Not a fan of this piece, overall.

Cryptocoin hype/scams are dumb. Who cares.

See also, from Brooke Allen's "How to hire good people instead of nice people" https://brookeallen.com/2015/01/14/how-to-hire-good-people-instead-of-nice-people/:

I won’t get between you and your dreams. If you have a dream, I need to know what it is so we can figure out if this job gets you closer. If you don’t have a dream then that’s fine, as long as you really want one and you’re not addicted to wishing and complaining.

Also available here (as a scanned PDF; original source unclear): https://designsciencelab.com/resources/HumanitysPath_BF.pdf

I can't parse this. Ravasio says any typo is probably her fault. The best I can come up with is "an enormous amount of energy", which doesn't make sense as a typo, but does sort of sound the same.

I don't think this is a good definition. The example, at least, is a bad one. That resource could still exist (the same way a .docx that lives in the Documents directory and has been uploaded but later had the file host go down would still exist)—it just wouldn't be resolvable by URL.

I don't think this is a good example. I'd call it bad, even. It's self-defeating.

This page is excellent for an example of HTML being an adequate substitute for traditional office formats.

Yeah, why has this become so normalized? It's gotten to the point where people will respond to something by posting nothing but an attempt at false attribution by rewording the other—typically in the most convenient, pithy, hackneyed, and strawmannish way—and then putting quotes around it while drowning in plaudits from those who already agree—often for reasons no better than shameless tribal affiliation.

The basic precondition to summarizing the other's position in order to refute it is that the other side actually agrees that it's an accurate summary of their position. If you don't have that, then you don't have anything.

Yes, those are the questions for people interested in pieces like this one. What are the answers?

Not really. https://web.archive.org/web/20150828195814/http://adamspitz.com/avocado/2011/05/05/open-source-is-not-enough/

What's with the Americanized punctuation style here?

Change my view: Hypothesis is suitable for this.

Here's one: suppose Alice reads a book and adds it to her library then learns through this system that Tom, Dick, and Mary have it in their libraries, too. Thing is, Tom finished reading it 6 weeks ago, Dick read it last summer, and Mary read it 12 years ago as an undergrad. Would this be a good reading group?

As a sort of "gutter bumper" approach, guiding you on what is and isn't accepted in the language, they're nice, but I can imagine as a child that it would have annoyed me when I wanted to express something and found that the "only" reason why I couldn't follow through on something was because they made something the wrong shape, keeping me from doing the thing, and not understanding.

Contrast this with the remark below about pattern languages being "a set of design rules that loosely define how a system should work, rather than a strict specification".

https://hypothes.is/a/QtqfWujBEey_TWdqwW7yQw

Turtles are reptiles.

Is "layer" the right choice here?

NB: this is culture-specfic

NB: these two metaphors are at odds. You can see this in the way that authors treat user agent overlays as intrusions into their space—a place for them to control, instead of e.g. a note clipped to the copy that belongs to the reader.

The owned-space one is definitely worse, but I fear that for many people it's now the default—for both those seeking control and those who are the indirect objects of control.

I don't know if this is true for anyone. It certainly seems like most people who are digital natives (or immigrants) rarely make the connection and end up missing out on some lessons from print that would actually be helpful.

This pie in the sky has been promised for the last 10+ years. It's not happening.

A lot of these ideas are junk. This one, though, is achievable. triplescripts.org.

ALGOL 2020

Fun fact: the amount of time between 2010—the year Dahl mentions here—and ES2015—aka ES6, where modules appeared—is less than the amount of time between ES2015 and today. And yet people act like modules are new (or worse, just over the horizon, but still not here). It's a people problem.

This is misleading/hyperbolic. The performance characteristics of WASM vs JS are nothing like a native binary vs the Bash interpreter.

See also: The Pinocchio Problem

Some incarnation of the Fly Pentop/Livescribe focused on this.

See also; plugging these: * A new publishing discipline * plain.txt.htm (An assembler)

The fact that the author is describing it in these terms is really evidence that the main achievement here is overcoming the limitations of his or her own mental blocks.

This is an excellent piece, even though the writing is (probably intentionally) in places too obscure.

Ibid

Probably not the best descriptor, owing to domain collision. Almost anything else would be better, e.g. "Gallery".

Dear Wanderer:

You're looking for http://pascal.hansotten.com/uploads/ucsd/ucsd/Richard%20Kaufmann%20-%20What%20The%20Heck%20Was%20UCSD%20Pascal.pdf

Also available on Vimeo https://vimeo.com/127605643

@5:50:

In this portion of the machine, we keep these brass matrices.

Throughout, "matrices" can be heard to be pronounced as "mattresses". Could this have something to do with the origin of the phrase "going to the mattresses"? It seems more likely than the conventional explanation that involves safehouses and literal mattresses, which strikes me as really dubious.

Compare "capicola" → "gabagool".

NB: I'm pretty sure this is referring to fact that the site was live, and it had open registration. The source code was not being worked on in the "open", even under lax definitions of that word.

Is "automated deployments" really the solution?