I was quite psyched when I read this so maybe I can tell you why it's interesting to me, although I agree the announcement could have done a better job at it.
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.
I share your pain. You might enjoy Plotnine for python, helps ease the pain. The only bad thing about ggplot is that once you learn it you start to hate every other plotting system. Iteration is so fast, and it is so easy to go from scrappy EDA plot to publication-quality plotting, it just blows everything else out of the water.
But isn't this then just another tool that you're including in your project? I don't get why I would want to add this as a visualization tool to a project, if it's already using R, or Python, etc...
I mean, is it to avoid loading the full data into a dataframe/table in memory?
I just don't see what the pain point this solves is. ggplot solves quite a lot of this already, so I don't doubt that the authors know the domain well. I just don't see the why this.
Well there's always going to be a dependency anyway: loading the data, making it a dataframe, visualizing it, this might be 3 libraries already.
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.
I see, that's insightful. At first sight I thought of it as a kind of novelty, extending SQL with a visual grammar to integrate with a specific plotting library. But from your comments I can now imagine it has potential as a general solution for that space between data - wherever it comes from, it can typically be queried by SQL - and its visualization.
Thinking further, though, there might be value in extracting the specs of this "grammar of graphics" from SQL syntax and generalized, so other languages can implement the same interface.
I completely agree, and I think this is also where I'm quite excited. This project's connection with ggplot
, which has one of the most respected grammar for plotting, means that it would be in a good position to achieve what you describe.
I would even add that it fits into a more general trend where operations are done within SQL instead of in a script/program which would use SQL to load data. Examples of this are duckdb in general, and BigQuery with all its LLM or ML functions.
I did try this, but for whatever reason it kept getting added back automatically. I forget the details of exactly why it was happening because it was close to a year ago, and in the compatibility guide it says this is supported, but I'm not sure if it was at the time or I was running into something different. This was a contract gig for me where I knew it would be ending within a month or so, which meant I didn't bother spending a ton of time trying to figure out a long-term solution.
Interesting, I tried on a recent version so who knows? I do find that sometimes jj is a bit precious with ignored files if the file exists before the ignore rule, even if you untrack. In those situations I almost always "delete/recreate" after the rule is added.
Hi, author here! Thanks for the feedback, as I mentioned this is also to clarify things for myself so this helps a lot.
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?
That is the same impression I got reading this. I would enthusiastically use any OS-first method if it means one less brittle dependency, but the current usage of environment variable is rather different than what is described in the post.
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.
That's a really good point, I hope at the very least it enables a "car -> public transport -> bikes" flow. So even if these people were taking the metro, all that extra metro space can accomodate car-owners who wish to switch.
It depends though. At least in London a lot of cycleways were made by removing bus lanes and replacing them with high quality segregated cycle lanes.
This has led to a big increase in %age terms of cyclists in London, but a fairly significant decline in bus passengers.
I think roughly 300m/yr cycle journeys were added, but bus has lost 500m pax/yr (mainly because of increased congestion making them less and less attractive). Note this isn't all down to bus lane removal, but it's a significant part of it.
I live in the Netherlands where the weather is arguably tougher than in Paris (rain, cold and wind for large portion of the year) yet everyone bikes year in year out.
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.
Paris has one thing that Amsterdam does not that makes cycling more challenging: elevation. (Ok, Amsterdam has bridges but those are for the most part really short and momentum is enough to carry you across).
I cycled to work every day in Southern Germany, which had even more elevation, it was not a huge problem, you get fit enough in now time. Older people just use e-bikes.
Bicycles have had gears for almost a century, and they allow to tackle hilly areas easily. Also, the Netherlands is notoriously windy, and a headwind is just as difficult as a hill.
No, what makes the Netherlands different is their street design prioritizing safety rather than speed at all costs. When the streets feel safe from speeding drivers, more people choose to ride a bike.
Not at all. I simply suspect that you are uninformed about why cycling is popular in the Netherlands. In the 60s the Netherlands was just as flat as it is today, but it wasn't a cycling paradise. It all changed with the campaign "Stop de Kindermoord" (literally translated as "Stop the Child Murder"), which began in 1972.
Considering I'm not Dutch, you may feel reassured there is no superiority feeling at play here.
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.
The same reason people generally don't regret having kids even though the commitment and overall change of your life are much greater than what you described for dogs.
They are objectively similar in that both are a big multi-decade commitment to a living being that you chose for yourself (yes, you did choose to have the kid unless you live in a country with no birth control access) but saying something is similar is still not making a value comparison
Yeah of course you can choose the level of evaluating how things are similar. Yes they both breathe. Yes they have DNA. Both are objectively true.
Also, you keep saying value comparison like it's something I used against OP. I never mentioned anything about dog <=> child, nor did OP. I just meant that the core decision of having either is different, so it's not comparable even though you could boil it down to "you care for both".
reply