_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.

To statically ensure a stack overflow does not happen requires that recursion is rejected by the type system. Austral does not do that so the stack overflow is a dynamic condition similar to memory allocation failures.

Yet Austral returns optional types from any memory allocation function rather than calling abort.

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.

One never writes such expression in a serious code. Even with move semantic and lazy evaluation proxies it is hard to avoid unnecessary copies. Explicit temporaries make code mode readable and performant:

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

Markov’s variety of the constructive mathematics is just what Bishop did plus the assumption that Church-Markov-Turing thesis holds. One does not need to assume that to recover any result of classical mathematics applicable in the real world. Also all those weird results of Markov’s approach that apparently “contradict” the classical mathematics is a consequence of Church thesis. Without that one cannot prove them. So Bishop’s approach is always compatible with classical mathematics.

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.

The notion of uncountable set assumes certain axioms and classical logic. If instead one assumes rules of constructive mathematics, then one cannot construct uncountable set. Simplifying only computable numbers can exist.

Also spot prices reflect the storage availability. The storage will be filled by October according to the existing contracts. I.e. there is no much room to receive more gas if it will have to be brought to Europe in the next few months.

A really cold winter without Russian gas may bring the spot prices back to record levels as then the supply lines will be the bottleneck.

Long term Europe needs bigger storage to smooth price volatility.

The E4X spec was just bad. There were too many corner cases with very unintuitive behavior or just plain spec bugs. I wish it was E4H focusing on needs of HTML with no xml namespace nonsense. It could have a chance then.

QT is used for embedded systems that may run for 10 and more years. If a device requires certification, one does not want to upgrade to a newer QT as that may require to certify the software again, while for security fixes the requirements are much more simpler.

Spectre and other hardware bugs are not going to be fixed for code running in the same address space. The moment DB allows untrusted WebAssembly to run, then that code can read anything the DB server keeps in memory.

In Norway there is no realistic option to have fiber cheaper than 45-50 Euro per month.

Based on personal experience 10 MBit/s is enough for video including full HD options. In fact it worked better than 100 MBit/s that was shared with several users and when somebody was downloading big gaming files.

It all depends on price details. In Norway one needs to pay about 20 Euro/month for a phone subscription with amount of data that allows, for example, watch YouTube or do video calls occasionally outside WiFi. Yet for 35 Euro/month one can get a mobile subscription with 1 TB of traffic with 10 MBit/s speed. That is enough to watch movies and do many kinds of remote work.

Yet the fiber costs at least 50 Euro/month. So it only makes sense to get broadband if it is shared by 4 people.

In Julia with multiple dispatch there is no problem to adding more things to the global namespace. But it does not work for Python, so it’s developers must be very conservative with global names.

Naming intermediate steps require some non-trivial efforts. It can even distract from the main task of getting the results.

In programming the code will be read multiple times and good names will help the future readers. But in data science the calculation will be most likely will not be reused. So efforts to name things will be waste of time.

With modern IDE writing JSDoc comments is a fast process

10 years ago I have used Closure compiler from Google, https://github.com/google/closure-compiler/wiki/Annotating-T... , as a type checker. We had to use for production a different minimizer, not the closure compiler, but it was extremely useful to check for types and JSDoc-style annotations were very readable with minimal distraction.

Flow for JS from Facebook also supports types-as-comments, https://flow.org/en/docs/types/comments/ , but those are rather ugly as one has to intermix them with JS rather than using separated comment block on top.