HN user

Mr_P

456 karma
Posts0
Comments67
View on HN
No posts found.

Android and Chrome need on-device AI capabilities. Google can't lock down those weights like it can with server-side ML.

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.

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.

For all the hate that Java tends to get, the language natively supports this distinction between:

* Expected errors - Checked Exceptions

* Unexpected errors - Unchecked Exceptions

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

I think they should have let him publish the paper.

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.

This is literally the 'O' in SOLID.

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.

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.

The author titled one of the sections "Midpoint circle algorithm".

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.

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.

There's a 2016 CppCon talk here about making C++ Modules work at scale for Google's 100Mloc mono repo: https://www.youtube.com/watch?v=dHFNpBfemDI

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.

If generalized to 2D (and over the unit sphere), you'd get Google's S2 library (https://s2geometry.io/).

In 3D, the same can be done with morton codes (or a 3D hilbert curve) to build an implicit octree. Some raytracing systems use this for fast BVH construction.

In either case, this approach differs from mipmaps in that the underlying data can be sparse, and is simply stored in a sorted array.

I wouldn't be surprised if Google's TPU's pushed them far over the edge on this. I'd bet TPUs running inference for Ads models can basically print money for the company.

They've also already been building their own network chips for some time. So, given the scale of their datacenters, I think it's entirely reasonable that they'd outpace nvidia.

CLion (and other IDEs) have pretty good vim plugins: IdeaVim, VsVim , Vrapper.

They're not perfect, but I also made the switch from vim to CLion and never looked back. With a half-decent plugin for editing text, there's not much value in using a more minimalist vim setup IMHO.

Dependency injection systems (like Dagger or Guice) are essentially programming languages that specifically model this kind of initialization-vs-runtime distinction. Dagger is actually implemented as a compiler extension.

Singletons can be declared once, and then provided to various systems that need it, with read-only access.

In fact, they're more flexible than that: one can declare multiple nested "scopes" that each have their own initialization phase. For example, a web server could have one scope for process-wide singletons, and another for request-scoped "singletons".

The only thing missing is that these DI systems are for java, which doesn't have the const-correctness you'd ideally want. I'm not aware of any equivalent (and widely-used) systems for languages like c++ or Rust.

(Yes, I can feel hundreds of HN readers rolling their eyes as they read this, given the bad rep. DI systems have, but they're widely popular among FANG companies for a reason.)

Which advice did/would have helped you landing your first job after university?

Take a few advanced, specialized CS classes by your 3rd year. These often have large end-of-semester projects that can be fairly open ended.

These final projects are a great way differentiate yourself from the thousands of other CS grads looking for jobs.

Sure, you could get an 'A' in class by doing the bare minimum for a project. Alternatively, you could go beyond course requirements and have something to show off for potential employers, even if just another resume item to use as a conversation-starter. If you're doing the project anyway, going an extra 10% over the top is relatively easy, especially compared to trying to land a meaningful contribution to an open-source project or building a separate portfolio project from scratch.

Masks are effective at stopping people from unintentionally infecting others.

See: https://www.nytimes.com/2020/04/10/well/live/coronavirus-fac...

"Even a simple mask is very effective at trapping droplets from your coughs and sneezes. A recent study published in Nature from the University of Hong Kong and the University of Maryland asked 111 people, infected with various viral illnesses (influenza, rhinovirus and a more-mild coronavirus), to exhale into a giant funnel. Sometimes their noses and mouths weren’t covered; other times they used a simple, not-particularly-well-fitted mask.

Without the masks, the infected people exhaled contagious droplets and aerosols, tiny particles that linger in the air, about 30 percent of the time they were tested. When the infected patients wore a mask, it blocked nearly 100 percent of viral droplets and some of the aerosol particles."