I wouldn't call this a minor detail (i.e., nitpicking), and it is worth pointing out again and again when these studies get public attention.
We should encourage stronger research designs (including A/B tests) if we care about the impact of AI use on mental health outcomes. A study like this one cannot say anything about the effect at all (it is even possible that AI use will have a positive impact on mental health).
A lot of people might read this and infer that AI use causes depressive symptoms, but the study cannot say anything about causation at all. The study is also transparent about this fact: "Further work is needed to understand whether these associations are causal"
Great stuff! You can make minor adjustments to the R-script so you do not need to rely on {dplyr} and {tidyr}. For example, use merge() instead of left_join() and use the base pipe, |>, instead of the magrittr pipe, %>%.
100% agree. I am more than happy to see Astral taking steps in this direction. People can continue to use uv, ruff, and ty without having to pay anything, but companies that benefit tremendously from open source initiatives can pay for a private package registry and directly support the continued development of said tools.
Looking good! What does it mean that it is free forever? That the code is available on GitHub and we should not have to be concerned about the site going offline or moving to a different place (that is not free)? Or, if it takes off, that we should begin to see ads? Or that this is the free tier option and future iterations can expect you to pay to, say, remove a watermark?
Most of these examples/walkthroughs look like they have been generated by LLMs. They might be useful for teaching purposes, but I believe they significantly underestimate the amount of domain knowledge that often goes into data extraction, data cleaning and data wrangling.
Point taken! I should have considered a subtitle for the post to make it clear what my main point is. That being said, I tried to nuance the post and not make any bold predictions. I am happy to revisit the argument in five years and see where we are.
Fair point. My personal preference is still for blog posts to share this information in the URL, i.e., to communicate when a blog post was published even before I click a URL.
Usually bloggers tend to write new entries if they change their mind or have any updates to previous blog posts. I personally prefer this approach rather than changing the content of old blog posts. But I agree that this might be more of a personal preference.
Good point! There is a difference between blog posts and pages to take into account here. For blog posts, I would like to see at least the publication year in the URL, as well as the exact date in the post itself.
For pages, I am fine with leaving out the date in the URL, but I would still like to see a publication date + last update date (if not a URL to a changelog).
My issue is that it can often be difficult to evaluate whether a date 'is relevant at all' at the time of publication. For that reason, I prefer bloggers to be transparent about when something was published (and/or revised).
I agree with a lot of these ideas but I do not get the obsession with short urls. E.g., why not make it easy for readers to see the date of when something was published?
In this case I cannot even see a publication date on the post itself (looking at the archive it says it is from December 26, 2012). I would personally prefer a URL like /2012/minimal-web/ rather than /w/.
[1]: https://news.ycombinator.com/item?id=48552440