Presaging version control systems.

Typo in the tag here; "transculsion" should be "transclusion".

Well, the whole point of the Web was that everything would be given a (world-wide) identifier. Your current list of bookmarks has an identifier, but it's a local one. Once you have a world-wide identifier, it's only short jump to making it resolvable so that your bookmarks list has a URL, and browsing your bookmarks would be as simple as visiting that list.

Or read it here: https://archive.org/details/weavingweb00timb/page/n9/mode/2up

Pssh. 9-780062-515872 isn't the ISBN (which is 006251587X). It's the EAN-13.

No way. HTML is way better suited for it!

The fact that this book is an SPA—instead of just, you know, a bunch of web pages—is very annoying.

Totally screws up my ability to middle click the "links" in the TOC.

It also messes up the browser scroll position when clicking back/forward.

You're looking for https://www.science.org/doi/10.1126/science.98.2557.580.b, probably.

(This DOI, i.e. 10.1126/science.98.2557.580-a, is linked to from https://pubmed.ncbi.nlm.nih.gov/17835862/).

This is a massive failure of infrastructure (and education/"professionalism"—by and large, most people whose careers are in operating or maintaining Web infrastructure don't haven't been inculcated into or adopted the sort of "code of ethics" that sees this as a failure).

The thing might just be for something like the Internet Archive to get into training or selling professional services for handling companies' "Web presence, done the right way". (This is def. take some organizational restructuring, however.) I'd like to see, for example, IA-certified partner organizations that uphold the principles described here and the original vision for the Web, and professional associations that work hard at making sure the status quo improves a lot over what's common today (and doesn't slide back).

Hmm. I'm skeptical of the certainty with which this is said.

Given a series of trials the claim here is that if you took a blockbuster and released it for "free" (supported by ads) on YouTube) then the ad revenue even when multiplied by the greater number of viewers would not only not surpass ticket sales from the subset of the same viewers who'd be willing to pay for tickets, but that it wouldn't even be able to cover the production budget. That's both a strong claim and a claim that I'm not sure is correct. For comparison, Netflix (and even ad-supported streaming services, albeit ones with lower budgets) seem to do pretty well with just a fraction of the <$10-per-viewer take that makes up monthly revenue.

dubious

principle of least (literal) power

The notion of "productive consumption" has, for some people, an almost irresistible appeal.

There's a presumption here (and in the linked article) that those people want to talk to you—that they're just quietly suffering their desire to have some interaction with you, if only it were the case that you'd allow it. This is way more condescending than the thing that the article seeks to correct.

Thankses simply do not belong in a bug report. It's an almost surefire indicator that there's something wrong culturally and that your bugtracker isn't so much being used for bug reports as it is filled with support requests.

In other words, no to the rotten cultural expectations that are by far what you're most likely to encounter on GitHub. I promise—things really were so much better before it came along to try to be Facebook-for-software-development.

I think the default assumption that this is what's going on is a huge part of the problem. I see a similar thing happen on GitHub constantly, where project maintainers try to "upperhand" contributors, because they see the contribution as something deliberately undertaken to benefit the person who is e.g. submitting a bug report. This is a massive shift away from the spirit of the mid-to-late 2000–2010 era characterized by initiatives like Wikipedia (and wikis generally) and essays by Shirky on the adhocracy around the new digital commons.

