Fully agree.
Also, jq exists, a simple example how open and simple interfaces (text streams) allow for extensibility. There is a reason why so much is built on top of "simple terminals".
> That means you have a mix of FORTRAN, ada, c, rust, some custom internal corporate language, and so on all mixed with the C++. If your build system cannot handle that mess i'm not interested
In that case I would just use the rust toolchain which I'm sure can handle this stew.
I'm using C/C++, which do provide a good level of type safety.
And no, types are absolutely not my problem. In fact, rigid type systems are a frequent source of practical problems, and they often shift the game to one where you're solving type puzzles -- instead of working on the actual functionality.
Come on, dude. C provides almost no type safety whatsoever. There’s no point in saying “C/C++” here, because you won’t adopt the C++ solutions for making your code actually typesafe.
Type safety is not a standardized term, and it is not binary. Being black and white about things is almost always bad. One needs to weigh and balance a large number of different concerns.
A lot of "modern C++" is terrible, terrible code precisely because of failing to find a balance.
I work for a Japanese company and if you've ever worked with them you know they go crazy with testing (often automated). I get bugreports like this constantly. And while you might argue if that's a use case or not (mostly it's not), a crash is still a crash! We do go the extra mile to analyze and fix those. It makes the software overall more robust and on occasion you really find a much severe underlying issue that would have exploded in your face also in other, more realistic workflows. Don't dismiss bugs without at least understanding what's happening! As others have stated, a lot of these weird issues are race conditions which might suggest a bigger problem in the design.
Yes! This sort of thing is always, always a real bug which can sometimes randomly show up in normal usage. Figuring out the root cause is really satisfying, so a good repro case (even if it’s just “spam this button a whole bunch and it usually crashes”) is valuable.
Or you can just shrug it off as a mysterious unknown glitch, and live with software that mostly works but occasionally crashes - like almost all software, sadly.
I still remember (well, have screenshotted) this amazing error I encountered in my first exposure to C++. I was writing code for an assignment implementing my own vector container from scratch, and got "no suitable user-defined conversion from "CSXXX::vector::r_iterator" to "CSXXX::vector::r_iterator" exists".
Thank you GCC for telling me that I'm missing a copy/move constructor (can't remember which it was). Clear as mud as always. At least with the several pages of template instantiation errors you can scroll to the top where useful information can sometimes be found.
It's my impression that people tend to underestimate "junior engineers" in the C++ world. I'm always impressed at conferences that there are so many young people holding presentations about really advanced topics.
IMHO this "no junior will ever understand that" attitude comes mostly from older folks who learned C++ as C with classes and to whom even the STL is a work of the devil.
Those people giving talks at conferences are the best of the best. 99.99% of people who write C++ have no interest in the arcane depths of the language, and would rather things "just work" over having a library that does something cool, but hard to debug when things go pear shaped.
Not all, the people giving talks are just people who happen to be interested and curious.
This idea that only the best of the best are able to be curious and learn the nature of the tools they use at a very deep level is misguided and furthermore promotes a kind of anti-intellectualism.
It's also a large part of why I think many developers get burned out, imagine working in a culture with other engineers where people are kind of pressured to only do boring work, stick to boring features, only write code in a very narrow manner that satisfies the lowest common denominator using the same old boilerplate over and over again and keep doing that for a decade or longer versus an engineering culture that values people being inquisitive, breaking out of their comfort zone, writing interesting libraries that abstract out common patterns and eliminates painful repetition, and who appreciate the inherent complexity of challenging problems instead of treating it like some arcane voodoo that only the select few can understand.
