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.

> We don't know if Web would be nearly as successful if it started with WASM instead of JS. The ability to just open a text editor and make a web page has served well in the early days.

And you would be able to do that just fine. All you'd need to do is include the JS compiler (helpfully hosted at http://cdn.google.com/ecmascript-2015.wasm) in the <head> of the HTML file's script tag, open a text editor and type away. Or, you know, include a more sane language like typescript, or python. Heck even lisp if you're so inclined. Or, and this is like totally crazy, but say you need performance, and want tight control over memory layout and allocations, then go for C or rust! Oh and no need to minify your JS. Just ship the WASM precompiled. Save on browser compilation time and network bytes at the same time. So long as you generate WASM that the browser understands use whatever lang makes you happy. Type it right into a text editor and include the compiler in the head of the HTML. Easy peasy.

It's without question that JS has held back web development for decades. Of course, people didn't know any better back then, and really JS was added as almost an afterthought, so we can't really blame them for getting it wrong.

We do know better now though. And still we get WGSL. Looking forward to 2041, when we finally get WGASM. The hottest new thing in web gpu technologies.

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.

Don't know of a good single resource that is comprehensive. A high level overview of autodiff approaches can be found here: https://www.robots.ox.ac.uk/~tvg/publications/talks/autodiff...

Some example implementations based on dual numbers: 1. http://www.ceres-solver.org/automatic_derivatives.html 2. http://www.imm.dtu.dk/~kajm/FADBAD/

Newer ML frameworks do source to source transformations, which allows calculating the derivative without changing the function signature, but the concepts used remain the same.

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?

Scooters could be using NFC/RFID payments today (e.g., Apple pay) instead of QR codes. So you could just walk up, tap your phone, and go. UWB offers no real usability advantage here. Scooter companies don't use these methods because they want you to install their app for user retention reasons.

So what's missing in your scooter use case is a loyalty mechanism rather than a lack of payment technology.

Since they say their intent is to compete on price with S3 / CDNs, it seems possible to be able to download a file without having permissions to delete that file. If that were not the case, then Sia would be limited to personal backup only.

Seems like this could be a common use case for pirates. Similar to how Megaupload or Fileshare worked a few years ago.

Sia's encryption doesn't protect the file hosts, if the uploader posts a link + decryption keys for pirated content to a public file sharing forum.

Does the take down notice go to everyone that hosts a fragment of the file? Who is liable if the uploader can't be traced?

Similarly, there's probably a ~€2.5 bn line item in the EU budget that reads "misc. Google fines". ;)

Agreed. Even if 2d graphics somehow made sense for standardization, it's not the place to start. How about first standardizing a linear algebra library that defines 2d/n-d vectors & matrixes? It's a prerequisite for an ergonomic 2d graphics library. And even such a library, which arguably has way more utility being in a standard, you'd still be hard pressed to find an optimal design (just look at design tradeoffs between glm, Eigen, etc.).

My point is that neither PoW nor PoS are decentralized. Which was in response to the original comment.

I’ll let other people prognosticate as to what, if anything, that means for their future.

Energy production is heavily regulated and centralized to a few entities. Very much like financial institutions.

It's highly unlikely that the free market somehow sorts this out in the future, considering that it's the free market that gave rise to these power law distributions to begin with.

PoW will centralize towards cheap energy access. PoS will centralize to majority stake holders. I would bet that such energy access or stake follows a power law distribution. So long as that is true, neither system will ever provide decentralization.

No, I think you mean Russia the government, not "russians" the people. The latter have little say over the policymaking of the former.

Different programming domains require different tools. Language wars stem from programmers incorrectly extrapolating the requirements of their domain to other domains that they're unfamiliar with. C is a good choice for kernel development. C is a bad choice for numerical computing. JavaScript is a good choice for web development. JavaScript is a bad choice for kernel development.

Some high profile C++ projects: LLVM, Webkit, v8 JavaScript engine, Chromium, Tensorflow, PyTorch, Eigen, OpenCV, Skia, Unreal Engine. C++ is a good fit for those projects: the right mix of expressiveness, portability & performance. It's not a good fit for other projects. Pick the right tool for the job. Move on with your life.

Yeah, we're using Shopify for our online store. Recently started using their PoS system because we were already set up on their platform. I suspect this is a driving force for other customers as well.

Shopify, Square and Stripe are poised to become direct competitors if you follow this inertia.

So long as mining remains profitable, as it has to be in order for anyone to spend resources on mining, the energy race will continue. As mining profits decrease over time, so too will the pool of miners who are able to mine profitably.

The network will, as a result, centralize over time to a select few that have access to cheap and plentiful energy. These "big energy" :) companies will control most of the hashing power.

You can already trace this with bitcoin by looking at who the early miners were versus who the miners are now.

I'm not advocating for decentralization. Just offering that up as a common argument that PoW advocates use.

I think that in reality, PoW systems become more centralized over time. You can already see that with Bitcoin. Eventually the gatekeepers become those with the largest energy resources available to them, and "we the people" will be in the noise when it comes to hashing power.

I'd rather take energy efficient centralization than faux decentralization that also happens to destroy the environment.

Proof of work systems are, at the core, a race towards ever greater energy consumption. They're an environmental disaster waiting to happen. Surprised how little attention this gets.

I would argue that the benefit of decentralization is not worth the price.

That's true for software that cares about the location of celestial bodies. In those cases use UTC by all means as event markers. That allows you to count calendar days. However to calculate the duration between two dates down to the second you will still first want to convert to TAI to get the correct answer.

Getting the mapping function wrong will only result in displaying a human readable time wrong. Databases, and in fact all systems, should use TAI-UT1 internally and across computers. And only convert to something else when displaying a human readable string.

The solution is actually quite simple. [1]

1. Use TAI-UT1 (International Atomic Time, monotonic, no leap seconds, with zero on 1958 Jan 1) for time keeping

2. Define conversion functions that map TAI-UT1 to/from UTC/UT1/etc

Use TAI-UT1 when you want to:

- synchronize the clocks of a network of computers

- calculate time elapsed

Convert to UTC/UT1/etc when you want to:

- Display a human readable date

- You're writing navigation or astronomy software

Introducing leap seconds into UTC would then just mean updating the TAI<->UTC mapping function. So all it would affect is how human-readable dates are displayed & navigation/astronomy software is re-aligned to celestial body positions.

[1] http://www.stjarnhimlen.se/comp/time.html