how important is the concrete syntax of their language in contrast to the abstract concepts behind them what I mean they say can someone somewhat awkward concrete syntax be an obstacle when it comes to the acceptance

That's a you-problem. The pieces are there—the language is stable, and there's a ludicrously backwards compatible World Wide Wruntime that you can trust to be around—it's on you if it fails.

It's not. It's a document markup language.

Most Web developers, however—going back to 1999 and before—certainly treat it like it's a display technology.

We have that. It's the Web platform. The hard part is getting people to admit this, and then getting them to actually stop acting counter to these interests. Sometimes that involves getting them to admit that their preferred software stack (and their devotion to it) is the problem, and it's not going to just fix itself.

See also: Lorie and the UVC

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

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)

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.

People are so quick to point out the lack of interest for people (and programmers, esp.) to pay for software. If this were distributed as HTML, maybe a way to hack around this unfortunate cognitive hangup would be to frame it as If you're buying an ebook: the manual for the software. It just so happens that this manual can be interpreted by a machine.