I.e. programming is not supposed to be easy. So if one sticks to it, the problem has to be hard at least from the management point of view.

Classically one can imagine that as if electron was hit by a particle. But then we have light diffraction and interference, which classically is described as a wave. So from a classical point of view light travels as a wave but interact as a particle.

As of nature of the light, then consider that there is a reformulation of a classical electrodynamics that eliminates electromagnetic waves all together. There are only electrons that interacts with each other directly with no waves in between. Feynman spent quite some time trying to develop quantum electrodynamic based on that. He failed. Still the point stands that we never observe light directly but only through its effects on electrons and other charged particles. So it could be that what we call light is a theoretical artifact and there is no light in reality.

This proposal does the opposite. It transforms the loop body into a closure passed into the iterator.

This slows down object access as detecting and stripping the NaN tag requires few CPU instructions. Plus it assumes that pointers only have 48 bits with rest are zeros (true for AMD, ARM and Intel) or at least have fixed values (can be arranged on more exotic CPUs). But that does not require to box numbers greatly reducing GC pressure.

Chromium eventually dropped support for such builds. At Google the developers have access to a compilation farm that compiles within like 5 minutes. With such farm unity builds makes things slower as they decrease parallelism. So Google decided not to support them not to deal with very occasional compilation breakage.

The problem in practice is that accounting for the existing information is hard with guessing of priors etc. But that is the problem of applicability of Bayesian inference, not the problem with the principle itself.

I.e. Bayesian inference is a good answer to the philosophical problem of induction. It is sad that the article has not even touched on that subject.

For example, in practice the raven problem is not to guess if all ravens are black but to predict the color of the next raven if that color affects a decision.

From that perspective if one knows absolutely nothing about ravens and has seen a single black raven, then it is mathematically sound to guess that the next raven will be black, not white, and make a decision accordingly.

For a system language I would like to see that when the compiler cannot infer the bound on the stack size or when that static bound exceeds some static limit, a function call is treated as fallible.

And stack overflow is a memory allocation failure, so why is the discrepancy? I.e. for the language focusing on correctness this is an unfortunate omission.

On the other hand none of popular or semi-popular system languages allows to explicitly control stack consumption. Zig has some ideas, but I am not sure if those will be implemented.

auto t = minus(vec1, vec2); mul_by(t, 0.5/0.3); add(t, vec3); mul_by(t, 0.3); v4 = std::move(t);

As for Hahn—Banach I can only site the book “Techniques of Constructive Analysis” by Douglas S. Bridges:

For example, our proof of the Hahn-Banach theorem (Theorem 5.3.3) is, as it stands, a valid algorithmic proof of the classical Hahn Banach theorem. Moreover and this is one advantage of a constructive proof in general our proof embodies an algorithm for the construction of the functional whose existence is stated in the theorem. This algorithm can be extracted from the proof, and, as an undeserved bonus, the proof itself demonstrates that the algorithm is correct or, in computer science parlance, "meets its specifications". …

The Hahn-Banach theorem enables us to extend a normed linear functional, with an arbitrarily small increase in norm, from a subspace of a normed space to the entire space. This fundamental result has numerous applications throughout functional analysis.

In the constructive context we deal only with the extension of linear functionals on subspaces of a separable normed space. The standard classical proofs extending the theorem to nonseparable normed spaces depend on Zorn's lemma and are therefore nonconstructive. … The classical Hahn-Banach theorem says that we can extend a bounded linear functional v from Y to a functional u on the whole space X with exact preservation of norm. In general, as Exercise 5 shows, we cannot do this constructively. But, as we shall see, if we impose extra conditions on the norm of X, then we can make the extension norm-preserving.