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.

I dunno about this assessment...

They knew, and they tried.

They just eventually stopped trying, because they beat Netscape and Sun.

Well...

Depends on how you measure it.

From a 2022 perspective, things are largely thought of as the opposite. People including developers and users alike on the whole seem to prefer the free-form canvas that enables non-traditional (otherwise referred to as "non-native") UIs—even if developers hate the front-end tech stack.

Not saying I share the sentiment—just observing that the folks who prefer colorful, do-what-you-want UIs like those found among mobile and Web apps tend to outnumber the SerenityOS fans.

Yeah, but they're basically cribbing the paradigm introduced by the Lisa and popularized by the Mac in 1984. (At least that used to be the case—before Chrome introduced the hamburger menu and everyone else followed suit, Microsoft's attempt to change things up with the ribbon not withstanding.)

Two things which typical users have been shown not to care about. (I understood the shortcuts thing around this time. It took me, like, 5–10 years after the date that this post was published to realize the thing about menu bars, too. And I'm not even a Mac user.)

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.

Right. If there are two ways to take a statement, one which is absurd because it's inconsistent with actual fact and another which isn't, it's a bad idea to make an argument that hinges on it being the former—that would mean you're insisting on an absurdity.

they keep coming

another you-problem

There is. It was standardized in ES6 aka ES2015. 2015! Direct your ire in the appropriate direction, i.e., at your vendor—and, ultimately, at yourself regarding your own lack of foresight.

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

The truest thing I've read in this post so far.

I don't think so. I go back look at what boundaries were being pushed in historical projects like some of the stuff that Tolmasky was doing and I see way more than today.

The last 10 years are pretty stagnant, in comparison. React sucks up a lot of resources to ultimately do little more than reinvent the wheel (poorly). Same with the adjacent tools mentioned here.

This statement belies some ignorance of history, I think, or some form of intellectual dishonesty.

JS is objectively and demonstrably slower on the uptake than what happened with Java.

Well, "as a whole", JS includes non-Node-affiliated silliness; it does get used by people in ways that doesn't involve any of this stuff. So use it that way, too, if you have a problem with the way you're using it now (and you should have a problem with it—so stop doing that!)

No. Well, yes, this is true, strictly speaking. But, again, this is a true-in-some-sense-that-isn't-relevant-here sort of way.

Parents are not responsible for the crimes that their children grow up and commit.

The NodeJS community is responsible for the NodeJS community's problems. And people outside the NodeJS community who choose to align themselves with the NodeJS community are responsible for their choices.

JS is evolving too rapidly—the ECMAScript group is putting too much in the language too often—but that's not the problem described here.

As noted in the comments on HN[1], the complaints here are not about JS, but about NPMJS/NodeJS specifically and how the NPM approach to engineering fails.

1. https://news.ycombinator.com/item?id=33965914

@15:40

His point is that a lot of software design has failed to be even as good as print design--that software design really has focused so much on interaction, we kind of treat the computer as this machine that we need to manipulate and less about displaying information--for people to make decisions, to come to conclusions, to learn something--and that by focusing so much on interaction design, by focusing so much on the computer as a mechanical thing, we've really made bad software.

And so he wants to say part of the problem here is that the people who design can't make these context-sensitive magic ink--right? It's like: print design but now it knows something about your context. And so designers really aren't able to make these rich information things that are dynamic but not interactive. And so you could really kind of call this "Interaction Considered Harmful", and the idea is that our software should only be interactive when it has to be and really our software should be context-aware, good, print-like displays of information.

This brings interesting questions back up like what happens to your online "presence" after you die (for lack of a better turn of phrase)?

Aaron Swartz famously left instructions predating (by years IIRC) the decision that ended his life for the way that unpublished and in-progress works should be licensed and who should become stewards/executors for the personal infrastructure he managed.

The chrisseaton.com landing page has three social networking CTAs ("Email me", etc.) Eventually, the chrisseaton.com domain will lapse, I imagine, and the registrar or someone else will snap it up to squat it, as is their wont. And while in theory chrisseaton.github.io will retain all the same potential it had last week for much longer, no one will be able to effect any changes in the absence of an overseer empowered to act.

def

NB: the footnote at the end indicates that this was originally published in Byte Magazine (October 1990). By a reasonable guess, the 2004 date here is when this online copy was published to drdobbs.com?

See also: Brad Cox on software ICs

I find it difficult to reconcile these two tenets with the claim that "Taylorism is so deeply ingrained in every aspect of not just modern commerce but life in general".

Many (most?) places—even big engineering orgs like Samsung—are failing on the first principle alone and are doing a lot of wasteful, gut-driven operational stuff.

cf akkartik

No, it doesn't. The "binding problem with this" is a problem that (some) people have. JS binds it the right way.

That's Node, not "JS".

No, not everywhere.

You start replacing var with let and things can be observed to break (e.g. multiple declarations, no declaration before use...)

This is not nearly as common as the highlighted comments suggest—at least not for undergrads at public universities in the US. It is a thing, though, with grad students (for obvious reasons).

I call it "RISC-W" (esp. since Wirth is not actually pronounced like "worth", which is the backbone of this attempted pun).

Prior art: https://en.wikipedia.org/wiki/ALGOL_W

great turn of phrase

Today, you tend to hear "web app" as a term used e.g. to contrast SPAs from classic, form-based apps. But the term was already being used then, when (barring the use of plugins, which weren't really "of" the Web) only the form-based ones were viable because SPAs and similar Web-native RIAs weren't yet an option.

Should we refer to those (the classic Web apps) as "turn-based apps" to emphasize the paradigm in play (i.e. REST)?

No link? It's http://ln.hixie.ch/?start=1088526392&count=1

One of the most obnoxious motivators for turning out code that ends up sucking.

When trying to save keystrokes, prefer keyboard macros over code macros that get checked in as source code.

NB: the up-to-date, "production" version of this journal dates this post as November. And ased on the updates ichi.city currently reports for this page (which was 23 days before the Wayback Machine's November 28 crawl), it looks like November 4, rather than October 4, is correct.

See also:

In the Smalltalk community, I always had the reputation as the guy who was trying to make Smalltalk more static so it was more applicable for industrial applications. In the Microsoft environment, which is a very static world, you know, I go around pushing people to make everything more dynamic.

— Allen Wirfs-Brock, in an interview with Jon Udell https://hypothes.is/a/YH0Mwp0yEeu-Ybt6B3i1Ew

Hey, traveler. Try <https://web.archive.org/web/20200808025946/https://sec.ch9.ms/llnwd/ch9/9/5/8/4/5/2/ju_wirfs-brock.mp3>.

Hey, traveler. Try <https://web.archive.org/web/20200808025946/https://sec.ch9.ms/llnwd/ch9/9/5/8/4/5/2/ju_wirfs-brock.mp3>.

can't parse

déformation professionnelle

again: unmatched class selectors

additionally, it's not the fact that they are unmatched (or that they are class selectors specifically) that it's a problem—it's the fact that there are a lot of them

the entire choice of focusing on classes and class selectors here is basically a red herring