hackrmn

Why do they keep making them BIGGER and BIGGER? Our hands don't grow that fast, most adult males have been struggling using their phone with one hand. Only the vocal minority prefers to oversized phone-computer, most of us just want to use it briefly on the go before tucking it back into the pocket, without it tearing a hole in it (which my last two phones have done).

If anyone is listening -- can you put a cap on the dimensions? 5.5" screen is plenty, if I want the cinema experience I will either a) go to cinema or b) use some VR/AR device, for the rest of use cases, like watching a movie on a bus/plane/train, it doesn't weigh up against carrying a brick with you.

Indeed, on the point of parser generators utilizing "text"-based grammar [files], Lexy is not among these.

It's been a while I've had to sit down applying or writing a parser or a parser generator, but it being/offering a "simple recursive descent" parser, does that mean left-recursion is a no-go?

In my opinion, parser libraries/frameworks indeed are all mired by the usual suspects which make adoption painful:

* Must learn another grammar language which for some strange reason I suspect has to do with "tradition", must reside in _a file_ -- as opposed to just be expressed with code (i.e. `bin_expr = Concatenation(Ref('expr'), bin_op, Ref('expr'))`); if a BNF language _is_ used for grammar, it almost always is used with some non-standard syntax for helping resolve shift/reduce errors, etc -- which for me puts it into the same "this is not needed" category

* Defined by the kind of parser that is generated, so implying you have to know parser theory in order to know what languages you will never be able to parse with said library/framework; made even worse when some kludge is added with extensive documentation on how to get out of the predicament because "the parser cannot theoretically handle the grammar/language but it otherwise is really great because it uses ABC kind of parsing which is why we chose it" -- the impression it gives a person who knows parsing enough to know they need to construct a grammar and that the grammar may feature ambiguities, is that they have to learn more parser theory; when you learn more parser theory, you usually just implement your own parser unless you need to parse e.g. C++, admittedly; for case in point, see my remark on the "recursive descent parser" being used with Lexy

To be frank, I like the addition of yet another parser generator -- the more the merrier, because contrary to that one earlier statement, that "parsing is a solved problem", I think it is not -- the theory has substantial headway on the practice, meaning that in theory it is [a solved problem], but in practice it is not, in my experience.

Testing by "simulating" button presses and other actions like that, including inspecting pixels, is part of so-called "black-box" testing, and offers merit(s) of its own. At least because software is used by people who click buttons which may modify pixels, and these people are not concerned what your model is, they don't even know anything about the way you may have implemented the latter. In the end everything is run on a fairly RISC-y CPU, it either works or it doesn't (from user's perspective) -- replicating the user's workflow is useful in that it it uncovers issues that matter to users and thus normally affect your bottomline.

In my experience, writing readable code and writing code that behaves correctly (fulfills the contract/requirements without hiding potential faults) is often mutually exclusive -- most people end up doing one or the other. This is related to the never-ending functional programming vs. "traditional programming" (a target in motion, largely OOP or in the very least "whatever is taught at the graduate schools"), since the former, in contrast to the article which pretty much _assumes_ the latter, doesn't even facilitate "variables", literally or in informal sense (things you can "assign to", whether changing or not).

Anyway, I happen to belong in the latter category according to most -- the longer I have been doing this, the more I lean into the purely functional style, almost mathematical vigor, because I have learned how much (or rather little) margin there is to introduce subtle errors once you have actual _variables_ that may change freely, which start to encourage you to do other things which in the end contribute to lack of correctness, readable or not.

Now, you may blame people like me, and I cannot blame you for not having the cognitive load capacity to understand some of the code I write "succinctly", but my point is that for all the merit of the article (yes, I agree code is read much more often than it is written, lending value to the "readability" argument), it doesn't acknowledge the fact readability and correctness are _in practice_ often mutually exclusive. Like, in the field. Because I wager that the tendency is to approach a more mathematical expression style as one becomes better at designing software, with adversarial conditions manifesting in terms of bugs hiding in mutability of state and large, if "simple", bodies of functions, classes (which have methods you cannot guarantee to not mutate the object's state).

