mbeex

Some time ago, I - a seasoned C++ and Python developer - became part of a team, redesigning build and deployment aspects of a complete embedded code landscape, embracing a lot of developmental activities, projects, whole product lines etc..

I think most people who recommend alternatives completely underestimate the degree and extent of specific compiler, tool, library, IDE, and general native-build environment knowledge that CMake has swallowed and incorporated over its years of existence and continues to do so. Including all these quirks & particularities of the endless number of components, software artifacts and tools it handles. This is the whole reason for his success and the one thing no swift, elegant, new-paradigm new player can surpass short-, mid- or - in some cases - even long-term.

Most of the time you can tell the real experience of someone judging CMake simply by his kind of troubles with it. Admittedly, the syntax is ugly and often inconsistent. Consider a list 'alist' and depending on context you can or must reference it as either alist, ${alist} or "${alist}" - terrible, true. The most complex data type is aforementioned list, often as under pain bearable nested variant. Math is cumbersome, no unicode support for string manipulations like positions, length calculations, the list is going on seemingly ad infinitum.

But you can learn this rather quickly and when you write CMake code for some weeks you will become accustomed to it. In the meantime, other levels of annoyances begin to appear. For example, the allowed context of generator expressions is inconsistent, incomplete and sometimes - from a cmake writers point of use - almost artificially limited. Take add_custom_command: It allows for GE's in his DEPENDS and also COMMAND sections - but not as argument for OUTPUT. But wait, starting with CMake 3.20 it does, but:

" Arguments to OUTPUT may use a restricted set of generator expressions. Target-dependent expressions are not permitted. "

Unfortunately, those are often exactly what the developer is looking for. Reason here is as in many cases the deeply ingrained two-pass configure-generator nature of CMake.

For any real project, state becomes quickly important. Diving through many levels of sub directories and maintaining/conveying information between the associated CMake projects becomes far from trivial in no time. And no, cache variables are not the solution.

Another issue is the interaction with higher languages in CMake code. Most people start quickly with execute_process(${MY_PYTHON} ...) in order to handle more challenging topics. Problem is the lack of smooth communication of the results without workarounds like temp files, whatever else.

Also, any dependency requirements not covered by the standard cases, might it affect rebuilds, reconfigures or regenerations, requires deeper knowledge of CMake's actual dependency resolution mechanisms. Often only inspecting his time-stamping bookkeeping or exploiting his trace / graphviz / file-api output will help here (neglecting source code inspection, this is rather rarely required).

In principle, the task requires a fully-fledged programming language - but containing all the accumulated knowledge of CMake about his subjects.

Not an advertisment, but for any beginner I can only recommend Craig's book

https://crascit.com/professional-cmake/

It continously integrates changes from new versions. He is also always helpful in CMakes own discourse forum and gitlab issue tracker.

