C++ reflections (1 of N)

There was this article that generated a bit of a heated series of comments among C++ developers. Some words in this article hurt (the ego) and could have been said differently… anyway at least it may make people reflect a bit.

Not sure why, but domain specific languages (DSLs) don’t seem to be very prevalent yet.

C++ has many design flaws. Many due to legacy reasons. Some of them probably will never be fixed or changed due to backwards compatibility with the endless amount of existing and mission crticial C++ code. And we will need
C++ developers to maintain these existing and critical systems/libraries.

For cases where performance really matters, unfortunately C++ is a very strong (or sometimes the only) candidate.

The problem is when C++ is used in the wrong context/domain. For example, nowadays nobody would write a desktop GUI application in C++. but on some embedded devices you would (Qt).

Due to its complexity, C++ should be used only in a limited context. C++ is painful to use unless you’re familiar with its weird idiosyncrasies. People with domain knowledge are usually not C++ experts, but domain experts. A domain expert has enough things to think about, and adding C++ to the mix would make them less efficient and more annoyed.

For research (science, with expensive and rare domain knowledge), you would not use C++ because it just slows your scientist mind down with unnecessary language/machine details. But when the research goes into application then you may need to rewrite the researcher’s Python code in some other language for performance reasons.
And that language is sometimes C++, sometimes else.

The complexity of C++ may also make many people accidentally and necessarily become “C++ experts”.

Sometimes it is also difficult to foresee what performance a certain language implementation would give. For example, you choose Java/etc, and then after one year of development you face performance issues. Then you may have to pick up a different language that compiles to more efficient code, and rewrite parts or the entire program. Again, choosing this “more efficient language” is tricky, so you are likely to pick one that is already battle-tested even if it hurts your brain (C++).

Using DSLs in a “right tool for the right job” manner is a great idea. BUT 🙂 In a single project you’re likely to have a limited budget. So you may not afford to pay polyglot software engineers, or multiple software engineers for each DSL. You may also want your team to be “full-stack” (no silos), and also want to deliver on-time. The more tools your team has to master the more difficult and costly development becomes. Unless all the DSLs use similar/familiar syntax, but that may be problematic too, because programmers may introduce bugs/perf issues when writing code in DSL-A while thinking in DSL-2. 🙂

In web/enterprise development the tendency is already kind of DSL-like. You use Javascript for UI/frontend (with its endless frameworks/”DSLs”), Java/Kotlin/C#/Scala/etc for backend, Go/Rust/C/C++/etc for very performance critical backend.

And then job security… you may choose a well established language (Java/C#/C++) to have a chance on the job market. Every language needs to be learnt and mastered at some level because each has its own idiosynchrasies (you need to think in language-A to write “good” code in language-A).
If you want to be a general software engineer then mastering 2-3 languages is hard enough. With a multitude of DSLs for different domains, you may not be able to be a “general software engineer”. You would have to become a domain expert. Doing that in multiple domains is probably more difficult than “just” learning a few general purpose langugaes.

Yes, I hate C++ for many reasons. It makes me waste time with language details, beginners and even experts are bugged with seemingly unimportant things: how to pass this parameter (value/ref/const&/*/optional/etc), how to return this parameter, how to assign this result (const/&/auto/etc.), how to initialize this (default/value/braced/etc), use template not runtime polymorphism here, how to design your class (explict/default special functions, virtual destructor, etc) etc etc.

C++ is good for embedded/high-perf work because there by nature you MUST think about these language details. That is part of the domain knowledge of the embedded developer when using C++. It would be great to have a DSL for embedded. But that DSL would also have to be somewhat extensible by the programmer. And that may lead to an overcomplicated DSL. And if it’s extensible only via a comittee then that may be a slow process and people move on to some other DSL (or non-DSL) 🙂

I wish we wouldn’t need C++! I really do! 🙂

END OF POST

---