[generic_user]

You could make the case that the reason why we have C/C++ and its still in use is because of the tone deafness of academic language designers.

Language designers have been arguing (mostly with themselves) since the 1970's that pointers are dangerous and memory management is bad and that programmers should not have those things.

We can go on using C/C++ and language designers can go on creating there new version of Pascal. We all know how that turned out.

> I think we have argued enough about that putting this responsibility in the hands of very imperfect programmers is precisely the problem and we should do the best we can to stop it.

System designers and those writing performance critical code program hardware. Not an abstract machine that the language designer thinks is good enough for lowly programmers.

Convince Intel and AMD, Nvidia etc, that they should make chips and instruction sets that have no access to memory, cores, vectors and so forth because 'we should do the best we can to stop it'. Lets see how many of there clients want to buy useless blobs of silicone.

A computer is a tool for computation not an adult diaper designed to prevent leaks.

[DCKing]

We've gone from arguing "the security issues for C are overrated" to now arguing either "security issues don't have solutions I like" or "real programmers should be able to deal with these things" (I'm not sure which).

In addition, you're arguing a strawman. Nobody says that direct memory access should be taken away permanently. Many 'safe' languages allow you to directly access memory when you need it.

> A computer is a tool for computation not an adult diaper designed to prevent leaks.

This attitude is why we can't have nice things. It would be great if you cared more about the security and safety of the things you make than whether you look cool while making them.

[generic_user]

> We've gone from arguing "the security issues for C are overrated" to now arguing either "security issues don't have solutions I like" or "real programmers should be able to deal with these things" (I'm not sure which).

I don't think anyone was arguing any of those points. What was being explained is that C/C++ is designed to be flexible and simple and it was know from its inception that that flexibility lets the programmer 'shoot them selves in the foot'. Building out tooling to address any error patters in usage and keeping that basic simplicity and flexibility is desirable. More desirable then moving to a more complicated less flexible language that may eliminate some possible errors.

There are literally millions of C/C++ programmers and projects writing secure reliable code. Picking out a few open source projects and turning there bug reports into an internet drama is not going to convince anyone the sky is falling.

> In addition, you're arguing a strawman. Nobody says that direct memory access should be taken away permanently.

I think its fairly clear that the sentiment was.

"putting this responsibility in the hands of very imperfect programmers is precisely the problem and we should do the best we can to stop it."

This has been the justification for every misguided attempt to 'make things better' for a very long time.

A short list of unnecessary things that needed to be stopped thought the years. * Pointers * Manual memory management * Unconditional Jumps * direct access to machine words ie bytes * assembly instructions. etc..

I am fairly skeptical of arguments that suggest 'the programmer does not need that'.

[DCKing]

> There are literally millions of C/C++ programmers and projects writing secure reliable code.

I believe that there are millions of C/C++ programmers that think they are writing secure reliable code. But these there is an overwhelming amount of evidence that they don't and (for C at least) can't. There is plenty of evidence that at least C does not give you the proper tools to actually write safe code outside of trivial programs in the first place. (I cannot speak for C++)

You're still arguing a strawman. Nobody wants to take away your pointers, manual memory management, unconditional jumps or assembly, and nobody is suggesting that you don't need them. People just want to make it easier to use them responsibly without making the mistakes everybody keeps on making all the time.

[generic_user]

Those Millions of C/C++ programmers have certainly accomplished more and have happier lives then the Tens of armchair safety experts groking internet drama.

In my experience the people who wring there fist at C/C++ are generally people who at one point tried C/C++ and either got frustrated and quit or got told they suck or turned down at job interviews. Or they are people trying to sell you the new hotness and have some personal gain to accomplish. People I know who did some C/C++ and now work with other languages could care less about replacing C/C++. They just do there thing.

And honestly, academics and busybodies have been whining about safety and memory and hating on C/C++ for decades. We need to get rid of it. It smells, its bad for your teeth etc. Creating a never ending stream of total crap programming languages that no one wants to use. That never actually do what there creators propose that they do. And that never replace what the say they want to replace.

Even some crusty C++ programmers still hate on C coders and how did that work out for them :)

[klibertp]

> System designers and those writing performance critical code program hardware. Not an abstract machine that the language designer thinks is good enough for lowly programmers.

Oh, so you say they don't use C, right? It's defined in terms of abstract machine which has very little in common with how actual hardware works nowadays...