We need to find means to write code that is readable but without compromising other factors like mutability which _too_ has been shown to compromise correctness. What good is readable software that never manages to escape the vortex of issues, driving the perpetually busy industry "fixing bugs".

At my place of work, I obviously see both kinds of the "mutually exclusive", and I can tell you without due pride and yet with good confidence, people who write readable code -- consisting of aliasing otherwise complex expression with eloquently named variables (or sometimes even "constants", bless their heart), and designing clumsy class hierarchies -- spend a lot of subsequent effort never being able to be "done" with the code, and I don't mean just because requirements keep changing, no -- they sit and essentially "fixup commit" to the code they write, in perpetuity, seemingly. And we have select few who'd write a code-base with as few variables as possible, with a lot of pure function -- what I referred to as "mathematical programming" in a way -- and I never hear from them much offering "PRs" to fix their earlier mishaps. The message that sends me is pretty clear.

So yeah, by all means, let's find ways to write code our fellow man can understand, but the article glosses over a factor that is at least as important -- all the mutability and care for "cognitive load" capacity (which _may be_ lower for current generation of software engineers vs earlier ones) may be keeping us in the rotating vortex of bugs we so "proudly" crouch over as we pretend we are "busy". I, for one, prefer to write code that works right from get-go, and not have to come back to said code unless the requirements which made me write it the way I did, change. On a very rare occasion, admittedly, I have to sacrifice readability for correctness, not because it's inherently one or the other, but because I too haven't yet found the perfect means to always have both, and yet correctness is on the absolute top of my list, and I advocate that it should be on top of your as well, dare I to say so. But that is me -- perhaps I set the bar too high?

Current state of things is a mixed bag, in my opinion. XSLT wasn't perfect, and XML required a lot of repetition and neither got the amount of scrutiny both deserved to advance past their own inconvenience. But a lot of what we have today has just as many drawbacks, and that _despite_ WHATWG and Google hawking over it all. XML had namespaces, which alone were quite a potent feature that allowed to manage _semantics_ of data with more rigor and flexibility -- compared to the in my opinion amateur-ish "custom elements" HTML 5 approach, and how Apple refuses to implement parts of the spec., because they "don't believe in inheritance" (I am being liberal but those who know know). Then there is the HTML 5 parser itself -- "for the masses" -- with its idiotic and incomprehensible rules that are element specific, for which reason noone ever remembers these. Forgot a `</p>`? No problem, you can discover your omission after you've shipped! HTML 5 parser never aborts!

Is XSLT enjoying the equivalent of Streisand Effect? Ever since news came out of Google wanting to rid Chrome of XSLT support, there has been a number of XSLT-related news here. I am not complaining, I think XSLT deserves a second life, it hasn't had the scrutiny it deserves, nor its "15 years of fame".

I've not heard of Jane Street, but looking at the site, it seems they're quite the tech-savvy group for an _asset trading_ company. And reading the article, they apparently "trade" (pun intended) in quite a few different things from CSS to OCaml, which is really nice to see for a place that doesn't directly deal with software as their [business] product (or did I misunderstand their market?).

In software engineering the statement "interfaces, not implementations" has been used for a long time (certainly at least Robert "Uncle Bob" C. Martin started teaching), which is a generalization on the "we don't break userspace". In essence it cooks down to declaring an interface without announcing or depending on the implementation. With OOP languages like C++, a code base would aggressively use interfaces as types, never concrete class types (which implement the interface), so that it can make it easier to reason about how and whether the program behaves when one implementation of an interface is swapped for another.

With Linux, which is a C codebase by and large, they load and pass pointers to structures to kernel procedures which can do as they please -- as long as the documentation on said structures (which usually says which fields and how are retained with which values and so on) remains unchanged. That's their "object oriented programming" (yeah, I know Linus would likely have hated the comparison).

