The spirit of schoolyard insults toward adults is as strong as ever.
I write software professionally since 1991, and at no point anyone complained about its design or implementation quality, except for those "colleagues" who could not write a usable program themselves. If you think, you are not among those, please show me your own accomplishments that do anything nontrivial, and explain what wonderful design you have made for those, and why did you choose those methods and not all other available alternatives.
It's more of a fact of not reimplementing the same thing twice. It has absolutely nothing to do with complexity.
In most situations but not all. Sometimes new implementation is simply better. Sometimes existing implementation drags in dependencies on shit that should be avoided. Sometimes the purpose of the code is better served by a different mechanism that you mistake for re-implementation.
If you can't find out when to use smart pointers you're a bigger moron than those you're criticizing.
Your opinion on when to use something does not necessarily reflect its effective use. Again, people that have only narrow, prescriptive, ideology-bound knowledge, may not understand that there are superior methods for reaching the same goals, or goals that can not be reached using methods they know.
If you have to fit your data to your code, you're doing it fucking wrong.
Again, you are attributing to me and "criticizing" the very position I am against. I have said that the data model and data flow are usually the primary part of design, and code is supposed to be built around it. You don't even read what I said, you are responding to your fantastic view of people whom you feel superior to.
Honestly if you think using smart pointers typically requires shoehorning shit,
Very often so. However it would be possible to discuss "smart pointers" if you mentioned WHICH kind and implementation of smart pointers you are talking about. As usual, ignorant people refer to something, believing that there is only one instance of it.
"Smart pointers" are a general technique of having an object that implements functionality of a pointer with some, usually consistency-enforcing rules applied to it. "Old" C++ standard library has auto_ptr that does very little when it comes to rules-enforcing -- it is useful if the code has to enforce "ownership" and is otherwise a one-trick pony with all kinds of unexpected, counterintuitive and undesired behavior. Whoever used it, is now screwed because auto_ptr now deprecated, and is replaced with slightly different unique_ptr. It was replaced because, against all intentions, it did not properly enforce what it was supposed to enforce consistently across all possible targets, so there is now plenty of buggy code or code that will become buggy after supposedly nonintrusive changes. If programmers did not rely on it, there would be less bugs. C++11 got unique_ptr and shared_ptr, taken from a hideously huge Boost library. Before, one would have to drag Boost into his program just to use those. Now, it provides a two-trick pony that is actually useful, but is a horrible building block for data reflecting any complex model.
Then, of course, there is a general technique of implementing "smart pointers" that actually allow to enforce rules taken from the data model, and not just general pseudo-garbage-collection mechanism limited to some set of objects. Smart programmers, foreseeing that they may end up handling complex rules, may create those specifically for their own classes, knowing that there will be time when those new, and not generic rules, will have to be enforced. Sometimes the solution does and sometimes it does not end up having a pointer-like interface, but the functionality of referring to objects and handling those references in an organized way is very common in all software. As you ignoramuses sneer at those implementations, software that uses them, ends up being more efficient and safer to develop.
And between those two, there are plenty of libraries (including the same Boost) with their "smart pointers" that have various properties. For an ignorant person they look like great, revolutionary, all-encompassing method of handling all data in the world. For a knowledgeable person they are implementations of methods that existed for as long as there was computing, and can be implemented within literally minutes, with whatever propertie
You probably wouldn't want to use software RAM drives for anything serious, if your RAM has no error correction. Most hardware RAM drives use ECC (or at least buffered) RAM.
I'm a bit surprised at the excited "sky is falling" quote at the end about the Constitution needing protecting, but I think if you dropped a bomb on the lot, there are enough copies of it that we could start over much better.
But here is the problem -- they would start fighting between each other, and recruit others into their armies.
There are plenty of situations when "they" (if you mean, pieces of STL) are an appropriate solution. I can assure you, and everyone, that programmers who studied C and wrote complex software with it, are perfectly capable of using those mechanisms where appropriate. But then you wouldn't notice the difference.
The difference happens when the task is not possible to reduce to those "situations that happen very often" without massive amount of ramming round pegs into square hole and vice versa. For experienced programmer, the ugliness and inefficiency of a program shoehorned into the wrong data model is far greater than inconvenience of developing software without cookie-cutter pieces already given to him. Implementing data models and structures is a no-brainer to him, and once done, it can be re-used in the same project, or generalized to be usable in other similar situations.
For an incompetent amateur, the thought of actually handling data is unbearable, so he would rather use wrong model that has nice and shiny implementation and compensate its wrong nature by more ugly, impractical, error-prone code. But worst of all, a militantly ignorant incompetent amateur would berate everyone else for not doing things the way he would,
You didn't discredit him at all because you're just a dumbfuck with a big ego. In fact, your attacks are quite pathetic, and you don't even understand a lot of what the other person is saying because of your self-righteousness.
Oh, I understand what he is saying very well. He is one of "programmers" who only got dumbed-down prescriptive knowledge in his "education". He does not realize that everyone who actually practices programming, got descriptive knowledge, and is capable of operating beyond the stupid rules he believes to be fundamental in computing, or fundamental parts of C++ language. He (you, actually -- obviously it's the same idiot, or one completely interchangeable with him) berates people for not shitting in a potty, and wandering out of his room, just because those are things he was told not to do.
Others are pointing and laughing.
Who exactly is "pointing and laughing", other than kindergarten kids?
You're just another C moron.
The only people I have heard complaining of this, are 1990's crash-course graduates who believed that they can make BIG MONEY by "studying computers" and ended up being fed an idiotic set of "how-to-fake-it" instructions that have nothing to do with either Computer Science or practical software development. There were hordes of them in 90's when anyone claiming to be able to program, would get a job, and they have spent 2000's picking up each and every fad. The arrival of widespread use of STL caught them at the time when they were abandoning VB, so this is what they sucked up as the fundamental -- the only fundamental -- part of their understanding of C++ and object-oriented programming in general. They were enamoured with each and every ideology that proclaimed itself to be "the right way" to write software -- not because those people could understand the reasons behind but because each such ideology is proclaimed in the same commanding form of rigid set of rules that they are indoctrinated to accept and obey.
Sure, they are still there. The amount of horrible, primitive code that does not do its work and leaks memory when it does not crash, is a proof that they are around. They all went, like sheep, into "managed code",.Net and C# when Microsoft promised it as a panacea, and they are now running back to C++ once same Microsoft made a 180 degree turn, and called Stroustrup to Redmond to announce it (oh wow, I have just checked, your qsort() example was a copypasta from his presentation there).
(I can do it until this article is locked -- I had to deal with you morons for half of my life, and my hatred for people like you is far beyond anything you can ever feel or be motivated to do. So if you are trying to create an impression that your opinion is popular by posting schoolyard insults in large numbers, you are going to lose).
The only things allowed are analog inputs, so you have to buy HDMI to analog converter, than digitize its output back. This is what I do (but my converter is limited to 1080i, so it's still painful).
Then you were writing code that was irrelevant in 1998. It was not highly performant, and nobody cared about the shit that you wrote.
You made claims that C programmers are accustomed to "optimizing" their code in some unusual ways. This is incorrect. The fact that compilers had poor optimization decades ago, has no effect on this because progress in compiler optimization is completely unrelated to anything a human would do when imitating a compiler.
No, I hate C because it has permanently crippled the entire world.
The only person who can make such an idiotic claim is one who does not know how computers work.
(C people do retarded shit like #define NULL 0, char c = NULL, etc)
"C people" don't do that because NULL is already defined as 0, and is specifically used for pointers, to make code more readable. Since you don't know how pointers work, you do not understand the purpose of this.
C's type unsafeness and horrible conversion rules damaged C++ very very badly.
WTF do you mean by "type unsafeness"?
Also, standard libraries __implementation__ have nothing to do with language. Learn to understand the difference.
Don't pretend to not understand what I said.
Standard libraries could just as well be completely thrown away without changing the nature of the language. In C and C++ they are BUILT using language's own mechanisms. They do not use anything else. In other languages libraries have to be written in a different language, but C and C++ are self-contained -- they not only have compilers written in themselves, their libraries are also written in themselves, except for low-level routines that do not have representation at the language level (system call, process startup/exit). If C++ was "better" in a way you crave so much, it would not have C++ standard library, or it would have to become a language of a different category -- a language that has its library written in another language. Even a mentally deficient person like yourself would recognize what does that mean.
No, I did not write that.
Yes, you did, you just didn't realize that what you see as inherent property of a language is merely a piece of code written in it -- not even by the same person who created the language, and following completely different set of ideas.
You, like a fool seem to think there are two different ways to write code. You think that systems level code (libraries, compilers, kernels, etc) *should* be seperate in terms of readability (#define #if #else shit everywhere, horrible preprocessor abuse, and the list goes on) with "normal" code that people write in their daily lives.
That's the very opposite of what I said -- you are refuting your own position and attributing it to me. Either that's some kind of double strawman, or you can't comprehend anything you read, and replace it in your head with something you want to read.
I am specifically saying it is possible to merge the two because of the language features of C++ **AND** advancements in compiler techniques. Without the latter using certain features of C++ cause performance decrease while trading it with productivity increase. Now for many of these cases, there is no such tradeoff.
It has nothing to do with advancement in compiler technologies. From the days of BSD UNIX in 70's (and probably earlier in Bell Labs), system libraries were written in clean, readable C, without any idiotic tricks. That "over-optimized" code you are attributing to "old" programmers does not exist. When someone had to optimize code implementation that compiler could not produce, he used assembly, and that kind of code is extinct for decades except for DSP and extemely unusual hardware. Compilers getting better merely contributed to increased performance, but from the very beginning it was kno
It's about supposed "optimization" that in the past was done by C programmers, and now should not be done because compilers are "smarter". The idiot I am arguing againt, does not know how algorithms may be possible to optimize, he thinks that at some point C was like assembly, and old programmers' minds are "tainted" by experience of doing some kind of crazy optimization. In his mind (or, more likely, in the minds of his ignorant "teachers"), the ideas of unusual hardware-dependent optimization techniques being common in the past among application developers, and of modern compiler being able to adapt compilation to produce hardware-optimized code, had a baby.
But that's exactly what they are NOT doing! Look at the output, it's completely natural-looking except for objects wobbling as if they are made of jelly.
No. Compilers were predominantly non-optimizing because computing resources were limited.
At no point in history of C or C++, it was worth to try to "optimize" anything that a modern compiler would optimize better. Even before such optimizarion was implemented. The problem is, you and "modern programmers" have absolutely no idea what optimization is and what it is not, so you believe that someone had to specifically trick compiler into making something "faster". In reality, the problem with most software never was "insufficient optimization" or " excessive attempts of optimization" but idiotic choice of an algorithm. If there is a O(1) algorithm, someone who chosen O(N^2) algorithm is guilty of not "insufficient optimization" but of being a fucking idiot who does not understand the nature of the problem.
Yes, first two is a mistake by Stroustroup, but I suppose it was to get good traction among existing C programmers. But it backfired because C programmers polluted C++ usenet groups filling it with "void *" crap code that other newbies then saw and learnt and then never understood how to actually write in C++. If you ever find yourself writing regular application code and manually allocating resources or using raw-pointers in C++ it is a huge red flag that something is wrong (or about to go wrong very very soon)
If Stroustrup could implement C++ without C features, he would. The truth is, ALL THOSE FEATURES YOU LOVE SO MUCH IN C++ ARE IMPLEMENTED THROUGH C MECHANISMS THAT YOU HATE. They can not be disabled because they are not merely the low-level mechanism C++ is implemented upon, they are integral part of the C++ language and its design. Look into the standard library sources, and you will find code that is worse than anything you ever dared to criticize. That is, if you understand what you are looking at in the first place.
All you said is "some great lords and masters of the language used features of the language to implement a nice and cozy subset you are allowed to use. However no one but them is allowed to use those features because they are magical people who can deal with data structures and everyone else is a fucking moron who can't be trusted to deal with that". You can not imagine that someone may dare to implement a completely new container from scratch, and it will be more suited to the given application than something you have duct taped together out of some cookie-cutter pieces you have found in the standard library. The programmers you are criticizing, are using the same mechanism library uses, for the same purpose. That's not because they are unaware of "almost the same" being in the library, that's because they know about data structures more than people who wrote the library.
The famous example is glibc's qsort. If you look at the code its quite performant - BUT its messy, unreadable and unmaintanable. Intermediate or newbie programmers look at it and think this is the only way to write code if you want to write high quality performant code. Well C++ shows you a better way. std::sort outperforms it thoroughly while still managing to give you a algorithm that works on generic containers.
qsort() implementation is very simple, and it uses exactly the same abstractions, C++ is based upon. If you find it any less elegant than C++ counterpart, your understanding of the language is so primitive, you are not qualified to use either C or C++.
Yeah.. and LISP has manual resource management too.
Actually yes, it does, though not explicitly. C++, on the other hand, does not have a universal garbage collector that always applies to all objects, like LISP has, and comparison between those two mechanisms, C++ scope/lifetime and LISP garbage collection, reveals your ignorance of fundamental concepts in data handling, ones that are more fundamental than languages themselves.
Rubbish. A good programmer does not "discover" the data
How fucking dumb do you have to be to not realize he's probably comparing "manual" as in operator new, delete, malloc, free, etc. to "automatic" as in shared_ptr, stack allocation, etc. where less intervention is required by the programmer?
No, I understand it perfectly.
The problem is, in most, no, overwhelming majority of situations, those "automatic" methods are completely inappropriate.
Filter that precedes the decision is not AI -- it applies to the whole image iniformly, and contains no conditionals (and for this reason can be SIMD'ed so easily). Once you start establishing cutoffs, start smoothing and centering, detecting contiguous edges and areas, it's AI.
"Holodomor" articles in multiple languages directly contradict each other (and one in English contains nothing but US propaganda and baseless accusations of Robert Conquest).
As a rule, Wikipedia articles about all historical events in 20th or 21st century are heavily colored by propaganda, and likely to be wrong in all but most basic aspects (time, location, few associated political figures, reaction of the media in the country where prevailing editor happened to be located, etc.)
Once this will be found out, using "portable applications" (running un-approved executables on company hardware) will be considered "installation", and you will be fired.
Slashdot Mirror
This has nothing to do with the language. It's bad enough that Unix C library is included in there.
How about not?
And this has nothing to do with updating Ubuntu or any breakage that would (not) happen in the process. If system installs, it updates.
It doesn't.
Well, Power Mac is not a server-class hardware.
The spirit of schoolyard insults toward adults is as strong as ever.
I write software professionally since 1991, and at no point anyone complained about its design or implementation quality, except for those "colleagues" who could not write a usable program themselves. If you think, you are not among those, please show me your own accomplishments that do anything nontrivial, and explain what wonderful design you have made for those, and why did you choose those methods and not all other available alternatives.
It's more of a fact of not reimplementing the same thing twice. It has absolutely nothing to do with complexity.
In most situations but not all. Sometimes new implementation is simply better. Sometimes existing implementation drags in dependencies on shit that should be avoided. Sometimes the purpose of the code is better served by a different mechanism that you mistake for re-implementation.
If you can't find out when to use smart pointers you're a bigger moron than those you're criticizing.
Your opinion on when to use something does not necessarily reflect its effective use. Again, people that have only narrow, prescriptive, ideology-bound knowledge, may not understand that there are superior methods for reaching the same goals, or goals that can not be reached using methods they know.
If you have to fit your data to your code, you're doing it fucking wrong.
Again, you are attributing to me and "criticizing" the very position I am against. I have said that the data model and data flow are usually the primary part of design, and code is supposed to be built around it. You don't even read what I said, you are responding to your fantastic view of people whom you feel superior to.
Honestly if you think using smart pointers typically requires shoehorning shit,
Very often so. However it would be possible to discuss "smart pointers" if you mentioned WHICH kind and implementation of smart pointers you are talking about. As usual, ignorant people refer to something, believing that there is only one instance of it.
"Smart pointers" are a general technique of having an object that implements functionality of a pointer with some, usually consistency-enforcing rules applied to it. "Old" C++ standard library has auto_ptr that does very little when it comes to rules-enforcing -- it is useful if the code has to enforce "ownership" and is otherwise a one-trick pony with all kinds of unexpected, counterintuitive and undesired behavior. Whoever used it, is now screwed because auto_ptr now deprecated, and is replaced with slightly different unique_ptr. It was replaced because, against all intentions, it did not properly enforce what it was supposed to enforce consistently across all possible targets, so there is now plenty of buggy code or code that will become buggy after supposedly nonintrusive changes. If programmers did not rely on it, there would be less bugs. C++11 got unique_ptr and shared_ptr, taken from a hideously huge Boost library. Before, one would have to drag Boost into his program just to use those. Now, it provides a two-trick pony that is actually useful, but is a horrible building block for data reflecting any complex model.
Then, of course, there is a general technique of implementing "smart pointers" that actually allow to enforce rules taken from the data model, and not just general pseudo-garbage-collection mechanism limited to some set of objects. Smart programmers, foreseeing that they may end up handling complex rules, may create those specifically for their own classes, knowing that there will be time when those new, and not generic rules, will have to be enforced. Sometimes the solution does and sometimes it does not end up having a pointer-like interface, but the functionality of referring to objects and handling those references in an organized way is very common in all software. As you ignoramuses sneer at those implementations, software that uses them, ends up being more efficient and safer to develop.
And between those two, there are plenty of libraries (including the same Boost) with their "smart pointers" that have various properties. For an ignorant person they look like great, revolutionary, all-encompassing method of handling all data in the world. For a knowledgeable person they are implementations of methods that existed for as long as there was computing, and can be implemented within literally minutes, with whatever propertie
You probably wouldn't want to use software RAM drives for anything serious, if your RAM has no error correction. Most hardware RAM drives use ECC (or at least buffered) RAM.
All server-class hardware always uses ECC RAM.
Didn't you get the memo? There are no large databases anymore, all database servers are supposed to have more RAM than the size of their database.
*** BARF!!! ***
I'm a bit surprised at the excited "sky is falling" quote at the end about the Constitution needing protecting, but I think if you dropped a bomb on the lot, there are enough copies of it that we could start over much better.
But here is the problem -- they would start fighting between each other, and recruit others into their armies.
And this is wrong for all those applications because it prevents the human viewer from noticing anything else.
There are plenty of situations when "they" (if you mean, pieces of STL) are an appropriate solution. I can assure you, and everyone, that programmers who studied C and wrote complex software with it, are perfectly capable of using those mechanisms where appropriate. But then you wouldn't notice the difference.
The difference happens when the task is not possible to reduce to those "situations that happen very often" without massive amount of ramming round pegs into square hole and vice versa. For experienced programmer, the ugliness and inefficiency of a program shoehorned into the wrong data model is far greater than inconvenience of developing software without cookie-cutter pieces already given to him. Implementing data models and structures is a no-brainer to him, and once done, it can be re-used in the same project, or generalized to be usable in other similar situations.
For an incompetent amateur, the thought of actually handling data is unbearable, so he would rather use wrong model that has nice and shiny implementation and compensate its wrong nature by more ugly, impractical, error-prone code. But worst of all, a militantly ignorant incompetent amateur would berate everyone else for not doing things the way he would,
You didn't discredit him at all because you're just a dumbfuck with a big ego. In fact, your attacks are quite pathetic, and you don't even understand a lot of what the other person is saying because of your self-righteousness.
Oh, I understand what he is saying very well. He is one of "programmers" who only got dumbed-down prescriptive knowledge in his "education". He does not realize that everyone who actually practices programming, got descriptive knowledge, and is capable of operating beyond the stupid rules he believes to be fundamental in computing, or fundamental parts of C++ language.
He (you, actually -- obviously it's the same idiot, or one completely interchangeable with him) berates people for not shitting in a potty, and wandering out of his room, just because those are things he was told not to do.
Others are pointing and laughing.
Who exactly is "pointing and laughing", other than kindergarten kids?
You're just another C moron.
The only people I have heard complaining of this, are 1990's crash-course graduates who believed that they can make BIG MONEY by "studying computers" and ended up being fed an idiotic set of "how-to-fake-it" instructions that have nothing to do with either Computer Science or practical software development. There were hordes of them in 90's when anyone claiming to be able to program, would get a job, and they have spent 2000's picking up each and every fad. The arrival of widespread use of STL caught them at the time when they were abandoning VB, so this is what they sucked up as the fundamental -- the only fundamental -- part of their understanding of C++ and object-oriented programming in general. They were enamoured with each and every ideology that proclaimed itself to be "the right way" to write software -- not because those people could understand the reasons behind but because each such ideology is proclaimed in the same commanding form of rigid set of rules that they are indoctrinated to accept and obey.
Sure, they are still there. The amount of horrible, primitive code that does not do its work and leaks memory when it does not crash, is a proof that they are around. They all went, like sheep, into "managed code", .Net and C# when Microsoft promised it as a panacea, and they are now running back to C++ once same Microsoft made a 180 degree turn, and called Stroustrup to Redmond to announce it (oh wow, I have just checked, your qsort() example was a copypasta from his presentation there).
(I can do it until this article is locked -- I had to deal with you morons for half of my life, and my hatred for people like you is far beyond anything you can ever feel or be motivated to do. So if you are trying to create an impression that your opinion is popular by posting schoolyard insults in large numbers, you are going to lose).
history needs 50 years to be rewritten by the winners :)
No, it needs 50 years for anyone other than winners to get noticed again. Then 50 more years for propaganda workers to move to greener pastures.
But those books do not present themselves as the result of worldwide consensus. Wikipedia does.
Verboten, too.
The only things allowed are analog inputs, so you have to buy HDMI to analog converter, than digitize its output back. This is what I do (but my converter is limited to 1080i, so it's still painful).
Then you were writing code that was irrelevant in 1998. It was not highly performant, and nobody cared about the shit that you wrote.
You made claims that C programmers are accustomed to "optimizing" their code in some unusual ways. This is incorrect. The fact that compilers had poor optimization decades ago, has no effect on this because progress in compiler optimization is completely unrelated to anything a human would do when imitating a compiler.
No, I hate C because it has permanently crippled the entire world.
The only person who can make such an idiotic claim is one who does not know how computers work.
(C people do retarded shit like #define NULL 0, char c = NULL, etc)
"C people" don't do that because NULL is already defined as 0, and is specifically used for pointers, to make code more readable. Since you don't know how pointers work, you do not understand the purpose of this.
C's type unsafeness and horrible conversion rules damaged C++ very very badly.
WTF do you mean by "type unsafeness"?
Also, standard libraries __implementation__ have nothing to do with language. Learn to understand the difference.
Don't pretend to not understand what I said.
Standard libraries could just as well be completely thrown away without changing the nature of the language. In C and C++ they are BUILT using language's own mechanisms. They do not use anything else. In other languages libraries have to be written in a different language, but C and C++ are self-contained -- they not only have compilers written in themselves, their libraries are also written in themselves, except for low-level routines that do not have representation at the language level (system call, process startup/exit). If C++ was "better" in a way you crave so much, it would not have C++ standard library, or it would have to become a language of a different category -- a language that has its library written in another language. Even a mentally deficient person like yourself would recognize what does that mean.
No, I did not write that.
Yes, you did, you just didn't realize that what you see as inherent property of a language is merely a piece of code written in it -- not even by the same person who created the language, and following completely different set of ideas.
You, like a fool seem to think there are two different ways to write code. You think that systems level code (libraries, compilers, kernels, etc) *should* be seperate in terms of readability (#define #if #else shit everywhere, horrible preprocessor abuse, and the list goes on) with "normal" code that people write in their daily lives.
That's the very opposite of what I said -- you are refuting your own position and attributing it to me. Either that's some kind of double strawman, or you can't comprehend anything you read, and replace it in your head with something you want to read.
I am specifically saying it is possible to merge the two because of the language features of C++ **AND** advancements in compiler techniques. Without the latter using certain features of C++ cause performance decrease while trading it with productivity increase. Now for many of these cases, there is no such tradeoff.
It has nothing to do with advancement in compiler technologies. From the days of BSD UNIX in 70's (and probably earlier in Bell Labs), system libraries were written in clean, readable C, without any idiotic tricks. That "over-optimized" code you are attributing to "old" programmers does not exist. When someone had to optimize code implementation that compiler could not produce, he used assembly, and that kind of code is extinct for decades except for DSP and extemely unusual hardware. Compilers getting better merely contributed to increased performance, but from the very beginning it was kno
Have you noticed what the argument is about?
It's about supposed "optimization" that in the past was done by C programmers, and now should not be done because compilers are "smarter". The idiot I am arguing againt, does not know how algorithms may be possible to optimize, he thinks that at some point C was like assembly, and old programmers' minds are "tainted" by experience of doing some kind of crazy optimization. In his mind (or, more likely, in the minds of his ignorant "teachers"), the ideas of unusual hardware-dependent optimization techniques being common in the past among application developers, and of modern compiler being able to adapt compilation to produce hardware-optimized code, had a baby.
Either you are lying, or Ubuntu installation at your work is managed by saboteurs.
But that's exactly what they are NOT doing! Look at the output, it's completely natural-looking except for objects wobbling as if they are made of jelly.
No. Compilers were predominantly non-optimizing because computing resources were limited.
At no point in history of C or C++, it was worth to try to "optimize" anything that a modern compiler would optimize better. Even before such optimizarion was implemented. The problem is, you and "modern programmers" have absolutely no idea what optimization is and what it is not, so you believe that someone had to specifically trick compiler into making something "faster". In reality, the problem with most software never was "insufficient optimization" or " excessive attempts of optimization" but idiotic choice of an algorithm. If there is a O(1) algorithm, someone who chosen O(N^2) algorithm is guilty of not "insufficient optimization" but of being a fucking idiot who does not understand the nature of the problem.
Yes, first two is a mistake by Stroustroup, but I suppose it was to get good traction among existing C programmers. But it backfired because C programmers polluted C++ usenet groups filling it with "void *" crap code that other newbies then saw and learnt and then never understood how to actually write in C++. If you ever find yourself writing regular application code and manually allocating resources or using raw-pointers in C++ it is a huge red flag that something is wrong (or about to go wrong very very soon)
If Stroustrup could implement C++ without C features, he would. The truth is, ALL THOSE FEATURES YOU LOVE SO MUCH IN C++ ARE IMPLEMENTED THROUGH C MECHANISMS THAT YOU HATE. They can not be disabled because they are not merely the low-level mechanism C++ is implemented upon, they are integral part of the C++ language and its design. Look into the standard library sources, and you will find code that is worse than anything you ever dared to criticize. That is, if you understand what you are looking at in the first place.
All you said is "some great lords and masters of the language used features of the language to implement a nice and cozy subset you are allowed to use. However no one but them is allowed to use those features because they are magical people who can deal with data structures and everyone else is a fucking moron who can't be trusted to deal with that". You can not imagine that someone may dare to implement a completely new container from scratch, and it will be more suited to the given application than something you have duct taped together out of some cookie-cutter pieces you have found in the standard library. The programmers you are criticizing, are using the same mechanism library uses, for the same purpose. That's not because they are unaware of "almost the same" being in the library, that's because they know about data structures more than people who wrote the library.
The famous example is glibc's qsort. If you look at the code its quite performant - BUT its messy, unreadable and unmaintanable. Intermediate or newbie programmers look at it and think this is the only way to write code if you want to write high quality performant code. Well C++ shows you a better way. std::sort outperforms it thoroughly while still managing to give you a algorithm that works on generic containers.
qsort() implementation is very simple, and it uses exactly the same abstractions, C++ is based upon. If you find it any less elegant than C++ counterpart, your understanding of the language is so primitive, you are not qualified to use either C or C++.
Yeah.. and LISP has manual resource management too.
Actually yes, it does, though not explicitly. C++, on the other hand, does not have a universal garbage collector that always applies to all objects, like LISP has, and comparison between those two mechanisms, C++ scope/lifetime and LISP garbage collection, reveals your ignorance of fundamental concepts in data handling, ones that are more fundamental than languages themselves.
Rubbish. A good programmer does not "discover" the data
How fucking dumb do you have to be to not realize he's probably comparing "manual" as in operator new, delete, malloc, free, etc. to "automatic" as in shared_ptr, stack allocation, etc. where less intervention is required by the programmer?
No, I understand it perfectly.
The problem is, in most, no, overwhelming majority of situations, those "automatic" methods are completely inappropriate.
Filter that precedes the decision is not AI -- it applies to the whole image iniformly, and contains no conditionals (and for this reason can be SIMD'ed so easily). Once you start establishing cutoffs, start smoothing and centering, detecting contiguous edges and areas, it's AI.
"Holodomor" articles in multiple languages directly contradict each other (and one in English contains nothing but US propaganda and baseless accusations of Robert Conquest).
As a rule, Wikipedia articles about all historical events in 20th or 21st century are heavily colored by propaganda, and likely to be wrong in all but most basic aspects (time, location, few associated political figures, reaction of the media in the country where prevailing editor happened to be located, etc.)
Once this will be found out, using "portable applications" (running un-approved executables on company hardware) will be considered "installation", and you will be fired.