I agree, and one thing that makes me skeptical is that for it to be effective, the fish being punched would presumably have to understand that the octopus wants it to act in a certain way - i.e., the hypothesis seems to imply that the fish has a theory of mind with respect to the octopus. Similarly, it seems to imply that the octopus has a theory of mind about the fish - it believes that the fish will understand why the octopus is punching it.
I'm not saying that this is impossible, but it is a very big claim. Furthermore, it is not clear from the video that the punching has the outcome implied by this hypothesis. It seems at least as plausible, at least from the video alone, that the octopus is just keeping the fish away from stealing an anticipated meal.
On looking at it again, I think the reporter and/or editor have introduced unnecessarily teleological language. The researchers themselves describe the octopus behavior as though it is a matter of herding the fish - presumably, I suppose, to where it feels there are more prey to be found.
They don't give the death penalty to teenagers making 'silly mistake's. It's a sentence not handed out without weighty thought and only to those who knowingly and intentionally take life.
I'm so tired of the "next Einstein" pithy replies. These are adults who have done heinous crimes against innocent people. Justice requires severe consequences.
By this logic, holding someone against their will is illegal too. When a state does it, we call it incarceration. Is it wrong for the state to sanction incarcerating someone?
This seems like an exceedingly bad hill to die on. Curtis Flowers was convicted and sentenced to death six times for the same murder by juries of his peers, yet he's a free man today.
We don't have a better system at the moment, accepting its judgements is reasonable in light of that. And backseating when we're probably missing 90% of the evidence presented at court is unlikely to be any more accurate.
This is so undervalued when maintaining an older codebase. Please, for the sanity of those who come after you - make the code look like the existing code.
"Please, for the sanity of those who come after you - make the code look like the existing code."
I think it's a great rule of thumb... but there are exceptions.
For example, Funnily enough I was reviewing some code just today written by someone else and that I'm going to be asked to expand on or maintain. It looks like this:
var example1 = Object;
var example2 = Object;
var example3 = Object;
...
var example147 = Object;
And then later there are corresponding variables assigned to different objects which are:
var tempExample1 = <some object instantiation>;
var tempExample2 = <some object instantiation>;
var tempExample3 = <some object instantiation>;
...
var tempExample147 = <some object instantiation>;
And this goes on and on. It's real special once we get into the real business logic. (and to be clear... "example1" are the actual names, I'm not just obfuscating for this comment.)
The reason it looks like this is because the original developer copied the examples from the developer technical documentation for what they were doing verbatim; this documentation only had one variable so the numbering was the way to get multiple variables. Knowing this system, they didn't have to do that, they could have very easily assigned meaningful names for all of this. (To be fair, the original developer isn't a developer but a consultant business analysist saying, "Oh yeah, I can do that!" to the client.... billing all the way).
I can tell you with great certainty and righteousness: I'm not going to make my code look like the existing code. I may well do some refactoring to make the existing code vaguely scrutable.
I appreciate that what I'm describing is an extreme case and not really what you or parent comments really were addressing. I just stop to point out that what you describe is a rule of thumb... a good one... but one nonetheless. And, as an absolute rule of thumb about rules of thumb, there are no absolute rules of thumb. Ultimately, experience and judgement do matter when approaching the development of new code or decades old code.
The concept of "make the new code look like the existing code" still applies - in the example you gave, if you need to add examples148-200, and want to do it in a better way, then it would be wrong to do that new way for the new code; either you are willing and able to refactor the previous 147 cases as well (so that the new code matches the existing code, because the existing code was updated), or you keep the existing structure.
Unless of course you work in a wild-west codebase where you can basically tell who wrote what code because everyone has a distinct style and they never converge. ugh
If you want to pay bottom of the barrel wages you’re gonna get employees that are at the bottom. An accident could cause many times a workers annual wage, so they’re trying to go for preventative measures.
I’m honestly surprised they can still find people who want to work for them.
That’s easy to say when it’s someone with our level of opportunities but some people don’t have a whole lot of other options. And it’s not like Door Dash and Uber are any better.
> I’m honestly surprised they can still find people who want to work for them.
The slow and steady eradication of middle class jobs + the lack of a humane and dignified safety net + the need for food, clothing and shelter. I think very few people want to work as an Amazon warehouse worker or driver, as in make a career of it. It's one of the USA's many Jobs Of Last Resort.
If "singing along" is a leading indicator of being in an accident, then amazon should absolutely not employ drivers that sing along. People get injured or killed in accidents, we dont need to observe them if we have sufficently strong signals that show risk (IE: driving at 100mph, driving while drunk, etc). What I don't understand is if you tell drivers "dont sing along" does that negate the predictive value of "singining along" as a signal for propensity to be involved in an accident.
reply