I've always been a staunch opponent of using `/v1/` kind of element in the URL. I understand its function and the convenience it allows for "versioning", but I grew up with HTTP and I always liked how it insisted the URL is well, the _location_ of the _resource_, and `/v1/` just muddies things up being in the URL -- it's obviously not a version of the resource that `/v1/` would be indicating, but of the API implementation, which is the first telltale sign that it's an architectural "blunder", and these compound in my experience, always and invariably given enough time.

If the consumer wants to consume a specific version of the API, the means to do so can be implemented with an alternative domain name, or -- even better (who wants to maintain alternative domain names) -- with a request _header_, e.g. `X-API-Version: v1` (or another one, perhaps a standardised one).

In any case, the `/v1/` thing is something of cargo cult programming -- I remember someone proposed it a good while ago, and it's been adopted since without much afterthought, it seems. It doesn't make sense to debate pros and cons of REST/HATEOAS if your resource identifier scheme is poorly designed, IMO.

I know opinions are divided on what I am about to mention, but what about CAPTCHA to filter bots? Yes, I am well aware we're a decade past a lot of CAPTCHA being broken by _algorithms_, but I believe it is still a relatively useful general solution, technically -- question is, would we want to filter non-humans, effectively? I am myself on the fence about this, big fan of what HTTP allows us to do, and I mean specifically computer-to-computer (automation/bots/etc) HTTP clients. But with the geopolitical landscape of today, where Internet has become a tug of war (sometimes literally), maybe Butlerian Jihad was onto something? China and Russia are blatantly and near-openly shoving their fingers in every hole they can find, and if this is normalized so will Europe and U.S., for countermeasure (at least one could imagine it being the case). One could also allow bots -- clients unable to solve CAPTCHA -- access to very simplified, distilled and _reduced_ content, to give them the minimal goodwill to "index" and "crawl" for ostensibly "good" purposes.

This isn't accurate. I mean in generally you're pointing in the right direction. Your vague statements on "esoteric OS" are not helpful, and in fact I think that it is maybe _you_ who don't know your computer as well as the person you were replying to, do -- after all they bring up relevant and actual details while you point at generalities like "Mail > Google".

Let me try to steer this in a constructive direction -- you're implying use of "GMail" with your "Mail > Google". That is fine -- it's certainly possible to set up a Google account with Mac OS X through the "Accounts" feature, implying SSO and/or reusable credentials API.

But that does not come as default with the OS, and it requires active user participation, which makes your argument a bit of shifting the goal posts indeed -- Mac OS X does not send any data to Google by default, not out of the box. You do not need an "esoteric OS", and such an OS set up with something like described above for Mac OS X, or to demonstrate the simplicity of your argument, a Google Chrome binary blob (e.g. Ubuntu) makes the OS much less "esoteric" since it's now too a "Google vehicle". Point being that Mac OS is not a Google vehicle by default. Neither is Windows, for that matter. And this for a very simple reason -- normally both Apple and Microsoft are _competitors_ to Google, and they would very much prefer the data they would have been able to collect on the user, is sent upstream to Apple and Microsoft respectively, not to their competitor. But that is tangential, again -- the primary point is that by default Internet is not Google, not with e.g. Firefox on Windows.

Let me be perfectly clear -- there's zero tracking by Google unless you use one or multiple of a) a Google provided Web browser, e.g. Chrome, and b) use Google's Web services. By using e.g. Firefox (which is indeed funded by Google) your data are _not_ sent to Google by default, and a Web extension like uMatrix also nips attempts by sites to send data to Google, in the bud. None of this is an esoteric OS.

I have nothing against warning us against Google monopoly, but I find your follow-up replies to be deflections and doubling down when the person is making it perfectly clear that their network does not contain data being sent to Google (in as far as they can trust their packet logs, I would say, but if you were to contest that, you'd need to try harder indeed).

> can anyone explain the modern trend of not including publishing dates in blog articles?

In such cases, I usually try to see if the `Last-Modified` header served with the HTML document over HTTP, can be useful, but I conclude that often the same people who don't bother with dating their content -- you'd think they'd understand where the word _blog_ comes from, as in "[web]-log" where timestamps are paramount -- these same people don't know or care how HTTP works. Hint: the `Last-Modified` is the last modification time of the _resource_, in this case the actual HTML document. Just because your "backend" re-rendered the content because you didn't bother with setting up your server caching correctly, doesn't mean you should pretend it's a brand new content every day (which https://jakub.kr/components/oklch-colors does, unfortunately, so you won't know the timestamp from HTTP).

