Assuming no major medical issues, no layoffs, no major accidents, etc. Your estimates may not work out.

They were really good in the 90's. At some start ups people were getting paid in stock options and landlords were taking stock options for rent. I joined a start up but I held out for cash, I was never that stupid.

FWIW, a republic CAN be a democracy. At least in principle, and if you aren't too picky about exact definitions. (I'm not asserting that the US states were ever more of a democracy than was classical Athens, however.)

It will if you're using C or C++.

FWIW, *most* of the text I'm working with is ASCII-7, but some of it isn't. Short quotation in, e.g., Greek. I need to be able to count the chars, etc. Utf-32 is an immense waste of space...and I already expect to be doing a lot of paging because of excessive memory use.

Would they be provided with uniforms, food, pay, and medical care at least while on duty? Hey, you may have solved the problem of poverty and income inequality as well. To pay for it we could define tax dodging as treason.

In addition the weapons industry did not have a rich and powerful lobbying group called the "NRA" working for them.

There is what I call "Cargo Cult" management. Some smart people observe things, collect metrics, and develop techniques which improve the way of doing business at least in some circumstances. There are some successes at least initially as early adopters see its value and being often above average use it in their situations. But then it becomes popularized by seminars, books, etc. and it becomes a buzzword. So people buy the books, got to the seminars, take the training etc.

But something happens. Maybe the intelligence level regresses to the mean or the people picking it up are too rigid to change or they are too cynical or lazy. But instead of really understanding the methodology they just buy the books, attend training and seminars, get the certifications etc. They know the buzzwords but they really do not know the meaning behind them. They do not "get it". It becomes a "Cargo Cult" exercise. So it starts to fail and people start to look for the next magic bullet.

It happened with TQM, Six Sigma, CMM, XP Agile, pair programming, and probably a host of others I probably do not know of.

C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8. And the absurd part of it is that they could easily do a good job. Utf8 is just a byte array with various routines to interpret the code. Glibc does a reasonable job for a C library...not ideal, but reasonable.

All the array needs is a way to address a chunk by character # rather than by byte #, a way to copy of a character or a slice of chars, and a way to determine the general character classification of any character. Also a few methods: first(), last(), hasnext(), hasprior(), next() and prior(). And these all "sort of" exist, except getting the general character classification. (Do note that these functions need to operate on utf-8 characters rather than on bytes.) But several different ways of doing this are already known. Vala, e.g., handles it without difficulty, and is able to emit C code (using Glibc libraries).

So it's not a programming difficulty that's holding things up. It's the standards bodies...or, perhaps, some members of them.

But I've looked at C++11, and it is not a satisfactory answer. Vala has a good answer. D (Digital Mars D) has a different good answer. Even Python3 has a pretty good answer. (I don't like that in Python you can't determine memory allocation within the string.) Also Racket, etc. But C++ doesn't.

It's hardly a solved problem. There are approaches that can be made to work, but that's not the same thing. The current approaches are all clumsy, and often that's a charitable description. It's usually doable. Saying anything beyond that is fulsom praise.

OTOH, because different languages have different basic derived structures, it's often not clear exactly what the best approach would be, even when one is considering things carefully. For one purpose the best I've been able to come up with is marshalling everything into a byte array, and then separating it back out. Doable, but hardly what I'd call "a solved problem". Probably an insoluble problem because the different languages map the same concept differently internally. So you need to deal with it on a special case by special case basis.

Perhaps you need to define what you mean by "more general purpose". I tend to consider C the most general purpose of languages, because it *isn't* specialized to some task. It's true that , e.g., FoxPro was better at interfacing to the FoxPro database, but that's NOT being general purpose, that's being special purpose.

OTOH (to get back on thread) I don't consider C a very secure language BECAUSE it is lacking in specializations. This means you need to keep creating, e.g., hash tables from scratch, and every time you do it you are likely to introduce an error.

Ada is in an in-between state. It's very secure against some types of errors. The facility for defining specific types is a particular instance. If one defines a meters type, then one cannot store an inches type into it...unless one uses a numeric literal, because one needs to allow instances to be created from numeric litrals. OTOH, this very security introduces verbosity, and verbosity is a common entry point for errors. (I used the meters/inches example because of the nortorious example of the space probe where that was misused. Ada did NOT save the day. And the reason that it didn't was because doing things properly would have been too verbose.)

In principle, every "Turing complete" language is as general purpose as every other. Practical considerations are the distinction between them. If you're doing database programming, then you are less likely to make mistakes if you use a language that contains extensions specialized to make database use easier. (I barely count embedded SQL, because while SQL is reasonably great for manipulaitng databases, it's lousy at interfacing to programming languages. Everything either needs to be converted into a string, or a blob, and blobs are clumsy to handle.) But note that these "databse extensions" are specializations away from "general purpose".

Without chemicals and modern equipment most industrial farmers at least would starve.

People speak of the wisdom of crowds but the madness of crowds create things such as financial crashes or stupid wars.
Shall we discuss and research this?

Hypothetical situation. I am an IT director. I track trillions in revenues and hundreds of billions in taxes. Do I 1)
switch to a new system with unknown security risks and associated costs in upgrading in house systems and applications?
or
2) Do I stick with a true and tried system for a few tens of millions more?

No brainer. Stick with the devil you know. This is not some happy little mobile app like the "Annoyed Nematode" you are dealing with the financial futures of both the US government and each and every person who must file taxes.

I think we need to take a serious look at the "many eyes" theory because of this. Apparently, there were no eyes on the part of parties that did not wish to exploit the bug for close to two years. And wasn't there just a professional audit by Red Hat that caught another bug, but not this one?

I have to say I'm even less confident in the plan to couple it to DNSSEC.