I read the article/rant, and he's bitching about the complexity and time required to learn and use modern frameworks and tools, not so much about planning and management. The summary is a bit misleading.
I think part of the problem is that "programming" is itself so diverse. If you were to be a graphics programmer, you would certainly need your linear algebra, geometry, etc. If you worked with scientific computing, you'd need even more math (e.g. differential equations, statistics, etc). If you worked as a DSP programmer, you'd need to know calculus (and then some). In contrast, web development doesn't really require any of these. However, they all involve "programming", and the people writing the software can all be called "programmers", even if one's writing a website (no math) and another is doing a fluid dynamics simulation (lots of math).
I was in Paris just last week. There were no "locked down" monuments, and there were no armed personnel patrolling the streets. There were some military-types at the Arc De Triomphe, but that's because of Bastille Day celebration preparations -- that is, they were there for a celebration, not for a patrolling. You're spouting nonsense.
Their OpenCL drivers are pretty bad. Completely arbitrary changes can have huge impacts on things like VGPR usage. Optimizing an OpenCL kernel on an AMD card is like black magic. Not that I'm praising NVIDIA here, they're still on OpenCL 1.1...
Or... if you're using C++, use a Standard Library container? They all keep track of their sizes, and can perform runtime bounds checks (by using say, at() rather than the bracket operator). Or Write your own class with an array member and an accessor that does bounds checking. It's not difficult to do. At all. And templates aren't meant for addressing buffer overflow problems, or as a replacement for raw pointer (use STL containers). Or garbage collection (use RAII). I get the feeling you aren't too familiar with C++?
Take a look at "The art and science of programming" by Donald Knuth, it's examples are in Pascal but if you inhale the wisdom in the book you will understand when I say that the language it uses is irrelevant.
Just in case this confuses the submitter, the actual title is "The Art of Computer Programming". And IIRC the code examples aren't in Pascal, but rather in "MIX" assembly, which is a hypothetical language for a hypothetical machine. Also, be forewarned that it has a steep learning curve...
Not sure if I'm missing the joke here (if so, apologies), but just because the book title is "Exceptional C++" doesn't mean the whole thing is about exceptions.
Exceptions are covered for a few chapters in that book, but some of the recommendations aren't really relevant anymore; C++11 deprecated many of the problematic parts of exceptions (e.g. exception specifications), and much like valarrays, no one really used them anyways
My normal rules of thumb are:
- No operator overloading, especially type casts.
- Templates are mostly used for container classes, or in rare cases algorithms.
- Spare use of method/function overloading.
- Try to use template parameters that are themselves of as simple of a type as is practical.
Some operators shouldn't be overloaded (e.g. &, && and ||), but good luck writing any non-trivial container classes without overloading the assignment operator. You may think you're not overloading these, but the compiler is simply auto-generating them for you since you didn't provide one (namely, copy-assignment operator and move-assignment operators). As with any language feature it can be abused, but they can be quite useful when used judiciously. (i.e. if you're writing a Matrix library, you'll probably want to overload the arithmetic operators).
It's true that there are pitfalls to using templates, but I think you're grossly overstating their dangers (while ignoring all their benefits). You can do some pretty amazing things with templates; in the least they reduce code duplication, and at best they allow compile-time polymorphism, better error detection, and a whole different paradigm for using C++ (metaprogramming can pretty closely resemble functional programming).
In a word, C++ has the best binding support for GPGPU.
Both CUDA and OpenCL started off as C-based API -- CUDA has since moved to C++, and is moving towards more modern, idiomatic C++, both for its host-side API and device-side code (e.g. has support for kernel templates). OpenCL is a bit behind in this respect, although it also has both C and C++ bindings. You can also use fortran, but the majority of use-cases for GPGPU work is C++, and will be for the foreseeable future.
OpenCL and CUDA both do have other bindings (off the top of my head,.NET, java and python), but these are 2nd class support-wise.
Features are added and behavior is changed for the sake of changing, with no benefits to any software quality whatsoever.
Spoken like someone who doesn't know what they're talking about.
No benefits to software quality? Point out any new feature in C++11 that was added that didn't have a reason. (I would be very interested in fact, as I can't think of any off-hand); the newly added features are done with specific problems in mind. They might not be the problems that YOU encounter, but someone else has.
The "complex" rules for templates are laid out in painstaking detail in the standard. There can be surprising interactions with other language features(e.g. explicit template function specialization), but (based on personal experience), after having encountered them once or twice, you learn about them and avoid them in the future. On the other hand, having what would otherwise be runtime errors reported at compile time saves time on debugging, and generates more robust code.
Those with odd-numbered plates lucked out; apparently they've already discontinued the practice, after having issued roughly 4000 tickets.
One especially pertinent quote from the linked article:
""I know it's not great to say it but I'm willing to take my car and pay the fine to get my kids to school, because I don't have the choice," one woman told the TV network."
Actually, the C++ community will call you an idiot because most of your complaints are simply a result of your misunderstandings.
There is no encapsulation either at compile time (you need to recompile your code if you touch any code where the private members change) or run time (feel free to modify those so-called private members, though; all you need is their memory location).
Your gripe about runtime encapsulation is idiotic; you would really have to go out of your way to get the memory address of a private variable (you would have to guess its location, which would be compiler-specific due to compiler-generated members like the vtable or alignment padding), or by requiring the class itself return a reference or pointer to the variable. C++ assumes you're competent and isn't going to stop you in pathological cases.
Exceptions leak memory unless you wrap everything in a "smart pointer"...
Using RAII is standard, idiomatic C++. You can use smart pointers for dynamic memory or allocate your variables on the stack. That way, (as long as your destructor is correct), you won't leak memory, even in the face of exceptions. Pretty easy, right? As an added bonus, its performant and deterministic. What's not to like?
auto_ptr is gone, and for "that decade" it was standard to roll your own smart pointers or use boost. Now you have unique_ptr and shared_ptr as your primary standard library smart pointers.
There's finally garbage collection in the standard library through std::shared_ptr but it's just reference counting, so just forget about, e.g. lock-free multithreaded data structures..
I guess you'd be pretty amazed to hear that there are portable, lock-free data structures written in C++ then! In fact, boost already has a few.
Also, if you really want reflection, Qt has support for it (via MOC, though you'll have to jump through some hoops with QObject).
It would be nice to have regex support, but I wouldn't want them to halt their entire development pipeline to implement it. If they had to finish implementing the previous standard before starting on the next one, we would still be on C++03 on account of exported templates.
Tell that to my compiler. I'd say if anything software is very structured; you have a limited pool of recognized syntax that can be combined in specific ways. If you're using a library, you have to adhere to its API. Ultimately your code will be running on some processor, which has a limited set of instructions it can perform. Software has no laws? Hardly.
For your own sanity, stay away.
Sounds like it might already be too late for you...
It should also be noted that as of C++11 threading is part of the C++ standard library (so you usually won't have to use pthreads or any other platform-specific threads directly).
Last I checked (a few years ago) CUDA had better tools and more features than OpenCL. Has this changed much since then? OpenCL didn't even support templates back then...
For completeness, it should also be noted that both C and C++ work with MPI and CUDA. Fortran can theoretically be faster than C or C++ as its compiler can optimize more aggressively (due to the lack of pointer aliasing in Fortran), but I don't have any hard data for how much of a difference it would make in actual runtime speeds.
Slashdot Mirror
I read the article/rant, and he's bitching about the complexity and time required to learn and use modern frameworks and tools, not so much about planning and management. The summary is a bit misleading.
I think part of the problem is that "programming" is itself so diverse. If you were to be a graphics programmer, you would certainly need your linear algebra, geometry, etc. If you worked with scientific computing, you'd need even more math (e.g. differential equations, statistics, etc). If you worked as a DSP programmer, you'd need to know calculus (and then some). In contrast, web development doesn't really require any of these. However, they all involve "programming", and the people writing the software can all be called "programmers", even if one's writing a website (no math) and another is doing a fluid dynamics simulation (lots of math).
FDA officials estimate the collection was assembled between 1946 and 1964 by government scientists.
Tell me again what role Obama had in this?
I was in Paris just last week. There were no "locked down" monuments, and there were no armed personnel patrolling the streets. There were some military-types at the Arc De Triomphe, but that's because of Bastille Day celebration preparations -- that is, they were there for a celebration, not for a patrolling. You're spouting nonsense.
Well, Lois Lerner was appointed by Bush in 2006.
Their OpenCL drivers are pretty bad. Completely arbitrary changes can have huge impacts on things like VGPR usage. Optimizing an OpenCL kernel on an AMD card is like black magic. Not that I'm praising NVIDIA here, they're still on OpenCL 1.1...
Or... if you're using C++, use a Standard Library container? They all keep track of their sizes, and can perform runtime bounds checks (by using say, at() rather than the bracket operator). Or Write your own class with an array member and an accessor that does bounds checking. It's not difficult to do. At all. And templates aren't meant for addressing buffer overflow problems, or as a replacement for raw pointer (use STL containers). Or garbage collection (use RAII). I get the feeling you aren't too familiar with C++?
Take a look at "The art and science of programming" by Donald Knuth, it's examples are in Pascal but if you inhale the wisdom in the book you will understand when I say that the language it uses is irrelevant.
Just in case this confuses the submitter, the actual title is "The Art of Computer Programming". And IIRC the code examples aren't in Pascal, but rather in "MIX" assembly, which is a hypothetical language for a hypothetical machine. Also, be forewarned that it has a steep learning curve...
Not sure if I'm missing the joke here (if so, apologies), but just because the book title is "Exceptional C++" doesn't mean the whole thing is about exceptions.
Exceptions are covered for a few chapters in that book, but some of the recommendations aren't really relevant anymore; C++11 deprecated many of the problematic parts of exceptions (e.g. exception specifications), and much like valarrays, no one really used them anyways
Well, C++ threads and the new memory model would take more than just a little more typing. Same for rvalue references.
My normal rules of thumb are: - No operator overloading, especially type casts. - Templates are mostly used for container classes, or in rare cases algorithms. - Spare use of method/function overloading. - Try to use template parameters that are themselves of as simple of a type as is practical.
Some operators shouldn't be overloaded (e.g. &, && and ||), but good luck writing any non-trivial container classes without overloading the assignment operator. You may think you're not overloading these, but the compiler is simply auto-generating them for you since you didn't provide one (namely, copy-assignment operator and move-assignment operators). As with any language feature it can be abused, but they can be quite useful when used judiciously. (i.e. if you're writing a Matrix library, you'll probably want to overload the arithmetic operators).
It's true that there are pitfalls to using templates, but I think you're grossly overstating their dangers (while ignoring all their benefits). You can do some pretty amazing things with templates; in the least they reduce code duplication, and at best they allow compile-time polymorphism, better error detection, and a whole different paradigm for using C++ (metaprogramming can pretty closely resemble functional programming).
In a word, C++ has the best binding support for GPGPU.
Both CUDA and OpenCL started off as C-based API -- CUDA has since moved to C++, and is moving towards more modern, idiomatic C++, both for its host-side API and device-side code (e.g. has support for kernel templates). OpenCL is a bit behind in this respect, although it also has both C and C++ bindings. You can also use fortran, but the majority of use-cases for GPGPU work is C++, and will be for the foreseeable future.
OpenCL and CUDA both do have other bindings (off the top of my head, .NET, java and python), but these are 2nd class support-wise.
Features are added and behavior is changed for the sake of changing, with no benefits to any software quality whatsoever.
Spoken like someone who doesn't know what they're talking about.
No benefits to software quality? Point out any new feature in C++11 that was added that didn't have a reason. (I would be very interested in fact, as I can't think of any off-hand); the newly added features are done with specific problems in mind. They might not be the problems that YOU encounter, but someone else has.
I use C++ almost daily -- if you're doing any CUDA (or OpenCL) work, then you'll want to be using C++.
If template error messages bother you, use Clang. It outputs much saner template error messages.
The "complex" rules for templates are laid out in painstaking detail in the standard. There can be surprising interactions with other language features(e.g. explicit template function specialization), but (based on personal experience), after having encountered them once or twice, you learn about them and avoid them in the future. On the other hand, having what would otherwise be runtime errors reported at compile time saves time on debugging, and generates more robust code.
Those with odd-numbered plates lucked out; apparently they've already discontinued the practice, after having issued roughly 4000 tickets.
One especially pertinent quote from the linked article: ""I know it's not great to say it but I'm willing to take my car and pay the fine to get my kids to school, because I don't have the choice," one woman told the TV network."
There have also been accounts of (wild) elephants helping humans
And what about the nepotism in the peer review process? Was that somehow by accident as well?
There is no encapsulation either at compile time (you need to recompile your code if you touch any code where the private members change) or run time (feel free to modify those so-called private members, though; all you need is their memory location).
Your gripe about runtime encapsulation is idiotic; you would really have to go out of your way to get the memory address of a private variable (you would have to guess its location, which would be compiler-specific due to compiler-generated members like the vtable or alignment padding), or by requiring the class itself return a reference or pointer to the variable. C++ assumes you're competent and isn't going to stop you in pathological cases.
Exceptions leak memory unless you wrap everything in a "smart pointer" ...
Using RAII is standard, idiomatic C++. You can use smart pointers for dynamic memory or allocate your variables on the stack. That way, (as long as your destructor is correct), you won't leak memory, even in the face of exceptions. Pretty easy, right? As an added bonus, its performant and deterministic. What's not to like? auto_ptr is gone, and for "that decade" it was standard to roll your own smart pointers or use boost. Now you have unique_ptr and shared_ptr as your primary standard library smart pointers.
There's finally garbage collection in the standard library through std::shared_ptr but it's just reference counting, so just forget about, e.g. lock-free multithreaded data structures..
I guess you'd be pretty amazed to hear that there are portable, lock-free data structures written in C++ then! In fact, boost already has a few. Also, if you really want reflection, Qt has support for it (via MOC, though you'll have to jump through some hoops with QObject).
It would be nice to have regex support, but I wouldn't want them to halt their entire development pipeline to implement it. If they had to finish implementing the previous standard before starting on the next one, we would still be on C++03 on account of exported templates.
... software follows no laws.
Tell that to my compiler. I'd say if anything software is very structured; you have a limited pool of recognized syntax that can be combined in specific ways. If you're using a library, you have to adhere to its API. Ultimately your code will be running on some processor, which has a limited set of instructions it can perform. Software has no laws? Hardly.
For your own sanity, stay away.
Sounds like it might already be too late for you...
It should also be noted that as of C++11 threading is part of the C++ standard library (so you usually won't have to use pthreads or any other platform-specific threads directly).
Last I checked (a few years ago) CUDA had better tools and more features than OpenCL. Has this changed much since then? OpenCL didn't even support templates back then...
For completeness, it should also be noted that both C and C++ work with MPI and CUDA. Fortran can theoretically be faster than C or C++ as its compiler can optimize more aggressively (due to the lack of pointer aliasing in Fortran), but I don't have any hard data for how much of a difference it would make in actual runtime speeds.