Yes, Rosemary Kennedy is a famous example of an abuse of lobotomy. Her case was particularly cruel, because the doctors did not stop cutting into her brain until she was unable to speak coherently.
B: "It has a CPU that Linux supports."
S: "It is not design to run Linux."
B: "It has a chipset that Linux supports. All of the hardware has Linux drivers."
S: "Yeah but it is not designed to run Linux!"
B: "What about it is not compatible with Linux?"
S: "Go fsck yourself."
Perspective? Lobotomy began with extremely careful scraping of the brain, meant to do the absolute minimum damage possible. Then some greedy quack in the USA took it to a ridiculous extreme, turning a nice young lady into a wheelchair-bound mess because her stuck-up family was worried about their social standing, and that soon degenerated into a procedure that should have been called a crime against humanity:
If your drug addiction is going to kill you in the next 6 months
There are no certainties about that sort of thing, but there is a certainty about the sort of brain-damaging lobotomy described in TFA: it is irreversible and destructive.
Obviously you have not met many security engineering researchers. I have news for you: DRM is a form of computer security. DRM is what computer security becomes when you want to prevent a computer's owner from using their computer in certain ways.
Who do you think is being hired to design DRM systems? What kind of person do you think would come up with an idea like this:
A signed bootloader with the kernel path and device drivers prevent the next aulurion worm/rootkit from taking shape as nothing untrusted can run from the kernel.
It also ensures that users cannot do this sort of thing:
See, the distinction here is subtle. If the user can modify their kernel, but only when their computer is a special "modify the bootloader" mode (or if the user can sign their own bootloader etc.), then the security argument makes sense. If the user cannot, then there is no security argument, because forbidding the user to modify their own system has nothing to do with security -- unless by "security" you mean "DRM."
If this could be used for gnu/Linux the situation would be great for security.
...and that is a case in point. If this could be used for GNU/Linux it would be great for security; it cannot be, because this is not about the security of the user, but rather the security of privileged "media partners" and other companies. The security that "Secure Boot" is meant to provide is security against secret keys being copied out of RAM by some teenager using a debugger, or cheating in MMOs by people who modified their kernels to defeat anti-cheating technologies, or people who might try to use their computers in ways they were supposed to pay extra to do, and so forth. The adversary in the "Secure Boot" security model is the user of the computer, and that is the problem.
Let me guess -- in a "real" police state, the police are soldiers, mass numbers of people are imprisoned without a fair trial, communications systems are built with government surveillance in mind, prisoners are a source of cheap labor, and the government uses propaganda to remind everyone that this is how life should be?
Most people do not care. They just want to get their entertainment -- sports, celebrity gossip, "news," gossip about their friends and family, etc. If they are required to use their real names, they will do so. If their communications is being monitored, they will not care, because they only really cared about getting their entertainment in the first place. People only care about censorship when it directly affects them; tell people that Japanese comic books are censored in the United States, by law, and they will say, "So what? I do not read those anyway, those are disgusting and stupid and I bet there is something wrong with that guy who was arrested for possessing them." Americans think nothing of the fact that their police carry military weapons or that we arrest and imprison more people each year than China (nor do they stop to think about the fact that most "convicted felons" were never actually convicted by a jury, or that we do not have enough courts in this country to give that many people a jury trial).
It is getting harder and harder over time to launch novel software stacks
I suspect that will change when electronic healthcare systems start being rolled out. There will be a demand for new systems, for systems that are not designed by committee, and a new set of languages and frameworks will be used to pad resumes.
What is needed are big problems; that is where novel frameworks can come in and give people exciting solutions. Healthcare systems are a big problem; there is a lot of room for novel frameworks. You still see time- and money-wasting redundancy in healthcare; for example, doctors typing out information and printing a prescription, only for patients to have a pharmacist read the prescription and type all that information again. Over the next decade, a tremendous amount of software will be written to address these problems, on the scale of the amount of software that was written to address Internet and web problems.
We will also see an increasing focus on reliability, both from healthcare and from business, which will leave plenty of room for new frameworks. It is still difficult to use formal methods, even with the availability of tools like PVS and Coq. Eventually, someone is going to have a great idea that will make formal methods easier to use, or will expand the use-cases for formal methods, and you'll see people padding their resumes with the name of that system. I suspect that as the cost of bugs becomes larger, the need for such systems will grow, until finally there are so many people trying to solve the problem that a solution will become inevitable.
Shake things up a bit, and novel frameworks will arrive. We still have lots of software problems, and software needs keep changing.
You are the one issuing the smartcards. When someone needs access to the server, you either give them a smartcard and add the card's public key to the authorized_keys file. In theory, the smartcard cannot export its secret keys, so you know that only a person who possesses the card and correctly entered the pin could be using that key to log in (in practice, smartcards can sometimes back up keys; I would assume that if you need to control client keys, you would not be issuing such cards).
If this is for desktop use, it asks ssh-agent. If it cannot do that, oh well, the backup did not happen and hopefully I see an error message in the morning.
If this is for something more general, it is a service that is confined in any number of ways (SELinux would be my preference).
...and on the remote end, whatever the backup script logs in as is confined -- no permissions to do anything other than write a backup.
As it stands, there's no way for the server to reject a key that has no pass phrase, a poor passphrase, or an old pass phrase
There is, however, a way for the server to accept only particular client keys -- say, keys that are known to have been generated on a smart card. SSH can be configured to look for authorized keys somewhere that users cannot write to (a basic centralized keystore), and there is some amount of support for a PKI. You cannot force users to have good passphrases, but you can force them to use smartcards (which is probably better than a passphrase anyway).
I see brute force attacks on passwords all the time; you do not see that with keys. Yes, if you are dealing with an adversary who is organized, well-funded, and specifically attacking you, you should be taking extra precautions with keys (and with many other things), but for most SSH use-cases the adversary is just trying to find the least secure system anywhere on the net, and does not care who owns it.
So rather than scare people about poor key management, let's scare people about bad passwords -- which is nearly all passwords.
On the other hand, it's the only mainstream language I know that supports both very low-level and very high-level programming style.
It is not the only one that supports this; it is, however, the only one that manages to botch it so badly. Lisp programmers have been doing this for decades; likewise, ML and Ada support this.
The problem with C++ is that the low-level constructs are hard to escape -- you have to work very hard to ensure you don't wind up using a primitive pointer, a fixed-width integer, a floating point number, etc. C++ programmers must do extra work to remain at a high level -- extra work to ensure that "42" becomes an arbitrary-width integer, extra work to ensure that string literals become string objects and not pointers, extra work to ensure that a rational number type is used rather than floating point numbers.
On the other hand, in Lisp, you need to do extra work to get low-level things. You need to explicitly tell your compiler that you want "42" to be a fixed-width integer (usually, Lisp programmers do this for optimization purposes); it is very hard to deal with primitive pointer types, which are not even standardized (there is no way to make such things portable or safe). Even when you get something low-level, you need to work hard to ensure that it stays low-level; something as simple as incrementing a fixed-width integer requires you to explicitly say that the result should be fixed-width (otherwise, you get an arbitrary-width integer, because the language won't set up a situation where an overflow might occur unless you explicitly ask for that).
C++ can easily do multiple dispatch, by using templates.
As we all know, that is "easy," especially compared to languages that have multiple dispatch built in.
No mainstream programming language has a depentent type system yet.
Non-mainstream programming languages have dependent types. What's stopping C++? That could be something that really helps C++ shine -- you know, something that actually sets it apart in a positive way from other languages.
Continuations are difficult
I know, and that is the typical excuse. That is why it took over a decade to fix the template/right shift problem, and that is why C++ falls behind high level languages: the standard avoids things that are "hard."
Handling correctable errors can (and should) be handled at library level, and c++ can perfectly do that. Exceptions are for exceptional situations.
Well, as an exercise, figure out how an I/O library should handle an attempt to write to a full disk. Should it open a GUI dialog? Should it just die?
Or, do you think this is an exceptional situation, and that the client code also needs to know how to retry or abort whatever operation failed? Luckily, we have languages that do not break encapsulation like this.
C++ does DSLs fine
OK, add operator@ to the language.
C++ does partial evaluation just fine, thanks to templates.
In other words, the programmer can implement this by hand, using templates, and get something that works sort-of like how it would work in a language that has it built in. Which is exactly what I was replying to: the objection that C forces you to do things that are built-in to C++.
C++ does currying just fine as well, thanks to templates and function objects.
See above.
C++ does pattern matching just fine, and now that it has lambdas it is easier and more natural than ever before.
C++ does not do pattern matching at all. You get a switch statement, which gives you some small amount of pattern matching on values, and some amount of pattern matching on function arguments. Otherwise, you are stuck trying to implement it yourself (see above) or finding another way.
Life is short.
Yes, life is short. That's why people who have hard computational problems are not using C++; they have more important things to do than deal with C++ and it's barely-usable feature set.
OCaml comes to mind; FFTW was written in OCaml. Lisp also comes to mind; CL-PPCRE outperformed libpcre (C, not C++, but how exactly would C++ help speed up regular expression parsing?). Both languages are safer than C++ (in many sense of the word "safe"), and both perform on par with C++ (unless the programmer is ignoring performance).
Really, your one-dimensional view of performance versus safety is simplistic and, well, one-dimensional.
There's nothing dangerous in throwing from constructors. Of course destructors are a different matter.
Unless the object is being constructed in the global scope, in which case there is nowhere for the catch block to be placed. Or if the object is being constructed as part of the destructor of another object, which would happen if you were using smart pointers and the destructor passed a smart pointer object to some function.
Remember, this is about C++ being a horrible language compared to C.
Fair enough, although for all of the complexity of C++ it does little to solve the problems we see with C (perhaps not more dangling pointers, but not substantially less either).
When you write C the "right way", you end up basically manually coding, what C++ gives you automatically.
In C++, you still have to do things by hand that other languages give you automatically (and in ways that need not be the case). For example:
Multiple dispatch
Dependent types (templates get you 1/100 of the way there)
Continuations
Handling correctable errors (there is no real mechanism for saying, "OK, I fixed the problem, now you can try the operation that caused the error")
Embedded languages (operator overloading gets you 1/100 of the way there on this one as well)
Partial evaluation
Currying
Pattern matching / unification
Invoking the compiler at run time
...and that is not even an exhaustive list. Some of these features are related to each other; for example, continuations make error recovery a non-problem. The lack of a powerful macro system and the enormously complex grammar make it hard to implement these features without modifying your C++ compiler, which is very much non-trivial (compare to Lisp, where new features can be added via the macro system; this is how object oriented programming was first added to Lisp).
The standards committee missed its chance to really make C++ competitive against modern languages with C++11. I suspect they will miss the mark again in C++14, and probably in C++17 as well. Eventually C++ is going to die, because programmers will be less concerned with things like compatibility with the error-prone and incomprehensible programming techniques of the 1970s and more concerned with solving bigger problems and writing reliable code (I seriously doubt that C++ will be a winner in healthcare systems; there is just too much working against C++ there, and too little in its favor).
If C++ were a car, the accelerator would be a pedal located under the passenger seat, a dial on the radio, and a lever in the trunk. Most users would just shift into neutral, which would be a 14 step process, and push their car around the block; they would then point to this as a major accomplish, and would note that once the car is in neutral it is powerful -- after all, you can always shift into drive if you really need to!
Yeah, and here are some applications that run in demanding environments, that were not written in C++, and that you would probably be hard-pressed to write in C++ (at least with the same results):
Hm, that's interesting -- demanding environments, high stakes, and no C++. This might be a clue; it is the experience of a team working in another demanding environment, that used some C++ code but mostly Lisp, who were not terribly impressed by what they saw with C++ (it seems like it was more of a chore for them):
These days, C++'s modern smart pointer classes make memory management a complete non-issue.
So, do you need shared_ptr, weak_ptr, or unique_ptr? I ask because (a) choosing the wrong one will create bugs in your code and (b) this is another example of something that is automatically determined in other languages.
This is just the power of C++ in action.
Yes, it certainly is: the power to create inflexible programs that act as magnets for bugs.
It is not hard to find examples of why C++ is bad. C++ is statically typed, but fails to deliver the sort of type system power that ML gives programmers. C++ is object oriented, but provides no metaobject protocol and forces programmers to resort to its clumsy templates system to do things that are not hard in languages with MOPs. C++ programmers are expected to figure out whether or not they should use a shared_ptr, weak_ptr, or unique_ptr, or if they should just give up on smart pointers and try to manage memory deallocation on their own (and, of course, there is no garbage collector, not even an optional one). The fact that "move semantics" and "r-value references" are considered to be highlights of C++11 speaks volumes about C++.
For me, the major issues in C++ are not even the lack of features, although most people start there; I point to the difficulty with writing reliable code in C++ as the most important problem. C++ exceptions are only useful in cases where there is no possible way to recover from an error. There are situations in C++ where exceptions are the only way to signal an error; thus there are situations in C++ where recoverable errors become unrecoverable for no reason other than deficiencies in the language. Worse still, the very situations where exceptions are the only way to signal an error also happen to be the situations where throwing an exception is dangerous: constructors and destructors. Beyond handling errors, there is the lengthy list of undefined behavior in C++, much of which could have been defined without any ill effects. The C++ standard even fails to rule out programs that could not possibly make any sense; for example, having a non-void function without any return statements (yes, most compilers will warn you about that -- but warnings are not part of the standard, and if most compilers can detect this there is really no excuse for the standard not explicitly forbidding it).
It is not hard to understand why "C++ is horrible" has become the go-to response to any comment about C++. It is a horrible language, and it is likely a culprit in the billions of dollars wasted on software bugs each year (buffer overflows, dangling pointers, etc.). It is a horrible language because it is inflexible, it lacks expressive power, and it makes things that are simple in other high-level languages needlessly difficult (how do you give the user a macro system that allows them to extend any feature of your program in C++? In some languages, that is as simple as giving the user access to a REPL, from which they can override or extend any behavior.). We are, unfortunately, stuck with this language, and will likely be stuck with it for a while (though I am hopeful that the need for reliable healthcare software will ultimately kill C++, MUMPS, and other awful languages).
What compatibility with C? C and C++ diverged long ago; there is now only a non-empty intersection of the two languages.
High-level languages often include an FFI, and that FFI is usually able to call compiled C functions. Lisp does it, Haskell does it, even Java supports this (and by extension, so do JVM languages like Scala).
How is continuing to support the language that allowed programmers to create many of the most infamous bugs in the history of computing a source of language power? When I think of language power, I think more of things like the ML type system, the Lisp macro system, embedded definite clause grammars, etc. -- things that enable programmers to write code in a single day that would take weeks of effort to get right in C++.
Slashdot Mirror
Yes, Rosemary Kennedy is a famous example of an abuse of lobotomy. Her case was particularly cruel, because the doctors did not stop cutting into her brain until she was unable to speak coherently.
B: "It has a CPU that Linux supports."
S: "It is not design to run Linux."
B: "It has a chipset that Linux supports. All of the hardware has Linux drivers."
S: "Yeah but it is not designed to run Linux!"
B: "What about it is not compatible with Linux?"
S: "Go fsck yourself."
https://en.wikipedia.org/wiki/Transorbital_lobotomy
If your drug addiction is going to kill you in the next 6 months
There are no certainties about that sort of thing, but there is a certainty about the sort of brain-damaging lobotomy described in TFA: it is irreversible and destructive.
At least in the long term addiction carries a higher incidental rate of death, lowered quality of life, and such than seizures.
Yes, let's lobotomize people who are addicted to drugs like this commonly used stimulant:
https://en.wikipedia.org/wiki/Coffee
it seems to only stop addictions 10% better than traditional methods
I wonder if "traditional methods" include this utterly worthless crap:
https://en.wikipedia.org/wiki/12_step_program
I also wonder how much better this lobotomy approach is than traditional methods other than 12 step programs...
WTF does DRM have to do with security?
Obviously you have not met many security engineering researchers. I have news for you: DRM is a form of computer security. DRM is what computer security becomes when you want to prevent a computer's owner from using their computer in certain ways.
Who do you think is being hired to design DRM systems? What kind of person do you think would come up with an idea like this:
https://torrentfreak.com/how-the-mpaa-knows-where-movies-are-pirated/
Let's put it this way: Vader was seduced by the dark side of the force
It is not about DRM at all
Not at all you say? Not at all about DRM...then what happened here:
https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/
A signed bootloader with the kernel path and device drivers prevent the next aulurion worm/rootkit from taking shape as nothing untrusted can run from the kernel.
It also ensures that users cannot do this sort of thing:
http://www.evilavatar.com/forums/showthread.php?t=7650
Or even something as simple as this:
https://en.wikipedia.org/wiki/Decss
See, the distinction here is subtle. If the user can modify their kernel, but only when their computer is a special "modify the bootloader" mode (or if the user can sign their own bootloader etc.), then the security argument makes sense. If the user cannot, then there is no security argument, because forbidding the user to modify their own system has nothing to do with security -- unless by "security" you mean "DRM."
If this could be used for gnu/Linux the situation would be great for security.
Let me guess -- in a "real" police state, the police are soldiers, mass numbers of people are imprisoned without a fair trial, communications systems are built with government surveillance in mind, prisoners are a source of cheap labor, and the government uses propaganda to remind everyone that this is how life should be?
https://en.wikipedia.org/wiki/CALEA
https://en.wikipedia.org/wiki/SWAT
https://www.nytimes.com/2012/03/11/opinion/sunday/go-to-trial-crash-the-justice-system.html?_r=0
https://en.wikipedia.org/wiki/Prison_labor#United_States
https://en.wikipedia.org/wiki/Barry_McCaffrey
Worse than China? No, not worse than China. Better? Well, at least we have not started harvesting organs from our millions of prisoners.
Is that what most people want?
Most people do not care. They just want to get their entertainment -- sports, celebrity gossip, "news," gossip about their friends and family, etc. If they are required to use their real names, they will do so. If their communications is being monitored, they will not care, because they only really cared about getting their entertainment in the first place. People only care about censorship when it directly affects them; tell people that Japanese comic books are censored in the United States, by law, and they will say, "So what? I do not read those anyway, those are disgusting and stupid and I bet there is something wrong with that guy who was arrested for possessing them." Americans think nothing of the fact that their police carry military weapons or that we arrest and imprison more people each year than China (nor do they stop to think about the fact that most "convicted felons" were never actually convicted by a jury, or that we do not have enough courts in this country to give that many people a jury trial).
It is getting harder and harder over time to launch novel software stacks
I suspect that will change when electronic healthcare systems start being rolled out. There will be a demand for new systems, for systems that are not designed by committee, and a new set of languages and frameworks will be used to pad resumes.
What is needed are big problems; that is where novel frameworks can come in and give people exciting solutions. Healthcare systems are a big problem; there is a lot of room for novel frameworks. You still see time- and money-wasting redundancy in healthcare; for example, doctors typing out information and printing a prescription, only for patients to have a pharmacist read the prescription and type all that information again. Over the next decade, a tremendous amount of software will be written to address these problems, on the scale of the amount of software that was written to address Internet and web problems.
We will also see an increasing focus on reliability, both from healthcare and from business, which will leave plenty of room for new frameworks. It is still difficult to use formal methods, even with the availability of tools like PVS and Coq. Eventually, someone is going to have a great idea that will make formal methods easier to use, or will expand the use-cases for formal methods, and you'll see people padding their resumes with the name of that system. I suspect that as the cost of bugs becomes larger, the need for such systems will grow, until finally there are so many people trying to solve the problem that a solution will become inevitable.
Shake things up a bit, and novel frameworks will arrive. We still have lots of software problems, and software needs keep changing.
You are the one issuing the smartcards. When someone needs access to the server, you either give them a smartcard and add the card's public key to the authorized_keys file. In theory, the smartcard cannot export its secret keys, so you know that only a person who possesses the card and correctly entered the pin could be using that key to log in (in practice, smartcards can sometimes back up keys; I would assume that if you need to control client keys, you would not be issuing such cards).
As it stands, there's no way for the server to reject a key that has no pass phrase, a poor passphrase, or an old pass phrase
There is, however, a way for the server to accept only particular client keys -- say, keys that are known to have been generated on a smart card. SSH can be configured to look for authorized keys somewhere that users cannot write to (a basic centralized keystore), and there is some amount of support for a PKI. You cannot force users to have good passphrases, but you can force them to use smartcards (which is probably better than a passphrase anyway).
I see brute force attacks on passwords all the time; you do not see that with keys. Yes, if you are dealing with an adversary who is organized, well-funded, and specifically attacking you, you should be taking extra precautions with keys (and with many other things), but for most SSH use-cases the adversary is just trying to find the least secure system anywhere on the net, and does not care who owns it.
So rather than scare people about poor key management, let's scare people about bad passwords -- which is nearly all passwords.
On the other hand, it's the only mainstream language I know that supports both very low-level and very high-level programming style.
It is not the only one that supports this; it is, however, the only one that manages to botch it so badly. Lisp programmers have been doing this for decades; likewise, ML and Ada support this.
The problem with C++ is that the low-level constructs are hard to escape -- you have to work very hard to ensure you don't wind up using a primitive pointer, a fixed-width integer, a floating point number, etc. C++ programmers must do extra work to remain at a high level -- extra work to ensure that "42" becomes an arbitrary-width integer, extra work to ensure that string literals become string objects and not pointers, extra work to ensure that a rational number type is used rather than floating point numbers.
On the other hand, in Lisp, you need to do extra work to get low-level things. You need to explicitly tell your compiler that you want "42" to be a fixed-width integer (usually, Lisp programmers do this for optimization purposes); it is very hard to deal with primitive pointer types, which are not even standardized (there is no way to make such things portable or safe). Even when you get something low-level, you need to work hard to ensure that it stays low-level; something as simple as incrementing a fixed-width integer requires you to explicitly say that the result should be fixed-width (otherwise, you get an arbitrary-width integer, because the language won't set up a situation where an overflow might occur unless you explicitly ask for that).
C++ can easily do multiple dispatch, by using templates.
As we all know, that is "easy," especially compared to languages that have multiple dispatch built in.
No mainstream programming language has a depentent type system yet.
Non-mainstream programming languages have dependent types. What's stopping C++? That could be something that really helps C++ shine -- you know, something that actually sets it apart in a positive way from other languages.
Continuations are difficult
I know, and that is the typical excuse. That is why it took over a decade to fix the template/right shift problem, and that is why C++ falls behind high level languages: the standard avoids things that are "hard."
Handling correctable errors can (and should) be handled at library level, and c++ can perfectly do that. Exceptions are for exceptional situations.
Well, as an exercise, figure out how an I/O library should handle an attempt to write to a full disk. Should it open a GUI dialog? Should it just die?
Or, do you think this is an exceptional situation, and that the client code also needs to know how to retry or abort whatever operation failed? Luckily, we have languages that do not break encapsulation like this.
C++ does DSLs fine
OK, add operator@ to the language.
C++ does partial evaluation just fine, thanks to templates.
In other words, the programmer can implement this by hand, using templates, and get something that works sort-of like how it would work in a language that has it built in. Which is exactly what I was replying to: the objection that C forces you to do things that are built-in to C++.
C++ does currying just fine as well, thanks to templates and function objects.
See above.
C++ does pattern matching just fine, and now that it has lambdas it is easier and more natural than ever before.
C++ does not do pattern matching at all. You get a switch statement, which gives you some small amount of pattern matching on values, and some amount of pattern matching on function arguments. Otherwise, you are stuck trying to implement it yourself (see above) or finding another way.
Life is short.
Yes, life is short. That's why people who have hard computational problems are not using C++; they have more important things to do than deal with C++ and it's barely-usable feature set.
OCaml comes to mind; FFTW was written in OCaml. Lisp also comes to mind; CL-PPCRE outperformed libpcre (C, not C++, but how exactly would C++ help speed up regular expression parsing?). Both languages are safer than C++ (in many sense of the word "safe"), and both perform on par with C++ (unless the programmer is ignoring performance).
Really, your one-dimensional view of performance versus safety is simplistic and, well, one-dimensional.
There's nothing dangerous in throwing from constructors. Of course destructors are a different matter.
Unless the object is being constructed in the global scope, in which case there is nowhere for the catch block to be placed. Or if the object is being constructed as part of the destructor of another object, which would happen if you were using smart pointers and the destructor passed a smart pointer object to some function.
Remember, this is about C++ being a horrible language compared to C.
Fair enough, although for all of the complexity of C++ it does little to solve the problems we see with C (perhaps not more dangling pointers, but not substantially less either).
When you write C the "right way", you end up basically manually coding, what C++ gives you automatically.
In C++, you still have to do things by hand that other languages give you automatically (and in ways that need not be the case). For example:
The standards committee missed its chance to really make C++ competitive against modern languages with C++11. I suspect they will miss the mark again in C++14, and probably in C++17 as well. Eventually C++ is going to die, because programmers will be less concerned with things like compatibility with the error-prone and incomprehensible programming techniques of the 1970s and more concerned with solving bigger problems and writing reliable code (I seriously doubt that C++ will be a winner in healthcare systems; there is just too much working against C++ there, and too little in its favor).
If C++ were a car, the accelerator would be a pedal located under the passenger seat, a dial on the radio, and a lever in the trunk. Most users would just shift into neutral, which would be a 14 step process, and push their car around the block; they would then point to this as a major accomplish, and would note that once the car is in neutral it is powerful -- after all, you can always shift into drive if you really need to!
Every programming language has bad parts; use the parts that aren't bad.
That would mean, as a first step, not using pointers. Which would rule out something as simple as hello world.
Yeah, and here are some applications that run in demanding environments, that were not written in C++, and that you would probably be hard-pressed to write in C++ (at least with the same results):
https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool
https://en.wikipedia.org/wiki/FFTW
http://www.haskell.org/haskellwiki/Haskell_in_industry
Hm, that's interesting -- demanding environments, high stakes, and no C++. This might be a clue; it is the experience of a team working in another demanding environment, that used some C++ code but mostly Lisp, who were not terribly impressed by what they saw with C++ (it seems like it was more of a chore for them):
http://www.paulgraham.com/carl.html
Of course, that was ten years ago. Times have changed; now C++ has r-value references and smart pointers!
These days, C++'s modern smart pointer classes make memory management a complete non-issue.
So, do you need shared_ptr, weak_ptr, or unique_ptr? I ask because (a) choosing the wrong one will create bugs in your code and (b) this is another example of something that is automatically determined in other languages.
This is just the power of C++ in action.
Yes, it certainly is: the power to create inflexible programs that act as magnets for bugs.
It is not hard to find examples of why C++ is bad. C++ is statically typed, but fails to deliver the sort of type system power that ML gives programmers. C++ is object oriented, but provides no metaobject protocol and forces programmers to resort to its clumsy templates system to do things that are not hard in languages with MOPs. C++ programmers are expected to figure out whether or not they should use a shared_ptr, weak_ptr, or unique_ptr, or if they should just give up on smart pointers and try to manage memory deallocation on their own (and, of course, there is no garbage collector, not even an optional one). The fact that "move semantics" and "r-value references" are considered to be highlights of C++11 speaks volumes about C++.
For me, the major issues in C++ are not even the lack of features, although most people start there; I point to the difficulty with writing reliable code in C++ as the most important problem. C++ exceptions are only useful in cases where there is no possible way to recover from an error. There are situations in C++ where exceptions are the only way to signal an error; thus there are situations in C++ where recoverable errors become unrecoverable for no reason other than deficiencies in the language. Worse still, the very situations where exceptions are the only way to signal an error also happen to be the situations where throwing an exception is dangerous: constructors and destructors. Beyond handling errors, there is the lengthy list of undefined behavior in C++, much of which could have been defined without any ill effects. The C++ standard even fails to rule out programs that could not possibly make any sense; for example, having a non-void function without any return statements (yes, most compilers will warn you about that -- but warnings are not part of the standard, and if most compilers can detect this there is really no excuse for the standard not explicitly forbidding it).
It is not hard to understand why "C++ is horrible" has become the go-to response to any comment about C++. It is a horrible language, and it is likely a culprit in the billions of dollars wasted on software bugs each year (buffer overflows, dangling pointers, etc.). It is a horrible language because it is inflexible, it lacks expressive power, and it makes things that are simple in other high-level languages needlessly difficult (how do you give the user a macro system that allows them to extend any feature of your program in C++? In some languages, that is as simple as giving the user access to a REPL, from which they can override or extend any behavior.). We are, unfortunately, stuck with this language, and will likely be stuck with it for a while (though I am hopeful that the need for reliable healthcare software will ultimately kill C++, MUMPS, and other awful languages).
Want more safety? Performance not an issue? There are better languages for those cases than C++,
There are also better languages if you want both safety and performance.