I think the developers-vs-non-developers framing here is off, because in my experience there is either no correlation or the of the correlation that exists, programmers are more sensitive to things being needlessly complicated—which would make sense given that "mechanical sympathy" is a significant factor in a lot of programmers' footing, and programmers are more wont to look at something, say to themselves, "This is stupid. I'm going to fix it," and then do so—compared to the average person who is not accustomed to their environment having the malleability of software.

This does not follow.

This "missing stairstep" analogy is appropriate here, though that metaphor is most commonly associated with a very specific type of problem involving guys who are creeps.

As it relates to the broader context of technology that this piece situates this anecdote within, it could be considered a form of implicit step zero or an analogy for developer tunnel vision.

@ryanwwest it does, actually. I frequently (have to) resort to saving a page in Firefox to my computer so that I can circumvent the Content Security Policy headers that an author/publisher has applied to their pages, since the Hypothesis bookmarklet won't load otherwise.

I'm sympathetic to the overall point and the comments that led up to this piece (perversely enough), but I find this in particular to be terribly unpersuasive.

For a person who has a point to make, the answer this question should be, "Who cares?" A focus group might find that that no matter how ways you try to workshop a given piece, it still does worse than posting a blueberry pie recipe. That doesn't mean you should post a blueberry pie recipe instead.

RSS isn't "just like [how] you can subscribe to podcasts". It is what let's you subscribe to podcasts. A podcast feed is an RSS feed.

Whether something has (or has not) been "met with general agreement": great turn of phrase; artfully put

Mm, "inherent"? No. They don't need to be...

/r/SelfAwarewolves

No, the NPM world and the entire "bundler" ecosystem is broken.

NPM: how not to do JS.

Yeah, well, shockingly enough, global ("top-level") variables are bad. Who knew!

NB: robertknight.me.uk is not rknight.me, though Robb Knight (of rknight.me) is both rknightuk and Robb Lewis (i.e. rmlewisuk/robblewis.me).

Confusing!

Hey, traveller:

You are looking for https://datatracker.ietf.org/doc/draft-connolly-w3c-accessible-registries/

Any system where knowing the True Name of a document is tantamount to having control/privileges is fundamentally broken, full stop.

This is:

Franz, Michael. 1994. “Technological Steps toward a Software Component Industry.” In Proceedings of the International Conference on Programming Languages and System Architectures, edited by Jürg Gutknecht, vol. 782, edited by Gerhard Goos and Juris Hartmanis. Lecture Notes in Computer Science. Springer. https://doi.org/10.1007/3-540-57840-4_36.

This is:

Fröhlich, Peter, and Michael Franz. 2000. “Stand-Alone Messages: A Step Towards Component-Oriented Programming Languages.” Proceedings of the Joint Modular Languages Conference on Modular Programming Languages, JMLC ’00, September 6, 90–103. https://doi.org/10.1007/10722581_9.

Wirth and Reiser make (I think) a similar use of the terms "open" and "closed" in "Programming in Oberon", 1992.

This may explain the way that Rochus used the same terms in his comment(s) on HN, but this needs to be investigated. The latter is certainly at odds with what "open" and "closed" were being used to refer to* in the comment he was responding to.