Directly related to a question I posed a few years ago about who should really be funding open source. My conclusion: professional developers who are are most directly involved with how the source is put to work—and who benefit from this (in the form of increased stature, high salaries and bonuses, etc., in comparison to the case where the FOSS solution hadn't been available). This runs counter to the popular narrative that frames the employer as a "leech" and silent on the social and moral obligations of the employee who successfully captured value for personal gain.

It's like this: the company has some goal (or "roadmap") that involves moving forward from point A to point B. The company really only cares about arriving at the desired destination B. They negotiate with a developer, possibly one who has already signed an employment contract, but someone who is made aware of the task at hand nonetheless. The developer agrees to do the work meant to advance the company towards its goals, which potentially involves doing everything manually—that is, handling all the work themselves. They notice, though, that there is some open source software that exists and that can be used as a shortcut, which means they won't have to do all the work. So they use that shortcut, and in the end their company is happy with them, and they're rewarded as agreed (not necessarily at the end, but rewarded nonetheless with e.g. regular paychecks, but also possibly receiving a bonus), and they advance in their career. Who's extracted value from the work of the open source creator/maintainer here? Is it really just the company?

McQuaid seems to agree with my view, going by the way he (later) identifies both Bob and TechCorp as benefitting from Reem's work; cf https://hypothes.is/a/MBN0aDnuEe2aF8s2kWTPrg

See above.

You can check at uspto.gov. (The search engine is terrible, by the way.)

See below

visible-web-page looks to have been published and/or written on 2022 June 26.

I emailed Omar a few weeks earlier (on 2022 June 7) with with a link to plain.txt.htm, i.e., an assembler (for Wirth's RISC machine/.rsc object format) written as a text file that happens to also allow you to run it if you're viewing the text file in your browser.

(The context of the email was that I'd read an @rsnous tweet(?) that "stuff for humans should be the default context, and the highly constrained stuff parsed by the computer should be an exceptional mod within that", and I recognized this as the same principle that Raskin had espoused across two pieces in ACM Queue: The Woes of IDEs and Comments Are More Important Than Code. Spurred by Omar's comments on Twitter, I sent him a link to the latter article and plain.txt.htm, and then (the next day) the former article, since I'd forgotten to include it in the original email.)

JS engines are good from a technical perspective. The problem with JS is the Node/NPM culture.

Again: mostly enabled by the fact that he was young.

Another key ingredient. Society is participatory.

This is not to be discounted. Mentoring is a big deal generally, but a lot of what made this possible likely came from the novelty of dealing with a child. If you replace Kevin with, say, a 25 year old who is no more or less capable or committed, what changes is others' behavior in their interactions.

This design constraint is exactly what people are so bothered about 30 years later. Generality! Portability! That's why you don't get to exercise full control of the sort that your "native" stack would give you. It's also why the Web has not only endured, but has attained a level of ubiquity that is not matched by any other "platform".

• https://foldoc.org/Compound+Document+Architecture
• https://en.wikipedia.org/wiki/Open_Document_Architecture
• https://www.osti.gov/servlets/purl/5671048
• http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/vms/vax_document/AA-PB6KA-TE_DEC_ODA_Compound_Document_Architecture_Gateway_Users_Guide_199104.pdf
• VMS Compound Document Architecture Manual, Digital Equipment Corporation, Maynard, MA., December 1988

This touches on the subtle, underrated brilliance of Wikipedia's (mostly) flat namespace.

Intertwingularity is inescapable.

Thirty years on, we're still losing stuff. (You could even argue that the Web—as it has been put in practice, at least—has exacerbated the problem.)

Lots of the problems that Hypothesis runs into (incl. those described here in this post!) could be attributed to this. They could probably be neatly described in a volume titled "The Perils of Self-Publishing", in a section dedicated to the consequences of non-uniform practices.

Here's the Anno pitch deck: https://docdrop.org/pdf/Hypothesis_deck_22Aug-4b7ys.pdf/

Taken from Maciej Cegłowski https://idlewords.com/talks/website_obesity.htm.

common misapprehension; only command procedures are commands (not "everything")

Try https://web.archive.org/web/20111102182554/http://adamspitz.com:80/avocado#post-14

helena-lang.org should host a demo in the form of a copy of the "meat" of the project that can run directly in the browser from the open web (ideally launched via a single button here on the homepage) without having to install an extension (or at least anything more complicated than a bookmarklet)

This highlights a problem with the Web: the fusion of document identifiers and the channel through which the (or "an") information/service provider makes it available.

Suppose stakeholder S wants to mirror a document D (published in an HTML-based format) originally distributed by authority A. This will probably involve having to touch D in order to rewrite links to point at S's copies of auxiliary resources instead of A's originals. Simply copying the representation's bytestream is not sufficient.

"[... temporarily]"

Wrong. Here, I'll show you:

Forget about AGI for a moment. Instead, pretend we're talking about pecan pie. Most people probably can't answer the question, "What would I recognize as a pecan pie?" (or a sandwich). And yet thousands of people are able to make (and thousands more people are able to enjoy) pecan pie all the time—probably every day.

This RFC lacks any acknowledgement of the text/uri-list media type.

Also: just don't take photos/videos and reduce your social media "footprint" generally.

Privacy-respecting alternatives don't address the issue raised earlier with the comparison to the celebrity iCloud leaks. Because, to reiterate, privacy and security are different things.

See: Surveillance Camera Man * https://boingboing.net/2012/11/02/surveillance-camera-man-wants.html * https://www.youtube.com/watch?v=X9sVqKFkjiY

Someone is going to need to eventually explain their convoluted reasons for labeling this a downside.

Sure, strictly speaking, a bigger source tree is bad, but delegating to package.json and npm install doesn't actually change anything here. It's the same amount of code whether you eagerly fetch all of it at the same time or whether you resort to late fetching.

Almost none of the hypothetical benefits apply to the way development is handled in practice. There was one arguably nice benefit, but it was a benefit for the application author's repo host (not the application author), and the argument in favor of it evaporated when GitHub acquired NPM, Inc.

No, those are orthogonal. Whether you obtain the code for your dependency* at the same time you clone your repo or whether you get it by binding by name and then late-fetching it after the clone finishes, neither approach has any irreversible, distinct consequences re bugs/fixes.

* and it still is a dependency, even when it's "vendored"...

Additionally, as more time passes, it will become less and less of a problem.

It's a little bit of a misapprehension/mistake to describe this as translation into JS.

It only occurred to me reading this now, and musing about the code size and relative performance of simple programs written first in a to-be-compiled-to-JS language and then in JS, that the folks associated with these pushes are taking the sufficiently smart compiler position. Connected to superinferiority?

This is probably too ambitious, impractical. For most cases, it would suffice to make sure that the tools used to produce "traditional" release packages can run in the browser. (I.e., the release itself need not be able to run in the browser—though it doesn't hurt if it can.)

"secure" is used in this context to mean, roughly, "work with adversarial input"

I also found https://github.com/sbarman/Ringer

Some other things:

• If I visit https://www.zylstra.org/blog/ and content from e.g. this blog post https://www.zylstra.org/blog/2022/09/10-thoughts-after-100-annotations-in-hypothes-is/ has been inlined, Hypothesis doesn't know how to deal with this—it doesn't know that the annotations that apply to the latter can also be layered onto the inlined content at /blog/. This is a minor quibble insofar as you can measure it on terms of mere convenience. Less minor, however, is that if a user attaches their annotations to /blog/, then it will eventually be orphaned (as more posts are written and the now-current ones get bumped off the page), and will never appear in the correct place on the actual post.

• When people annotate Wikipedia there's a high likelihood that the annotation will become orphaned as the content changes, even though the version that was actually annotated will usually be available from the article history.

This was Peter's motivation to create annotations.lindylearn.io.

Public ones, at least.

What kind of premium services?

Traveler:

You want https://www.w3.org/DesignIssues/LinkedData.html

Traveler:

You want https://www.w3.org/DesignIssues/Webize.html

This reminds me of "I did write some code in Java once, but the code was in C and Lisp (I simply happened to be in Java at the time ;-)".

This link is a 404. Why did Roy start doing this?

Example of when "proprietary" is not an antonym of "open source".

Another approach, inspired by the <label> element, would be to encode these selectors as separate <link> elements in the head. You could write your links as normal, and then add these <link rel="selector" for="foo" href="XXX[...]X" /> to your document (where foo is the ID of the <a> element, and the href value is selector).

Neat.

The answer is: linking party pays. I.e., after 30-ish years of the Web put into practice, what has emerged is that it is the linking party's responsibility to ensure:

• that the material remains available (by keeping a copy around, or arranging for the same thing by delegating to a third-party), and
• there is some reliable way to establish provenance (which can be handled in tandem with delegation to same third-party, as with availability)

These are only necessary if these two (availability and reputable provenance) are actually desirable properties. But in the event that one or the other or both is desired, the rule is that linking party pays.

This is the only realistic one—and the only way to reconcile the vast pre-Web corpus that is ostensibly meant to be ingested to occupy a first-class status on the Web.

It still ~requires some amount of versioning (though not necessarily with the cooperation of the publisher, from whom it would be prudent to assume harbors a mildly adversarial outlook; cf Wayback Machine, Perma.cc, etc).

It's almost like a pick two/impossible trinity.

You can either have: - a resource that stays up-to-date (e.g. by a convenient URL that always points to the most recent revision, i.e. documents are mutable) - links that don't break

You can't have both.

If you choose the latter, your document can never change--not even to say the current version is out of date. This also means using unique ("versioned", you could say) URLs--one for every revision, with it only* being possible for later revisions to point to earlier ones, almost like a Git-like DAG.

If you choose the former, you're gonna be breaking your links (and those of others, too).

* The workaround would be to include in rev A (which predates rev B) a URL to a non-existent resource, and you preregister your commitment to deposit a document (rev B) there. Not possible in systems which rely on content hashes, but imminently doable under the norms of the way URLs get minted. (Still doesn't fix the problem of have a clean and up-to-date URL like /pricing or /about/team, though.)

I don't understand this.

Presaging lightweight wikilinks? (Or at least WikiWords?)

The page https://www.w3.org/DesignIssues/Multiuser.html#3 links here (to #GenericLinking).

Since this page currently returns 404, try https://www.w3.org/History/19921103-hypertext/hypertext/Products/Microcosm/Microcosm.html.

Why it's pointless to insist that links should have been bidirectional: it's unenforceable.

Try * http://www.html-tidy.org/ * https://github.com/htacg/tidy-html5

Obnoxious.

As someone recently pointed out on HN, it's very common nowadays to encounter the no-one-knows-else-what-they're-doing-here refrain as cover—I don't have to feel insecure about not understanding this because not only am I not alone, nobody else understands it either.

Secondly, if your code is hard to understand regarding its use of this, then your code his hard to understand. this isn't super easy, but it's also not hard. Your code (or the code you're being made to wade into) probably just sucks. The this confusion is making you confront it, though, instead of letting it otherwise fly under the radar.* So fix it and stop going in for the low-effort, this-centric clapter.

* Not claiming here that this is unique; there are allowed to be other things that work as the same sort of indicator.

And by the way, if you ever do do anything good with it, it'll just become a cesspool of people posting Donald Trump memes and complaining about what movie didn't have the right people in it on Twitter. That's what your inventions will be used for, right? Not advancing humankind and producing some kind of good future for everybody.

... says the guy who has dedicated his life to video games.

Previously: https://hypothes.is/a/tCHXEvj-Eey1N3dRiP4I4Q

Nice property. It would be nice if HTML Tidy could do the same.

This is the earliest known reference to HTML's class attribute that I've found in a public document so far: 1995 May 6 in draft spec 02 (i.e. the third revision) of the HTML 2.0 spec.

This postdate's Håkon W Lie's original CSS proposal (from 1994 and which doesn't mention classes) and predates the first CSS draft specification (dated to 1995 May 31 in one place and which mention's HTML's ability to subclass in order to "increase the granularity of vcontrol" [sic]).

The "subclassing" word choice here is interesting. It matches the model eventually suggested in HTML 3.x, but at the time of this draft, HTML was in a draft specification stage (third revision — "02") for HTML 2.0

I'm interested in the discussion that led to this.

You sure about that, Dan-from-25-years-ago?

You're looking for this, I think: https://www.w3.org/People/Connolly/9703-web-apps-essay.html

If you manage to find a copy of this (or already have one) please let me know!

It's always funny/interesting to read these not-quite-projections about overhyped tech from a far enough vantage point, but this sounds a little like what I've advocated for in the past, which is resurrecting Google Gears.

If the thesis is sound, then logically we should expect the instances where people have decided to "use terribly slow scripting and techniques" to produce better programs; the not-slow (non-"scripting") stuff to be worse.

You can only pick one:

• software is worse because hardware improvements mean that what were previously noticeable inefficiencies are no longer noticeable
• programs that are written in low-level languages and don't as much incur runtime overheads are better on average because they're written in low-level languages that aren't as wasteful

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

This calls for a perspective shift: that "random Python program" is your browser.

Notice with the line about Tom and Huck being boys, the bottom-up description sounds unnatural.

not what semver is actually about

https://github.com/ganelson/inform

You accidentally a word.

This piece would benefit from better editing—e.g. its use of pronouns with an unnatural (or too-far-away) antecedent, dubious phrasing like "all the more", etc.

still widely held today

traditional compilation foils "symmetric authoring"

I can't get behind the call to anger here, even if I don't approve of Apple's stance on being the gatekeeper for the software that runs on your phone.

Elsewhere (in the comments by the author on HN), he or she writes:

The biggest problem I try to convey is that you have no way of knowing you'll get the rejection

No, I think there were pretty good odds that before even submitting the first iteration it would have been rejected, based purely on the concept alone. This is not an app. It's a set of pages—only implemented with the iOS SDK (and without any of the affordances, therefore, that you'd get if you were visiting in a Web browser. For whatever reason, the author both thought this was a good idea and didn't review the App Store guidelines and decided to proceed anyway.

Then comes the part where Apple sends the rejection and tells the author that it's no different from a Web page and doesn't belong on the App Store.

Here's where the problem lies: at the point where you're - getting rejections, and then - trying to add arbitrary complexity to the non-app for no reason other than to try to get around the rejection

... that's the point where you know you're wasting your time, if it wasn't already clear before—and, once again, it should have been. This is a series of Web pages. It belongs on the Web. (Or dumped into a ZIP and passed around via email.) It is not an app.

The author in the same HN comment says to another user:

So you, like me, wasted probably days (if not weeks) to create a fully functional app, spent much of that time on user-facing functions that you would have probably not needed

In other words, the author is solely responsible for wasting his or her own time.

To top it off, they finish their HN comment with this lament:

It's not like on Android where you can just share an APK with your friends.

Yeah. Know what else allows you to "just" share your work...? (No APK required, even!)

Suppose you were taking classes and wanted to know the rubric and midterm schedule. Only rather than pointing you to the appropriate course Web page or sharing a PDF or Word document with that information, the professor tells you to download an executable which you are expected to run on your computer and which will paint that information on the screen. You (and everyone else) would hate them—and you wouldn't be wrong to.

I'm actually baffled why an experienced iOS developer is surprised by any of the events that unfolded here.

Not to dispute "deathanatos"'s (presumably) thorough refutation, and although the Wat behavior remains the default for compatibility reasons, but most of these problems are fixed with a single pragma.

Odd way to describe it! You could easily have said "Chrome 1.0" or "Firefox 1.x-level" (or even "Firefox 2.x" or "Firefox 3"), since JS didn't really change between 2000 and 2010. (ECMAScript 5 was standardized in 2009 but not bene, that's December 2009. IE 8 didn't introduce ES5, and it definitely wasn't available in IE at the tail end of the year. Full ES5 compliance didn't even really show up in browser until 2012-ish, not even Chrome—the one browser that had short release periods at the time.)

Corollary: Spolsky (at least at the time of this article) didn't really understand types, having about the same grasp on computing fundamentals as your average C programmer.

The thing that gets me about takes like this is that it's all the stuff below the Web content layer that accounts for what makes all this stuff harder than it needs to be.

What's the hard part about distributing content (static or not, but let's go with static for simplicity)? It's registering a domain, updating DNS, and keeping a Web server up—all systems that have nothing to do with the "infernal" trio and also generally programmed in what are typically described as saner languages and their traditions. It's either that, or it's relying on somebody else, like GitHub Pages, and integrating the implementation details/design decisions for their value-add into your workflow.

To "build a platform" is ambiguous, but it sounds a lot like "creating a server-side application to serve non-static content and handle associated requests". Is the infernal trio to blame for the difficulties of that, too?

So run a typechecker on the code to check your work if you want type checking. That is what TypeScript does, after all. And it's been around long enough that people shouldn't be making the mistake that a runtime that support dynamic types at runtime means that you can't use a static typechecker at "compile time" (i.e. while the code is still on the developer workstation).

With this comment, the anti-JS position is becoming increasingly untenable. The author earlier suggested C as an alternative. So their contention is that it's easier to write bug-free code in C than it is in JS. This is silly.

C hackers like Fabrice Bellard don't choose C for the things they do because it's easier to write bug-free code in C.

Perfect synopsis of /r/programming

The author might as well have written, "I have no idea what I'm talking about and rely on pattern matching based on social cues I have observed."

What is the relationship between "arcane code" and "code that you'd have to recompile"?

Where does it say they're "going with web-like scripts"? (And what is "more traditional code"?)

This note (and most modern JS programmers' code) could benefit from the eradication of its aversion to this.

Nah. OOP is just "messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things". Inheritance not needed.

Bob Nystrom used something like this while writing Crafting Interpreters. He wrote a post about its bespoke build system.

https://journal.stuffwithstuff.com/2020/04/05/crafting-crafting-interpreters/

a literal "missing step"

• https://wiki.triplescripts.org/wiki/Implicit_step_zero
• https://en.wikipedia.org/wiki/Missing_stairstep

I'm not sure that the narrative implied by these statements is accurate.

Reminiscent of Helping my students overcome command-line bullshittery

Nothing particular to what's described here, but this gives me an idea for a design of an efficient IME that doesn't require manually adding the brackets or even starting with an a priori intention of linking when you begin writing the to-be-linked phrase. The idea is that you start typing something, realize you want to link it, and then do so—from the keyboard, without having to go back and insert the open brackets—at least not with ordinary text editing commands. Here's how it goes:

Suppose you begin typing "I want to go to Mars someday", but after you type "Mars", you realize you want to link "go to Mars", as this example shows. The idea is that, with your cursor positioned just after "Mars", you invoke a key sequence, use Vim-inspired keys b and w (or h and l for finer movements) to select the appropriate number of words back from your current position, and then complete the action by pressing Enter.

This should work really well here and reasonably well in the freeform editor originally envisioned for w2g/graph.global.

I disagree that this is harmful. Striving to linearize things has payoffs. The resistance to doing so, on the other hand, is definitely what I would call harmful (to "communication", as the author put it, esp.).

Have you ever delivered (or witnessed) a lecture in non-linear time? You can't. Because you can't help but grapple with the inherent linearity arising from the base substrate of our existence, eventually.

That's probably not a bad conclusion—if you insert the phrase "one of" before "the closest". (And there's no bias fueling my agreement; I don't work with the JVM).

For my bet, the Web platform is still the better option, though, and it has to do not just with its current ubiquity, but the factors that have led to that ubiquity, including versatility and relative ease of implementation (cf Kling et al).

Yes! This is essential. Ask, "What does this probably actually require?"

in other words, it captures too many irrelevant details whose effect sums to null (and in the best case should be replaced by NOP).

See also DSHR on preservation, along with Rothenberg and Lorie (independently).

See Hinsen's https://rescience.github.io/ten-years/

I dunno. I think the common argument that the Web was not intended to be an application delivery platform is both (a) ignorant of basic facts in subtle ways that are materially relevant to the particular use case described here and (b) poorly applied to this use case, given those particulars.

I don't like most traditional Web apps or what passes for best practices in the contemporary culture. I don't write them, and I'm not defending them.

But we're talking about scientific literature here. I'll dispute the general argument as it applies to the specific use case under discussion by pointing out that a document-centric platform is in fact exactly the correct tool for the job in this case. The only thing that could be better is if you were able to write your paper more or less as you ordinarily do for journal publication and then feed the journal article into a machine able to comprehend the methods at a deep level and then simulate what it describes. We don't have that, though. But we can to author documents that are a little more explicit instead. This is not a terrible consolation prize. So we really should start seizing the benefits of the current circumstances, lest the Web platform actually turn into something unsuited for this. (Which, perversely, is most likely to happen as a result of pursuing the vision of making it more suited for traditional software development.)

Again—by all means, don't compile to asm.js (or WASM, or from TypeScript, etc.). Put it to use on its strengths and in the spirit of its original vision.

Better yet, not compiling to asm.js at all. Just WYGIWYG (What You've Got Is What You Give [Me, Too]).

I agree. And this very reason (along with the complexity, mentioned in the following paragraph) is what should disqualify VirtualBox.

The virtual machine manager you should use is the one you assumed would be available when you published this post (and that you were correct about, and that I am using right now to read it): the Web browser.

There's some sleight of hand here, which treats "when no one uses it in daily life anymore" as a given. That (folks continuing to use it) is the stability of the Web platform.

Besides, even if we suppose that people have stopped using it (dubious), the entirety of what constitutes "the 2013 Web platform" is not necessary—only the parts that are actually used for computation and I/O. That's much smaller.

Fortunately, the 2013 platform is a subset of the later one.

"can't is too strong a word here"

The truth of this has consequences not just for the metaissue of recomputation, but the entire raison d'etre of doing performance studies to begin with.

"The greatest performance improvement of all is when a system goes from not-working to working"

X for thee, not for me

This kills the crab.

Category error; C, C++, and Fortran are programming languages, not tech stacks.

Perverse!

See also https://hypothes.is/a/u7uYDMDuEeyKnBcDsiTnlg

See https://activepapers.github.io/