_0w8t

The error handling verbosity in Go should be blamed partially on the formatter that replaces one-liner if err != nil { return err } with 3 lines.

From a technical point of view nothing prevents the scripting package to be just as informative with errors as bash and have a helper to log and clear the error. If it is not already the case, I call it a bug.

There are plenty of web site builders that allow for a drag-and-drop construction. But people who use them are not programmers.

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.

Experimentally one never observes waves. Light is detected based on its interaction with electrons and that is always by an electron absorbing a quanta of energy, not via some continuous process as would be the case with waves.

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 describes 32 bit CPU. As opposite to V8, SpiderMonkey, Mozilla’s JS engine, uses 64 bit words and NaN boxing, even on a 32 bit CPU, to represent a generic JS thing.

When there are more bits in a pointer than NaN 52 bits allows, the trick is to replace pointers with indexes from the start of JS heap. This is not efficient even with arrangement like having heap aligned, say, on 4GB or even more granular address so to get the full pointer one just use bit operation, not an add. But if one wants efficiency, then make sure that types in the code is stable and JIT will generate type-specific code.

I.e. C# and many other languages transform a function with the yield statement into a state machine implementing the iteration protocol.

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

Defer will be executed normally when the function exits. yield here is not a statement but a normal function.

The big plus of stellarator design is inherent absence of plasma instabilities affecting tokamaks. Notice that future upgrade of Wendelstein may allow to hold plasma for a hour compared with minutes at best with tokamaks. Many physicists for that reason believes stellarator is the only way to archive practical fusion.

In modern JS engines with 64-bit CPU when the engine cannot deduce types and must use a generic word to represent any kind of values numbers (double values) are not boxed. Rather for everything else a NaN tag bit pattern is used. I.e. code checks if the word matches the NaN pattern. If not, a double is assumed. Otherwise the NaN is checked if it is a real NaN o something else masked as NaN.

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.

The primary reason for Pimpl is to ensure binary compatibility for C++. QT uses it extensively precisely for this reason. Reduced compilation time is just a nice bonus.

Chromium once supported unity builds. For me it speeded up builds from 6 hours down to 1 hour 20 minutes on a Windows laptop. And Chromium tries to make their headers reasonable.

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.

Bayesian inference is mathematically sound as it is based on a very generic postulates and allows to compare probabilities based in the current information and made a decision accordingly. With the proper approach the errors are automatically accounted for. I.e. if the errors are large, then one will see that probabilities are too close each other to make a sound decision. Still if one must made a decision, then one can just use the answer based on Bayesian reasoning.

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.

The article has not mentioned Bayesian inference, which allows to make sound decisions under uncertainty.

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.

Inferring the number of loop integrations or recursion levels is in practice impossible when the number depends on the user input.

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.