Buyed the real thing from his site (https://www.kleinbottle.com/ as mentioned) 1.5 years ago. Much more to enjoy there anyway.

Thanks Cliff & Greetings from Germany

> (or really `refs/heads/origin/`)

It is worth the time to fully understand refspecs. Once people do, they tend to understand all essential ramifications of branch and repository naming.

Reading the comments, I get the impression that many people are somewhat lacking perspective.

I've been writing software professionally for more than 25 years, > 30 years in total. gnuplot has been around all that time. Developed in an academic environment, people probably (certainly) had other things to do than argue about name comparisons to other projects. And nobody cared.

There are things that are not an invariant of time. And frankly - open source along with the ideological battle over it is certainly one of those things. There were times with a much healthier way of dealing with zealots (Oh, this will cost me karma, but fortunately I don't care :-)

I started walking three years ago at the age of 55 for ~2000 km per year since. There was Hypertension and a suspected heart problem at this time, so I was cautious about running. I also have a nice area of wood very close to my home.

It turned out quite well. I am officially heart-healthy today, blood pressure went down about 20-25 mm Hg, weight 10-15kg.

Regarding running - I do it the same way I do something for my upper body. Sometimes the body is longing for it, and than I do it. In the case of running: Long walks often give a certain stiffness, especially in the legs. When this happens, I simply include a few (1-3) kilometers during the walk.

I also learned, that it is far easier to sustain such a regime instead the more common forms of exercise. I think its more natural for all but a few people in the long run. Someone wrote here about running as hunting/fleeing which by origin is necessarily associated with stress. I think there is much truth in this.

The only part that becomes sometimes difficult, is the time demand. Doing the math: My 180 km / month are 12km (two hours) every other day. I had to aquire some additional discipline to make it happen.

As someone else remarked here, if you are good enough to become employed, this would in my opinion statuate one kind of level (among many possible) describing something reasonable final (I agree of course, after this you will learn a lot more).

The other point is, life is not finished with doing coding. While I'm still a not too bad programmer, in particular my C++ abilities are not on par with my former ones. Simply, because I nowadays write most things in Python, wear other hats than pure programming etc., but I certainly can say I learned to code.

I'm a trained mathematician, but old enough to elude anything serious regarding computers during my studies more than 25 years ago. I did some Turbo Pascal + Assembler for my own interests completely self-taught during that period, though. I had to change direction at 31. After five years with small gigs mixed 50/50 with employment (main result: Getting an in-depth grasp of C++), I became a full-time freelancer at the turn of the millenium. I never looked back and always learned along the way. Because people continue reaching out to me, I tend to think doing some things right.

Where are the other 700 comments?

I'm in no way a native speaker - but even I recognize that in English 'master' has - and always had - many different meanings. One of them completely equal to the German 'Meister'.

It is all about context. Question is, why certain groups emphasize - or better: impose deceivingly by altering him - the wrong context to a crystal-clear situation.

> The German way is

What exactly do you know about "the" German way?

First and foremost, it is a disproportionately loud group in terms of the media, small or not. This is the important issue.

I got the impression, that he refers more to the fate of his own hopes.

No, and in particular by speaking about slices with a lower dimension d-1 it becomes not immediately clear, what their volume has to do with the one in dimension d of the original body, mentioned at the begin of the article.

It is. But unfortunately, most people are not willing to separate the concept of progress from something that is magically inherently good. Same as with evolution or agile development :-)

> This is not how politics work in the rest of the world.

On the contrary, a strengthening of this very pattern can be observed everywhere.

> The deal breaker for me is the fee for bank transfers, something I've never paid for before.

You are too young :-). This also might change. German banks start again to take monthly fees for accounts, so why not for single transactions.

This said, I have to deal with accounts in NZ and Europe. Fees as well as speed for transfers between them is a whole other world when using TW compared to classic banking. These kind of costs have exist forever, SEPA conditions are the exception, not the rule, internationally. TransferWises multi-currency account is a nice part of the package. I learned here today, this can be done even cheaper by using a Forex broker like IB, but I don't need this on a daily basis.

> Sounds like your personal experience.

You can say exactly the same from the opposite perspective.

I'm a freelancer and while I am _personally_ more than happy with remote work (prefering it for many years), many people are not. It is also a cultural thing, agreed. But the culture based on personal contact isn't a bad thing per se. In many cases it is superior, especially when considering mixed variations. Regarding the argument that companies get remote work wrong, the same is true for the former normal of physical presence. There is simply much more experience with this. It will not need much time, until remote work shows his nasty sides large-scale too. And they are there yet. Control mechanisms as one of the more unsubtle examples become more sophisticated every day.

> but the differences between individual VGA cards were too big.

Buyed the programming manual for the ET4000 GPU (>100DM for this manual alone, a lot for a student from the eastern part of Germany at this time), opcodes and all. I liked the possibility to easily mix Assembler with Pascal in Turbo Pascal. Machine code for graphics, FPU, interrupt programming, the higher language for anything else.

After that, I learned C from the Open Source Fractint. So, the transition wasn't that painful after TP's decline.

And anything was so snappy in Turbo Pascals text mode windowing system (as with Norton Commander too).

