esoterae

Honestly, this is a reasonable itemization of experience with individual tools, but this reads like a recipe for Company Cake instead of a case-by-case statement of need, selection, and then evaluation. Cargo culting continues to wrap its tendrils around the industry and try to drag it into the depths of mediocrity, and this largely reads to me like a primer for how to saddle yourself with endless SaaS bills. I recognize that every situation has its nuances, but I think approaching running a company from "what tools do you use" is pretty much the biggest possible example of ignoring that maxim.

The full aphorism is:

Jack of all trades, master of none, is oftentimes better than master of one.

If a vegan LLM evangelist crossfitter comes up to you at party, which one do they talk about first?

What a remarkable stalking horse to try and kneecap right-to-repair by arguing "Please, think of the chil^H^H^H^Hhackers!"

You wouldn't download a CAR, would you? You wouldn't hack your own INSULIN pump, would you?

Face it: If it's GPL and vulnerable to interference, responsibility is squarely on the manufacturer and the fastest death-free way to prove it. If it's GPL and modified by the owner, fuck off.

I think their point was that there is no empirical definition of information as it relates to the observer. The expurimint you cite worked upon a physical system that already had a state prior to the expurimint.

If everything is information, then nothing is.

A disordered system still has state. You just don't know what it is.

The whitespace thing is actually one of python's major flaws. That feature attaches syntactic meaning to non-printing characters. From a human standpoint, there're many examples of silence having some kind of meaning. From an engineering standpoint, that entire methodology is insane. Communication needs to be positive and deliberate.

Remember that Apple SSL bug "goto fail"? That was a whitespace bug, because even if the C feature predated python, everyone's eyes had been trained to slide right off that particularly crass shortcut as python was widespread by that point.

Where does one begin with this kind of fallacy-ridden mud slinging? Appeals to both authority and majority, and guilt by location just to name the first three.

So what if "everyone in Seattle hates AI"? What gives The Author the right to simultaneously invalidate Seattle's comparatively immeasurably larger advantage in experience, qualification, and education? If even the ludicrously biased title had even the barest hint of truth to it, they've stacked the deck against themselves in credibility unless they've already mentally biased themselves to blindly dismiss anyone that doesn't mirror their own now blatant fanaticism. Which we've already established now includes all of Seattle.

So put this out on the curb with the rest of the garbage meant to inflame and divide, because on it's face it is neither reasonable nor factual.

Where do any of us stand but on the shoulders of giants?

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.

  -- C. A. R. Hoare

Reading this as a pilot, this thing reads like a primer for How Not To Think.

The author might think they're being a meta-pirate by saying "oh these are all possible actions proscribed by most organizations" implying that the proscription itself is a sign of ossified incompetence, instead of identifying the underlying one-true-savior fallacy that underpins it all.

The general danger here is human error. The point of leveraging a collaborative environment is to design process to detect and remediate human error before it radiates outward into more cost. The farther it goes, generally, the higher the cost, non-linearly. It shouldn't be "never do this", but instead "if you're going to do this use every tool at your disposal to make sure it's done correctly." Siloing the entire decision tree to yourself is exactly how not to do it.

> They did really well in some things like ... devops

Did they, though? I ask because the vast majority of people touting LLM as a huge win usually seem to speak from a.. DK-heavy perspective. As in, the bulk of their profession experience hasn't actually been doing the subject they're gushing about the LLM crushing.

So I ask you, what is your level of devops experience to make such a dismissive, sweeping statement? I am pointedly inquiring about my own area of expertise, in case that wasn't clear.

While we're exposing implied things, let us also expose the assumption that this was posted by a real person (:

The driver of this output is a uniform lack of comprehension all the way down.

> we shouldn't focus on how a word is defined in dictionary [sic], but rather ... the ... meaning behind it.

This is a spectacularly, objectively invalid take.

Did you not notice how this started over someone saying "That's not the definition of memory safety" and then prevaricating about the bush when asked to provide their definition? Your theory that this is an argument over semantics is correct, but not fully understood.