Twey

> The result is that we will live in a demon-haunted world, full of marvelous devices whose operation we will not understand, based on engineering principles we will not understand, discovered using formalisms we will not understand.

Well, that's just where we started — and then we developed science and mathematics to understand it. Why would it be any different if the demons live in our technological progeny instead of the natural world?

In constructive mathematics I think you'd be right: to call a problem decidable would require you to produce the algorithm that decides it, so you couldn't call the Collatz conjecture decidable (nor could you call it undecidable!). But the usual definition of decidability is classical.

This is slightly bizarre now I think about it: the definition of decidability allows the algorithm selection to be undecidable!

We have official government ID (the national insurance number, roughly equivalent to a USian SSN), but names aren't expected to reliably link it in one hop, and we're politically averse to laws that require citizens to produce it in various circumstances, e.g. carrying ID cards, even though in practice most people do carry some form of government-sanctioned ID. Name changing is mostly limited by the fact that it becomes the duty of the person using a different name to laboriously link the new name to any previous names they've used wherever you need some paperwork in a different name. E.g. you need to provide your NI number to be employed, which typically means you need to have a paper trail back to it across any renames you might have had.

But we are importing this model now in Boris Johnson and Farage. As far as I can see Farage is doing exactly (a British spin on) the GWB strategy: despite having a pretty classical private-school upbringing he's created a ‘bloke from the pub’ character that is much more relatable to the lower classes, and it seems to be working pretty well.

It was really interesting to me to see BoJo's take on it, which was similar but with aristocratic mannerisms (and stereotypes!) mixed in. I guess it was aimed at the middle class, for whom upper-class dogwhistles have typically landed well.

> The drawback with more phonetic systems like Gregg is that one has to learn entirely new ways of spelling words.

The point of the phonetic systems is that you don't have to ‘spell’ words at all: what you say is what you write.

(Then there are briefs, of course, but those are for additional benefit.)

And yet there is a correct algorithm — it's either the const yes algorithm or the const no algorithm.

We don't _know_ which algorithm it is, but that's not relevant to the definition of undecidability, which only requires that the algorithm exist.

Quantum computation is not super-Turing: anything you could solve with a quantum Turing machine you could also solve with a classical Turing machine, albeit sometimes a lot slower. We know how to emulate quantum systems in classical systems.

Ironically Rust (hence the name) was originally billed as the language that did nothing novel at all, but just productized a bunch of concepts that were already well understood in the PL field :)

I think that a programming language — much less a programming language _ecosystem_ — is such a large space of decisions that statistically you're inevitably going to let a few of them slip. And even (as in Rust's case, initially) if you don't aim to do anything new, the combination of the interactions between features and the ways people want to use your language culturally can land you places you never anticipated when doing the initial language design. I don't think anybody in the early years of Rust could have anticipated how async would look today, for example, and IIRC Graydon Hoare still doesn't like where it ended up.

Then, there's the old software adage that the right decision for one level of adoption doesn't necessarily translate to another level. Because it's so hard to predict the impact of early decisions, early versions of programming languages are basically prototypes: your aim is to get out enough of the core differentiators of the language that people can start playing with it and _imagining_ what it will be like to work with the final thing. Part of that involves making the barrier to entry as small as possible (e.g. bundling a full build system into the precompiled compiler executable) but it also implies that you don't want to spend more time than necessary on things that work the same as other languages. If you can see the ‘obvious omission’ in the language then that means you can already imagine how it will work when that thing is implemented! As an implementor you can always flesh it out as you approach 1.0, or, if the right thing to do is so obvious and you have an enthusiastic open-source community, you can just wait for the community to build it for you.

Go's generics case is a bit different, I think. I don't claim to be an expert here (I haven't followed Go development much) but as far as I understand it the omission of generics from Go was a deliberate ideological choice: they hoped to get by with the absolute minimum of generic functionality, and the experiment was how little they could get away with and still have it adopted. (Unfortunately, I think the experiments Go was trying to run were stymied by Google and Kubernetes throwing their weight behind it, which led to a pattern of adoption that had little to do with the language design itself: we may never know what would have become of it if it had been left to stand on its own.)

I think that arguably an (active) object à la Kay is itself a process — it doesn't have shared memory with the rest of the program (regardless of how that's achieved).

