I would agree, but I'm arguing that archiving and redistribution is part of the medium that the copyrighted work was published in. The webmaster of the site certainly knew that the site would be archived.
As I pointed out in another post, that is no defence. Otherwise, because I know that releasing any good software in electronic format is likely to result in someone distributing it on a warez site, I am implicitly granting permission for that to happen. Because anyone who releases a decent audio track knows that it's likely to wind up on P2P, they are implicitly granting permission for that to happen. In fact, we might as well do away with the entire concept of copyright, because releasing any copyright material at all gives implicit permission to violate the copyright arbitrarily.
Fortunately for all concerned, we have laws to make clear when behaviour is considered unacceptable ahead of time, and we have a legal system to deal with those who ignore those laws and do it anyway.
I suspect it's more likely that more than one person in the world thought of the same joke. I got this firsthand from the guy who was holding the camera, so either he'd heard about a guy on the other side of the world doing it and was joking with me (which is possible, of course; this would have been about the same time as the original article) or maybe the guy he nicked had read the article and decided to try his luck over here...
I wonder if there have been suits over the Google, formerly DejaNews, archive of Usenet.
As far as I know, there hasn't been any definitive court case anywhere on the basic concept of Usenet archives. They at least have some kind of defence, because you inevitably expect Usenet messages to propagate beyond your control, and you expect that services providing Usenet feeds will charge money to their customers in exchange for relaying the information. IMHO, for Usenet archives it's more a question of whether permanent storage is a reasonable expectation for which permission is implied by posting, which can at least be argued reasonably either way (e.g., it usually isn't and it's common expectation that messages will disappear after a few days vs. the technical standards not saying anything about necessary expiration and considerations of increased cheap storage space at service providers compared to when Usenet was first running).
I'm pretty sure that at least one business that reproduced Usenet via the web and added those annoying automated keyword-linked ads on top of someone's posts has been screwed for it in court, though; IIRC, they were found to be publishing a derivative work without permission. I've come across at least one techie forum that was abusing many posts I've made to a programming newsgroup this way, which I did find inappropriate (they are generating ad revenue purely from distorting words I wrote, even advertising compilers in a post whose whole point was that you shouldn't write code depending on a specific compiler!), so I don't have much sympathy. If anyone can remember the case that established this one, I'd appreciate a reference.
You are fighting for the losing side and against progress in this argument. The problem is that the more people who think like you, the longer progress will be held up.
From someone who just demonstrated a fundamental misunderstanding about copyright even as it stands today (ignoring the concepts of fair use exemptions and implied permission) that's a bit rich.
I wonder how many people wanting this "progress" actually contribute their own content for others to use, and how many just want everything for free?
There is this thing called 'reasonable expectation'. In the case of the WWW the reasonable expectation to have is that publishing something on it means it is out there, will be copied, linked to, shared, archived etc.
Says who?
By your standard, there is a reasonable expectation that any good software I release will be copied illegally and distributed on P2P, so I have no right to take action against those who do it.
My personal opinion? The law needs to be changed to protect groups who do exactly this. This is one of many areas where copyright law needs to be diluted in order to remain credible. If people performing what is obviously a public service, who do make best-efforts to honour the wishes of those who do not consent to be a part of what they're doing, need to worry about the legality of doing so, the law is wrong and liable to fall into disrepute.
It would certainly be beneficial to adopt such an approach, but for two basic problems.
Firstly, you impose a burden on anyone distributing their work to notify every archive (of which there could be many) that they do not wish their material to be archived. You could argue that this is what robots.txt is for, but short of passing laws to this effect or some piece of clear case law (that was a joke, BTW) in every jurisdiction, that file has no special legal standing. Moreover, since it's not widely known about, it's hard to see how such case law could be justified today anyway; a typical family publishing a web site on their ISP-hosted web pages couldn't reasonably be expected to know about the robot protocols.
Secondly, it's not entirely clear that without adequate protections such a group is providing an invaluable public service. If content providers become reluctant to share material that they might later publish for profit (say) because of the risk that someone else will gain the right to republish it first and diminish its value, this is not incentivising the distribution of works, which is the whole raison d'etre of copyright.
Without imposing something rather severe, like universal, worldwide guidelines on how any archive must be run, compulsory registration by all archives with some centralised service, and the absolute right of any copyright owner to have their content removed from all archives just by providing proof of their copyright ownership to that service, it's hard to see how you can reconcile the basic right of a copyright holder with the desirability of allowing archiving where no-one objects.
i agree... if this case managed to place restrictions on the Internet Archive, it would have serious repercusions all throughout the internet, as any type of caching could be construed as copyright infringement.
Not necessarily. Any type of caching without permission is copyright infringement, unless an exemption applies. The sort of excerpts in search engines that you describe might be a fair use. You could argue, though it's not nearly as clear cut, that caching live content is a fair use. It's hard to see how republishing someone else's material that is not currently available in that medium is anything but a flagrant infringement of copyright.
Frankly, it amazes me that there haven't been many more cases where various Google facilities (Groups, Cache, and conversions to HTML) and the Wayback Machine haven't been sued. I don't see how they really have a legal leg to stand on; there is no special exemption to copyright because you're Google or the Internet Archive.
I'm really sick and tired of companies that have absolutely no clue how the Internet and the world wide web works putting up sites and then expecting you to never cache them anywhere.
<mini-rant> And I'm really sick and tired of people that have absolutely no regard for how the law works copying material off the Internet and then expecting never to get sued for it, claiming some legally naive and ethically dubious justification. </mini-rant>
Seriously, we have this discussion every time Google or the Wayback Machine or whatever comes up. Putting material on the Internet does not give up your copyright on it, place it in the public domain, grant others the right to reproduce it any way they see fit, or otherwise work differently to copyright laws as they apply to all other media. There are necessarily certain implied rights, but arguing that actually ripping someone else's material and then making it publicly available after they've withdrawn it from their own site is a pretty big stretch to anyone without a vested interest.
Before anyone shoots back the inevitable responses about information wanting to be free, not controlling the flow, yada yada, please stop and think for a minute. A lot of the useful content on the web is made available by volunteers or companies who don't expect to profit from it immediately, but whose future business may be damaged if the information is taken and republished by others. Many of these people will just stop putting information on the web at all (see Slashdot discussions passim) if you abuse the access, and that doesn't benefit anyone.
In fact, limiting the rights of others to distribute your works in order to encourage you to make them available is exactly what copyright is for, and this sort of case is a textbook example of why the principle matters.
Likewise, my new machine circa 2002 didn't get one. (Actually, it was more because I couldn't undo a couple of the small screws from my previous machine's drive, or it would have done as a "just in case" precaution. D'oh.)
I gather there are a few niches where floppies are still necessary; someone was telling me something about SATA drivers for some OSes in a previous Slashdot discussion, and I'm never quite sure about Windows recovery disks and such. However, it seems either a CD-based or USB-based alternative is available for things like emergency booting and back-ups these days, and the greater capacity and physical robustness makes them much more suitable. I can't say I've missed the floppy drive with my current PC.
Heh. My driving instructor's husband was a traffic cop, with a few stories to tell. One time, the enforcement guys he worked with sent the usual speed camera photo to someone who'd gotten himself caught well over the limit, with the usual official notice telling him he had to pay a fine.
Being a bit of a practical joker, the speeder sent them back a photo of three ten pound notes (the fine in question).
Being up for a joke themselves, the enforcement guys sent him back a photo of a pair of handcuffs.
I'm reliably informed that the fine arrived, in cash, the following day.
When I returned, it seemed Java had been developed and B.S. apparently revamped C++ to look more like Java.
OK, now I know you're trolling. True, one of C++ and Java has been changing, in very significant ways, to look more like the other, but you've got them the wrong way around. "We don't need templates!" cried the Java evangelists, yet now Java 1.5 introduces generics. Ditto for enumerations, and much more. C++ got these things at least somewhat right the first time, and Java (and C#/.Net) are only just catching up. We ought to be 20 years further on by now, with C++'s efforts consigned to the history books as a stepping stone to something much better, yet they're only just now being half-heartedly emulated!
As for your original comment that you've never seen any good C++ code, well, if you think using friend is a common thing then you obviously haven't seen very much C++ code at all. The language has changed a lot in the past 15 years, and you still seem to view it as it was then, ignoring all the developments in both language features and effective usage idioms that have come about since.
Having to throw (& catch, & handle) an exception just to indicate a simple failure is a little bit too much when a simple int return type to identify an error condition could do.
That wouldn't do at all. Throwing an exception to indicate construction failure means a failed construction usually doesn't leave the name that would have referred to the constructed object in scope, which means you can't try to use it accidentally. Dumping this effective idiom for naive return codes would be like introducing a finally keyword but dumping RAII: it's a step in the wrong direction.
Almost any language can read like english if done cleverly.
Yes, although personally I'd say "be easily readable" rather than your "read like english", because English isn't always what you want due to inherent ambiguities and the like. In fact, I'd go as far as to say that one of the hallmarks of a good programmer is how readable his code is.
I've noticed an almost circular pattern here. Beginners write code that's pretty simple because they don't know any more, but that code sometimes doesn't perform well, or misses cases, or contains other subtle bugs. More experienced developers, with a wider range of language tools and programming techniques at their disposal, will use those extra techniques to plug the gaps and fix the bugs, but this creates lots of nasty special cases and "clever tricks" that are a maintenance and readability hazard. The really good programmer goes full circle, once again writing code that is very simple and easy to read. The difference from the beginner is that the expert will integrate most of the special cases cleanly into the design so they just don't arise in the first place. He will use extra language features or design techniques sparingly, and only when a simpler approach is inadequate. And above all, it will always be clear what tools and techniques are being used, and what the results should be.
Now getting back to C++, you are not forced to do anything except write code like the following:
T & list::iterator::operator* () const
{
return current->data;
}
Yeah I suppose this is obvious, and simple! (NOT)
If you think that syntax is difficult, sure, maybe C++ isn't for you. To anyone who understands basic C++ ideas like references, scoping, const correctness and operator overloading, that's a pretty trivial function. C++ isn't really aimed at someone who isn't willing to learn these things, and that sort of person shouldn't be using C++.
If, however, you find the concepts involved difficult, maybe programming isn't for you. Any programmer who thinks using Java or Python or whatever means they don't have to understand ideas like indirection and iteration is pretty much a liability.
If you're just hiring meat to perform a particular task, unless they did it maliciously, how the hell can it be the employee's fault?
Do you really, honestly believe that an employee in a book store sold these books by accident, and that their management hadn't told them about the release date? I know a couple of people who work in bookstores here, and they've had the release conditions drilled into them for months already.
I find the idea that a guy with access to the "secure" storage took a bit of extra money home one night to look the other way far more plausible, and you can hardly blame management for that.
It's the book store's fuck up, not the book buyers.
So is selling on stolen property, but the police will still take it back from the (innocent) buyer and return it to its rightful owner.
Before anyone gets in a mess, I'm not saying these two situations are equivalent or making any statement about physical vs. intellectual property here. I'm just demonstrating that there are cases where the sort of action talked about here can be used by the legal system for genuine reasons.
I'm not sure who you're talking to, but everywhere I go, I see Java on the up and up.
I'm talking to people who work on scientific applications, instrument control applications, games, and system software, for a start. Every one of those is a huge development area, perhaps not quite as big as "business apps" (i.e., databases), but certainly on a comparable scale. Java's chance of penetrating any of these areas significantly is approximately not very much at all. It just isn't cut out for the performance and/or low-level control that is routinely used in this sort of application.
By all means, let Java's use for developing business apps grow; that is where it seems to work well, and a domain probably better suited to Java than to C++. Similarly, for undemanding (in performance and control terms) desktop apps, or the equivalents on mobile phones and such, Java should be right at home. Perhaps the same is true of some embedded systems as well, though I suspect many of those will run into similar limitations to the external instrument control world and decide to stick with C or C++ anyway. But really, this is a different world to the one in which C and C++ live. They were only king of the other spaces by proxy before, because no-one else stepped up and said they'd do it.
Seriously, this is a real logistical problem for big releases like this. Some store, somewhere, through no fault of their own and no ill will on the part of the publisher, will see their delivery held up because of a road accident, or a fire at a warehouse, or any of 101 other unlikely reasons that become near certainties when things are scaled up.
The only reason a store would lose out on a lot of sales without agreeing is if it were the unlucky one here. However, with the sort of numbers you're talking about, quite often someone is that unlucky one. As the GP pointed out, it's therefore in everyone's interest to agree a common release date so the logistics (and any logistical problems) can be dealt with in good time.
That wasn't so much insightful as wishful thinking on the part of someone who isn't a manager.
We used to have a culture where management never took any heat for anything, which was a bad thing. But expecting someone to take responsibility for something they had no realistic knowledge of or control over (and expecting managers to supervise all staff all the time in case someone makes one little mistake is just that situation) then holding them accountable is as absurd as any other feel-good political correctness, and about as constructive.
I'm not a manager, BTW, just a guy who believes in credit where it's due and not assigning blame randomly just because something went wrong.
According to "Effective C++" - Meyers, if you need to know the type of a class, you designed your classes wrong.
Or, alternatively, Scott is wrong on this one.
There is a reason to have dynamic_cast in the language. Consider, for example, a class hierarchy with three levels, where some virtual functions are introduced in the middle level, but all you have is a reference to the top level base class. If you have an algorithm that deals with this class hierarchy, and wants to call one of the mid-level virtual functions if the object it's got is of a suitable type, then the only way to get there safely, in general, is via a dynamic cast.
Anything else either requires polluting the topmost base class's interface, or some part of the system to have deeper knowledge of the types involved. (Try it.) The deeper knowledge may theoretically always be available, somewhere, and possibly at the expense of hideous code duplication, but in practice it's often cleaner and more maintainable to go with the dynamic cast.
You're missing a lot of background here. The article is more about some of the design principles they're adopting (e.g., focus on extending the library, while keeping the language as unchanged as possible) than about enumerating all the new features under consideration. If you want the latter, much of the discussion is public; just search the standards committee's web pages.
Stroustrup created a language that has lasted some 20 years already, with an estimated user base of 3 million people, popularising numerous programming concepts previously reserved for academic or obscure programming languages, and you are going to lecture him about timing? That's really very, very funny.
The STL is real. It works. It rocks. Compilers get better at making it incredibly fast all the time.
OK, I'm a bit of a C++ fan (I like practical tools), but let's keep this in perspective.
The containers/iterators/algorithms parts of the C++ standard library are real.
They mostly work, aside from the glaring omissions (hash tables? circular lists?) and design blunders (vector<bool>? basic_string?).
They don't really rock. The containers are handicapped by the absence of corresponding literals, which even the practical monstrosity that is Perl can do. Many of the algorithms are crippled by the lack of first-order functions and the like, and look like a strange attempt at humour to anyone familiar with functional programming languages. Numerous articles have been written by clever people about how to get these C++ features to almost do something using a page of code that other languages can do in one line described in the first chapter of the book.
And the performance is OK, but since compilers still have to accept underlying aliasing concerns and the like, it's still somewhat held back compared to a more robust type system that didn't allow for things like pointer arithmetic.
Slashdot Mirror
As I pointed out in another post, that is no defence. Otherwise, because I know that releasing any good software in electronic format is likely to result in someone distributing it on a warez site, I am implicitly granting permission for that to happen. Because anyone who releases a decent audio track knows that it's likely to wind up on P2P, they are implicitly granting permission for that to happen. In fact, we might as well do away with the entire concept of copyright, because releasing any copyright material at all gives implicit permission to violate the copyright arbitrarily.
Fortunately for all concerned, we have laws to make clear when behaviour is considered unacceptable ahead of time, and we have a legal system to deal with those who ignore those laws and do it anyway.
I suspect it's more likely that more than one person in the world thought of the same joke. I got this firsthand from the guy who was holding the camera, so either he'd heard about a guy on the other side of the world doing it and was joking with me (which is possible, of course; this would have been about the same time as the original article) or maybe the guy he nicked had read the article and decided to try his luck over here...
As far as I know, there hasn't been any definitive court case anywhere on the basic concept of Usenet archives. They at least have some kind of defence, because you inevitably expect Usenet messages to propagate beyond your control, and you expect that services providing Usenet feeds will charge money to their customers in exchange for relaying the information. IMHO, for Usenet archives it's more a question of whether permanent storage is a reasonable expectation for which permission is implied by posting, which can at least be argued reasonably either way (e.g., it usually isn't and it's common expectation that messages will disappear after a few days vs. the technical standards not saying anything about necessary expiration and considerations of increased cheap storage space at service providers compared to when Usenet was first running).
I'm pretty sure that at least one business that reproduced Usenet via the web and added those annoying automated keyword-linked ads on top of someone's posts has been screwed for it in court, though; IIRC, they were found to be publishing a derivative work without permission. I've come across at least one techie forum that was abusing many posts I've made to a programming newsgroup this way, which I did find inappropriate (they are generating ad revenue purely from distorting words I wrote, even advertising compilers in a post whose whole point was that you shouldn't write code depending on a specific compiler!), so I don't have much sympathy. If anyone can remember the case that established this one, I'd appreciate a reference.
Blockquoth the AC:
From someone who just demonstrated a fundamental misunderstanding about copyright even as it stands today (ignoring the concepts of fair use exemptions and implied permission) that's a bit rich.
I wonder how many people wanting this "progress" actually contribute their own content for others to use, and how many just want everything for free?
Says who?
By your standard, there is a reasonable expectation that any good software I release will be copied illegally and distributed on P2P, so I have no right to take action against those who do it.
It would certainly be beneficial to adopt such an approach, but for two basic problems.
Firstly, you impose a burden on anyone distributing their work to notify every archive (of which there could be many) that they do not wish their material to be archived. You could argue that this is what robots.txt is for, but short of passing laws to this effect or some piece of clear case law (that was a joke, BTW) in every jurisdiction, that file has no special legal standing. Moreover, since it's not widely known about, it's hard to see how such case law could be justified today anyway; a typical family publishing a web site on their ISP-hosted web pages couldn't reasonably be expected to know about the robot protocols.
Secondly, it's not entirely clear that without adequate protections such a group is providing an invaluable public service. If content providers become reluctant to share material that they might later publish for profit (say) because of the risk that someone else will gain the right to republish it first and diminish its value, this is not incentivising the distribution of works, which is the whole raison d'etre of copyright.
Without imposing something rather severe, like universal, worldwide guidelines on how any archive must be run, compulsory registration by all archives with some centralised service, and the absolute right of any copyright owner to have their content removed from all archives just by providing proof of their copyright ownership to that service, it's hard to see how you can reconcile the basic right of a copyright holder with the desirability of allowing archiving where no-one objects.
Not necessarily. Any type of caching without permission is copyright infringement, unless an exemption applies. The sort of excerpts in search engines that you describe might be a fair use. You could argue, though it's not nearly as clear cut, that caching live content is a fair use. It's hard to see how republishing someone else's material that is not currently available in that medium is anything but a flagrant infringement of copyright.
Frankly, it amazes me that there haven't been many more cases where various Google facilities (Groups, Cache, and conversions to HTML) and the Wayback Machine haven't been sued. I don't see how they really have a legal leg to stand on; there is no special exemption to copyright because you're Google or the Internet Archive.
<mini-rant> And I'm really sick and tired of people that have absolutely no regard for how the law works copying material off the Internet and then expecting never to get sued for it, claiming some legally naive and ethically dubious justification. </mini-rant>
Seriously, we have this discussion every time Google or the Wayback Machine or whatever comes up. Putting material on the Internet does not give up your copyright on it, place it in the public domain, grant others the right to reproduce it any way they see fit, or otherwise work differently to copyright laws as they apply to all other media. There are necessarily certain implied rights, but arguing that actually ripping someone else's material and then making it publicly available after they've withdrawn it from their own site is a pretty big stretch to anyone without a vested interest.
Before anyone shoots back the inevitable responses about information wanting to be free, not controlling the flow, yada yada, please stop and think for a minute. A lot of the useful content on the web is made available by volunteers or companies who don't expect to profit from it immediately, but whose future business may be damaged if the information is taken and republished by others. Many of these people will just stop putting information on the web at all (see Slashdot discussions passim) if you abuse the access, and that doesn't benefit anyone.
In fact, limiting the rights of others to distribute your works in order to encourage you to make them available is exactly what copyright is for, and this sort of case is a textbook example of why the principle matters.
Likewise, my new machine circa 2002 didn't get one. (Actually, it was more because I couldn't undo a couple of the small screws from my previous machine's drive, or it would have done as a "just in case" precaution. D'oh.)
I gather there are a few niches where floppies are still necessary; someone was telling me something about SATA drivers for some OSes in a previous Slashdot discussion, and I'm never quite sure about Windows recovery disks and such. However, it seems either a CD-based or USB-based alternative is available for things like emergency booting and back-ups these days, and the greater capacity and physical robustness makes them much more suitable. I can't say I've missed the floppy drive with my current PC.
Heh. My driving instructor's husband was a traffic cop, with a few stories to tell. One time, the enforcement guys he worked with sent the usual speed camera photo to someone who'd gotten himself caught well over the limit, with the usual official notice telling him he had to pay a fine.
Being a bit of a practical joker, the speeder sent them back a photo of three ten pound notes (the fine in question).
Being up for a joke themselves, the enforcement guys sent him back a photo of a pair of handcuffs.
I'm reliably informed that the fine arrived, in cash, the following day.
You could try Eckel's Thinking in C++, which is available for free in electronic format via his web site.
OK, now I know you're trolling. True, one of C++ and Java has been changing, in very significant ways, to look more like the other, but you've got them the wrong way around. "We don't need templates!" cried the Java evangelists, yet now Java 1.5 introduces generics. Ditto for enumerations, and much more. C++ got these things at least somewhat right the first time, and Java (and C#/.Net) are only just catching up. We ought to be 20 years further on by now, with C++'s efforts consigned to the history books as a stepping stone to something much better, yet they're only just now being half-heartedly emulated!
As for your original comment that you've never seen any good C++ code, well, if you think using friend is a common thing then you obviously haven't seen very much C++ code at all. The language has changed a lot in the past 15 years, and you still seem to view it as it was then, ignoring all the developments in both language features and effective usage idioms that have come about since.
Thanks for the info, but alas this has been getting me about every other post since the weekend. :-(
That wouldn't do at all. Throwing an exception to indicate construction failure means a failed construction usually doesn't leave the name that would have referred to the constructed object in scope, which means you can't try to use it accidentally. Dumping this effective idiom for naive return codes would be like introducing a finally keyword but dumping RAII: it's a step in the wrong direction.
Yes, although personally I'd say "be easily readable" rather than your "read like english", because English isn't always what you want due to inherent ambiguities and the like. In fact, I'd go as far as to say that one of the hallmarks of a good programmer is how readable his code is.
I've noticed an almost circular pattern here. Beginners write code that's pretty simple because they don't know any more, but that code sometimes doesn't perform well, or misses cases, or contains other subtle bugs. More experienced developers, with a wider range of language tools and programming techniques at their disposal, will use those extra techniques to plug the gaps and fix the bugs, but this creates lots of nasty special cases and "clever tricks" that are a maintenance and readability hazard. The really good programmer goes full circle, once again writing code that is very simple and easy to read. The difference from the beginner is that the expert will integrate most of the special cases cleanly into the design so they just don't arise in the first place. He will use extra language features or design techniques sparingly, and only when a simpler approach is inadequate. And above all, it will always be clear what tools and techniques are being used, and what the results should be.
If you think that syntax is difficult, sure, maybe C++ isn't for you. To anyone who understands basic C++ ideas like references, scoping, const correctness and operator overloading, that's a pretty trivial function. C++ isn't really aimed at someone who isn't willing to learn these things, and that sort of person shouldn't be using C++.
If, however, you find the concepts involved difficult, maybe programming isn't for you. Any programmer who thinks using Java or Python or whatever means they don't have to understand ideas like indirection and iteration is pretty much a liability.
Do you really, honestly believe that an employee in a book store sold these books by accident, and that their management hadn't told them about the release date? I know a couple of people who work in bookstores here, and they've had the release conditions drilled into them for months already.
I find the idea that a guy with access to the "secure" storage took a bit of extra money home one night to look the other way far more plausible, and you can hardly blame management for that.
So is selling on stolen property, but the police will still take it back from the (innocent) buyer and return it to its rightful owner.
Before anyone gets in a mess, I'm not saying these two situations are equivalent or making any statement about physical vs. intellectual property here. I'm just demonstrating that there are cases where the sort of action talked about here can be used by the legal system for genuine reasons.
I'm talking to people who work on scientific applications, instrument control applications, games, and system software, for a start. Every one of those is a huge development area, perhaps not quite as big as "business apps" (i.e., databases), but certainly on a comparable scale. Java's chance of penetrating any of these areas significantly is approximately not very much at all. It just isn't cut out for the performance and/or low-level control that is routinely used in this sort of application.
By all means, let Java's use for developing business apps grow; that is where it seems to work well, and a domain probably better suited to Java than to C++. Similarly, for undemanding (in performance and control terms) desktop apps, or the equivalents on mobile phones and such, Java should be right at home. Perhaps the same is true of some embedded systems as well, though I suspect many of those will run into similar limitations to the external instrument control world and decide to stick with C or C++ anyway. But really, this is a different world to the one in which C and C++ live. They were only king of the other spaces by proxy before, because no-one else stepped up and said they'd do it.
Your tinfoil hat is slipping. :-)
Seriously, this is a real logistical problem for big releases like this. Some store, somewhere, through no fault of their own and no ill will on the part of the publisher, will see their delivery held up because of a road accident, or a fire at a warehouse, or any of 101 other unlikely reasons that become near certainties when things are scaled up.
The only reason a store would lose out on a lot of sales without agreeing is if it were the unlucky one here. However, with the sort of numbers you're talking about, quite often someone is that unlucky one. As the GP pointed out, it's therefore in everyone's interest to agree a common release date so the logistics (and any logistical problems) can be dealt with in good time.
That wasn't so much insightful as wishful thinking on the part of someone who isn't a manager.
We used to have a culture where management never took any heat for anything, which was a bad thing. But expecting someone to take responsibility for something they had no realistic knowledge of or control over (and expecting managers to supervise all staff all the time in case someone makes one little mistake is just that situation) then holding them accountable is as absurd as any other feel-good political correctness, and about as constructive.
I'm not a manager, BTW, just a guy who believes in credit where it's due and not assigning blame randomly just because something went wrong.
Or, alternatively, Scott is wrong on this one.
There is a reason to have dynamic_cast in the language. Consider, for example, a class hierarchy with three levels, where some virtual functions are introduced in the middle level, but all you have is a reference to the top level base class. If you have an algorithm that deals with this class hierarchy, and wants to call one of the mid-level virtual functions if the object it's got is of a suitable type, then the only way to get there safely, in general, is via a dynamic cast.
Anything else either requires polluting the topmost base class's interface, or some part of the system to have deeper knowledge of the types involved. (Try it.) The deeper knowledge may theoretically always be available, somewhere, and possibly at the expense of hideous code duplication, but in practice it's often cleaner and more maintainable to go with the dynamic cast.
You're missing a lot of background here. The article is more about some of the design principles they're adopting (e.g., focus on extending the library, while keeping the language as unchanged as possible) than about enumerating all the new features under consideration. If you want the latter, much of the discussion is public; just search the standards committee's web pages.
Stroustrup created a language that has lasted some 20 years already, with an estimated user base of 3 million people, popularising numerous programming concepts previously reserved for academic or obscure programming languages, and you are going to lecture him about timing? That's really very, very funny.
OK, I'm a bit of a C++ fan (I like practical tools), but let's keep this in perspective.
The containers/iterators/algorithms parts of the C++ standard library are real.
They mostly work, aside from the glaring omissions (hash tables? circular lists?) and design blunders (vector<bool>? basic_string?).
They don't really rock. The containers are handicapped by the absence of corresponding literals, which even the practical monstrosity that is Perl can do. Many of the algorithms are crippled by the lack of first-order functions and the like, and look like a strange attempt at humour to anyone familiar with functional programming languages. Numerous articles have been written by clever people about how to get these C++ features to almost do something using a page of code that other languages can do in one line described in the first chapter of the book.
And the performance is OK, but since compilers still have to accept underlying aliasing concerns and the like, it's still somewhat held back compared to a more robust type system that didn't allow for things like pointer arithmetic.