Well, it only took about 15 hours for the site to be discovered by the Internet Troll Federation and be absolutely stuffed with slurs and hate memes.

Which was to be expected, frankly.

Not sure at which point the site allowed HTML, but for the first couple of hours or so there was only text for thoughts there, then the "hypermedia" of the kind described above, appeared, rendering the site useless. Just wait until someone discovers even better means to weaponize the HTML post feature -- there's bound to be galore of client-side vulnerabilities, I expect, if only due to Unicode possibilities...

While an alluring title, and commendable argument, I do not necessarily think this is about computer or user interfaces. Ok, so I, instead of navigating Finder, or Windows Explorer, or something analogous where I have an idea in my head of where my _files_ (a tangible, while "transferred" concept) are, ask an AI agent "list files I was working on last week". This does not imply a computing problem unless by "computing" you mean I am unable to organize myself and my head does not compute -- I either know where my files are, or I don't. An AI complements my memory here, this isn't a UI problem, it's just me getting lazier or more complacent, like someone with "functioning depression" who gets by at the cost of living in a "functioning mess". I am not sure I would want to hold myself to such a standard. If this was only about efficiency -- sure, let the AI complement myself, but this starts to look like explaining sheer lack of organizaiton and calling it "the end of tooling" (because I can't or won't use the tooling anyway, too much hassle). Meaning that us advancing into a WALL-E (or "Idiocracy") age where we just voice commands to AIs while we literally lie on a bed -- is that a good thing?

Let me try to clarify and simplify my rambling: I would like AI to help me, I do, but I should know where my project files are, should I not? If our memory isn't needed, I am sure evolution will shrink it. Then we put an "AI" in our brain to remember for us, and the circle is complete?

I appreciate your response. I made a point of not revising my comment after posting it and finding in a subsequent parable the following, quoting:

> Each SM is broken up into 4 identical quadrants, which NVIDIA calls SM subpartitions, each containing a Tensor Core, 16k 32-bit registers, and a SIMD/SIMT vector arithmetic unit called a Warp Scheduler, whose lanes (ALUs) NVIDIA calls CUDA Cores.

And right after:

> CUDA Cores: each subpartition contains a set of ALUs called CUDA Cores that do SIMD/SIMT vector arithmetic.

So, to your defense and my shame -- you *did* do better than I was able to infer from first glance. And I can take absolutely no issue with a piece elaborating on originally "vague" sentence later on -- we need to read top to bottom, after all.

Much of the difficulty with laying out knowledge in written word is inherent constraints like choosing between deferring detail to "further down" at the expense of giving the "bird's eye view". I mean there is a reason writing is hard, technical writing perhaps more so, in a way. You're doing much better than a lot of other stuff I've had to learn with, so I can only thank you to have done as much as you already have.

To be more constructive still, I agree the border between clarity and utility isn't always clearly drawn. But I think you can think of it as a service to your readers -- go with precision I say -- if you really presuppose the reader should know SIMD, chances are they are able to grok a new definition like "SIMD lane" if you define it _once_ and _well_. You don't need to be "unwieldy" in repetition -- the first time may be hard but you only need to do it once.

I am rambling. I do believe there are worse and better ways to impart knowledge of the kind in writing, but I too obviously don't have the answers, so my criticism was in part inconstructive, just a sheer outcry of mild frustration once I started conflating things from the get go but before I decided to give it a more thorough read.

One last thing though: I always like when a follow-up article starts with a preamble along of "In the previous part of the series..." so new visitors can simultaneously become aware there's prior knowledge that may be assumed, _and_ navigate their way to desired point in the series, all the way to the start perhaps. That frees you from e.g. wanting to annotate abbreviations in every part, if you want to avoid doing that.

