bluquark

One interesting thing about gikun is the widely different forms it can take according to the stylistic purposes of the text.

- Most of the time it's simply a pragmatic way to introduce a clarification without breaking the flow of the text, essentially a more concise form of parenthetical or footnote.

- In classical poetry it is used for a variety of effects, for example novel synecdoches. One side of the gikun might refer to a season, and the other side might refer to a key detail the poet idiosyncratically associates with that season.

- But the contemporary Japanese learner usually notices them the most in fantasy/sci-fi manga and novels. In this genre it's used to introduce in-universe jargon while showing its meaning in parallel. At the extreme, it can allow writers to go over-the-top with how much special jargon the universe includes, without slowing down the pace of storytelling. (This can pose quite a challenge for translators!)

Dan's point about being aware of the different levels of inequality in the world is something I strongly agree with, but that should also include the middle-income countries, especially in Latin America and Southeast Asia. For example, a user with a data plan with a monthly limit in the single-digit GBs, and a RAM/CPU profile resembling a decade-old US flagship. That's good enough to use Discourse at all, but the experience will probably be on the unpleasantly slow side. I believe it's primarily this category of user that accounts for Dan's observation that incremental improvements in CPU/RAM/disk measurably improve engagement.

As for users with the lowest-end devices like the Itel P32, Dan's chart seems to prove that no amount of incremental optimization would benefit them. The only thing that might is a wholesale different client architecture that sacrifices features and polish to provide the slimmest code possible. That is, an alternate "lite/basic" mode. Unfortunately, this style of approach has rarely proved successful: the empathy problem returns in a different guise, as US-based developers often make the wrong decisions on which features/polish are essential to keep versus discarded for performance reasons.

For what it's worth I've gone the opposite direction (one language, 70k Anki reps). For me, carefully adding context has largely felt like time wasted at card creation time (which can a surprisingly large proportion of study time per card, given how brisk reviewing usually is) and I've been bothering with it less and less. The default simple cards my dictionary plugin creates are usually good enough for me. I go out of my way to add context on the front of the card now mostly when it's a specialized word almost always seen within that context (so there's zero added value in learning it independently).

I do agree with the general idea that laziness and going easy on yourself is good though. I give myself quite a lot of slack when grading my answers, applying a "my understanding of this word is close enough to avoid confusion in practice" threshold rather than some impractical ideal of native-level mastery.

Anki FSRS moves closer to being a "just-in-time" algorithm based only on user-provided inputs. And although its data structures aren't strictly modular, they come as close as practical to that ideal while still remaining compatible with legacy Anki decks and extensions.

In practice, that's illustrated by the fact that there's now a button to fully recompute all intervals and difficulties based only on your history and the current algorithm tunings. And if you've already been using FSRS and the tunings haven't changed, the recomputation won't have any effect because it's equivalent to the incremental computations after each review.

So in principle it could be thought of as a just-in-time pure function, which involves a cache of generated data only for legacy & performance reasons.

I unfortunately can't find it right now, but I remember seeing a semi-famous quote from the 1950s/60s? calling out variable-speed windshield wipers as an absurd consumerist luxury emblematic of what's wrong with America.

The refrigerator camera sounds like the same kind of thing. Modestly useful feature that may well become standard-issue someday because the underlying components can be made very cheaply at scale.

10x over 75 years is a ~3% risk-free annual return. It looks like ordinary government long-term bonds (like 30-year treasuries) were yielding around 4% in 2008, making this look at first glance like a good deal for Chicago.

However, municipalities with a good credit rating can usually issue bonds that pay out about a third less yield than treasuries, thanks to favorable treatment of municipal bonds in the US tax code. I don't know how healthy Chicago's rating was in 2008 but even if somewhat mediocre, it's likely they could've gotten 3% or less on the bond market.

So at a minimum there was no advantage for the city in signing up for a sweetheart deal with strings attached, instead of covering the shortfall by issuing a bond.

Brooks' definition of a silver bullet was "an order of magnitude improvement" and certainly none of those innovations individually come anywhere close. But I agree it's plausible that combined they might amount to one single order-of-magnitude improvement (as compared to average early-1980s development), for the subset of organizations that apply all of them together effectively.

In my personal experience at my workplace I've certainly observed many times that the quote "Adding manpower to a late software project makes it later." is not universally true. When things go well, onboarding an experienced engineer and assigning them a parallelizable task has often proved a relatively lightweight process on teams I've been on, and I've seen the new member's productivity rapidly exceed their communication burden on the rest of the team.

That might be explainable by how several of the innovations you listed reduce the need for communication between humans. For example, we now need less communication about regressions since CI/CD alerts the responsible party immediately, and we need to ask fewer questions when individuals can examine the entire history of a codebase in version control themselves.

(That doesn't mean Fred Brooks's work is now obsolete, this story is consistent with Brooks's underlying analysis of the problem.)

Well, "need" is subjective. But subpixel rendering has diminishing returns as DPI goes up and (as the article describes) it causes several performance and interoperability problems, so the appropriate DPI threshold to turn it off might reasonably be somewhere lower than parity with print. Everyone agrees it's a good idea on cheap low-dpi displays, but whether it's still worth the costs on so-called "retina" displays is a judgment call.

PPP is for comparing consumer lifestyles. World-tradeable goods like military hardware are precisely the kind of situation where PPP adjustments should not be made.

Of course the sums are not directly comparable for other reasons, such as corruption in Russia and procurement dysfunction in the US. But those factors would need to be estimated explicitly.

(EDIT: Thanks for the replies, I hadn't heard that there also exist specific estimates of "defense-sector PPP", so I acknowledge what I wrote above was wrong.)

One problem of scale here is that unless a tooling investment has made literally 100% of the work easy, most of a developer's workweek almost by definition winds up spent on the remaining slow and hard problems.

So investing in tooling certainly improves productivity, but whether it can make things "fun" depends on which categories of hard/slow problems a given developer enjoys.