Consider surgery instead of software development. There are general best practices, but the difference between a good surgeon and a poor one is a small number of deaths. Malpractice insurance is high. Litigation is constant. And patients still die on the operating table. It's unclear what all the malpractice tort law actually gets you in the end.

To your point that "executives should be tracking performance daily", there's an argument that all that data should be publicly released daily. It would make it nearly impossible to hide mismanagement and actually remove most of the human overhead since it would be impossible to spin bad data on a daily basis.

I take comfort in re-reading much of the 70's and 80's literature which focuses the possibilities of user experience. We still haven't fully explored all the dreams of half a century ago.

If AI forces the business case that "code is cheap", I can only hope we re-double our efforts at creating new interfaces and capabilities for computer systems. The Meta glasses, Apple Vision, and the like are small steps in this direction.

He's always been involved in mentoring high schoolers, undergrads, and, of course, his own grad students. It's not surprising that he's working with a 24 year old.

He's a bundle of energy in math and sports and always looking for the new thing. Jumping in on a new project in a burgeoning field is very much his m.o.

What Wildberger is suggesting is that, rather than taking an nth root (solution to x^n = A where A is a fraction) as a "fundamental" operation, what if we took power series with "hyper-Catalan" coefficients as fundamental operators? (This is where I get a bit fuzzy because I haven't read and understood his work.)

Galois proved that you can't have a general algorithm for solving polynomials of degree >= 5 if all you can use are +,-,*,/, and nth roots. But what if you can use a different operation besides nth roots? That's what Wildberger is proposing and apparently it works for higher degrees.

Stepping back a bit, this is very much in line with Kronecker's notion that God made the natural numbers and all else is man's handiwork. There's no avoiding infinite series for computing non-rational roots of equations, but it is possible to choose series that are easier to work with.

I tried to read about Willow, but could never make heads or tails of it [1]. It seems to be a hierarchical key value store with a bunch of extra fields for timestamps and cryptographic tokens, but it's woefully short on working examples. Even the recent Rust library [2] is effectively a bunch of abstract classes with implementations that just throw errors.

I could make a quip about the state of European tech sophistication, but I'll let it pass with a polite smile.

[0] https://willowprotocol.org/earthstar/spec/

[1] https://willowprotocol.org/specs/data-model/index.html#data_...

[2] https://github.com/earthstar-project/willow-rs/tree/main

No one knows how to compute the size of that group in general (in fact no one has proved that it's finite!). Computing the rank of a curve via non-analytic means is more akin to a bespoke proof than a straightforward computation (see Noam Elkies' work).

So saying you're going to disprove BSD with blind computation is rather naive unless you're sitting on several career-defining proofs and not sharing them.

In 1.5 years living here, we've had the cops called on us once when we let our 7 year old walk 2 blocks to her friend's house unescorted. We also have to deal with the muscle cars and loud motorcycles which whizz by our house at 3 am each Saturday evening. We also know our neighbors who are of all ages and walks of life and there is never a moment we are fearful for our children's safety.

Please try embracing the opposite view. College campuses in the US are not an aberration, but rather an example of what community could look like.

  create view LoggedInUserView as
  select u.id as id, u.name as name, u.email as email
  from Users u
  join Cookies c on c.name = 'login' and u.id = c.payload->>'userId';

Most people wouldn't design their schema in a SQL database like this with a bunch of special-use relations/views, but datalog encourages you to do so since defining a new relation is the only means of abstraction. In effect, you've created an API endpoint similar to /api/auth/users and, what's more, you can use the LoggedInUserView in other rules to define new relations.

However, they made an explicit design decision to not include a query optimizer and execute the clauses as they were written. This is usually fine since the author has some idea of what the best order is, but there are O(2^k) different permutations of clauses so doing it by hand will fail at some point (if you want the optimal ordering).

The more interesting answer is to think of datalog as making it easy to encode nearly all of your application logic as a bunch of self-referencing, incrementally updated, materialized views. Some examples:

  # view of Users table for currently logged in user
  LoggedInUserView(name, email, id) :- Users(id: 
  payload["userId"], name, email), Cookies(name: "login", payload).

  # view of Users for admin
  AdminUserView(name, email, id) :- Users(id, name, email), Cookies(name: "login", payload), payload["isAdmin"] = true.

  # posts a user can see
  PostsView(title, content, id) :- Posts(title, content, public: true).
  PostsView(title, content, id) :- Posts(title, content, author: payload["userId"]), Cookies(name: "login", payload).

The examples above can be neatly replicated in Supabase or Postgraphile (the OG of auto-generated GraphQL over Postgres), but you can do a lot more with datalog as a language. The Hellerstein paper mentioned above is a good starting place.