NB: there may be a race condition here? In which case, running into errors should be (one) expected outcome.

ETOR probably stands for Estimated Time of Restoration

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

This is stated like unanimous agreement is a foregone conclusion.

The Web is for content. Just because people do build in-browser facsimiles of mobile-style app UIs doesn't mean that the flattening of content and controls into a single stream is something that everyone agrees is a good thing and what should be happening. They should be doing the opposite—curbing/reigning it in.

You mean your promise—the position of the Web Hypertext Application Technology Working Group.

Have you considered that the problem might have been you and what you were trying to do? You're already conceding failure at what you tried. Would it be so much worse to say that it was the wrong thing to have even been trying for?

You mean developers will gain.

Fuck developers.

Jesus fucking Christ. Fuck this shit.

This isn't new. Also: good—application developers shouldn't be the only ones holding the keys to the kingdom when it comes to making stuff available on the Web. Authors* and content editors should have those keys.

* in the classic sense; not the post-millennium dilution/corruption where "authors" is synonymous with the tautologically defined "developers" that are spoken of when this topic is at the fore

On HN, the user bitwize (without knowing he or she is doing so) summarizes (the first half, at least) of the situation described here:

The appeal of JavaScript when it was invented was its immediacy. No longer did you have to go through an edit-compile-debug loop, as with Java, or even an edit-upload-debug loop as with a Perl script, to see the changes you made to your web-based application. You could just mash reload on your browser and Bob's your uncle!

The JavaScript community, in all its wisdom, reinvented edit-compile-debug loops for its immediate, dynamic language and I'm still assmad about it. So assmad that I, too, forgo all that shit when working on personal projects.

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

Basically, ignore almost everything that Modern JS practitioners tell you that you need to be doing. You're halfway there with this experiment.

One of the most interesting and high-quality JS codebases that has ever existed is all the JS that powers/-ed Firefox, beginning from its conception through to the first release that was ever called "Firefox", the Firefox 3 milestone release, and beyond. To the extent that there was any build system involved (for all intents and purposes, there basically wasn't), the work it performed was very light. Basically a bunch of script elements, and later Components.utils.import calls for JSMs (NB: not to be confused with NodeJS's embarrassing .mjs debacle). No idea what things are like today, but in the event that there's a lot of heavy, NodeJS-style build work at play, it would be wrong to conclude that it has anything to do with necessity e.g. after finally reaching the limits of what no-build/low-build can give you (rather than just the general degradation of standards across Mozilla as a whole).

The best possible outcome for everyone likely includes a world where MS open sourced (at least as much as they could have of) Trident/EdgeHTML—even if the plan still involved abandoning it.

Ooh... this might benefit from improvement. I mentioned to Rochus the benefits of direct (no build step) runnability in the vein of Python or JS, and he responded that he has already done this for Oberon+ on the CLI/CLR.

For the same reasons that direct runnability is attractive, so too might be the ability to copy and paste to mix both syntaxes. (Note that this entirely a different matter from whether or not it is a good idea to commit files that mix upper and lower case; I'm talking about friction.) Then again, maybe not—how much legacy Oberon is being copied and pasted?

I agree, of course, with the criticism of the price point. As I often say, $9.99/month (or even $4.99/month) is more expensive than premium email—and no matter how cool you think your thing is, it's way less important than email. You should always return something for ~$20, especially if you already have a free tier. (When I say "for $20" here, I'm talking about a one time payment, or on a subscription basis that maxes out at $20/yr.)

The following musings are highly specific to the market for what's being sold here.

Paying $20 should get you something that you aren't bothered about again for the next year. Maybe to make it even easier, enable anyone to request a refund of their $20 for any reason within the first 7 days. This gives a similar feel to a free trial, but it curbs abuse and helps target serious buyers in the first place. In the event that 7 days is not enough time even for people to convince themselves that they need it, maybe keep open the ability to use a severely limited version of the service for the remainder of the year. E.g. you can continue to log in and simulate what you'd get with the full version, but it's only accessible to you because you can't publish them and/or share links with anyone who doesn't have access to your account.

