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.

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/.

Depends on the post`s content whether the date is relevant at all.

Also, what if it's a technical post that was published a decade ago but updated last week?

Many people would probably dismiss the info just by looking at the date.

I would never add the date, but I agree with the shorturls.

A good URL should not be too long but also not too short. (Although intermediate paths can be short, e.g. /u/123 instead of /users/123 is fine)

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).

But that's exactly what I meant:

I am all for a very transparent "published at" and "last updated at"

BUT NOT in the URL

Because either you would update the URL to the last updated_at (which leads to complications if updated often, need to keep a 302 for each updated/outdated url although it's not moved permanently, rather temporarily until next update)

Or you would be stuck with the original published date in the URL and potential readers could dismiss it based on a wrong assumption (that it's outdated)

An alternative is to keep posting new entries for every update, but that gets annoying as well, because you still need to show somehow that the old versions are not the newest.

So I totally agree to be upfront about original publishing date as well as last update date, but I would not put it in the URL, not for blog posts or any other page.

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.

It may just be that we consume different bloggers is all!

I read quite a few who update texts, e.g. in the space of Rust or Webgpu

In any case, I got your point. Thanks for the respectful, interesting discussion. Have a wonderful day!

This kind of wonderfully civilised and respectful discussion between people who do not see something the same way is why I love hn. Thank you both, have a good Sunday!

I feel the dates of publication and last update should be readily available, that is in the content and at the beginning. Of course this goes against minimalism, and plenty of maximalist websites omit this information as well.

ggplot2 is pretty much an exception at this point, and if the package was created today it would use the pipe instead of add [1]. Most packages use pipes now (especially with the introduction of the pipe operator in R 4.1.0).

[1] https://forum.posit.co/t/why-cant-ggplot2-use/4372/7

I am no R expert, but pipes don't seem the most intuitive for ggplot. This is because they would imply that, e.g., ggtitle() %>% geom_point() means that ggtitle() outputs an input for geom_point().

That’s exactly how ggplot (not 2!) worked: https://github.com/hadley/ggplot1

I have gotten into the habbit of removing any software with opt-in AI chatbots. I recently uninstalled iTerm2, and I fear Firefox will be next.

just curious, why is this the case?

I am not against AI in software per se (I like the ChatGPT desktop app), but I prefer not to have AI in tools where the primary use case is not related to AI. Specifically, I don't want to have to consider how the AI is being developed and integrated (e.g., whether my data is being used for training an LLM), and, in general, I prefer for my software to be a bit conservative in relation to new trends (being it anything from crypto to AI).

Sure looks like it. Here is an archived version: https://archive.is/c4XbV

Thanks! I had problems accessing the webpage (due to my adblocker).

Very ironic if that's a regex bug or "special case" in the adblocker filter list.

That's fair, I should have elaborated a bit more on that point in my post. My thinking is that I need to use principles that will optimise the signal-to-noise ratio. In other words, just consuming everything in my feed is not optimal. One effective way to optimise the signal-to-noise ratio is to block Twitter Blue accounts.

I am not saying that all content from Twitter Blue accounts is bad (I am sure a lot of it is very good), but that I - on average - will get better content in my feed from not having any Twitter Blue accounts showing up.