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

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

@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

Good case for S4/BYFOB+bookmarklets.

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.

That's a good reason to make sure it's verified by the compiler (or, if you prefer, that the project source code is validated against the documentation)—not dissimilar from the way compilers' typecheckers already work.

See above https://hypothes.is/a/YInIGFvMEe2Z3G-_AAsduQ

On the other hand, those features may have actually sent us back.

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

if I can't make sense of it and be productive in it with just vim, grep, and find, your code is too complex

I'd be willing to relax the requirements (or should that be "tighten" in this context?) and say that even grep and find should not be necessary, either. That's one of the worst parts about working with C or Go codebases—having to resort to each just to figure out where stuff lives. The circumstances that lead to "A lot of engineering is looking for things" are something that we should be trying to rectify, not accommodate.

See below https://hypothes.is/a/sSSKKFvNEe2UV99rNBoV0Q

One of the most important questions (if not the most important question) to keep in mind when writing code comments. This is what you should be seeking to answer.

This project gets it backwards.

We should not be writing in compiled languages with inline type annotations a la TypeScript and generating documentation from that (the same thing javadoc did 20+ years ago). We should be writing ordinary docs and working with tools that can ingest those, extract the information contained there, and validate the codebase+docs combo for coherence.

If you are seeing this message, try joining the triplescripts.org Hypothesis group.

Related: * https://hypothes.is/a/p6VM5rswEeyqyks2ynu8Bg * https://hypothes.is/a/vcKzHElbEeuSGo9Gi3k3Ng

You need to be in the triplescripts.org group to see this annotation.

Membership is semi-private, but only as a consequence of current limitations of the Hypothes.is service.

A copy of this annotation has been published in the Hypothes.is Public stream, which explains in detail that anyone is permitted to join.

Not so dissimilar to today (minus the taunting). Despite the ubiquity of what is loosely called the Web platform (i.e. the world accessible through ubiquitous, roughly W3C-/WHATWG-compliant browsers), the Web fundamentals that TBL originally wrote about in the early 90s has still yet to be embraced.

The error lies in the decision to alias /resource access to the contents of /resource.html. That's something that should not happen. It's as straightforward as that.

This is the key. It follows that the same results, then, could be seen if we devised a way to communicate the same desires to the machine when we're dealing with JS. (My preferred thought experiment: imagine a docs/ directory in the repo where these sorts of things are documented for the benefit of other programmers—alongside any other rationale that you would naturally hope to communicate as well—and that the computer itself were made to be able to read and act upon the very same documentation to guide its behavior.) See http://cr.yp.to/qhasm/literature.html

I have referred to this in the past as an emphasis on actor-based indexing, versus topic-based.

Why are people so seduced by this dumb argument—to the point that they almost seem proud of it?

First, it's presumptuous. Who says we're even using glibc instead of some other libc—which I just might choose to include in the projects I work on? Who says we're even using Linux, for that matter?

Secondly, even if we were, let's assume that we're not, and then see if that teaches us anything about the overall line of reasoning. The original comment was about NPM. NPM is used a fair bit for not just backend stuff but for managing packages used in the browser, too. Let's assume, for simplicity, that our program is entirely a browser-based JS+HTML+CSS app with no backend to speak of. Would the same people argue that, among other things, the Web browser sources would need to be included? Does it even make sense to argue that? Asking the system software question betrays a failure to accurately grapple with the classes of software artifacts we're dealing with, their role in the overall project, and our responsibility for them.

I think this is a terrible choice for "another example" (that is presumably supposed to be easier to follow in order to communicate what the curse of knowledge is). This whole paragraph should have been cut (or at least replaced with something better).

There's the honest part. It's a rhetorical sleight of hand meant to confer an advantage to the person rewriting the others' actual words—which, to repeat, would not be necessary if the two were actually "n[o]t significantly different" in the first place.

There's now a "long, 50+ comment chain" attached to the false quote. If this isn't sufficient to catch the eye and serve as a flag that the thing that you're saying they said isn't actually what they said, then there's no hope for agreement.

Once again: have some self-awareness.

Yes it does. Shutting down low-effort, Twitter-level dunking built upon made up quotes is worthwhile all on its own. And as a rule that when enforced minimizes confusion and mendacity, it's doubly worthwhile.

It's sorted. There's just a contingent pretending that there's something about it that isn't.