Despite being a Rust apologist and the fact that this paper makes Rust look better than its competitors, Steve Klabnik says this paper is quite bad and that he wishes people would stop referencing it.

For Oberon+, try https://oberon-lang.github.io/

The W3C actually chartered a CSV working group for CSV on the Web. Their recommendation resolves ambiguities of the various CSV variants, and they even went on to supercharge the format in various well-defined, nice-to-have ways.

Huh? This sounds like it's saying the opposite of what was said two paragraphs earlier.

In order to make it way easier to keep track of things in bookmarklet workspaces, there needs to be an option that adds an incrementing counter (timestamp?) to the bookmarklet title, so when dragging and dropping into your bookmarks library, you don't lose track of what's going on with a sea of bookmarklets all named the same thing.

This has been giving me problems in the latest Firefox releases. It ends up throwing an error.

@34:00

In theory? RDF, it's awesome. I like it a lot. This is why I'm working on this. But in practice [...] the developer experience it's not great, and when people when they see Turtle and RDF and all these things, they don't like it, you know? My opinion is that it's because of lack of learning materials and the developer experience to get started.

Miguel de Icaza Jun 17, 2022 @migueldeicaza Replying to @migueldeicaza @markrendle and 2 others The foundation should fund, promote and advance a fully open source stack. And the foundation should remove every proprietary bit from the code in http://dotnet.org.

Microsoft can and should compete on the open marketplace on their own. [...] And we should start with the debugger: we should integrate the Samsung one, it should be the default for OmniSharp and this is now we get contributions and improvements- not by ceding terrain to someone that can change the rules to their advantage at will.

I tried (although perhaps not valiantly, but as an outsider) to convince Miguel and the then-Director of the .NET Foundation in 2015 that this state of affairs was probably coming and that he/they should reach out to the FSF/GNU to get RMS to lift the .NET fatwa, become a stakeholder/tastemaker in the .NET ecosystem, and encourage free software groupies to take charge so that FSF/GNU would be around as a failsafe for the community and would inevitably benefit greatly esp. from any of MS's future failure on this front. I tried the same in reverse, too. They seemed to expect me to be a liaison, and I couldn't get them to talk to each other directly, even though that's what needed to happen.

I find it odd that this is framed here as an example of an "unusual thinker". The solution seems natural, if underappreciated, for a domain where any tool's output target is one that was specifically crafted to intersect with what is ordinarily a (or in this case, the) "preferred form for modification".

You can (and we probably all more often should) do the same thing with e.g. HTML+CSS build pipelines that sit untouched for years and in that course become unfashionable and undesirable...

This is a good thing. https://bracha.org/pluggableTypesPosition.pdf

Refer to §6 #3.

If this were using professionally installed videoconferencing hardware, there would be no need for "eye contact correcting software" if done right. The use of such software would be an indicator of failure elsewhere.

"... assuming you rebase your site on top of Indiekit beforehand" (which is a big leap).

Now just get rid of the server part.

The real missing link between (conventional) static sites and the W3C's social protocols is still static. This post itself already acknowledges the reasons why1.

See also https://news.ycombinator.com/item?id=30862612

See also: What happened to simple, basic web hosting?

"... with current recommended practices", that is.

There really is no substantial increase in trust. You were already trusting their player to do the right thing.

Some thoughts:

• This is indeed good UX.

• What's not good UX—and which I discovered/realized this week—is that there seems to be no easy/straightforward way to map a podcasts.apple.com podcast page to either its feed URL or to the original publisher/podcast's Web site. In reality, this would be as trivial as embedding a <link>.