Plenty of circumstantial evidence pointing to the fact NVIDIA prefers to hand out semi-tailored documentaion resources to signatories and other "VIPs", if not the least to exert control over who and how uses their products. I wouldn't put it past them to routinely neglect their _public_ documentation, for one reason or another that makes commercial sense to them but not the public. As for incentives, go figure indeed -- you'd think by walling off API documentation, they're shooting themselves in the feet every day, but in these days of betting it all on AI, which means selling GPUs, software and those same NDA-signed VIP-documentation articles to "partners", maybe they're all set anyway and care even less for the odd developer who wants to know how their flagship GPU works.

I grew up learning programming on a genuine IBM PC running MS-DOS, neither of which was FOSS but taught me plenty that I routinely rely on today in one form or another.

I find the piece, much like a lot of other documentation, "imprecise". Like most such efforts, it likely caters to a group of people expected to benefit from being explained what a GPU is, but it fumbles it terms, e.g. (the first image with burned-in text):

> The "Warp Scheduler" is a SIMD vector unit like the TPU VPU with 32 lanes, called "CUDA Cores"

It's not clear from the above what a "CUDA core" (singular) _is_ -- this is the archetypical "let me explain things to you" error most people make, in good faith usually -- if I don't know the material, and I am out to understand, then you have gotten me to read all of it but without making clear the very objects of your explanation.

And so, for these kind of "compounding errors", people who the piece was likely targeted at, are none the wiser really, while those who already have a good grasp of the concepts attempted explained, like what a CUDA core actually is, already know most of what the piece is trying to explain anyway.

My advice to everyone who starts out with a back of envelope cheatsheet then decides to publish it "for the good of mankind", e.g. on Github: please be surgically precise with your terms -- the terms are your trading cards, then come the verbs etc. I mean this is all writing 101, but it's a rare thing, evidently. Don't mix and match terms, don't conflate them (the reader will do it for you many times over for free if you're sloppy), and be diligent with analogies.

Evidently, the piece may have been written to help those already familiar with TPU terminology -- it mentions "MXU" but there's no telling what that is.

I understand I am asking for a tall order, but the piece is long and all the effort that was put in, could have been complemented with minimal extra hypertext, like annotated abbreviations like "MXU".

I can always ask $AI to do the equivalent for me, which is a tragedy according to some.

Native applications is a relatively fragmented market of different hardware and OS for platform, made more complicated by relative lack of interest (which is because the market is fragmented, a catch-22), and factors like needing to learn another programming language when you already know JavaScript and how it works on the Web, which is taught to more people every year for obvious reasons. Which is all why Github Electron, essentially a Google Chrome married to Node.js, both _JavaScript_ platforms, made such an impact when it was released. There's zero-install on the Web, too -- just follow a link and you're surfing applications. Python+Qt applications have to be installed, even if that means downloading these -- there's plenty of hosts configured to deny the user the privileges of running software they downloaded, no matter how native and how well mannered it is otherwise. There's fewer pairs of hands on the job (part of catch-22), and there's more standards and APIs to deal with, due to the fragmentation, even for all the cross-platform offerings. All this no doubt contributes to the market staying behind the juggernaut that the Web has become.

Before you roll your eyes and label me a millennial who's not seen anything but the absolutely appalling Web applications of yesteryear, fresh off inexperienced hands of developers who think they invented caching and what not -- I started off with x86 assembler and C then C++ in early 90's, and I hold genuine interest in everything we learned since before Intel made 8088 -- but I am simply describing the reality I see, not necessarily reality I want.