> and they always made it seem like I was the crazy one for thinking this.

Ask them a specific question about their code three months later.

Not this simple. Refactoring might mean invariance, but the more comprehensive your tests are, the more they also test the moving parts. That means, they have to be changed too. Many people forget the maintenance costs (and this has a much broader meaning than the refactoring example). Tests themselves have to be considered as a software (or more general) artifact with a cost.

I tried it (again). First impression: No support for the black formatter. We have 2021 - really?

https://youtrack.jetbrains.com/issue/PY-39750

> But for f-strings, it has full support for the "inline" variables.

Is this complete (meaning: it also includes more complicated expressions, referencing these variables)?

I'm asking, because some Python development tools are failing in doing it right. This leads to annoying reliability issues for refactorings (even for simple renames). Currently, I have the problem with Wing IDE.

> never any time pressure in life is a bit naive

Missing the related point from the comment is... what? Deliberate?

I dont buy this, reading many of the comments here. I'm not a native speaker and not certain at this moment if the figure of "hamster wheel" exists in English. But "rat race" does, as well as "cog in the wheel". There is a certain underlying trait of self-optimizing anything, also visible in the HN articles title itself (fortunately not so much the content) as well as in many other articles of this kind, coming up here continously. And these optimization considerations are >95% limited to time, they are much closer to self-exploitation than anything else.

Cooking for the moment aside, consider lunch. I'm German (sadly, the country became closer to the US in this respect). But if you ever worked in France or Switzerland for example (not to talk about countries even further into the South), you will spot much a difference here - yet in time spent, but also in the opinion what is important at all. Cooking is the same - it is not all "hungry family" (I certainly agree, at times it is), these are more often than not rationalizations. When I am cooking, the kitchen full of people is the most satisfying situation. It doesn't matter really, how long it lasts. This is not lost time, on the contrary! Also not in the context of work, because it eventually produces energy (I don't mean the calories) also for this.

A final small example: I have an Italian espresso machine here in my offices kitchen. Producing an espresso or cappuccino requires to do all steps manually: grinding beans, evaluating the pressure on the analog gauge, provisioning the milk, making foam from it, etc. - time-consuming! But it is a micro ritual, making my head free enough for handling some of the kinds of small problems, appearing during work. I could also buy something 'modern' using pads, maybe some sort of remote control, even a robot serving the final result to me (are there such things?). I certainly will never do this.

> It shouldn’t be discouraging that professional & motivated amateur chefs are faster than you

I don't see, why cooking should be a competition for speed in the first place.

What, if your ability for imagination is lacking? What, if this would be true in general? What do these implementers actually implement then?

I also think, I have another definition of 'idea' than most people here. It is common especially in software development, to see the way as the destination and incremental change as development caused by some magical good-ending evolutionary process. This includes a quite unsubstantiated belief in getting the right ideas automagically along the way.

You need both things. A good idea does not descent from heaven. Also, it has history in the person, creating it. This history is hard work in its own, inner fighting against the common and the environment. Jumping out of the box, all these pure implementers are unable to do.

I am working for 25 years in the industry. I have written real code from the beginning. But I am also a mathematician and can say I had a few good ideas along the way. I am proud of it.

> Ideas are so cheap and easy.

I doubt this.

In this case, give DeepL a try. Translations between English and German at least, are magnitudes above Google, IMO. Not without errors, of course.

"Neural Network weights are learnt via Gradient Descent and Neural Network architectures are learnt via Graduate Student Descent."

Like it!

Another issue here is an extremely narrowed definition of productivity. It has cog-like traits, Fordian belt work comes to mind. Yes, in this context you can become less productive for one reason or another. But all these micro-optimizations will also affect the mind in the long run in a much more profound way. More than anything its higher forms - even of productivity - especially these connected with creativity.

You cannot fight this with a clock watch the same way the vast majority of people cannot lose weight by simply dieting. For this, you need positive incentives. Not to be misunderstood, sometimes you have simply to grit your teeth.