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>.

Lots of second panel thinkers in these comments. Great case study.

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

where "does" here means "how the author recommends it should be styled", which is not actually the purpose of the class attribute

you suddenly find it worthwhile to acknowledge the existence of gzip?

what happened? https://hypothes.is/a/Bg1yFm4vEe2_WDuDjmBVaA

"in that order", apparently

just torpedoed your entire argument, dude

"reuse" is not the point of classes

semantics are the point

lol wut

vacillating wildly here

class selectors are not classes

"unused" or "unmatched class selectors" is what they're really talking about

you mean color-red; there is no .color-red class on the div

contradicted later

déformation professionnelle

Example of focusing on your weakest critics and choosing not to confront the strong arguments against your position.

You could pretty easily do this with a bookmarklet. (Call it "citehn", pronounced "citation".)

How about "online writing" (or just "writing")?

"circumferences", not "diameters", surely?

So don't do that.

The class attribute had been in HTML for years by the time this post was written—and (contrary to any belief otherwise) was meant for this purpose, and not something contributed by the CSS group for use with CSS selectors.

It's not. It's a document markup language.

Most Web developers, however—going back to 1999 and before—certainly treat it like it's a display technology.

something something Redbean and Justine Tunney

My biggest gripe about the EPUB specs is that they didn't require the container format be compatible for use with legacy Web browsers. Nuts!

You can change the framing and gain new insights.

