And without knowing that in advance I’d have assumed that link would have been to a commit or PR.
A link to a project is useful, but a succinct description of a project can be far more helpful. Something like, “tl;dr: Infinite Mac (the software for running classic Mac and NextStep in your browser) can now run…”
Anyone else find the standard "probability yardstick" very misleading on the "unlikely" side? I know the whole point of the article is that English speakers can interpret these phrases differently, but calling a 1-in-3 chance "unlikely" seems off. I would shift that whole side down—30% as "a possibility", 10% as "unlikely", 5% as "highly unlikely".
You're right, whatever they pick will be wrong, but that's "missing the forest for the tree"
The goal is to remove uncertainty in the language when documenting/discussing situations for the state.
It doesn't matter that it's wrong colloquially or "feels wrong". It's that when you're reading or talking about a subject with the government, you need to use a specific definition (and thusly change your mental model because everyone is doing as such) so that no one gets misunderstood.
Would it be better to always use raw numbers? Honestly I don't know.
Or new words unrelated to vernacular? Like "This is a cat-3 risk". When repurposing words in common usage they're always going to be fighting against intuition and triggering confusion because of it.
I was thinking this while reading it as well. Why go to all this trouble when we know in advance there will still be issues? Standardize on not using casual wording for quantified risks and instead provide the actual numbers. Something like "40 (out of 100) error 10 (plus or minus)". No more ambiguity. My offhand example even abbreviates nicely as scientific notation ie 40e10. I'm sure someone who actually spent some time on this could come up with something better.
> The first version of CONL used # as a comment token, but I quickly ran into issues. URLs contain #, so my next version...
Every other language has figured this one out as well. Wrap strings in quotation marks.
> That led to a data-model where each value is one of scalar|list|map (Compared to JSON’s null|bool|number|string|object|array, this felt good).
I'm not sure what a "scalar" is in CONL (is it always a string?) but a config file format having fewer types than JSON does not feel good to me. Even JSON's hand-wavy "number" type is problematic (whether "1" is an integer or float or some some other type is implementation-defined). TOML got it right to distinguish integers from floats. TOML got this right.
I don't see much mention in this discussion of how agile development impacts both the rate of bug creation and bug fixes. I only have my personal experience, but I suspect agile both encourages buggier software and longer-lived bugs than other methods.
The problem I see with it is the time-boxed sprints.Developers are rewarded for completing "stories" on time, not for the quality of that work. If a bug is found, they are rewarded for fixing it on time in another story (but only if it is high enough priority to warrant making it on the sprint board).
My experience is that getting it right the first time takes meaningfully longer than getting it nearly right, and agile rewards getting it nearly right. This is fine in the short term, but eventually the system grows a lot of subtle bugs, which add up to some big bugs that are expensive to fix. These take all the bug fixing time and the subtle bugs languish for attention.
This is fantastic to see! I've used XML off and on since it was the red hot tech of the early 2000s. I wouldn't choose it today for a green field project, but it's still around in so many places, so we definitely need a high-performance, high-quality library written in Rust for this.
This could become a great foundation for a typed, (mostly) etree-compatible, python library built on top of this. I've used lxml for years and it's still my goto, but there are lots of places where it could be modernized.
I like this taxonomy, though it is reductive to try to cram programmers into disjoint "tribes". Individual approaches to programming generally combine from all three, though in different proportion to different individuals.
Personally, I am driven most strongly by the "maker" approach, in that I write programs to be used. I also care deeply about correctness, simplicity, and performance in that order. I hate buggy, unmaintainable programs and the best way I know to make useful programs is to build them out of small, simple, correct components.
Performance is generally a more distant concern, but it really depends where you are in the stack. As you go down, performance becomes essential to usefulness, but the need for correctness doesn't disappear.
Was the data really important? Is it worth holding people's data hostage because of subpar developers?
I'm not at all saying that soft deletion shouldn't exist. I'm arguing that hard deletion should be the default, and then soft deletion practices should have some justification.
Instead the industry chose to just soft delete everywhere, which is good for the industry, and bad for users.
The industry chose the default of "data that is stored in durable storage is probably important". Sorry, I just don't see how that is bad for users when compared to the alternative default of "data that is stored in durable storage should be irretrievably deleted immediately".
Soft delete is a sensible default to prevent all sorts of problems. It's almost always good for a human to be able to get into the system and revert things if something bad happened.
It should just be followed up by hard delete several days or weeks later. The general policy should never be to hold things indefinitely.
As a practical example I have soft deletion for more or less everything on my desktop. There are periodic filesystem level snapshots and those stick around until I manually GC them. It has saved me more than once.
Thank you for your efforts in improving Python and especially thank you for helping to set the record straight in such a clear and visible manner.
Some of the sibling comments are saying there's "no need to apologize". One way this might be read is "no need to hold yourself to a higher standard". If this is the sentiment, then I disagree—we live in an age where accountability and intellectual integrity are undervalued. Being able to say that you and your team should have investigated a too-good-to-be-true result further before reporting it is setting a higher standard for yourselves.
But another way to read this is "no need to feel bad" and on this I agree. We all often fail to sufficiently challenge our own work, especially when it looks like something we worked hard on had a big impact.
> we live in an age where accountability and intellectual integrity are undervalued
I'm tired of this doomerism trope on HN. One thing has been constant in my life: People complaining that "we live in an age where accountability and intellectual integrity are undervalued". For me, it is on the same level as interviewing people for a local news show: "So, how's traffic these days?" "Oh, it's never been worse."
In what age were accountability and intellectual integrity "correctly" valued?
reply