Additionally, there's a missed opportunity in the podcasting space to make judicious use of the Link header—every piece of media served as part of a podcast should include in the HTTP response a link back to the canonical feed URL and/or the original site! (And they should also have CORS enabled, while they're at it.) Why isn't this already a thing? Answer: because it's a trivial detail; podcasters could do this, but what's the point?, they'd say—almost no one is going to attach a network inspector to the requests and check to see whether they're sending these headers for only the sake of steadfast and adherence to hypermedia ideals. Worth noting that this is the exact opposite of Jobs's principle of carrying out good craftsmanship throughout e.g. a chest of drawers or when building a cabinet, even for the parts that no one will see, in order to "sleep well at night". Maybe this could be used to shame Apple?

Traveller:

You're looking for https://www.ribbonfarm.com/2008/11/18/the-organization-man-by-william-whyte-introduction/

And cyclists need to make sure they have wheels attached before riding a bicycle.

This is one of those things that superficially seems like a relevant retort, but as a reply it's actually total nonsense.

Or, if you wanted to put it more abrasively: Instagram photos are not podcasts, dumbass.

Good example of the "always return something (for $20)" principle.

Another casualty of the Copenhagen interpretation of ethics (or close enough, at least)?

https://hn.algolia.com/?query=copenhagen%20interpretation%20of%20ethics%20strikes%20again&type=comment

The author here makes it sound like they have to reach out and grab content stream chunks, stitch them together with their own hands, and then plonk them down on the assembly line for 14 hours a day or something.

It's a program. You write a program that does the building.

This is not a good approach. It's the opposite of what you want. Module resolution remains easy for computers (because of their speed), but tedious for humans.

As a writer, maybe there's some benefit for no correlation. As a reader trying to understand a foreign codebase, esp. one who is in the moment trying to figure out, "Where is this thing defined? Where can I read the source code?" when jumping through procedure definitions, not being able to trivially ascertain which file a given thing is in is unnecessary friction. Better to offload a tiny bit of work onto the author who knows the codebase (or at least their own immediate intention) well rather than to stymie the progress of dozens/hundreds of readers trying to work things out.

Worth noting that for many of Rochus's own projects (esp. ones related to Oberon/Oberon+), it's just a bunch of .cpp and .h files in one directory...

Imagine an arxiv-like depository that dealt with native hypertext, rather than TeX/PDF.

Food for thought: PWP as a prereq? What about RASH+SingleFileZ

The opposite of current Web app norms (contra desktop).

This is the one thing so far where the procedural syntactic mechanism isn't doing obvious heavy lifting.

... at some expense to ergonomics.

It's odd that they didn't introduce special syntax for this. They could have even used import to denote these things...

The class semantics for new in ES6 really bungled this in an awful way.

Is that mechanism or culture?

Not all names, I think. Local identifiers, for example...?

Larry makes a similar analogy (pass by value vs pass by reference) to my argument about why patches are actually better at the collaboration phase—pull requests are fragile links. Transmission of patch contents is robust; they're not references to external systems—a soft promise that you will service a request for the content when it comes. A patch is just the proposed change itself.

Is that really the ultimate, most worthy goal? It seems that "minimizing the level of skill required[...]" is used as a proxy here for what we're really after—minimizing the total cost of producing the thing we want. Neither the minimization of skilled use nor reuse should be held as a priori goals.

The irony* of this comment is that Google and Google engineers are famously some of the most well-known users/proponents of monorepos.

* not actual irony; just the faux irony—irony pyrite, or "fool's irony", if you like

He doesn't exactly say it here, but many others making the same observations will pair it with the suggestion that this is because of some intrinsic property of the digital medium. If you think about it, that isn't true. If you consider paper, people tend to be/feel more empowered to tweak it for their own use (so long as they own the copy); digital artifacts seem more hands-off, despite their potential, because the powers involved are reserved for wizards, largely thanks to the milieu that those who are the wizards have cultivated to benefit themselves and their livelihood first, rather than empowering the ordinary computer user.

