The game Overwatch is a pretty great contemporary example of this [1]. It has some excellent fluid animations, which look really weird if you freeze frame them.
I don't think GPUs ever had branch prediction in the first place. You can however run into poor performance due to thread divergence, which is a similar kind of issue (with much less black magic).
Yes. I'm sure it would feel nice to pay off my apartment loan, but the interest rate on that is 2.75%, which is way lower than what I can (reasonably) expect to make on the stock market.
> Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifying not only that tests pass but that code conforms to the spec. This specification, and not the code that materializes it, is what the team would need to understand, review, and be held accountable for.
This just sounds like typical requirements management software (IBM DOORS for example, which has been around since the 90s).
It's kind of funny how AI evangelists keep re-discovering the need for work methods and systems that have existed for decades.
When I worked as a software developer at a big telecom company and I had no say in what the software was supposed to do, that was up to the software design people--they were the ones responsible for designing the software and defining all the requirements--I was just responsible for implementing that behavior in code.
Spec-driven development is basically PRIDE, the first proven commercial software methodology dating back to 1971. In fact it may be the culmination of PRIDE because PRIDE's creators realized coding wasn't the hard part; the hard part was systems analysis, determining what problem needed to be solved and what to build. Coding comes last and when you did it right, was simply a translation step.
And now that step can be 100% automated.
Information systems design was a solved problem in the 1970s. PRIDE turned it from an art into a proven, repeatable science. Programmers, afraid of losing their perceived importance, resisted the discipline it imposes as the mustang resists the bit, but now that they're going the way of buggy-whip makers, maybe systems design as a science will make a comeback after 50 years.
One of my first tasks at my first job out of college required me to learn dxl (doors extension language) and implement some really intricate requirements management features.
It was gratifying to build the confidence of learning a new language quickly that I had never even heard of before. DXL was also pretty awful.
Opened a lot of doors for me though, no pun intended.
A couple of quotes from one of the employed baristas (translated from a Swedish local news article) [1].
"I'm worried every time there's a delivery, I never know what she's ordered."
"I like it. At the interview, Mona didn't care that I have dialect or I don't have a doctorate. For her, the most important thing was that I was nice and could make coffee."
If he has learned something from the experiment, it is that it is the middle managers and all CEOs who are at risk of being replaced by AI – not the baristas.
"Without me here, it would have been difficult for Mona."
Yes, it is literally a place, I wasn't saying it wasn't. The fiction is that this is pure PR fluff of what is actually going on, a human/dev team is prodding this thing in ways to "manage" the employees. This was pointed out in their last PR stunt:
So yes, it is a type of fiction. They also have every incentive to hype this up, given what their company does. I really wish people had more skepticism and critical thought with these things, it isn't actually good at all for the AI space and its future success.
Considering the size (and significance) of the VSCode user base, it feels like someone should be in charge of ensuring that default behavior doesn't change without good reason.
Does anyone (or any team) have ownership of the extensions/git/package.json file?
There's an old German short film called Nicht löschbares Feuer (Inextinguishable Fire, 1969)[1] that I'm fond of. It was a protest film against Napalm and how some companies wouldn't really let their employees know what they were actually working on.
"I am a worker and I work in a vacuum cleaner factory. My wife could use a vacuum cleaner. That's why everyday I pick up a piece. At home I try to assemble the vacuum cleaner. But however I try, it always becomes a sub-machine gun.
...
This vacuum cleaner can become a useful weapon. This sub-machine gun can become a useful household appliance.
What we produce it depends on the workers, students, and engineers."
DOW Chemical was producing Agent Orange, but was getting a ton of public pushback - so bad it decided to stop production, forcing the Pentagon to look for an alternative supplier.
That supplier? A German privately owned pharmaco called Boehringer-Ingelheim. It's Chairman at the time? Richard von Weizsäcker, future President of Germany.
The production site was in Hamburg, is contaminated for the next thousand years. Boehringer is legally forced to operate pumps to prevent the dioxins in that site from reaching the water table. If those did, it would wipe out the full population.
This question has been boiling in my brain for quite a long time.
Consider a hypothetical scenario where one spy chinese or russian programmer working in Google or Meta might have siphoned off (copied and uploaded) all the important code (Monorepo) to the Mothership and all of us are now sitting ducks.
I am sure, this question might have crossed your minds. I have no idea. if blueprints for the TPU chip design could get leaked, imagine what might have already happened?
Minor point but this doesn't only have to be russian/chinese spies but rather this can be anybody including say the UK/Israel or even countries which can be considered "allies"
I'd also be surprised if this code isn't already available with the US forces too and sometimes the enemy can be from within too.
[1]: https://youtu.be/vIdeGmN__Pw?t=550
reply