In a sense I really get your complaint. It's the xkcd standard thing all over, we now have a new competing standard.

I think for me it's not so much the ggplot connection, or the fact that I won't need a dataframe library.

It's that this might be the first piece of a standard way of plotting: no matter which backend (matplotlib, vega, ggplot), no matter how you are getting your data (dataframes, database), where you're doing this (Jupyter or marimo notebook, python script, R, heck lokkerstudio?). You could have just one way of defining a plot. That's something I've genuinely dreamt about.

And what makes this different from yet another library api to me is that it's integrated within SQL. SQL has already won the query standardisation battle, so this is a very promising idea for the visualization standardisation.

In my experience, the only thing data fields share is SQL (analysts, scientists and engineers). As you said, you could do the same in R, but your project may not be written in R, or Python, but it likely uses an SQL database and some engine to access the data.

Also I've been using marimo notebooks a lot of analysis where it's so easy to write SQL cells using the background duckdb that plotting directly from SQL would be great.

And finally, I have found python APIs for plotting to be really difficult to remember/get used to. The amount of boilerplate for a simple scatterplot in matplotlib is ridiculous, even with a LLM. So a unified grammar within the unified query language would be pretty cool.

Regarding your points:

- I'm not sure I get your meaning here. My understanding is that for a random variable X, thr surprise is defined at the outcome level I(x) = - log p(x) while the entropy is essentially just the average value - sum_x p(x) log(p(x)). So to me it does look like entropy is expected surprise no? I do agree though that by being _expected_ surprise, entropy is itself a measure of surprise.

- I very much agree with that which is why I used _excess_ surprise (maybe relative is a better choice, but the intent is the same).

- That one I'm also confused about. It gets back to my first point: to me surprise (or information) is always defined at the outcome level first, so taking a moment is not tautological, it's meaningful, no?

Where .env files shine is that: - they act as a declaration of expected environment variables, - they are project-scoped, which is one big issue with using "/etc" for example

I personally like to set a .env.example for my collaborators to know what's expected, and I use a .envrc with direnv. And to make it more secure, I always have .envrc in my global gitignore so I can't just forget it.

The drawback is that for any non-interactive run (debugger) I have to manually add each variable each time.

I agree with another commenter that while flat, the Netherlands have their own hurdles (biking with a strong headwind on the banks of the IJ is not easy, even if flat), and I definitely agree that their city design is what makes this unique.

I lived in various parts of France growing up, and I can assure you there are flat cities there, yet biking in them felt very risky at best.

But with electric bikes becoming more affordable, hopefully the gap can eventually close.

And not just young active people, it's a habit found across all age groups, parents bike their children to school (or with them if old enough, etc.)

All that to say I wouldn't worry too much about the feasibility issue, it's really more of a mindset to adopt, and it's happening more and more in France.

Also, I don't know if it was supposed to be a covert ad for the cybertruck, but it reminded how ugly this car is.

You mention some advanced stuff like abstract index notation which is usually the hardest part to get right with things like simpy and even mathematica, how does your package handle simplifications of complex tensor expressions (GR, hydrodynamics, etc.)?

https://m.youtube.com/watch?v=UPTLA2aNASA&t=2s&pp=2AECkAIB