"Maybe if the infrastructure people were involved in development discussion earlier, they'd be able to raise their hands and say: wait a minute, you're going to blow up our logs."
"Maybe if you invited the operations people earlier, they'd have some ownership in the product."
Awww... You like each other but none of you dare to make the first move :D
Whole thread reads like bunch of guys shouting at each other "but but ... I know better!".
IMO this is main topic of the thread and of the article.
There are groups of people who instead of spending time to figure out how to work together and understand what other side has to say, they just throw shit over the fence.
Maybe some could start by reading points at least couple of times and try to understand instead of trying to write personal experiences as fast as they can in reply to other comment that hurts their ego.
The gap is a leadership problem, someone is accountable for all the "shipping". It's a made by divide and conquer strategies (more "abstraction" at higher level).
Maybe it works if you assume all employees want to do bare minimum and don't get blame for what was not delivered.
What I see most of the time is that people want to deliver, people want to be valued by their work.
Of course I am cynical as the next guy from me in terms of "getting on high horse" but there is a lot of people who want to do their job and want to do it well.
Playing divide and conquer, playing non-existing scare deadlines is going to work once or twice and any smart employee will leave after that kind of crap. Other option is you are going to get smart employees who cannot afford to leave, but because of that crap they will just stop giving any fuck.
I sign up in reality into "self fulfilling prophecy employee", when you treat your employees or other people with expectation that they are thieves - in the end they will steal from you.
If you treat your employees as if they suck - they will suck.
Of course there are bad apples but if one goes the road that everyone want's to rob him, he will get robbed.
So instead of devs inviting ops people to the meeting they want ops people at, you are saying ops people should go up to devs while they are working and offer to help, even when they aren't needed?
> Awww... You like each other but none of you dare to make the first move :D
Only if you ignore reality. If you hold a meeting and don't tell me about it, how can I attend? Both sides want the ops people involved. Maybe the one having the meeting should invite them.
And who exactly benefits from those optimizations? Do the delivery drivers get to take a leisurely drive, or are they just expected to make more deliveries "thanks" to their optimized routes?
"It really vindicates everything Snowden has said on the topic."
Did any of his statements really need vindication though? Have we not known about this forever? (e.g. https://en.wikipedia.org/wiki/ECHELON)
I suspect the real problem is, and always has been, our perceived inability to change any of it.
ECHELON is way worse then Pegasus though, cause ECHELON / PRISM / whatever you don't even need spyware on your phone or to be targeted to be scooped up in their net.
maybe. these are different problems existing in different scopes.
a modern echelon dragnet would get an absolute mass of encrypted data so your fear will depend on whether or not you believe governments can break that crypto, and if so, at what scale.
pegasus on the other hand is highly targeted, infects silently and completely takes over your device–the camera, the microphone, keyboard, etc… encryption will not help. nothing can save you.
echelon was dragnet, pegasus is targeted. both extremely dangerous yet i still find something about pegasus to be infinitely more frightening.
we’ve already seen very high profile journalists murdered from pegasus and i suspect we’re going to uncover more as it’s dug into further.
"He probably has earned the right to be condescending as much as say Linus has."
It's not about rights, it's about desires and personal insecurities. People who derive pleasure from condescension are just telling you that they're vulnerable to manipulation via flattery. It's bad opsec! :P
The only morally sound answer to that question is "anything or nothing" because any other choice implies that you have to justify why one organism is more worthy of life than another. Am I wrong or just not fun at parties? :D
That's pretty much the only way I eat animals. It may be anecdotal, but supermarkets near me sell all of their meat pre-killed in neat little packages. I've never had to grind the beef off of a live cow to get my burger meat. Lobsters are an exception to that rule, but still generally seem dead by the time people eat them.
My point was that there is no list that anyone can make that lets you sidestep the unpleasant fact that you have to kill something to eat (each of your 5 points involve taking the life of something else. Even eating roadkill implies killing bacteria and parasites). On top of that, you'll never know if the thing you killed felt pain so any choice you make is ultimately arbitrary. I'm not saying I feel good about this bleak conclusion but I'd rather be honest about it. My dinner deserves to know that it wasn't an easy choice!
My dinner deserves to know that it wasn't an easy choice
I hope my dinner knows how delicious it is before I eat it. I would tell it if I could. Although that could get pretty awkward if it's something I don't like much:
"Listen, can we just agree that neither of us is really going to like what is about to happen?"
That’s actually roughly len(arr) times, not three, since two of the calls are inside the loop.
But the far bigger red flag there is that that it doesn’t just use arr.reverse(), which does the same thing and is typically 8–10× as fast in some simple testing (assuming a list), or arr[::-1], which makes a shallow copy rather than modifying the object in-place.
This matches what I’ve been seeing in code examples: Copilot likes to implement things from scratch rather than using libraries or even standard library functionality.
It’s possible that the word “array” tripped it up here and that it would have done something saner had it been told “list”, but I doubt it. (Python’s built-in array module is very seldom used; if you talk of arrays, you’re probably dealing with something like numpy’s arrays instead. But it’s far more likely that the built-in list type was what was desired here.)
There’s also one other significant point of bad and dangerous style in the code generated: the reverse function mutates its argument and returns it. Outside of fluent APIs (an uncommon pattern in Python, and not in use here), this is generally considered a bad idea in most languages, Python certainly included. It should either mutate its argument and return None, or not mutate its argument and return a new list.
> That’s actually roughly len(arr) times, not three, since two of the calls are inside the loop.
You're right! I noticed it a few minutes ago and changed the wording accordingly. Thanks for pointing out how shockingly bad that algorithm actually is! :D
> (...) the reverse function mutates its argument and returns it.
Yeah, that mutate + return is confusing. It's also worth noting that, as a result of the mutation, the function doesn't work on immutable types like strings and tuples.
It's not shockingly bad to call len(arr) each time through the loop. It would be if we were talking about something like strlen() in C, but in Python it's just one more constant-time† operation each time through the loop, and not a very expensive one at that. Caching it in a local variable would still be better.
______
† Nothing is really constant-time in CPython, but it's pretty close.
Well, to be fair, the `len` operation on lists in Python is a constant time operation. What makes the example particularly bad is using a cast on the result of a floating-point division, rather than just using Python 3 integer division (i.e. the `//` operator). Copilot was clearly just spitting out Python 2 code here.
I think the difference is that redundant re-calculation is a code smell in any language, at all times, whereas the float/int division issue requires knowledge of Python 2/3 syntax quirks.
It's context-specific whether recalculation is a code smell. I've definitely gotten feedback from senior developers to just do len(x) repeatedly instead of "littering" (their words) the code with `xCount=len(x)` assignments (because they knew len was constant-time).
Sure, it makes sense if you find something like `len_x` or `x_count` significantly less readable than `len(x)` and if you don't have to worry about resources. Can't say I've been there though.
I did a quick test of this `reverse` function (which probably shouldn't exist in the first place) and, unsurprisingly, it became ~30% faster when `len(arr)` was only called once.
When I'm that resource constrained, I don't use Python. The changes necessary to make regular Python code performant defeat the goal of making it readable.
There's a reason NumPy's innards aren't Python code.
Both sides of this "readability vs. performance" debate can be argued ad absurdum but that's not my intention. All I know is that I try to conserve resources no matter what level of the stack I'm working on and those generated snippets certainly don't!
Indeed, but they're not intended to. Nothing about Copilot's specs even claims it's generating optimally-performant code. And the Python example indicates why that may not even be a desirable output (most performant and most readable are orthogonal metrics).
"Maybe if you invited the operations people earlier, they'd have some ownership in the product."
Awww... You like each other but none of you dare to make the first move :D