> Most rewrites answer to the engineer - what they want to learn, what offends their taste, what looks good in an interview - and not to the company paying the salary.

One big caveat to this is that a large (and increasing) part of the value of the senior engineering hire is their taste. ‘Taste’ as honed by the software industry approximates business needs that the business doesn't even know it has. Sometimes engineers struggle to articulate ‘why’ a particular change is beneficial because they're just pattern-matching: they've seen the existing pattern break in a dozen different ways in a dozen different codebases, so now when they see the same thing again it ‘offends their taste’ — it looks indefinably wrong even though it doesn't seem to be causing any direct harm right now.

(Of course, sometimes it turns out just to be that they don't understand what's going on, especially but not exclusively for more junior engineers. Pobody's nerfect.)

I think it definitely sits at a reasonable point in the tradeoff space here, but it's not the only reasonable point. And it's the nature of tradeoffs that some cases will slip through the cracks.

I did not know that was something people had done! Thanks for the pointer!

If I were to quibble, though: in-process implies exactly the absence of the isolation guarantees that OOP!Kay and microservices share.

(The overhead on a Boolean also makes my inner Mel Kaye burst into tears, but that's neither here nor there in this discussion I suppose.)

Taken to an extreme. It's not feasible with current microservice architecture to, for example, represent every Boolean in the program as a service.

I think that's more of a workaround than a fix. Relying on unstructured concurrency does mean you no longer have to understand the scheduling of your program's fibres (… until you do), but it introduces a bunch of new footguns around things like correct cancellation, error propagation, and predicting resource lifetimes.

All recurrent people problems are system problems.

That's an excellent question I don't have an answer for in general :)

IMHO the goal is usually for the compiler not to make these decisions but to provide the tools for the APIs people build to make them. That's kind of passing the buck, though.

I guess in this case the core problem is that the API for these I/O calls has no representation in the type system for what's happening to the buffer. Proxying it as ‘the programmer must think about this code path’ is a reasonable best-effort but, evidently, sometimes inadequate.

`Poll` is marked `#[must_use]` so if you were assigning to something other than `_` you'd get a warning that you're ignoring the `Pending` path. The Clippy lint is only for `_` which Rust considers a use by default.

Hence ‘sadly’. IMNSHO both of these (or at least _untyped) should be enabled by default. Untyped `let _` is too big a footgun during refactorings.

I said ‘flagged’, not ‘fixed’ :)

You can always write the wrong code if you want it enough. But hopefully a warning would have prompted someone to think harder about this flow.

This would have been flagged by Clippy lints `let_underscore_untyped` or `let_underscore_must_use`, which sadly are not enabled by default.

> I don’t use AI when I write, for the very reason that writing itself is the act of organizing and clarifying my own thought. Letting the bot write for me would be like paying someone else to exercise for me and hoping that gets me in shape.

I don't know why the author chooses to distinguish writing prose and writing code here. [Software is made of decisions](https://siderea.dreamwidth.org/1219758.html) and at least I usually like to flesh out those decisions through the act of writing code, which forces a level of precision that makes it hard (though not impossible) to handwave away important decisions.

Mathematics, and its empirical cousin science, are not about picking out individual things that are true in the universe. There is an infinite set of statements of things that are true about the universe, almost all of which are, necessarily, too complex (in a Kolmogorov sense) to be captured by a human mind, and each of which is so specific as to be largely useless. Once you have a statement, though, they're usually trivial to prove by observation.

Mathematics and science are both about building structure on large classes of facts about the (logical or physical, respectively) universe that allow us to generalize our knowledge and make predictions about facts we cannot yet observe. This also lets us make claims about things that are, individually, too complex for the human mind to grasp, by abstracting away the complex details into a simpler structure and then making the claim about anything that satisfies that structure.

To put it another way, mathematics is about finding beauty — specifically those things that exhibit structure that humans can grasp. Modern mathematics, for the most part, makes no claims about what lies outside that space: if it turns out that the universe consists only of things that humans can describe through mathematics that would be neat, but in the much more likely case that it doesn't mathematics continues as it is today.

