The road to hell is paved with good intentions and C++ modules (2023)

> a ninja compatible format can be generated but is not the default

The suggested flag was not for a "ninja compatible format", but to exclude things from the makefile snippet that ninja doesn't understand (yet). It would exclude necessary information for modules to function.

Problem is, the new syntax used by the compiler's -MF output violates current-day expectations by both compilers and build tools as to what those snippets contain, and it'll be a while to sort out what the acceptable syntax would be. As noted, Clang doesn't use this file to propagate the information at all.

Typical GNU attitude. I'd say the author is correct unless there is a good reason to make it incompatible with Ninja.

Exactly because of much greater stakes. A lot of heavyweights involved, and nobody agrees to yield. The result is a compromise, aka a solution which is unsatisfactory to all parties to an equal degree, as they say.

Best designs are produced by small, tightly-knot, often one-person design teams. Examples: Unix, Clojure, SQLite, Boeing-747, Westminster Palace in London.

Sometimes a small team with a cohesive vision keeps on attracting like-minded people or matching ideas, and the project grows with contributions from a large number of people. The key part of every such success is the vetting process. Examples: Python, Ruby, FreeBSD and OpenBSD.

Worst designs with most glaring, painful, expensive, even tragic shortcomings are produced by large committees of very important people from huge, very (self-)important companies, agencies, departments, etc. Each of them has an axe to grind or, worse, a pet peeve. Examples: PL/I, Algol-68, the Space Shuttle (killed two crews because the escape system was removed from the quite sane initial design); to a lesser degree, it's also HTML, CSS, and, well, C++ to a large degree :( The disease has a name [1].

Sometimes a relatively small and cohesive team in a large honking corporation produces a nice, cohesive design, like this happened to Typescript, certain better parts of CSS, and some of the better parts of C++. This may sometimes make a false impression that "design by committee" sometimes works.

[1]: https://en.wikipedia.org/wiki/Design_by_committee

Because the C family is guided by a committee. Even worse, an important and respected committee.

After a decade of using obj-c modules I'm still unclear on what the benefit of them is other than the Swift bridging aspects of it. There isn't really any observable difference in either compile-time performance or behavior from turning them on and off other than that a lot of the rules around inclusions are much stricter with modules enabled. The documentation claims that they should improve build performance, but AFAICT that isn't actually true or the difference is so small as to be irrelevant.

Is easy, you don't have the same amount of courdination problem, most of what's wrong in software today have in big part problems whit two things legacy and coordination problems, need back compatibility means that useful solution aren't posible, soy then you need to compromise and then compromise again because some users cant use you solution, so now you have solution who don't satisfied anyone, sum that whit natural misalignment of any organization and is obviously that focus sitmrs whit few stakeholders and willingness and capacity to break change can do a better job, this ins't particular problem of programming.

Backward compatibility with existing compilers.

And more importantly, not breaking old, old codebases, which is a very critical problem.

Obj-C++ and D don't have critical codebases, because there is just so much less code. Apple does what they want.

Like Stroustrup says, when a language is not used, it won't generate problem: I gues his quote is often quite overlooked, but it's very very true.

Compilers are a difficult topic.

I don't know of anyone happy with the C++ standard committee.

Some parts of the new std features were copied from Python, which is good, a semantic and naming a lot of people already know. Yet some weirdo decided to half copy the naming scheme of APL and we end up with functions named "iota". Seriously. What. The.

Don't get me started on features added in C++17 and deprecated 2 versions later.

Don't ask also why they decided to rename universal references by forwarding references while the former makes sense and the latter none, just because they were pissed to not have named it first.

All I want now, for the future of C++, is a Circle-like approach. I want to be able to selectively disable and replace legacy behavior and syntax, per file, so that at last we can have the language evolve.

It's because they're trying to make a module system that is compatible with decades of development based around `#include`. It's nowhere near as simple as making a new language with modules.

I almost feel like they should give up. IMO Rust and Zig have made C/C++ a legacy language. Except in some specific areas where Rust doesn't have mature libraries (GUIs & games mostly) you'd be silly to start a new project in C++.

Migrating existing C++ projects to modules likely isn't worth the enormous effort, and the days of starting new C++ projects are numbered... so why bother?

Would love to see the visualization if you have it on hand!

If by fixed you mean "elaborate measures for specificity and saliency but still the same order of undefined behavior & bugbears" then yeah? It's gotten a lot more... more.

Fortran modules are great for developers but a bit of a pain when setting up a build system (even though it’s quite straightforward now, it still requires a first pass with something like makedepf90 or one of its many equivalents). I find it quite a feat that C++ modules, while benefitting from the experience of many languages, ended up so broken.

Also, I never really liked cmake but this looks really bad.