lysdexic

I imaging trying to be a professional electrical engineer (despite having a degree)

That's the definition of specious reasoning, and fails to address the point I made.

I like this bit because it really is a common answer whenever someone complains about how maddening/inefficient some tooling is nowadays.

I don't think this is a valid take. What we see in these vague complains about levels of abstraction is actually an entirely different problem: people complaining that they don't understand things, and they feel the cognitive load of specific aspects is too much for them to handle.

If the existing layers of abstraction were actually a problem and they solved nothing, and if removing them would solve everything, it would be trivial to remove them and replace them with the simpler solutions these critics idealize.

Except that never happens. Why is that, exactly?

A very large part of the problem is that the people who are knowledgeable are often the ones that bought into the whole lone wolf coder shtick.

I'd add that a large part of the problem is that we have people complaining about perceived problems without being able to present any kind of solution.

This might be relevant to the discussion:

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

To start off, CLion is a paid service that costs individual users €100/year, while Qt Creator is completely free. That's a huge motivator to not onboard onto Clion.

But if you want me to give concrete examples of how problematic git UI can be, you are so far removed from reality and are neglecting the very visible and vocal struggle git beginners have.

And yet you were not capable of providing a single example. You managed to put together personal attacks, but no example.

Like everyone has mentioned, because you want the data to persist across program runs.

RDBMS do not imply persisted data. There are plenty of databases which support or are designed explicitly to work as in-memory data stores. Perhaps the most popular one is SQLite, whose in-memory store is a popular choice.

The problem with desperate monetization stunts like this video is that they rarely have any relevant content to show, and they are a formulaic output of mixing clickbait titles with 15min of inane fluff.

Why do so many programs use rational databases instead of loading the data during startup and keeping it in memory?

I presume you're referring to relational databases instead of rational.

The responsibility of a RDBMS is to implement a set of performance-focused data structures that help clients reliably get the data that they need in the fastest possible way, without having to reinvent the wheel.

More often than not, this data does not fit in the heap.

Also, in many usecases there is more than a single client.

Hope this helps.

What the fuck am I reading?

That explanation apparently it is: “because not everyone in the ecosystem acts the way CMake developers would want them to”, which I read as “CMakes design for external dependencies is broken.”

Not really, it just means you manifest a blatant and critical misunderstanding of what build systems in general do, and in particular what are CMake's responsibilities.

As you're guiding your opinion and expectations on a mental model that's fundamentally broken while being oblivious to the brokenness of the mental model, instead of identifying the real problem you're falling back to blame tools.

The issue is quite simple: CMake is a high-level abstractions which is used to generate arbitrary build systems on arbitrary platforms. No platform provides a standard way to make libraries or modules available. At best, Unix-like OSes store include headers and static and shared libraries in specific locations in the file system, but each library can and often does allow users to customize it's installation. There is no way platform-indendent or platform-specific way to configure these. How do you solve this issue?

CMake solves this issue in a very simple way: library vendors can export CMake config files that downstream dependencies can use to configure their CMake projects. The hard problem becomes a solved problem. However, this requires library vendors to own this leg of the process. Not all projects do. So what can be done about those?

For projects whose managers don't support CMake, CMake provides two mitigations: it ships with CMake-vended config scripts for popular libraries, and allows users to provide their own custom CMake Find modules.

Describing this approach as "broken" is quite honestly a very ignorant and clueless thing to do.

The fact is, where we are right now, today, the find_package/config script design in CMake frequently makes resolving external dependencies far more painful than it already is without that complication.

This personal assertion makes no sense at all and has no basis in reality. The only thing that find_package does is check if someone made available a script that tells CMake how to configure a dependency. If no script was provided, CMake makes the package as not found. If a script was found but it's sanity checks fail then CMake marks the package as not found. If a script is found and it's sanity checks passed, CMake can use the targets in builds. That's all there is to it. Pain-free.

The is only one caveat: you have to have some idea of what you're doing, and bad workmen tend to blame their tools.

I’m not sure you are aware, but TypeScript is not the first language (...)

This discussion is about TypeScript.