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.

Looking more closely though, this looks a lot like the Google "AI Cookie" from 2017, which also used Bayesian Optimization: https://blog.google/innovation-and-ai/technology/research/ma...

https://github.com/ARPAHLS/skillware/blob/main/skills/optimi...

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.

* Expected errors - Checked Exceptions

* Unexpected errors - Unchecked Exceptions

Idiomatic Java also makes heavy use of asserts, e.g. using the Guava Preconditions library.

We've seen time and again that various trends in ML turn out to have actually been dead-ends.

A few examples: https://arxiv.org/abs/2102.06356 https://arxiv.org/abs/1905.03678

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.

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.

This talk gives a great overview of why boolean flags (rather, if-statements) can be a code smell: https://www.youtube.com/watch?v=4F72VULWFvc

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.

There happens to be a Wikipedia page on "Midpoint circle algorithm": https://en.wikipedia.org/wiki/Midpoint_circle_algorithm

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.

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.

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.