alexkcd

The article literally cites a statement put out by a respected medical journal on Feb. 29, 2020, and signed by 27 scientists, "roundly rejecting the lab-leak hypothesis, effectively casting it as a xenophobic cousin to climate change denialism and anti-vaxxism."

Whatever your recollection of "rank-and-file scientists" attitudes is, the narrative on record is to the contrary.

The demographic for our app was primarily the US.

iOS apps are more profitable on a per install basis. So the discrepancy cannot be explained by there being multiple Android stores. Your hypothesis in brackets is the more likely explanation.

Source: I worked on an app with millions of paid subscribers.

From [1]:

> When writing SPIR-V, you can’t have two integer types of the same width. Or two texture types that match. All non-composite types have to be unique for some reason. We don’t have this restriction in Naga IR, it just doesn’t seem to make any sense. For example, what if I’m writing a shader, and I basically want to use the same “int32” type for both indices and lengths. I may want to name these types differently

This doesn't really make sense for IR. IR is not meant to be human writeable. It's meant to be generated by a compiler. So, having a one to one mapping between concept and name in the IR is a feature, not a bug.

Honestly, WGSL just repeats the JavaScript mistake: where we should have started with something like WASM instead of JavaScript. And JS could have been just one of the many languages that targeted WASM.

We were this close to not repeating this mistake by adopting an IR language (SPIR-V) for WebGPU, but then that got abandoned mostly for political reasons. Too bad. Now we get to write transpilers and hacks for decades to come, just like web people have been trying to paper over JS problems for decades.

I remember reading that too. I think Ben Horowitz might have talked about this in The Hard Thing About Hard Things, though I might be misremembering the source.

Agreed. Besides Geometric Algebra, dual numbers also play a huge role in automatic differentiation -- the core building block of modern machine learning frameworks.

I really like the analogy in this talk about how Al-Khwarizmi's six quadratic equations simplify to just one, once we learn about negative numbers and zero.

In a lot of ways, geometric algebra (and dual numbers) are our discovery of "negative numbers and zero", but for the 21st century.

No, because 10M generates a steady return in a growing economy. So the steady-state consumption of someone with a net worth of $10M is much greater than someone with $0, all other things (e.g., income) being equal.

Ah, that's good to know. This sounds exactly like what I'm looking for. Thanks will read up on this in the docs!

I'm not sure, but I think it's different. Specifically, I think you would do macro evaluation first, then fully evaluate the resulting program on run-time independent values, and only then evaluate the resulting program on run-time dependent values.

Edit: Also, run-time independent evaluation would need to handle branching differently. For example, in this expression: (if a b c). If `a` is not known at "compile time" then this expression remains in the AST, and run-time independent value propagation continues into `b` and `c`. If `a` is known at "compile time" then only `b` or `c` remain in the AST depending on whether `a` is true or false.

Yes, Julia has some of it. But you're still required to specify the template parameters of a type (unless I'm mistaken). Whereas what I'm talking about is that any value of a data type could be compile time known. For example, some or all of the dimensions of an nd-array, as well some or all values of said nd-array.

I really like how type checking is implemented for parameter lists. I think there's a more generalized extension of this.

Specifically, I think that there exists a lisp with a set of axioms that split program execution into "compile-time" execution (facts known about the program that are invariant to input) and a second "runtime" execution pass (facts that depend on dynamic input).

For example, multiplying a 2d array that's defined to be MxN by an array that's defined to be NxO should yield a type that's known to be MxO (even if the values of the array are not yet known). Or if the first parameter is known to be an upper-triangular matrix, then we can optimize the multiplication operation by culling the multiplication AST at "compile-time". This compile-time optimized AST could then be lowered to machine code and executed by inputting "runtime" known facts.

I think that this is what's needed to create the most optimally efficient "compiled" language. Type systems in e.g. Haskell and Rust help with optimization when spitting out machine code, but they're often incomplete (e.g., we know more at compile time than what's often captured in the type system).

I've put "compilation" in quotes, because compilation here just means program execution with run-time invariant values in order to build an AST that can then be executed with run-time dependent values. Is anyone aware of a language that takes this approach?