Claude is laughable hypersensitive and self-censoring to certain words independently of contexts (...)

That's not a problem, nor Claude's main problem.

Claude's main problem is that it is frequently down, unreliable, and extremely buggy. Overall I think it might be better than ChatGPT and Copilot, but it's simply so unstable it becomes unusable.

Can you clarify how “Not even Github managed to pull that off”?

GitHub actions has an atrocious user experience, to the point that even a year or so ago people where doubting it was production-ready.

Sure, you can put together a pipeline. But I challenge anyone to try it out with GitHub actions and then just try to do the same with GitLab or even CircleCI or Travis.

The fact that people compare GitHub Actions go Jenkins of all things is everything anyone needs to know about it's user experience.

I love the idea of being able to fit 4 big D’s

I'm more interested in knowing whether the charger actually supports that type of usage.

That is the work of a software engineer.

To build upon this, we need to keep in mind that at least in some jurisdictions the role of a certified engineer is only required in projects with relevant size, and the responsibility of that engineer is to ensure the project complies with all requirements and therefore be held responsible for any mishap. This means that it's perfectly fine if non-engineers work independently on complex tasks, provided that an engineer attests that their output is fine and takes responsibility in case it isn't and it causes problems.

Poorly defined nomenclature. Simple as that. I’m an “automation engineer”, have had many other titles (...)

Anyone can call themselves what they feel like it. However, in some jurisdictions and contexts the title "engineer" does have a specific meaning, consisting of someone who not only has the necessary and sufficient training but also is a member of a specific professional body. These credentials have meaning and those who try to pass themselves off as one without having the certification or credentials might be breaking laws.

Surely you got a bonus and a raise out of it right? Right??

The only reward I got from it was recognition from my team members, which was already more than what I was expecting to get.

My manager was praised for the higher team velocity and improvements in the team's burndown chart. The hallmark of having done good work is seeing others trying to take credit for it.

I think that it’s because a) the abstraction does solve a problem, and b) the idealized solutions aren’t actually all that simple.

I'd go a step further and state quite bluntly that these critics do not even understand the problem that the abstraction solves, and their belief is formed based on their poor and limited understanding of the problem space.

Everyone can come up with simpler alternatives if they throw most requirements out of the window. That's basically the ages old problem caused by major rewrites and their expected failure once the unknowns start to emerge.

But I still agree with the article because I also think that a) the problem solved by the added abstraction isn’t practical, but emotional, and b) the idealized solutions aren’t all that complex, either.

Hard disagree.

There is not a single technical argument refuting these abstraction layers; only ignorance of the problems they solve. It's easy to come up with simpler solutions if you leave out whole sets of hard requirements.

The idealized solution never leaves the conceptual stage because the idealized solution is never thought all the way through and the key requirements are never gathered. That's when the problems solved by the abstraction layers rear their head, and what forces these critics to face the fact that their proposed solution is inconveniently converging to the real world solution they are complaining about, but that they are reinventing the wheel poorly.

What do you mean by "build step"? For example, does running a barreler count as building?

Java is the only programming language to get popular as a result of marketing.

I don't think this is true. Java is an outstanding tech stack and was revolutionary in a lot of ways, to the point that it motivated others to shamelessly clone it and in the process create other outstanding tech stacks. See C#.

For starters, Java solved the deployment problem way before containerization was a thing. Developers could simply put together a fat JAR, drop it in a web server like Tomcat, and it would simply reload without a hiccup.

Java is also very tooling-friendly, and has a solid versioning policy.

In IEEE, VB is way way down the list. Do IEEE members use VB less?

TIOBE measures social media chatter. Odds are there are far more people posting noise about VB just due to the low barrier of entry.

Also if I recall correctly VB is heavily used to customize Excel spreadsheets, which contributes to a larger potential userbase than any programming language.

Something in the dependency tree will yell at you that it is deprecated or discontinued.

Only if you didn't pinned the dependencies you actually consume, and expect that all your dependencies magically comply with semver.

Blindly replacing dependency versions never worked, at least reliably. If you do not put in the work to ensure things work, more often than not you'll be surprised by them not working.

There is no C++ tool (AFAIK) providing an exhaustive check of ALL the data lifetimes.

Your reply reads like an attempt at moving the goal post.

The initial point was "Sometimes it’s easier to try a new idea in a new language (e.g. the borrow checker in Rust) rather than trying to shoehorn it into an existing language", to which I pointed the fact that yes it's indeed possible to "try a new idea" like borrow checking, and it only takes adding a tool that runs in a post-build/unit test step. It's simpler, easier, and does not force anyone to rewrite projects from scratch.

Claiming "oh but it might not work as well" is not an answer or a refuttal.