I do not mean to pick on C++: the same problems plague C, Ada, Alef, Pascal, Mesa, PL/I, Algol, Forth, Fortran ... show me a language with manual memory management and threading, and I will show you an engineering tragedy waiting to happen.
I think if programming is to make progress as a field, then we need to develop a methodology for figuring out how to quantify the cost-benefit trade-offs around "engineering tragedies waiting to happen." The fact that we have all of these endless debates that resemble arguments about religion shows that we are missing some key processes and pieces of knowledge as a field. Instead of developing those, we still get enamored of nifty ideas. That's because we can't gather data and have productive discussions around costs.
There are significant emergent costs encountered when "programming in the large." A lot of these seem to be anti-synergistic with powerful language features and "nifty ideas." How do we quantify this? There are significant institutional risks encountered when maintaining applications over time spans longer than several years. There are hard to quantify costs associated with frequent short delays and lags in tools. There are difficult to quantify costs associated with the fragility of development environment setups. In my experience most of the cost of software development is embodied in these myriad "nickel and dime" packets, and that much of the religious-war arguing about programming languages is actually about those costs.
(For the record, I think Rust has a bunch of nifty ideas. I think they're going down the right track.)
I think this is a pretty big myth that only applies to some of these language features.
If you admit that it applies to some language features, then it's not a myth by definition.
In Smalltalk, #doesNotUndertand: handlers and proxies and unfortunate "clever" use of message sends synthesized within custom primitives could result in outsized costs. (It's where method_missing comes from in Ruby.) It's not that you couldn't do powerful and useful things with those facilities. It's that large projects that were around for years tended to accumulate "clever" hacks from bright young developers with a little too much hubris. Often, those costs would be incurred years after the code was written.
Yes, it only applies to some language features. But it clearly does apply to some of them. I don't think it's easy to come by quantified costs for these. Doesn't this strike you as a problem for our field?
I think if programming is to make progress as a field, then we need to develop a methodology for figuring out how to quantify the cost-benefit trade-offs around "engineering tragedies waiting to happen." The fact that we have all of these endless debates that resemble arguments about religion shows that we are missing some key processes and pieces of knowledge as a field. Instead of developing those, we still get enamored of nifty ideas. That's because we can't gather data and have productive discussions around costs.
There are significant emergent costs encountered when "programming in the large." A lot of these seem to be anti-synergistic with powerful language features and "nifty ideas." How do we quantify this? There are significant institutional risks encountered when maintaining applications over time spans longer than several years. There are hard to quantify costs associated with frequent short delays and lags in tools. There are difficult to quantify costs associated with the fragility of development environment setups. In my experience most of the cost of software development is embodied in these myriad "nickel and dime" packets, and that much of the religious-war arguing about programming languages is actually about those costs.
(For the record, I think Rust has a bunch of nifty ideas. I think they're going down the right track.)