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/

Applicable as criticism for: - marketing analytics for "data-driven" campaigns - the sort of resume-driven development that is fashionable on Github - naive code reuse, generally

Good formulation! All scientifically relevant information—this demands that the programs themselves be "stored in stable and well-defined open file formats". This is precisely what is missing (both the mindset and the practice).

I suspect, though, that the author themself has missed this and is thinking of the "software environments" (that he later refers to in this conclusion) as being outside this purview. But it need not (and should not) be.

Not true. The standardized Web platform is not just more stable than Python, it's probably one of the most stable platforms in existence. It just moves (read: improves) slowly.*

Most people don't recognize this, because they pack the stable, standardized parts all in the same mental bag as the shiny, non-standardized parts (like Flash, for an example of decades past, or experimental vendor-specific stuff for a more evergreen problem), then end up getting bit in a similar way and blaming the environment rather than communal tendencies towards recklessness.

It also turns out that the Web's original academic underpinnings are deeply aligned with the goals of researchers looking for a way to work together—even if the final puzzle piece (ECMA-262) didn't come into existence until later in the decade when the Web first appeared. It's still old enough that it passes the litmus test proposed here.

* for good reason; after all, look at the evidence

My conclusion: the scientific computing community—and many Python programmers, generally—have done themselves a disservice by standardizing on Python. The problems that have been shown to arise here and in similar cases comes down to an impedance mismatch between what these programmers want Python to be and what Python actually is.

Another insight comes from observing the way in which folks from the affected group have tended to approach the problem—wading in with a sort of undisciplined, YOLO mindset and then thrashing when they've gotten in over the heads because it turns out that a lack of discipline permeates the actions of everyone else, too—which includes, crucially, those they look for to be disciplined so that there's something that can be relied upon.

Food for thought: although I'm not a Java programmer it's not hard to see that had they standardized instead on the JVM (doesn't necessarily have to be Java—could be a Python lookalike), then this would have almost certainly served them better here on the matter of stability and had the nice benefit of sidestepping the performance issues that Python is known for.

The "every problem in computing can be solved with another layer of hacks" school of thought.

This is still not the best way to put it. Decisions come at the expense of writing code. This maintenance work is something else.

Good point.

We can go further. Suppose I have a project written in TypeScript, and your affinity for TypeScript is well-known. Only—surprise!—I'm actually using TypeScript 1.x from n years ago. Are you still happy?

https://newspeaklanguage.org/

This is not strictly true, but it's not the worst thing in the world to pretend that it is.

This seems to be the position adopted by many developers. More than is reasonable. #3 and #4 probably account for most developers.

This one, it looks like: https://blog.khinsen.net/posts/2017/01/13/sustainable-software-and-reproducible-research-dealing-with-software-collapse/

Cited by https://link.springer.com/content/pdf/10.1007/s00287-018-01134-1.pdf

See also: Fielding

REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release.

That's a pretty deficient workaround, given the obvious downsides. A more robust workaround would be to make the cart stateless, as far as the server is concerned, for non-logged-in users; don't depend on cookies. A page request instead amounts to a request for the form that has this and this and this pre-selected ("in the cart"). Like with paper.

That seems like unnecessarily tight coupling. Surely there's a better level of abstraction that's higher than "emulate the hardware platform".

Huh?

nope

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

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

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

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

We just invented declarative programming.

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

Game Developer. September 2005.

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

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

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

See Too DRY - The Grep Test.

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

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

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

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

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

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

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

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

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

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

This is silly set of statements to make in series.

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

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

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

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

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

I'm having trouble parsing this.

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

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

Huh? Modules are ES6 aka ES2015.

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

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

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

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

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

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

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

This is a 404.

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

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

the problem with Golang that I described

Dissent: On Understanding Data Abstraction, Revisited

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

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

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

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

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

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

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

Related: lineality is a virtue.

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

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

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

gross

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

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

Another solution, in two steps:

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

See also: A New Publishing Discipline.

Mentioned above; also:

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

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

Sounds like write.as.

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

Think about the irony of this.

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

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

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

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

Until those things go away.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

These concerns also exist if you're using frameworks.

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

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

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

See algorithmic languages.

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

@6:15

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

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

@8:02

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

Git as He Is Poke(d)

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

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

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

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

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

Good use case for an LP doc.

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

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

Why the name, though?

@54:25:

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

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

cf Carse:

Finite players play within boundaries; infinite players play with boundaries

something something declarative effects

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

@2:10

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

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

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

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

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

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

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

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

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

See: Oberon

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

@52:20

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

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

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

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

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