Years ago, my college multi variable calculus and linear algebra courses were both taught primarily using course materials that were interactive Mathematica Notebooks.
We had access to all of the symbolic algebra tools and were even expected to use them regularly for both courses. It was great!
I'm not sure how well this would extend to introductory courses though, especially if the standardized tests still expect integration by hand.
Those same companies often invest in accessibility for vision-impaired users. I'm not sure you need a screen capture to scrape content when the site is designed to be navigable with a screen reader.
For anyone else who was confused to see a paper use the same name as a commercial product, it looks like Google Gemini was announced in May, whereas this was submitted to SOSP that had an April submission deadline.
GPU performance per dollar is only competitive for specific workloads. For extremely large scale compute, getting enough data center GPUs can also be challenging.
That said, I've also seen plenty of competitive drama in FAANG research labs, so this story is not hard to believe. More senior engineers often will use their seniority to power-grab control of projects. It sounds like Google execs did the right thing in the end.
The key idea is to break code into "chunks" that each do one thing.
Then, if you have to add a new feature, it goes into another chunk, instead of editing/modifying existing code.
The same logic applies to system design at different scales, whether fine-scale OOP or coarser-scale (micro)service architecture. The ideal size of an individual "chunk" is somewhat subjective & debatable, of course.
It's like Haskell-style immutable data structures, but applied to writing the code, itself.
Microservices is just OOP/dependency-injection, but with RPCs instead of function calls.
The same criticisms for microservices (claims that it adds complexity, or too many pieces) are also seen for OOP.
Curiously, while folks sometimes complain about breaking up a system into smaller microservices or smaller classes, nobody every complains about being asked to break up an essay into paragraphs.
It's not so much the existence of the flag, itself, but rather using an if-statement at the deepest-level of the call stack to conditionally modify behavior.
OP's blogpost advocates for data-oriented design (e.g. Entity Component Systems) as a mechanism for avoiding this, whereas the talk I've linked advocates for OOP. Both mechanisms are equally valid (imho) and are inline with widely-adopted industry practices for software architecture.
The page claims, "Bresenham's circle algorithm is derived from the midpoint circle algorithm."
The author of this blog post even made it clear, at the end of their article, that... "many explanations of midpoint algorithm use the final, optimized version. But I added several unoptimized steps."
I think there's a lot of value in a blogpost that demonstrates how someone could re-derive a widely-used algorithm from scratch.
> unless you have some indication people are increasingly picking the competitor over you, or especially and more simply leaving you in favour of the competitor.
If this happens, you've already lost. Software development has long lead-times. By the time there is significant customer attrition, bending the curve will be immensely difficult.
Good engineering strategy requires over-reacting to the right signals, and trends in the broader ecosystem are a wonderful source of signals. Large tech companies know this, and there's a reason why they'll quickly throw billion-dollar budgets behind exploratory efforts in response to competitors.
That said, it certainly depends on the industry. Some sectors are more fast-paced and competitive than others.
I'd bet someone just wanted to teach a course for fun and without compensation, but they had to formalize it and pose an actual job listing online for a month.
Probably explains why the "Open date" & "Final date" are just 30 days apart.
So, apparently it can work. I don't don't how much Google's internal Module incarnation differs (if at all) from what was ultimately published in the standard, but I'd expect it to be similar.
The article discusses a problem of resolving dependencies between compiling different c++ files. I'm no expert, but I think this dependency graph is implicitly baked into the build system, with tool-assisted user-written bazel rules.
So it's easier to just release those models as open source and make it official, since someone would inevitably hack the weights out anyway.