First it was shitty C code in the 90s, and now the Java language. At least I'm not totally burned out on Javascript yet :-)
What's the market do? Push all effort into C and C++. Results of that are still with us. (sighs) Go and Rust give me some hope in that they're first mainstream languages that solve some problems. On non-mainstream, Julia is an awesome development that might be re-applied to systems programming. Not to mention Racket's metaprogramming combined with C or assembler generation for a high-level use of low-level, fast language. Ivory language does that with Haskell, for example.
So, not as Worse as usual. Still true overall.
Not to mention the amount of money spent writing band aids for them., in form of static and memory analysers and more recently CPU instructions (Intel MPX).
Which not everyone uses, because either it isn't available on their platform, or they choose not to use them anyway.
Just like coders that despite C++ safety improvements over C, use it as C with C++ compiler.
" because either it isn't available on their platform"
I tried to solve that with my tools (lang X) using X-to-C compiler w/ seemless FFI for 3rd party code. Encouraged other languages to do that with many having done it before I got on the scene: Modula, Oberon, Ada, LISP/Scheme, and so on. Let them use good language with hardware/OS of choosing. Ignored it as you said.
"Just like coders that despite C++ safety improvements over C, use it as C with C++ compiler."
David Thornley brought this up on Schneier's blog when he said he was distrusting about those who mentioned "C/C++" as if they're same thing. That using modern C++ prevents many C issues if it's used correctly. Now, I abandoned C++ as anything but a compiler target after all the 90's empirical evaluations showed it was garbage. I think my critique that it lets you shoot yourself in foot easily and is hard to analyse probably still applies like it did when I cited them together. It's why I do.
Nonetheless, I honestly don't know how modern C++ developers code when they're doing it "right" with style guides, newer language features, peer review, etc. I think it would be fair in these discussions to do some new, empirical studies comparing proper C++ to Free Pascal, Go, Rust, Ada, etc in various attributes like was done in 90's. Critical that it's used as pro's say it should be so as not to mislead readers about effectiveness (i.e. C++ used like C didn't work). You know any resources I could use to catch up on topic that capture most or all of how pro's do C++ with modern features? Not necessarily most recent standard but what has been used at least past 5 years maybe 10.
- type safe enums (enum class)
- STL collections instead of plain C like types
- references for out parameters
- RAII
- smart pointers
- values types over heap allocations everywhere
- warnings as errors
The problem is making sure there aren't some guys in the team doing C style coding.
Nowadays C++ is still my language to go when I need to step out of Java and .NET.
The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code.
Effective Modern C++, Tour of C++, Elements of Programming and From Mathematics to Generic Programming are all good books, where safe modern C++ is used.
Thanks for the summary and references. Will be helpful if another honest language comparison is done of C++ against safe, systems languages. Or C++ developers against others on realistic, example programs.
"The problems faced by Turbo Pascal and other languages to keep up with the OS vendors SDKs teached me to only invest on first class languages for production code."
It makes sense. My solution was a auto-generating that from a better language and wrapping their libraries. That does take some serious tooling support, though.
https://www.gnu.org/fun/jokes/unix-hoax.html
Even a professional and fan of C once admitted that this was great because it could've been true. Ain't that something. ;)
So much programming machismo:
* Bounds checking is a little slower, so safeties off!
* Multiprocessing with explicit IPC is slightly slower than thread pools, so safeties off!
* Parameters and explicit return values to functions are a little slower than DATA-DIVISION / instance variable mutation whack-a-mole code, so safeties off!
Funny part is they say this even when alternative languages or libraries implement safety tricks without a performance penalty. Then we see clearly that their resistence isn't technical. ;)