If you hold Fn you get the traditional row of function keys, which seems like a pretty good tradeoff. And if you really hate that, you can simply configure the touch bar to always display them, in which case literally the only downside is that they are not physical keys anymore. Do people really touch-type the function keys so heavily that this becomes a an actual annoyance and not just an ideological one?
Adding an extra row of physical keys that do the same thing as the row of virtual function keys, at the expense of trackpad size and possibly ergonomic (harder to reach the touch bar) doesn't make a lot of sense IMO.
I like it as well, especially in applications like CLion/IntelliJ which have tons of keybindings I keep forgetting because they are different between Linux and macOS. The context-sensitive touch bar is actually very useful in these applications for things like rebuilding, changing targets, stepping through the debugger etc. without having to use the mouse.
There's a lot of things to complain about with Apple products, but if you ask me there's been enough touch bar bashing by now and people should just get over it. It's pretty useful in some situations, and IMO no real downsides, especially now that the esc key is a real physical key again. Why all the hate?
Apples and oranges, Delphi != C++, and on top of that I don't think you really want to make the argument that the Delphi IDE can do all the things CLion can do for C++. I fondly remember my time writing Delphi, but I'm not jaded enough about the resource requirements of modern IDE's to pretend that you can compare these environments equally.
Anyway, I don't really see the point you trying to argue here. It appears you are principally opposed to software that uses more resources than what you consider necessary, which is fine and in the case of something like CLion or VS code justified to some extent, because they are far from lightweight. But if you remove these ideological objections from the discussion, none of this actually matters all that much considering typical workstation hardware. I honestly don't mind trading 4 or 8 of the 16 GB of RAM in my laptop for all the features I get from CLion compared to the alternatives. A full compile and run of the thing I'm building can easily get by with (much) less than 2 GB. And if I would be developing something that uses up 8+ GB by itself, I probably want a beefier workstation with 32 GB or more anyway. It's just not an issue, RAM is plentiful, and it's in there to be used.
It's not the editor part that uses all this RAM I suppose, but the code parser and indexer that by default includes scanning & interpreting all your dependencies (system headers, boost, other third-party frameworks). There is a clang process that has the full AST for all of your code + its dependencies in the background all the time, so you can get search, index, autocomplete, syntax check, refactor etc. that actually works compared to the half-baked solutions you get with VIM plugins (and I've tried all of them).
I guess you can switch all of that off of course, but that's what makes it an IDE and not an editor. I think the memory tradeoff is perfectly fine for this kind of application.
One thing I've found with CLion is that you really, really want to edit the JVM settings for the IDE. By default it starts with a 2GB memory limit for the JVM, which even for small projects will severely drag down performance, e.g. my MBP would run very hot, spin the fans and the IDE would get very laggy. Increasing the JVM settings to allocate 8GB completely solved this.
I wanted to say exactly that. I've never been a big fan of vim plugins in IDE's, even though I still prefer them over no vim bindings. The VS code or Eclipse vim bindings are 'not great' at best, for example. But CLion + vim plugin is actually very good: it uses my .vimrc, doesn't mess up undo/redo, supports things like block select in visual mode, etc. The only downside is that it interferes with some standard CLion keybindings (which is inevitable I guess), so you have to remap some things.
Why? I've been running pi-hole on the home network for over 2 years already, and indeed sometimes I get complaints about shopping sites not working, but there is always an alternative site that does work so we order there instead. Just last week it even saved us money because it turned out a different site had the same product at a significantly lower price.
Apart from a few non-important edge cases literally every major site works without problems with a pi-hole. I think 'simply stop using sites that refuse to work unless they can track you' is a very valid and workable solution.
Adding an extra row of physical keys that do the same thing as the row of virtual function keys, at the expense of trackpad size and possibly ergonomic (harder to reach the touch bar) doesn't make a lot of sense IMO.