You're drawing a border on water -- there's no need to "separate" the Web from native. The Web is an application platform developed from a hypertext network (the old Web I re-label for comparison's sake), and the platform has tremendous value. You need to have tunnel vision to want to put genie back into the bottle, but again -- I absolutely hear and understand your argument. Do you have realistic suggestions?

Drew DeVault suggested another protocol, Gemini, a while back, having become frustrated with much the same observation you did. Just text mark-up served with efficient text-based protocol -- essentially a regression back to HTTP and HTML anno 1995 (possibly with more semantic elements). I think it's not only a fantasy but also a poor idea -- not because it's a bad idea in itself but because it assumes there's no possibility to do any of it with today's Web, but there is -- it's just that everyone's reaching for the fancy and the flashy once they start coding. What you were referring to with "focus jump around" and "shifting layout". We're sacks of flesh driven by hormones -- that's the best reason I can give you why the same platform that allows you to slap [a HTML that's worth reading](http://motherfuckingwebsite.com/), possibly [with a simple stylesheet that does the bare minimum to improve user's experience](http://bettermotherfuckingwebsite.com) -- is _not enough_ for authors. I'd call it "author's prerogative" -- the person who pays for the domain and the hosting, wants to exercise their authoring power and gets carried away with all the bells and whistles they slap on their pages. Users pull their hair out, in silence (or mostly ignored because "do I paint the walls in your house?").

Anyway, this is getting long -- the gist of my argument is that technically the Web is capable of supporting all the static HTML without an ounce of "shitty" scripting that makes everything border on "unconsumable". You're making a "dictatorship" argument along "if you can't make good readable sites, we're going to neuter the platform". But the platform _is_ what drives adoption of the Web, I say, albeit now nearing some cancerous growth from a skeptic's perspective. And yet: fix the _content_, not the _platform_. "Native" is just a word -- there's no native, everything is translated or compiled one way or another, including JavaScript (which _I_ consider a relatively bad general purpose programming language, even under ECMA oversight which fixed a lot of its warts, admittedly). Unless you're one of those ["real programmers"](https://xkcd.com/378/).

I'd argue that depends on what you mean by "innovation" -- Google has been pretty busy, meaning specifically developers on their payroll, churning out more or less useful Web API implementations, certainly at a far more frantic pace than people traditionally _blamed_ browsers of yester-decade for. Nevermind that some of these APIs are more haphazardly designed than others, truth be told most of them are okay and are aptly designed so it's not a critical issue (for Web developers or Chrome's market share). Google co-authors most Web standards and implement them often _before_ the "standard" is published (for better and for worse; anti-trust allegations, I am looking at you). But they're not idle, one thing's for sure. Markedly different than how I remember Microsoft resting for months if not years on their IE laurels, like a CO2 blanket in a room that evacuated all the air.

So yeah, how would you describe this lack of innovation you're referring to?

There can always be more innovation that isn't of the sort I described above, but Web _is_ made of Web APIs -- if a website cannot "do" it, you as a user of the site, won't be able to experience it, is my crude opinion. But I'd love to hear examples to the contrary, illustrating innovation that isn't Web APIs.

Removing tab-based browsing (an anti-pattern if you ask me)? Optimizations (speed, size, etc)?

I get your point, I do. Then again, a lot can be said about the "PR value" of letting what could be miniscule (by comparison) costs of serving static hypertext, be saved in the eyes of "potential" customers. It's pennies on the dollar and I am fairly sure Microsoft would get a lot more love from the "neckbeards" who need the old-school stuff and not the toys they insist on dangling in front of our faces (which they are famous for). Remember when Microsoft tried to get everyone away from Win32 by force-feeding everyone WinRT, writing "deprecated" over the former everywhere they could on their site(s), only to witness such a shit-storm of complaint and fury from people who actually rightfully knew Win32 was, for all its faults, one of the better things Microsoft has given us (in context of Windows programming, that is)?

Speaking of Win32 but not only that, I too have started being more cautious and pedantic about user manuals and other "paraphernalia" I have to rely on, for instance Win32 API documentation which is getting more scarce to find in sufficient volume and specifically _detail_. So I download and archive it (with implied off-site backup, which I have for most of my "home directory" stuff) -- I agree the only way to guarantee access is to, well, obtain a copy of the document...

With "free range organic" are you describing people or food? As in, "it's better to be a free range organic human [vs. battery/caged livestock human-like resource for exploitation]", or "it's better to _eat_ free range organic [food]"? These are two different things, and in either case I'd argue not an option for the people who struggle affording food that is health(ier) by modern standards.

So Tonsky's punishing us for leaving JavaScript enabled?

My go-to reaction to these things that Microsoft does, removing content, is always the same:

Microsoft, are you running low on hosting space, or something?

I mean, how does one of worlds largest software corporations, handing people OneDrive accounts left and right, not to mention all the other digital waste they're busily involved with, lack storage space for some valuable archive pertaining to use of one of the world's most popular OS and associated software suites? Someone should just forbid them to "retire" content, especially if posted by actual people.

Fortunately, The Wayback Machine / Internet Archive works overtime to take upon themselves the responsibility I think would have been best left to Microsoft.

Related: https://htmx.org/essays/htmx-sucks/ (on the actual HTMX upstream site)

Saying "I don't care about 'privacy' because I have nothing to hide" can be compared to saying "I don't care about free speech because I have nothing to say". Which says a lot, frankly.

I've been shouting this from "the rooftops" ever since I eventually independently had come to the same conclusion through sufficient volume of experience and empiry. I consider it a small tragedy, however, that my words tend to fall on deaf ears as I try to explain to e.g. co-workers why they should, in fact, parse their input and use the language's type system to their advantage, vs. all the `validateThis` and `validateThat` they seem to be copying from e.g. Stack Overflow. I see them stumbling and breaking their nose time and again passing URIs around as strings -- even in languages other than C (so this isn't obviously a problem C created and needs to solve alone) -- where it's never enforced that the URI is e.g. "absolute" or "relative" (nevermind the fact these people often don't seem to care for the difference). They do the same error with date and time (how many decades of advice do we need to accumulate and impart on our younger peers for them to irrevocably understand why e.g. date and time should never be passed around as numbers or strings, with very clearly documented and justified exceptions?). But the tragedy is never more evident when the person looks at you like you're suddenly talking Klingon to them and how bored they are with the notion and how it cannot be so important as to disturb their very important "coding project" (we don't write Knuth's "literal" programs any more -- we _code_).

I, too, have been saying this on occasion. In my observation, Mozilla has been in an increasingly suboptimal position with Firefox, for a while now, as Google and Microsoft have largely settled on splitting the market in between themselves where the core of Chrome is developed by the former and Microsoft spends their effort on what they are [better] at -- integration with Windows in the form of UX-level features and whatever else that they do with it to build Edge. Firefox is increasingly seen as a "fair" nuisance that is slower, and by comparison can afford less effort development-wise. Look at some of the practically critical issues in their Bugzilla database -- there are features there that have been waiting almost a decade for implementation, and the discussions point to a combination of code complexity that requires acute insight into the browser that is your typical bell curve distributed over developers familiar with it -- the number of developers who are able to actually deliver on those features, can probably be counted on two hands. And that is in part because most of these people are getting paid to do other things. In the very least Mozilla directs their effort in a manner that speaks for itself -- why are some of these features, like https://bugzilla.mozilla.org/show_bug.cgi?id=1360870 that would be considered critical in today's Web development environment, not implemented after nearly a decade? -- If Mozilla _is_ paying the developers?

This is why I too think we ought to migrate to Patreon-like direct sponsoring of individual (or vetted group) effort to generate some development steam for Firefox. It might make Mozilla deny these developers write-access to Firefox repositories for all I know, but a fork cannot be prevented.

I've been using Firefox since its "Phoenix" days (good memories!), but it's lagging behind the competition more and more, and while I'd be first to admit we don't need half the features Google is busy putting into Chrome which then "magically" appear in Edge (what a devious alliance, that), some of them are sound design but are absent in Firefox, to the detriment of developers. In short: Firefox is losing more ground faster than ever before, at some point the boundary conditions will cause it to no longer be a viable alternative for the average user, I am afraid. Which will cause a "cascading failure" where no developer will test for it, and you know what happens then (because we've been there before).

Given what you're vaguely implying -- that the switches would be nowhere near the first thing a pilot would normally think of in the kind of situation -- what are the odds the pilot asking on record "did you flip the fuel cut-off switch?" is the one who actually flipped the switches and was simply trying to fool the would-be investigation (even knowing they all are about to perish)?