mlthoughts2018

> “ If your heavyweight runtime is being launched 1000s of times to get a job done every day or multiple times a day, consider optimizing. Which may include changing the language. That's hardly controversial”

No, that is controversial because the time saved per run (even 1000s of times per run with multiple daily runs) is never going to come close to amortizing the upfront sunk cost of that migration and future maintenance.

I’m specifically saying in the exact case you highlighted, people will short-sightedly think it’s a clear case to migrate out of the easy-but-slow interpreted language or never start with it to begin with, and they would be quantitatively wrong, missing the forest for the trees.

> “ Programmers need to think long and hard about your process invocation model. Consider the use of fewer processes and/or consider alternative programming languages that don't have significant startup overhead if this could become a problem (anything that compiles down to assembly is usually fine).”

This is backwards. It costs extra developer overhead and code overhead to write those invocations in an AOT compiled language. The trade off is usually that occasional minor slowness from the interpreted language pales in comparison to the develop-time slowness, fights with the compiler, and long term maintenance of more total code, so even though every run is a few milliseconds slower, adding up to hours of slowness over hundreds of thousands of runs, that speed savings would never realistically amortize the 20-40 hours of extra lost developer labor time up front, plus additional larger lost time to maintenance.

People who say otherwise usually have a personal, parochial attachment to some specific “systems” language and always feel they personally could code it up just as fast (or, more laughably, even faster thanks to the compiler’s help) and they naively see it as frustration that other programmers don’t have the same level of command to render the develop-time trade off moot. Except that’s just hubris and ignores tons of factors that take “skill with particular systems language” out of the equation, ranging from “well good luck hiring only people who want to work like that” to “yeah, zero of the required domain specific libraries for this use case exist in anything besides Python.”

This is a case where this speed optimization actually wastes time overall.

Docker / containers are necessary but not sufficient. For example, in a machine learning CI / CD system, there could be a fundamental difference between executing the same step, with the same code, on CPU hardware vs GPU hardware.

Many CI systems try to strictly enforce hermetic build semantics and disallow non-idempotent steps from being possible. For example, by associating build steps with an exact source code commit and categorically disallow a repeat of a successful step for that commit.

Isn’t Drone also an example of the author’s ideal solution?

[flagged]

I do agree with the consistency thing. One bad culture failure mode is a case where one or two senior executives run amok enforcing their view of culture, while the CEO fails to enforce consistency and a bunch of other executives, directors, etc., just try to “stay out of it” and remain culturally neutral (which isn’t really possible).

I saw this in one company where it was the CTO running amok with an aggressive culture of yelling in meetings, slamming doors, and emphasizing arbitrary deadlines.

I saw it in another org where it was the CPO instead, trying to install Dilberty consultant snake oil with constant reorgs and zero accountability for product managers.

It’s really sad that you are blind to your own severe discrimination. If you think in sweeping generalizations like, “leftists make the mistake...” you really need to step back and spend time not commenting at all and work harder to gain more self-awareness about your own prejudices.

I know you will not like this comment and you will want to knee-jerk reply to “refute” it, but you need to resist that urge and admit you have really significant and really troubling prejudices that come through like a megaphone to others observing you, and spend time just dealing with that.

That you feel you are identifying solutions, or even a definition, not understood or pursued by people creating things like microinequity training, just reveals your ignorance.

I think my earlier comment which you described as a “no u” comeback was actually really apt and crystal clearly accurate based on your follow-ups.

sounds suspiciously actually like you don’t know what systemic racism is...

Posts that masquerade as “legitimate dissenting opinions just not getting a fair shake from the left by golly” but which really seek to undermine structures by which systemic racism can possibly be called out and held accountable for harm (like the framework of microaggressions) deserve to be flagged and shut down. They don’t serve any free speech or intellectual honesty purpose to preserve discourse and the psychological safety to disagree, and they are roundly disingenuous tools for filibustering actual legit discourse and progress. It’s just taking crass tools of hate groups and dressing them up with five dollar words and armchair discussion of academic freedom of expression, when really it’s just hostile noise jamming against progress.