Yes.

Yes.

Yes.

Geez. Have some self-awareness, bud.

There's nothing idiosyncratic about saying that you should distinguish quotes from non-quotes by abstaining from formatting the latter the same way as the former.

Use quotation marks to make it clear you're quoting somebody if you want. If you're not quoting somebody, don't do that. Don't build up a caricature based upon you would have liked for them to have said (so it's easier to pillory) instead of what they actually said.

This shit's easy.

In that case: great! no problem, then—just use the original wording, since by your own argument they are not significantly different; the original is sufficient.

Lots of comments here reminiscent about this restatement of the true purpose of the free software movement:

I know it's socially acceptable[...] to dump on Stallman's "software freedom"—or at least the choice of words to describe it—but this is exactly the kind of thing that it is meant to address. Superficially, Signal might look like it has the right accoutrements, having adopted a FOSS license and all, but it's not free software. Nothing that holds folks' systems and data hostage unless you comply with the program author's whims can be considered FOSS.

See also: Why Open Source Misses the Point of Free Software

When people, in response to some problem, just end up restating the problem factors as if it explains or addresses anything at all.

No.

I don't know why they wrote this; they know this isn't true. It's not just a case of me being a stickler/pedant. This example should have simply never been used.

Perhaps that should be addressed, rather than treating it as bedrock upon which to build.

Having only recently "got" what Wirth originally meant when he wrote about texts in Oberon as abstract data types, I'm sort of partial to something like that.

nit: should be "to roll back" here

The running program, that is (as just described).

Reminiscent of The Pinocchio Problem.

Reminiscent of the distinctions Martin Fowler makes on Projectional Editing.

@1:10:20

With HTML you have, broadly speaking, an experience and you have content and CSS and a browser and a server and it all comes together at a particular moment in time, and the end user sitting at a desktop or holding their phone they get to see something. That includes dynamic content, or an ad was served, or whatever it is—it's an experience. PDF on the otherhand is a record. It persists, and I can share it with you. I can deliver it to you [...]

NB: I agree with the distinction being made here, but I disagree that the former description is inherent to HTML. It's not inherent to anything, really, so much as it is emergent—the result of people acting as if they're dealing in live systems when they shouldn't.

@48:20

I should actually add that the PDF specification only specifies the file format and very few what we call process requirements on software, so a lot of those sort of experiential things are actually not defined in the PDF spec.

See also:

Alas, many things really must be experienced to be understood. We didn’t have much of an experience to deliver to them though — after all, the whole point of all this evangelizing was to get people to give us money to pay for developing the software in the first place! [...] When people ask me about my life’s ambitions, I often joke that my goal is to become independently wealthy so that I can afford to get some work done. Mainly that’s about being able to do things without having to explain them first, so that the finished product can be the explanation. I think this will be a major labor saving improvement.

From http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/

The metadata for this collection are not so great. Have a look here, instead: https://archive.org/details/pub_whole-earth

High fidelity scans are available at the Internet Archive: https://archive.org/details/sim_whole-earth_spring-1987_54/page/n3/mode/1up

This quote is introduced without a clear antecedent. What is it a reference to?

@55:10

Sri: [...] you can think about the possibility that we're actually going to do this with structured data but then properly incentivizing people in order to actually moderate and curate the set of facts about the world—

Will: Yeah, so I was gonna mention that, and I'm glad we're on the same wavelength here. What are the economic incentives that would help encourage the adding of correct, factual data to this knowledge graph and dissuade, I guess, spammers? [...]

Sri: Yeah, I think that there needs to be some compelling reason for people to want to add data to the knowledge graph. [...] I think that, "Can we get a knowledge graph that is expansive—as expansive as Wikipedia—that, you know, says all kinds of facts about the entire world?" Yeah, maybe[...]

Will: There are parts of the Web where people do that without financial incentives. I mean people list like every episode of, I dunno, Game of Thrones and annotate every time that people get killed or [...] all sorts of stuff. Fandom is like [a] huge thing and they just put out these... or like the—if you ever played Minecraft and looked at the Minecraft wiki, it's just so (chuckles) so detailed. Like, "Who spends all their time...?" [...]

Sri: The idea of fandom actually is very relevant here, because [...] I have so far been thinking about the idea that the incentives have to be backed by some type of economic value—

Will: Yeah, for a certain class of things [...] There are some things that are very well-tuned to economic incentives and the other stuff is well-tuned to fandom, right?

Video available here: https://www.youtube.com/watch?v=bjn5jSemPws

For checking which posts are new/updated, this is always the case. The only thing the HTTP cache-related headers can tell is that the feed itself has/hasn't changed.

Huh?

Bluh? This is exactly what looking for link[rel=alternate] is for—these "patterns" listed are arbitrary URLs...

Crazy! This underscores how badly Mastodon—and ActivityPub, generally—need to be revved to enable network participation from low-cost (essentially free) static* sites.

* quasi-static, really—in the way that RSS-enabled blogs are generally considered static sites

⬑ what khinsen calls software collapse

• limit capabilities it depends on (POLA)
• target the World Wide Wruntime (i.e. the browser), which is the only reliable platform that exists and can be expected to exist in the future

⬑ "The Code Rot Problem"

This page has a neat effect, first apparent with this example, where a blur effect is used on most of the text in the code block, except for lines 11–13 which are shown in sharp focus. (You can mouse over the code block to eliminate the blur effect.)

.torchlight.has-focus-lines .line:not(.line-focus) {
        transition: filter 0.35s, opacity 0.35s;
        filter: blur(.095rem);
        opacity: .65;
}

Each line is dumped into a div and the line-focus class set on those which are supposed to be unblurred.

(For ordinary code blocks without any blur/focus effect, the has-focus-class line is simply not used.)

This doesn't need to happen, and wouldn't happen if people treated blog posts for what they are—artifacts—instead of conceptualizing them as live systems.

That's not good.

The phrase "optional dependency" is an oxymoron.

The answer is ZIP and wget/curl and forgetting about sharing dependencies. Disk space is way cheaper than the time spent (often in frustration) trying to get something to work.

Not angling towards that sort of future is a lot like people from the punch card and paper tape era not allowing the computers do the stuff that computers do better than humans when it became cheap enough to let computers do it.

Good response overall, but with respect to this remark, I have been in different but not dissimilar situations where something like this does happen.

E.g. person notices that every time they enter a room (kitchen, let's say) everything looks just like it did the last time they saw it, and they aren't ever interrupted e.g. by my trying to use the space at the same time that they are. They then (incorrectly) conclude that it looks that way because I just never use that space (and it's okay for them to make a mess, or not worry about being mindful of how much time they're using the space for)—rather than registering the thought, "Gee, he really picks up after himself and tries to stay out of the way—a real life example of 'you won't even notice I'm here'. Maybe I should be that considerate."

@35:19

"This is how the working classes are robbed. Although their incomes are the lowest, they're compelled to buy the most expensive articles[...] the lowest priced articles. Everybody knows that good clothes, boots, or furniture are really the cheapest in the end, although they cost more money at first; but the working classes can seldom or never afford to buy good things. They have to buy cheap rubbish which is dear at any price."

@31:25 Robert Noonan's story.

Type-B procrastination accounts for a lot of the junk I see on people's GitHub timelines—and that type of social network-backed gamified gratification is why I've adopted a stance where I impose a huge entry fee on any workflow that routes itself through GitHub's servers.

Every time Bill Maher goes off on a tear about how American society should venerate old people the same way it happens in other countries, I can't help but think, "What 20 year old was Bill trying to fuck this week that led to these hurt feelings?" I'm picking up hints of that here, too.

Is this Paul's way of getting out of responsibilities? "No, I don't need to do that. See? I wrote a piece about it!"

@55:39

I would feel a little bit sad, but at the same time, this is a pattern I've seen happen over and over again. And especially with these big ideas about computing and self-expression and things like that [...] people start with these huge, huge ideas, but I think that they are so different--the diff is so much between where society is now and what some of these people are thinking about--that the most that can be absorbed at one time is like one unit--one meme--from that whole big vision. So, we're just gonna take like one small step at a time, and [...] you kind of just have to accept that, you know, that's success.

Garner, Bryan A. "Celebrating Plain English in Michigan." ABA Journal 107.5 (2021): 36. Business Insights: Global. Web. 7 Oct. 2022. URL http://bi.gale.com.atxlibrary.idm.oclc.org/global/article/GALE|A690034782/c13f1855872f0a231a7139cf729c45b6?u=txshrpub100020

Document Number: GALE|A690034782