> but at one time HN had people with critical reasoning skills reading
As long as HN keeps people with reading skills at all...
The GP directly argued against the blog post, and in favor of showing the extras before the movie, because "majority of Re-release audiences have seen the movie before and don't want to sit through the credits for extras".
(I happen to disagree with the argument on the basis of "who on Earth cares about extras anyway", but still, GP correctly made a coherent point.)
I was making an argument for before. If 90% of customers want it before so they dont have to sit through credits, it is very understandable that it is shown before.
That said, I have no clue what the actual percentage is. Maybe someone has A/B tested this
The sun is a giant fusion reactor known to cause cancer on a good day, and emit radiation bursts that can damage or disrupt power grids often enough that people can reasonably expect to read reports of them more than once in their lifetimes.
Even then. The sun is always a big ball of dangerous radiation, even despite things like the ozone layer. A nuclear rocket taking off isn't something you want to be near, but even literal Chernobyl wasn't as deadly in total as skin cancer was just in the year the reactor exploded.
i dev on main
in teams we build in environments that are very prod like
we have tests that verify code that has been deployed - no matter the location on startup
we build test and deploy from local machines (and test because startup)_- this is very reliable or else our tests woudl regularly fail
because of this we push to main after our deploy has worked
ofc this only works on smallish teams that push / pull very regularly and have good communication around who is deploying when.
it used to be a shout over a desk partition.
we go faster than you and break far far less than you
I feel like you missed the main point of what you are saying.
Whilst existing callers who obey the contract will not be broken by this callers who depend upon this code breaking for null values will no longer do so.
so it is a breaking change for them. You have just extended their behaviour.
That said if we defined the functionality of code as being valid within a scope of input and not defined anything outside of this we are safer in a sense. That said you do require feedback to show you are out of range.
But the point I want to make is that the line of argument that attempts to ascribe changes to behaviour on values that were out of scope as breaking changes is not helpful to anyone who is trying to co-exist via contracts in order to understand what work is expected as a result of change.
most of what developers have to ship is not in their control - very often teams are not responsible for defining what they do or how they do it now.
I wish you were right because it can be fixed by looking at developers but its the entire snake oil industry of deciding what to do that is the problem
so many people say this as if it is a sufficient rebuke of the whole point. OP agrees with you - the point is show it after.
I only pick on you because many people responded but at one time HN had people with critical reasoning skills reading