* (by analogy invoking Brad Cox's explanation early in his OO book)

There's an interesting juxtaposition here between the recognition of the value/utility related to the low-barrier-to-entry for using "doorless" apps while at the same time gating feedback/changes behind "submit a Pull Request [on GitHub]".

(As an alternative, 5apps deploy has a feedback widget that any app hosted there can opt in to allow users to submit frictionless feedback.)

Imagine if people just figured out how to practice source control...

This is borrowed from a passage in The Programming Task Considered as an Intellectual Challenge (EWD273).

What's interesting about the earlier piece is that just a few paragraphs earlier, he discusses abstract data types some 4–5 years before the paper by Liskov and Zilles and then immediately shifts into riffing on something very close to the Liskov Substitution Principle well before the latter was coined.

One of the aforementioned weaknesses is here, where we're assuming that any object definition with the relevant properties won't have any key/value pair where the value is itself an object. Example:

{ "id":"foo", "bar": {"baz":true}, "title":"fum" }

The above definition will subvert the processor's expectations and thwart its behavior, owing to the nested object definition associated with bar. This is a consequence of the shape of the JSON.parse reviver API/contract and that the processor is using a shared, mutable currentSourceGroup instead of doing something more involved with the result of Object.keys for an object-valued pair.

Shouldn't the use of Google Drive, Dropbox, etc. be completely encapsulated, so remoteStorage.js presents it as an option to the user—every user—without the app needing to do anything extra? The idea would be that there is a centralized-but-community-owned "app" that installs a ServiceWorker that fields requests from the rs.js client and translates them into (properly scoped) reads and writes.

(If the user wishes to use an alternative worker script, then he or she can register his or her own hosted version, and the community-owned instance delegates requests to it.)

He did. He made aboutfeeds.com.

One thing that bugs me about home-built homepages using static site generators as a consume is that the authors have to choose to have RSS, whereas when I find a good blog that's been around for awhile and it's hosted on WordPress, I can reliably pull in not just the most recent items but a copy of the entire backlog of posts into my feed reader.

This passage is quoted in Bowen's "Faster Than Thought".

Of course they don't. Go, Rust, and Zig are programming languages. Programming languages are neither fast nor slow. They're languages. They're inert. The author is conflating programming languages with compilers (or, really, compiler output), i.e. programming language implementations.

suggested wording: "but this is not strictly necessary for the @render trick to work. Go ahead and use the same trick in any of your application's existing, ad hoc JSON-based formats—or with the inputs to other apps that you use (assuming they don't cause a fuss when encountering unexpected property keys)."

This was actually a good, thoughtfully designed feature by Microsoft. We have picture-in-picture controls for HTML video now, but we need more of this sort of thing. We've gone way too long for browsers to still have such bad support for tables, to give one example.

This is:

Chisnall, David. 2012. “A New Objective-C Runtime: From Research to Production.” Communications of the ACM 55 (9): 44–47. https://doi.org/10.1145/2330667.2330682.

See also:

Callaú, Oscar, Romain Robbes, Éric Tanter, and David Röthlisberger. 2011. “How Developers Use the Dynamic Features of Programming Languages: The Case of Smalltalk.” Proceedings of the 8th Working Conference on Mining Software Repositories, May 21, 23–32. https://doi.org/10.1145/1985441.1985448.

This was a generous share.

Side note: I've had an unwritten draft post kicking around for a while (a few(?) years) under the title "Forms are forms"—with the idea being that the name of the HTML form element wasn't chosen arbitrarily. They have an analog in the, uh, analog world: forms. Like the ones printed on paper, and that you fill out (however and wherever you want), and then turn over to whomever is intended to process it. It's an accident (injustice?) of history that we started treating HTML forms differently.

In a more perfect world, the snippet shared here would be able to use the Stripe SDK to prepare an offline collection comprising an eventual form submission. You would then be able to load that collection into your favorite user agent (think: Postman, but for real humans, not people paid to shuttle JSON between endpoint to endpoint), which would then issue the requests and format/capture the output for your review.

That seems rather more a problem of the "stateless" environments...

That it's impossible to "program well" in units of an hour probably is wrong. But that's not the same thing as it being that case that doing things in units of an hour is no worse than if you had a larger block of time.

I'd bet a lot on it being possible to show that 3 hours of uninterrupted time (that you're able to know about and be prepared for in advance, e.g. because it's routine) is more than 3 times as productive as a single hour and more than 1x the productivity of 3 one-hour sessions (especially if those one-hour time blocks are not a recurrence of a predictable, daily routine).

It strikes me as odd to use GCC as the basis for comparison since (as I understand it) Fil-C++ is based on LLVM.

This raises an interesting question: must they?

Suppose instead of patterns or patterns-turned-to-components (libraries/dependencies) that Arnout lays out, we instead took an approach to component re-use where packages are authored rather to be dev dependencies (in NPM parlance) rather than ordinary dependencies. Modules would neither be dynamically loaded nor statically treeshaken-and-bundled, but rather a module/class would be annotated with an interface, and the dev dependency would (a) carry the implementation payload and (b) be responsible for analyzing the classes that are expecting to implement such pattern and then modify the source files of a conforming consumer in-place to provide the necessary method/property implementations.

The observer pattern would be a good use case.

It should go without saying that these are made-up numbers that the author just created out of nowhere.

How does that compare to Rust?

This unfortunately accounts for a lot of the projects that even the author here has probably given his endorsement.

The build process for most programs is basically unjustifiable if you rule out "this is just how building software works, and it's what you should expect to have to deal with" as a valid defense.

Rob Pike makes the argument that mouse use isn't actually all that inefficient.

There's a category error here. Many TUIs are actually GUIs that are limited to a brutalist set of drawing primitives—the ones compatible with terminal emulators. That's generally how the term is used, even if the expansion is literally "Text User Interface".

There's also the mistake here of conflating GUIs with the absence of keyboard accessibility. That need not be the case. There are plenty of GUI apps that are fully functional using just the keyboard...

I am aware that I'm "on the wrong side" of this in the way that Kesteloot describes—and I have been, even before I read his piece—but I'm totally divorced from the kind of customization fetishes that you see from the Vimmaxxing crowd, and I've become aware in the last year or so that there's a way that too narrow a focus can lead to misleading results in the same way that microbenchmarks can be (often are) not indicative of broader, macro-scale performance of real world applications.

Things that feel efficient can have measurable productivity gains elsewhere, even if they aren't actually all that efficient (or are objectively slower). Things that feel inefficient, even if they aren't, can be maddening and demoralizing, totally deflating one's will in the long run (over the course of an hour or a whole day), leading to faster exhaustion and a malaise that would have otherwise not been encountered.

Lawrence Kesteloot makes this point in his piece "Java for Everything".

(Aside: I’m on the wrong side of a different decision, the one to use vim for code editing. I feel very efficient when using vim, as code flies around the terminal, and I feel sluggish using Eclipse, and justify my choice with this efficiency argument. But surely all my gains are lost the first time I have to look up who calls a particular function, or when I have to look up the methods of an object manually. I recognize that I’m wrong on this one in the same way that dynamic language apologists are about their choice.)

(Side note: I suspect the author of this piece would disagree with Kesteloot's titular conclusion.)

The last word is important. This is a personality thing.

I remember being weirded out early on when crossing different online cultural contexts every time I strayed into an open source project where the folks on the bugtracker there couldn't handle the first part of the most common pattern for improving things: describing how a piece software currently does something that sucks, acknowledging that it could and should handle things differently, and then either writing the patch or indicating a willingness to accept one.

An uncanny number of personalities would get hung up on the "this sucks" part. I've even had people who consider themselves to be well-meaning but are otherwise uninvolved with the project and don't know that I'm the current maintainer appear in the comments and quarrel with me in response to a description I posted about some defect and/or a prescription—whether it's some UI interaction that I knowingly overlooked and failed to properly address in some earlier changeset and am documenting the this-sucksness of the current state of affairs or whether it's a bonafide regression I unknowingly introduced with some earlier fix.

Luis Villa also made the same connection in his 2016 LibrePlanet presentation:

https://lu.is/2016/03/free-as-in-my-libreplanet-2016-talk/

The Inner JSON effect

Wouldn't the prudent, top-down thing to do be replacing that "Hello world!" with harcoded markup comprising the homepage that you think you need the template engine for?

It doesn't if the team just replaced it with a Jira clone. But if the replacement is better than Jira, there are unaccounted for gains. The author is only considering one cost dimension.

What is this a reference to?

That's not a given.

It would be great to have a higher-order "token expressions" language that accepts productions for a context-free grammar (like the one in the Oberon language report) and an input string, and it would allow you to match on tokens and language constructs instead of just text.

Nope. You could just use the traditional approach where most tokenizers only have a generic tag/discriminant for all number tokens. The every-non-text-token-is-one-character constraint is arbitrary and unnecessary.

Turns out HTML is the most suitable cross-platform document format for desktop publishing, just like it's always been.

"de facto", not "canonical"

The motivation for this post may have been catalyzed by this Hacker News comment:

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

This is a category error. "Web" does not mean "HTTP(S)"; "Gopher" and "Gemini" are in fact part of the Web (subspaces).

A Web browser that exclusively browses Gopher- and/or Geminispace is still a Web browser (the same as a Web browser that exclusively supports HTTP(S) and eschews Gopher and Gemini and e.g. FTP).

GitHub always sucked.

This is simultaneously an understatement and overstatement.

The claim "They generally prefer to[…]" is probably too general and too strong a claim.

And the "prefer" part of the claim underemphasizes the truth, which is that it doesn't come down to mere preferences. It's done this way, by people who recognize it, because they recognize that it has to be done this way else it's either going to incur a tremendous penalty or it might not even reach "done" at all.

In today's dollars, it's cheaper at $27.99 rather than $43—but that's for a now-65-year-old work. The comparison is not the same.

Glass isn't a liquid.

Over the course of 2014, 2015, and 2016, I tried working with RMS to get him to patch things up with Miguel and issue a revised edict on the use of .NET and (ridiculously enough) the entirety of the C# programming language.

He hemmed and hawed and over the course of those conversations even suggested that Microsoft re-releasing .NET under the Apache license might not even be sufficient for him to retract the fatwa.

I suggest that someone take RMS's statement here as a mandate to declare that .NET is now hereby recognized by the FSF as sufficiently free, to prepare "GNU .NET Runtime", "GNU Mono" packages, and announce a victory for free software.

That's a stupid assumption.

Many computers that don't have a (pre-installed) Python distribution do have access to a (pre-installed) implementation of the World Wide Wruntime.

It would be logical to at least attempt to target it.

This is a loss (for semantics), not a win.

Classes aren't for CSS.

No you don't? It's explicit. The leftmost selector is written out.

It's actually the subsequent example using nesting that requires keeping track of what scope is applicable to a given selector based on its position relative to (inside) the parent scope with its own selector on a completely different line.

(This isn't to say that the latter is particularly hard, especially with the judicious application of whitespace and the curly braces providing assistance. But the alternative "older" style is not strictly worse to work with wrt the criteria cited. It's easier.)

Oh no! Not simple, readable CSS rules without nesting!

This isn't true. Most static site generators just have so little regard for UX that that's the only (or only reasonable) way to use them.

Self-modifying static site "generators" (incl. page builders) could and should be an entire thing, but it's the professional-developer class that's opposed to making that offering available to the public.

The general public also doesn't really give a shit about "CMSes". They don't care. They just want to update the website and be able to create new pages. It's the semi-technical folks whose brains have been tainted by déformation professionnelle that insist on CMSes as the (only) solution.

It wasn't, really. Those icons in the menus were well-known additions unique to Microsoft Office (read: deviations from platform conventions) at the time.

It doesn't naturally follow that by using WebAssembly, the ordinary WHATWG/W3C hypertext model will be broken.

The fact that these written-in-WebAssembly apps render to canvas is the problem here. If they were spitting out HTML (or the spiritual equivalent of draw calls/system calls that manipulat the document object model), then there would be no problem. Again, canvas is the problem.

No.

You don't? No, I do.

How could you not?

This is still the wrong way to do it. The right way to do it is to insulate your program from platform APIs entirely. It has the nice side benefit of making the code better, too.

A better solution still: have website authors just give users an offline copy to download (or throw onto a pod or static host under their control).

This is just "Using the Roku (ECP) APIs".

What an obnoxious title.

Kartik is right about the deficiency of most advice to address global complexity and make it legible/coherent. The only thing I've ever come across that does well at managing this is Lawrence Kesteloots dictum to write code top-down.

This ignores how much of the contents of "the user–maintainer feedback loop" in the GitHub era prior to the glut (infestation?) of LLM-generated pull requests were already low quality (often aimed at projects that were of dubious character to begin with—projects like Tailwind, cited here). Hashimoto et al just seemingly had a higher threshold for tolerance and have now found where their personal threshold is (or at least established an upper bound on its location).

Previously:

• Free Software Is Not Enough: On Practical User Freedom (2020)

• Open Source Is Not Enough (2011)

Sounds like something that could have been drastically simplified by just using bookmarks (but maybe iOS makes that painful, too).

Does it? It's not obvious from the problem and proposed approach described here that the homespun service doing the LLM work (or, rather, coordinating it) and the client submitting stuff to the third-party service need to be the same.

The client really only needs to authenticate with the service and ferry data into the account. The data can be prepped elsewhere. The only real constraint is that it comes from a trusted source.

It would be useful to reference specific parts of the HTML5 parsing algorithm here.

This is what happened with Bitwise University.

In 2018, I pleaded with Per when he announced the project to just take Wirth's Oberon, re-implementing it but change the lexer so it's a curly brace language, maybe changing the grammar in some other places so it's more comfortable for a C programmer, and only then consider adding a new backend (or, in hindsight, work on them in parallel—the point being to just fall back on the existing, already available, known-to-work implementation once it becomes apparent that doing a backend from scratch is hard). I.e., avoid the yak-shaving and get to the compiler-writing as soon as possible.

He decided not to, and the first substantial episode—"Day 2", the third stream—spent an hour faffing with a C implementation of "stretchy buffers" https://bitwise.handmade.network/episode/bitwise/bitwise002/

It's nice that this is a PURL (by virtue of the DOI system), but we can do better than this.

This is for:

Abramson, D.A. and Sosic, R. "Relative Debugging using Multiple Program Versions", Key Note Address, 8th Int. Symp. on Languages for Intensional Programming , Sydney, 3-5th May, 1995. In Intensional Programming I, World Scientific, ISBN 981-02-2400-1.

(From https://web.archive.org/web/19970504170226/https://www.cit.gu.edu.au/~davida/guard.html.)

Linked to archived paper: https://web.archive.org/web/19970504170226/https://www.cit.gu.edu.au/~davida/papers/islip.ps.Z

This is for:

Abramson, D.A. and Sosic, R. "A Debugging Tool for Software Evolution", CASE-95, 7th International Workshop on Computer-Aided Software Engineering, Toronto, Ontario, Canada, July 1995, pp 206 - 214. Also appeared in proceedings of 2nd Working Conference on Reverse Engineering, Toronto, Ontario, Canada, July 1995.

(From https://web.archive.org/web/19970504170226/https://www.cit.gu.edu.au/~davida/guard.html.)

Linked to archived paper: https://web.archive.org/web/19970504170226/https://www.cit.gu.edu.au/~davida/papers/case95.ps.Z

Hey, traveler. You're looking for https://www.cs.ucf.edu/~leavens/FoCBS/.

The voice associated with the narrator is so buffoonish in this piece, it reads like it was written by someone who found themselves in the role of the layperson and was deliberately (and a bit unfairly) caricaturizing the professional. But it's not.

The author comes across as really obnoxious, with no willingness to provide arguments/rationale to his hypothetical interlocutor, just vibes—very "That's just not how it's done."

It would be great if businesses and individuals took seriously the matter raised in this post, but the irony of this statement is that it doesn't align with what you generally find on independently created-and-run websites; getting the info unadorned is usually best found the big platforms, because Facebook, etc. control the site design, and the userbase has to contend with just providing the information. And even if you find, say, the visual design of a platform's look and feel to be unappealing, it is at least uniform.

The professional developer class strikes again, obscuring the fact that creating a website is just desktop publishing—document preparation with URLs—and not any more complicated than that (but for the fact that there's an entire industry of folks making it so in their own self-interest).

Still true now.

Great example of why "The Web" is really about, as TBL says, URLs, and not HTTP-and-HTML (and/or CSS, JS, etc., i.e. "WHATWG-flavored hypertext").

This is like how early works in math and physics don't use recognizable mathematical notation (because it didn't exist yet) and instead defined and described things prosaically.

Not surprising to see here. RFC 1738 hadn't happened yet.

Hey, traveller.

You're looking for https://www.w3.org/History/1992/ENRAP/Article_9202.pdf

samsquire is user chronological on the halfbakery.

HTTP at least has a provision for specifying URLs with Basic Auth credentials. It's interesting that sqlite's file-scheme URL parser didn't adopt an extension to the standard in that vein (RFC 8089 Appendix E, Section 1), instead of putting the key in the query string (which is another non-standard extension—not mentioned in the RFC at all).

Should be "apply".

Should be "copies".

Perversely, the quote here and emphasis in the content, is a fabrication.

Some observations:

• While it isn't easy, it is at least as easy as getting into a good school, and going to class and making good grades for four years. And with that said:

• Isn't this (the guarantee here—"guarantee"!) basically the same as the beliefs corresponding to the aforementioned bubble?

I think what Boodman failed to grasp at the time he first wrote this was that (b) many of those in his audience were persons who, having just invested four years into going to college with a reasonable expectation that it would pay off, weren't in a position (read: didn't have the resources) to suspend life for another 2-to-4 years trying to follow a plan like this (step #4 here—"Repeat[ing] steps 2 and 3 about 50 times"—is landing a patch to fix a new Chrome bug every two weeks) on the promise of an even more uncertain payoff, and—more perniciously—(b) a subset of those in his audience would have been those who were (more or less) already as capable as needed by the requirements of this process, but were in his audience nonetheless because, despite being so, it wasn't enough to "get them a good job" due to the stochastic nature of the market (incl. the fickle humans who are often gatekeepers in the "find a good job" process).

Elite overproduction

Another way of approaching the implementation versus abstraction issue when it comes to misconceptions about programming languages and their toolchains/runtimes is to make "[programming languages are notation, and] notation is not machinery" something of a catchphrase.

This passage is something like an ideal target (case study is misapprehension).

Geez. What a villainous combination of sentences.

I wonder where on the scale of "waste of emotional energy" this person puts getting worked up about what other people are criticizing.

Commenters on HN https://news.ycombinator.com/item?id=45896130 have mostly been critical of Camlistore/Perkeep in terms of whether or not it's a fully baked app, and then go on to talk about alternatives like Linkding, Zotero, or the (confusingly, similarly) named Karakeep. I think that gets it wrong.

The right way is to think of all those as all having backends that are all deficient in their bespoke ways and as being potential frontends for your Camlistore data.

The right question to ask is, "Why are projects like Shiori and Timelinize their own thing instead of better ways to interact with Perkeep?"

Git's "stupid content tracker" strategy of just snapshotting everything and treating storage/compression as a separate concern strikes me as the not-obvious-and-not-obviously-better-but-still-better approach and recording deltas as the obvious "solution" that turns out to be folly.

On the other hand, people have complained about Git stretched to other use cases, like with git-annex, being really slow.

This is worthy of close study.

A nice knock on of getting unzip working in love2d is I'm now able to load ods files (Libre Office's Calc format for sheets) directly.

Meaning I am able to hotload constants during runtime on file save without having to run an export from Calc.

Imagine if LibreOffice took table-editing and interoperability+sharing seriously and its native format for really simple tables like this were as simple as a plain text file with an HTML table in it.

(Or imagine if Web browser makers woke up and realized that, "People shouldn't need a copy of Excel or one of its clones to create/share/work on files with data like this.")

This would be much cooler if the TUI was a semi-general-purpose Web browser that happened to work really, really well with a certain highly opinionated, HTML-first frontend framework and that is what constituted the wire protocol from server-to-client.

The dearth of modern TUI-based Web browsers is a big disappointment.

Or you could not. Put a badge in the UI that indicates, "Hey, this thing was deleted. We still have a copy, though, and that's what you're seeing here. Pinafore is working for you."

This is the prime example I use to illustrate implicit step zero.

This is a well-known passage by Yegge explaining why GeoWorks didn't attain success with their object-oriented assembly, and why their object-oriented assembly is the reason for not doing so.

A pithier and more succinct analogy of the bigger picture that Yegge is trying to communicate here—something like what Engelbart struggled to get people to understand resulted in his metaphor of a pencil taped to a brick—would be, "There's a reason why programmers aren't writing code on punch cards anymore (and it's not just because the market for the equipment and, accordingly, the equipment itself, all but vanished and is no longer available)."

So document the process for updating the site in an SOP, making sure they're written in sufficient detail to be executable (by an agent—a user agent—sans LLMs), and then host the documents that detail those procedures on your site, as first-class content.

"Updating the site" then entails 1. consulting the SOP, and 2. carrying out the procedure there (either manually, or having your agent do it).

This is all achievable on a static site, provided there are Web-accessible (and, ideally, CORS-enabled) endpoints to control what content appears there (like the GitHub API, to name one example).

It's nuts that no mainstream browser has incorporated basic native table-editing controls by now. (They wasted no time adding JSON pretty-printers—unsurprising, really, given that their main actual concern is propping up the JS–industrial complex and the professional developer class and not real users, which they don't actually give a shit about, contra the Priority of Constituencies.)

There is and has been for a long time a huge opportunity for a "Photopea for CSV (and JSON)" to show up and take off.

No, this was never the case.

now a property of the program

To re-iterate: that's how it's always been. Programming languages and compilers are two different things. To conflate them is a category error.

Sure it is:

It's not really a debate, HTML is a markup language [1], not a programming language

This is a false dichotomy, and untrue on two points (a) that HTML is "not a programming language", and (b) that the stance you have taken is not up for debate.

You're using the term "programming language" as shorthand to refer to the subset of languages more rigorously referred to as Turing-complete general-purpose programming languages.* There are programming languages outside this subset that no less have set membership with the larger "programming language" superset.

A programming language is a programming language in the sense that they have come to exist with the advent of the stored program computer. Though HTML and other markup languages are not** Turing-complete general-purpose programming languages, they are used every bit as much to describe a stored program as a language you might encounter when opening a file containing G-code "instructions" for controlling a CNC machine.

* We had a similar (but not the same) silly recurring argument in the 90s where people, at a loss for words to accurately capture their thoughts and grasping at whatever came to mind, argued that there were two distinct classes: "programming languages" and "scripting languages"—a category error arising from the same phenomenon of mistaking loose, off-the-cuff shorthand for The Real Idea Behind the Thing That's Involved Here

** No overlooking the fact that HTML is a proper superset of CSS, a provably Turing-complete (though not general-purpose) programming language—and JS, which is, of course, a true general-purpose programming language

(Originally drafted in response to https://news.ycombinator.com/item?id=46747778)

The state of { journalism, the Web–industrial complex, and understanding about the fundamentals of research and scholarship } are so poor that the staff actually had to justify something as simple as citing your sources.

(In 2010, but still… 2010!)

https://github.com/solbjorg/oberon-riscv

The complainants' comments here are pure occupational psychosis.

See also: déformation professionnelle.

With these words, you might expect that programs that target the Wren reference implementation are faster than those written in Lua. But (again), languages are not language implementations, and the language implementation matters; while Wren programs written for the reference implementation available here are generally faster than programs that run on lua.org's Lua implementation, they're not faster than programs that run on LuaJIT.

No. Languages are neither fast nor slow. Only language implementations.

If only it weren't 25+ years later (and the PowerShell folks hadn't regressed on Windows).

... for people who have uvx installed.

... for people who have uvx installed.

k, but why not Oberon (with curly braces, of course)? It's both small and real/complete.

Right. Okay.

Good.