Checked out the free sample and it also screams LLM written.
I don't have a problem with using llms for projects per se if it helps, so long as there is a vision, but why would anyone buy an introductory book to a popular language which the same llm could one-shot? What's the added value here?
> A personal reality sure, but that's not a reflection of the community.
You say, to the community, as it describes how it relates to the message.
You may not agree with it, but surely this thread among many should show you this view is not fringe or denial, but how a strong segment feels. I concede it's a divisive topic, some people feel optimistic, others less so. I myself don't fully know where I stand. I just don't agree with branding all of this as "unhinged nihilism".
Maybe 'journalism' wasn't the best suggestion by the OP but I have to disagree with the rest of your message. It may be a rant, or less pejoratively it may be a cry for help of someone seeing their industry's future, but I can't accept that it's not well written.
When is the last time you opened an HN comment section and the main comment was that people enjoyed the writing quality? Maybe it says more about what we usually read as a crowd, but to me this was a breath of fresh air, it was engaging but also quite deep at times.
I think the mark of great writing is that it makes an impression on you, on others, in a way casual writing doesn't. At least that's my take on this.
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.
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.
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 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 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.
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.
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.
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.
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.
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.