Readit NewsI'm not exposed to this space very often, so maybe you or someone else could give me some context. "Sabotage" is a deliberate effort to ruin/hinder something. Are compiler engineers deliberately hindering the efforts of cryptographers? If yes... is there a reason why? Some long-running feud or something?
Or, through the course of their efforts to make compilers faster/etc, are cryptographers just getting the "short end of the stick" so to speak? Perhaps forgotten about because the number of cryptographers is dwarfed by the number of non-cryptographers? (Or any other explanation that I'm unaware of?)
I've been thinking about this a bit. We don't really think this way in other areas, is it appropriate to think this way here?
My car has an automatic transmission, am I a fraud because the machine is shifting gears for me?
My tractor plows a field, am I a fraud because I'm not using draft horses or digging manually?
Spell check caught a word, am I a fraud because I didn't look it up in a dictionary?
As a software developer, your job is to understand code and business constraints so you can solve problems the way most appropriate for the situation. If you aren't actually keeping up with those constraints as they change through time, you're not doing your job. And yeah, that's a kind of fraud. Maybe it's more on yourself than your employer most of the time, but... It's your job. If you don't want to do it, maybe it's more respectful of your own time, energy, and humanity to move on.
Or is this some 38T$ leveraged against our future? Like how this debacle in Chicago screwed over 75 years of residents.
https://www.courthousenews.com/seventh-circuit-upholds-chica...
A "loophole" is only a "loophole" to someone who agrees with yours. And I say it as someone who agrees in this particular instance.
https://www.investopedia.com/news/hyperinflation-produces-su...
https://decrypt.co/332083/billionaire-ray-dalio-urges-invest...
Plenty of them don’t like imperative loops, sure. But I’ve never seen someone assert that a simple loop is not intelligible to them while chaining functions are.
That said, it's easy to get carried away, and some devs certainly do. I used to be one of those devs, but these days I sometimes just suck it up and use a local variable or two in a loop when the intent is perfectly clear and it's not leaking side effects outside of a narrow scope. But I'll be damned if I let anyone tell me to make imperative loops my only style or even my primary one.
On the other hand, I don't think I've ever seen something as recursive as Ackermann's function in real life. So it can probably solve any problem you actually mean to solve.
What's wrong with that? Resolving conflicts is the boss' job. So long as the team mate is doing their actual job appropriately, that's all that matters.
> E.g. you leave some critical feedback in a PR review. The author of the PR doesn't like your comments, so they tell your mutual boss, then your boss comes to you to ask why you left the comments in the PR, instead of the author coming to you directly.
The author should not be coming to you directly, going through the boss is the appropriate route. If the author's complaints were unreasonable, it should be the boss telling them that, not you. If your boss is coming to you, it means they feel the author's complaints are at least partially valid, and you should be hearing that from your boss, not the author.
It's not necessarily a bad thing if people bypass the manager to settle things directly, so long as both parties are comfortable with that, but it's not a happy medium.