In the mastodon.technology shutdown post linked, the author describes a situation where the workload exceeds the capacity of an ordinary person, even a motivated one. (There's an argument to be made that this makes for someone who isn't merely an ordinary person—but that strengthens the point I'm about to make, instead of weakening it.)

How do we fix this problem? In other words, how do we ensure that the workload of an "instance" remains within the realm of feasibility for an ordinary person?

Answer: making it the responsibility of each person. A single volunteer admin should not be responsible for hundreds, thousands, or more other people. Getting each person to shoulder their own personal load is far more tractable.

What's absent, currently, is the means for each person to do so on their own in a way that we can realistically expect. That can be worked on. Software like Mastodon can be improved upon—necessarily drastically so—and infrastructure configuration can be improved to, to the point that it doesn't even feel like infrastructure configuration.

For people with very large spheres of influence, like Aral Balkan who recently disclosed that he's spending ~600 EUR per year for his instance, they can seek help, mining from the resources that are at their disposal that are a consequence of their wide reach. For ordinary people with up to a few hundred followers, they won't need to be exposed to this.

As for the sentiment behind the remarks about "dumping fresh content into our account for free", recognize that the fresh content has value, and there are ways to subsidize the resource use by parties with an interest in being able to capture some of that value for themselves. When you post a widely shared piece to your blog, then Google for example benefits from this, whether you're using Google Ads or not. It's the mere fact that there's something on the Web worth looking at that makes this beneficial.

In response to:

Typo in the title (should be "Compiler" and not "Complier")

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

Although, notably, that process, if very involved, can be captured in a separate document.

The big takeaway—in a world increasingly obsessed with apps (to the point that even things that originally were and still should be documents end up being conceptualized as apps—and all the downsides that comes with re mental guardrails).

See also: gradual typing

That's the entire topic, my guy!

"We should be optimising Mastodon so it incentivises more serve[r]s with fewer people." is the very premise of the conversation!

Mastodon "push[ing] the direction of the protocol or make it harder to cultivate an ecosystem of smaller ones."? "it needs to be easier to start smaller ones"? Are you just not paying attention to the conversations you're responding to?

Reminds me of:

What fascinated me was that, with every single issue we discussed, we went around in a similar circle — and Kurt didn’t seem to see any problem with this, just so long as the number of 2SAT clauses that he had to resolve to get a contradiction was large enough.

https://scottaaronson.blog/?p=232

This is where it starts getting ridiculous.

First, rather than social.stephenfry.com, stephenfry.com should be sufficient. Look at email. I can set my MX records to point wherever I want. I don't actually have to have a server with A records to field the email traffic.

Secondly, the @stephen part is superfluous, too! This is something where Mastodon et al had years (decades!) of hindsight to take care of this, and they still messed it up.

So make your application document-driven (i.e. actually RESTful).

It's interesting that we have Web forms and that we call them that and yet very few people seem to have grokked the significance of the term and connected it to, you know, actual forms—that you fill out on paper and hand over to someone to process, etc. The "application" lies in that latter part—the process; it is not the visual representation of any on-screen controls. So start with something like that, and then build a specialized user agent for it if you can (and if you want to). If you find that you can't? No big deal! It's not what the Web was meant for.

So don't.

I'm going to guess this is CSP-related breakage and guess further that the bookmarklet does not really do any work except inject script element that tries to load a Pinboard-hosted script.

There are ways around this, but no one seems that interested...

What a shame that they went with Python, rather than something that can already run directly in everyone's reader app.

I've mused about how installing a server-backed Web app (or server-side support for a given protocol) might be made as simple as saving a copy of a Word document or a copy of a PDF that someone has emailed you.

Consider MediaGoblin, which is the original context where I wrote this down.

The thing is is that MediaGoblin is written in Python; if you want to "deploy" MediaGoblin, you must deploy a Python app. I don't like that. Imagine instead of you "deployed" an app by installing its set of manuals

The idea is that you have a document that describes the MediaGoblin application—the software manual. Now imagine that manual were sufficiently detailed so that a person reading it were able to independently re-implement it. If you actually wanted someone to re-implement it, you could do worse than to give them a copy, with the expectation that they'd study it and it would be sufficient for them to learn how to go about making a MediaGoblin clone.

Suppose you didn't give it to a person, though, but you wanted to "teach" your server how to act like a MediaGoblin instance. Shouldn't we aim to make it as straightforward as being able to give your server a copy of the manual?

Prior art: - Rob Pike's talk about the Go compiler, and the way he references the ability to ingest PDFs of vendors' manuals and grow a new backend for the compiler - The VPRI/STEPS approach to a TCP stack - Literate programming

Aral Balkan's personal (single-user) Mastodon instance costs him ~50 EUR per month to run.

This list is missing https://smol.pub

I've mentioned before (most recently, I think, in a response to the Postcard creator) that it feels a little scummy to demand people pay to be able to use custom domains. It's like holding someone hostage and demanding ransom for their release.

I've thought about alternatives. I won't mention past ones here. Instead I'll sketch out a new one.

1. Sell support billed at a realistic rate, considering the costs (e.g. a flat price of something like $125 for up to ~2 hours), where buyer pays upfront

2. Maybe throw in a domain for "free" (i.e. included), so if the buyer isn't already bringing their own, they'll have one by the end

3. Any unused balance (e.g. completion of support task only took half an hour) gets credited to the account

4. Set up a wiki (a real wiki—not a GitHub-style anti-wiki) for the documentation; point out that it's in folks' best interests to help each other out and keep it up to date and even record their own notes for their own setup here if they want to avoid paying the support fee

The idea is to charge a high enough upfront fee for something that may not immediately consume up to its budget cap—such that you can, over time, recover own investment while making it feel like the buyer is getting all the value out of their payment.

Pretty bang-on.

Try https://katelynlemay.com/

You're looking for https://artifex.org/~bonnie/InvisibleW.html

This particular example is pretty sleight-of-handy; there's a double standard being applied here.

And here's why https://guzey.com/follow-up/.

There are lots of people who think the way that Alexey Guzey does: "A story: when I wanted to meet with a really busy friend of mine in SF, I first sent him 2 twitter DMs, then 2 emails, and then 3 text messages, letting him know that I will keep sending one text a day, until an email from him finally landed in my inbox letting me know that he would love to get lunch."

There are also lots of people who think they way that Heather Arthur does: that simply not replying is an adequate signal.

I find both to be contemptible.

Great metaphor.

contradictory sequence of words

Use of Docker makes for immediate negation of "easy". At best you can say that it's easier than some other, more difficult thing, but it's not "easy". If you do, then you've got your thumb on the scale, you're doing some Hollywood-style accounting, etc.

It's not. The Hypothesis sidebar loaded from a bookmarklet is a Hypothesis client, ergo it is possible to create a hypothesis client that lives in a single file (say client.html with all scripts inlined) that can be loaded directly from the disk (or dumped onto a host that offer simple, static Web space), and even opened up in a text editor to be read/edited by hand.