It's clear that gklitt is referring to the ability of extensions to augment the browser, but: * it's not clear that he has applied the same thought process to the extension itself (which is also software, after all) * the conception of in-browser content as software tooling is likely a large reason why the perspective he endorses here is not more widespread—that content is fundamentally a copy of a particular work, in the parlance of US copyright law (which isn't terribly domain-appropriate here so much as its terminology is useful)

This has almost always been the case—at least as far back as 10+ years ago with addons.mozilla.org, too.

NB: there's no such thing as a "CSS class". They're just classes—which you may use to address things using CSS's selector language, since it was conveniently (and wisely) designed from the beginning to incorporate first-class* support for them.

* no pun intended

This is an unfortunate reality about the conventions followed by programmers building applications with Web-based interfaces: no one honors the tradition of the paper-based forms that their digital counterparts are supposed to mimic; they're all building TOSS-style APIs (and calling that REST) instead of actual, TURN-style REST interfaces.

• MementoWeb
• WebDAV

That was what pre-WebExtensions Firefox was. Mozilla Corp killed it.

See Yegge's remarks on The Pinocchio Problem:

The very best plug-in systems are powerful enough to build the entire application in its own plug-in system. This has been the core philosophy behind both Emacs and Eclipse. There's a minimal bootstrap layer, which as we will see functions as the system's hardware, and the rest of the system, to the greatest extent possible (as dictated by performance, usually), is written in the extension language.

Firefox has a plugin system. It's a real piece of crap, but it has one, and one thing you'll quickly discover if you build a plug-in system is that there will always be a few crazed programmers who learn to use it and push it to its limits. This may fool you into thinking you have a good plug-in system, but in reality it has to be both easy to use and possible to use without rebooting the system; Firefox breaks both of these cardinal rules, so it's in an unstable state: either it'll get fixed, or something better will come along and everyone will switch to that.

Something better didn't come along, but people switched anyway—because they more or less had to, since Mozilla abandoned what they were switching from.

Worth noting that c-smile, the creator of Sciter, put out an offer during COVID lockdowns to make Sciter open source if someone would fund it for $100k. That funding never came through.

You're looking for https://mek.fyi/math

You're looking for https://mek.fyi/essays/software/what-the-browser-is-missing

https://michaelkarpeles.com/math.html

https://michaelkarpeles.com/essays/philosophy/what-the-browser-is-missing.html

My central goal is a universal knowledge repository freed of discrete "document" boundaries

I generally don't have to do that when reading except when reading books or academic papers. This suggests that there's not really anything wrong with the form of the book, but rather its content (or the stylistic presentation of that content, really).

I've said it a bunch the biggest barrier to accessibility of academic articles specifically is the almost intolerable writing style that almost every non-writer adopts when they're trying to write something to the standards for acceptance in a journal. Every journal article written for joyless robots should be accompanied by a blog post (or several of them) on the author's own Web site that says all the same things but written for actual human beings.

What if, when you bought a book, included was access to a self-administered test for comprehension? Could this even solve the paying-for-things-limits-access-to-content problem? The idea would be to make the thing free (ebooks, at least), but your dead tree copy comes with access to a 20-minute interactive testing experience (in a vendor-neutral, futureproof format like HTML and inline JS—not necessarily a Web-based learning portal that could disappear at any moment).

Consider: a version of the game 20 Questions that helps build up a knowledge base that can be relied upon for Mek's aforementioned Michael Jackson-style answers.

See also: Universal Access to Knowledge raises a concern of misuse

Minority(?) viewpoint: oclif-based command-line apps (if they're anything like Heroku's, at least) follow conventions that are alien and make them undesirable.

Well, you could write standards-compliant JS... Then people could run it on the runtime everyone already has installed, instead of needing to download Node.

Node is not a programming language.

This reminds me of, during the height of the iPod era, when someone I know was gifted* an non-Apple music player and some iTunes gift cards—their first device for their first music purchases not delivered on physical media. They created an iTunes account, bought a bunch of music on the Music Store, and then set about trying to get it onto their non-Apple device, coming to me when it wasn't going well trying to get it to work themselves. I explained how Apple had (at the time) made iTunes Music Store purchases incompatible with non-Apple devices. Their response was baffling to me:

Rather than rightly getting pissed at Apple for this state of affairs, they did the opposite—they expressed their disdain about the non-Apple MP3 player they were given** and resolved to get it exchanged for credit so they could buy a (pricier, of course) Apple device that would "work". That is, they felt the direct, non-hypothetical effects of Apple's incompatibility ploy, and then still took exactly the wrong approach by caving despite how transparently nefarious it all was.

Returning to this piece: imagine if all that stuff hadn't been locked up in the social media silo. Imagine if all those "comments, posts, and photos from the past 14 years" hadn't been unwisely handed over for someone else to keep out of reach unless you assimilated. Imagine just having it delivered directly to your own inbox.

* NB: not by me

* NB: not as a consequence for mimetic desire for the trendiest device; they were perfectly happy with the generic player before they understood the playback problem

This was initially confusing. What makes texting infeasible, but doing it through Facebook is feasible? I realized upon reaching the end of the next paragraph: "I cant make a new Facebook in 2023 and add all these old friends. Literally psychotic behavior."

When this person talks about "keeping up", they don't mean "interacting". They mean non-interactively keeping tabs on people they once knew but that they don't really have an ongoing relationship with.

See also: the work of Jeannette Wing on (the value of (teaching)) computational thinking.

It's interesting how few comments are engaging with the substance of the piece. They are encountering for the first time the idea that Rikard is providing a commentary on—that is, giving students their own big kid Web site, an idea that "belongs" to the "Domain of One's Own" effort—and expressing enthusiasm for it here as comments nominally about this piece, which is really rather intended to express a specific, reflective/critical response to overall idea, and does not pretend to present that idea as a novel suggestion for the first time...

References to "the World Wide Wruntime" is a play on words. It means "someone's Web browser". Viz this extremely salient annotation: https://hypothes.is/a/i0jxaMvMEey_Elv_PlyzGg

Missed opportunity here to simply name this GET.

College graduates in 2005 could understand what this meant. I'm skeptical that college graduates in 2023 can really grok this allusion, even if it were explained.

See also:

this previous comment thread with a minority detractor view on Idiocracy [...] argues it’s a little more dated to it’s specific Bush-era cultural milieu than everyone remembers

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

E.g.:

[Idiocracy's] "you talk faggy" [...] sadly was common in real life during the mid-00s [...] but would be completely taboo now

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

That's actually not (just) seemingly "personally unfair"—it's collectively unfair. The folks responsible for these things serve as the better example of self-centeredness...

The fact that we're not talking about a child here but that it was considered a normal for a 43-year-old man in 2005 to have this as his default setting perhaps explains quite a lot about the evident high skew of self-centeredness in folks who are now in their sixties and seventies.

I didn't notice this in 2005, but maybe I wasn't paying close enough attention.

thought-terminating ones, even

Very sophomoric argument, and it's hard not to point out the irony between this claim and everything preceding it wrt self-assuredness.

Is it impossible for there to exist people to whom this description doesn't apply, or is it merely annoying and inconvenient to consider the possibility that they might?

"All of humanity's problems stem from man's inability to sit quietly in a room alone" —Blaise Pascal

For better or worse, people will continue to run things to inspect the results manually—before grumbling about having to duplicate the effort when they make the actual test. The ergonomics are too tempting, even when they're an obvious false economy.

What about a test-writing assistant that let you just copy and paste your terminal session into an input field/text file which the assistant would then process and transform into a test?

and, apparently, business—which definitely explains the author's overall position, specific recommendations, and the fact that this blindspot (about failing to mention the intersection of business with their interest in messengers).

Happy to hear this is the author's position, at least, because delta.chat and/or something like it is really the only reasonable way forward.

(This isn't to say the current experience with delta.chat doesn't have problems itself. I'm not even using it, in fact.)

This isn't true: where does the "and device" part come in?

But we have already heard plenty of evidence about why this isn't true...

"I'll blame Apple" is both an acceptable and reasonable response to this.

Yeah, I don't want any of those. It's not that I'm merely unimpressed—I am actively opposed to several of them for good reasons.

The only reason why I "switched" to Signal ~5 years ago, was because it became clear that some of my messages weren't coming/going through.

When I switched to Signal, the experience was even worse. Someone would send the message or attempt a voice call, but Signal would not reliably notify me that this happened. I'd open the app to find notifications for things that should've been delivered hours/days earlier.

This had nothing to do with my app/phone settings. Signal did deliver some notifications, but it would do so unreliably. Eventually, I switched back to SMS in part because I was baffled by how the experience with Signal could be so much worse—as well as a bunch of dodgy decisions by the Signal team (which was actually the main catalyst for the switch back, despite the deliverability problems).

As a point of fact, this has nothing to do with SMS per se....

The lack of emphasis on the original design motivations for the Web as an analog for someone sitting at the reference desk in e.g. a corporate library who will field your request for materials is something that should be corrected.

To be clear: when PeterisP says parse the format, they really mean lex the format (and do some minimal checks concerning e.g. balanced parentheses). To "handle the semantics of a particular field" is a parsing concern.

Most interesting of all, perhaps, is that recent investigations prove absolutely that while expertness and efficiency may be possessed by the same individual, often the expert is not an efficient worker

Should be "no one".

This post is one massive derp. (Or rather, the problem solved by the changes documented here is... The post itself would instead be best described as one massive "duh".)

Spoiler alert: anti-wikis with heavyweight PR-based workflows that ignore how much friction this entails for user contributions don't beget many user contributions! (And it also sucks for the people getting paid to write and edit the content, too.)

You're looking for https://pocketcasts.com/plus/

Everything is foldable in IDEs so long as the IDEs make them foldable.

What about chained dotted access? foo.bar.baz is probably okay as bar.baz @ (the Foo) (or even @the Foo), but probably not if it takes the form bar.baz from the Foo. (It just doesn't look reasonable to me.)

Alternatively, what about @bar.baz for the Foo?

should be a "to" here

NB: not actually that much harder. In fact, my prescription today would probably be to omit the trailing s and allow only a bare single quote, which altogether would be incredibly easy to parse. (Omitting the s would also solve the it-doesn't-look-contrived-enough problem.)

This is indeed very good (for the reasons stated here).

See also: REST (compare: Fielding-style vs Valley-style)

We need to reunite model language and programming languages. This was the great vision of Simula[...] We need to stop believing that we can document programs by some well-written code or "clean code". Clean code is great for small programs. Systems need more than comments and a few diagrams—systems need the voice of the designer in them with multimedia, but they also need more expressive paradigms for putting these in our programs.

Although this episode is listed on Lex's own podcast page https://lexfridman.com/podcast/, it isn't actually available in the podcast RSS feed.

I guessed the URL.

And even though the latest episode right now is title #350, there are only "300 episodes" listed for the show on the Apple Podcasts page https://podcasts.apple.com/us/podcast/lex-fridman-podcast/id1434243584

Possibly this one https://doi.ieeecomputersociety.org/10.1109/VISSOFT55257.2022.00009

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

This can be migrated to a utility method (for ServiceProcurement); viz:

static initialize(slotted, page, key) {
  const { OverrideFailure } = ServiceProcurement;

  let override = new ServiceProcurement(page, key);
  if (!(slotted.name in override.global) ||
      override.global[slotted.name] != slotted) {
    throw new OverrideFailure(slotted, page, override);
  }

  override.global[slotted.name] = override;
}

(Alternatively, omit the override failure checking?)

This can (should) be parameterized—not just here, but in the procurement constructor.

Hardly small or simple. Huge departure from Oberon...

It should not go unmentioned that a big reason why this is the case is the types of folks from the presenter's social circles being hostile to this and trafficking in dubious maxims about how it somehow has to be this way...

and yet Moneyball took almost a century, and the human-level processes behind semiconductor fabrication remain astoundingly inefficient (doubly ironic given the task at hand...)

https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001yB

(Something else that has changed in the intervening years; most computers in the world—or a plurality of them, at least—are now running Android, not Windows, but Win32 is useless on Android. It's no help on iOS, either.)

Despite the number of times it's been submitted over the years (most recently two months ago), this post has received very little commentary on HN. I think it suffers for its choice of title. This snippet is a better candidate, I think.

More people are (finally!) coming to the realization that GitHub repos full of Markdown and the edit-via-pull-request anti-pattern is not a substitute for a real wiki.

no

another term for resume-driven development

the attitude of software designers that gripped the early 2010s described succinctly

Very awkwardly stated.

Quoted here: https://malleable.systems/catalog/

Quoted here: https://malleable.systems/catalog/

See also: Empowered free software

"It should travel with all the things that it needs"

See also: * Open Source Is Not Enough * Empowered free software

The modern library is the quiet reader's nightmare; I've been to many noisy libraries over the last decade.

Nice turn of phrase.

See also: mop handles that flex and bend like rubber when subjected to the downward pressure that is typical during mopping.

I've said it before: we focused too much on the dream of a 3D printer in every home when we should have focused on personal electric looms.

Would it be possible to adulterate glassware to glow underneath a blacklight?

terrible analogy is terrible—and I say this as someone who doesn't even fall in line with the general anti-copyright sentiment that is prevalent on sites like HN and Reddit

Use this to explain why Bernhardt's JS wat (or, really, folks' gut reaction to what they're seeing) is misleading.

I'm a big fan of how REST is explained in jcrites's comment as part of the discussion that arose on HN in response to this piece: https://news.ycombinator.com/item?id=23672561

in other words, widely referenced but rarely read

This is not true at all. It sounds like Austin is operating on a notion of what REST is that follows the popular misconception. ("The biggest of these misconceptions is that the dissertation directly addresses the problem of building APIs.")

See also: https://news.ycombinator.com/item?id=23672561

Yes it is, dumbass.

Also:

I am not sure why you think that having an obscure URI format will somehow give you a secure call (whatever that means). Identifiers are public information.

Fielding. 2008. https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-806

Maybe this is just a regional thing, but something I really began to notice several years ago is that (a) what Jamie is saying is true, but (b) it's evident that people actually love the unfalsifiability aspect of non-concrete claims—it's safe refuge that they actively seek out.

Two opposing examples from real life that particularly stuck out: * "Slow down. [You're going too fast.]" * "[...] since you always take so long"

(These were two different instances/contexts with, I think, a year+ in between them; it wasn't the contrast between them that made me notice the phenomenon. Rather, I recognized each one at the time as being part of this phenomenon. They just serve as good examples because of how easily they could be made concrete—and therefore falsified in light of the facts: "without defining exactly what 'too fast' means, what is an acceptable speed?", "without defining what it means to take too long, what is an acceptable amount of time to take?"—both arising from wholly disingenuous complaints that were forms of externalized gut reactions rather than anything that would hold up under scrutiny...)

Oh man, this metaphor really fell apart and, if anything, works against itself.

"If integrated circuits are superior to discrete components, why exactly are we supposed to be recreating the folly of reaching for reusable components in creating software?"

They don't, though. Things like JSON, XML, etc. mean you don't need to write a lexer--not that you don't need to write a parser. People land themselves in all sorts of confused thoughts over this (smart people, even).

From the 1976 edition of Naur, Randell, and Buxton's "Software Engineering: Concepts and Techniques":

Get some intelligent ignoramus to read through your documentation and try the system; he will find many "holes" where essential information has been omitted. Unfortunately intelligent people don't stay ignorant too long, so ignorance becomes a rather precious resource. Suitable late entrants to the project are sometimes useful here.

Burkinshaw on correctness and debugging. p. 162. (Only in the 1976 edition.)

Good case for S4/BYFOB+bookmarklets.