It's an interesting and maybe even useful trivium if (according to some set of axioms, such as those implemented by your favourite proof assistant) a fact is true, but it's not (human) mathematics, and if there's no useful way for humans to generalize from it there's no point in including it in a library of mathematics. It wouldn't be that surprising (but would be very interesting!) if there were an entire parallel class (or, more likely, family of classes, one for each AI architecture) of AI mathematics comprising structures that AIs can usefully generalize from. Such a thing has no reason to bear any resemblance to human mathematics, which is based on mapping structures to innate human linguistic and spatial intuitions, and may not yield any insights to human mathematicians.

Green threads predate modern async/await by quite a long way. Since async/await was developed, recent languages tend to prefer the ‘principle of least surprise’ by making the yield points explicit, since they interact in important ways with the code around them, with the notable exception of Go (which is very weird considering how explicit they decided to make their error handling).

Related research: Elliot Evans' Polytope (https://elliot.website/editor/).

Regular reminder: the ‘lines of code’ metric is a liability not an asset. The best engineer is not the one who can produce the most lines of code in a day but the one who can ship the feature with the fewest lines (and prepare the system to receive the next feature with few lines, too).

> Language doesn’t matter anymore: Python, Go, Rust, Node. But system design hasn’t changed.

I keep seeing this claim, and it's incoherent. Programming languages are the languages we use to express system design, and just like Sapir–Whorf in natural languages they admit, emphasize, or force consideration of different concerns in the design process. If we did get to the point where those languages ‘don't matter any more’ it would just be because modern tooling allows us to express ourselves at a higher level than these languages were designed for — but then whatever higher-level language you're using to express yourself matters instead (and matters more than ever: the higher-level you go the more inaccuracies compound).

Programming languages are designed for humans, not for computers.

Sorry, misread you — but you can substitute ‘monopsony’ into my comment and I think it still holds.

This is a ‘no true Scotsman’ so I don't think I can really respond to it directly. But I'll point out that my claim is not that some contracts bargaining for safety of life and limb are a form of duress but that all inherently are (to some extent). Especially when the other party's BATNA is ‘no guarantee of safety’.

No human can _100%_ consent to anything (… probably: free will is tricky). Coercion is a continuum, not a binary.

I don't really think that companies (or other parties in trades) bear moral responsibility for this inherently — a company that accepted every job applicant to try to meet their inelastic demands wouldn't last long, so the company itself is also under some duress even if it might like to. Trying to assign blame for complex distributed problems isn't really that simple. Your example in particular is a trolley problem, and I (personally) don't believe that pulling the lever makes you more culpable than deliberately choosing not to pull the lever.

But regardless of your chosen ethics, my point is pragmatic — while it's not correct to say that people take jobs only because they are under duress, it's also not correct to base arguments on them acting on their own free will based on their personal preferences. UBI experiments show significant changes in employee behaviour when inelastic demands are guaranteed to be met and negotiations pertain only to elastic quantities.

This effect is very much not limited to monopolies, though it's certainly easiest to see there. There's no step change from monopoly to competitive marketplace though. If you believe it's the company's moral duty to provide e.g. healthcare then in a non-monopoly situation that culpability is divided, though not abrogated (and beware the bystander effect!). From the employee's perspective, the spectre of physical harm is a bit further off, but it will still colour negotiations.

It's especially insufficient to generalize the working of the entire system from an example of a market in which employees currently have enough power to not really have to worry about the prospect of physical harm because it would be disadvantageous to the employers to cause it. Even if we take the current state of the SaaS startup market as reliable (which it isn't) the original argument was not limited to SaaS startup employees, and in other industries (including ones that are a bit down the pyramid from the SaaS companies) things are a lot less rosy for employees.

If those terms include the potential for predictable harms like lack of healthcare or housing if an agreement isn't reached, then yes, I think that is indeed an engagement in violence.

Now I'm not saying that the employer is necessarily morally culpable here — I'm sure most employers would like nothing more than to not have to worry about their employees' healthcare, and certainly I doubt many people enjoy having the ability to take it away. But it doesn't change the fact that it's impossible to have a real negotiation when inelastic demands are (potentially) unmet. Someone under threat of losing health insurance or housing is negotiating under duress, contrary to the comment I replied to.

Health is not a perk but an inelastic demand: a threat to withhold health is a threat of physical harm, and a negotiation in which one party's physical health is on the line is quantitatively but not qualitatively different from a negotiation held with a gun to that party's head.