There was an interesting documentary on the TV recently about, amongst other things, the simulators used by the military to train their people to use the new "digital battlefield" kit. Just the rooms used by the people supervising the training looked a bit like that 13-monitor set up; the aircraft simulators themselves were something else...
Alas, in this case, I suspect the answer is given away by the number of system cases under the desk: it's probably just a load of screen shots displayed on lots of different PCs.
Personally, I'd say the complete opposite. Gaming has been the driving force behind most of the major graphics card advances, and several of the other architectural improvements in PCs, for years, and bleeding edge gamers are always the first to buy the hot new stuff and thus keep the industry moving forward. Most people don't buy a swishy new graphics card more than once, having learned the expensive lesson that most software won't support it for a year anyway, and it'll be half the price and vaguely reliable by then. But the die-hards are the momentum of the graphics card business.
For quite some time, Carmack has been one of the few people who Microsoft paid attention to, because where iD went, the gaming population and thus the whole graphics card industry would follow. (And, rather amusingly, iD went for OpenGL and not DirectX at the time. But I digress...)
For my money, games supporting multiple monitors in a useful way would be a strong driver to getting better screens into more homes, rather than the other way around.
"Yeah, I'm going to need a few more of these GeForce FX 9999 Super Ultra Plus ++'s for some, uh, tests..."
You think that's bad? The producer of the last Bond movie allegedly had to ring up his contact at Aston Martin, which had lent them several DB7s to play with, and explain that they'd just accidentally crashed a car with a six-figure price tag into an iceberg.
The first example on the article web site is a pretty good case: you don't span the main game view across two windows, you play with a full-size main view on one screen and far more of the supporting information/controls than normal visible on the other. Gives you a larger main display and more convenient access to the extras. Any RTS fan is going to appreciate that...
Yeah, except I have heard officials from several governments make this point.
Really? Which governments have actually gone as far as setting up development teams to work with OSS? I might have missed them, but I'd have thought stories like that would have been front page news around here...
It was a bit hyped up, wasn't it? It's a shame. I was just starting to give her some credit, and then she committed the classic "pro in not-so-independent interview" faux-pas of blatant self-promotion, or in this case, Sun-promotion.
One second, Java is much better than its predecessor, C++, because of all these whizzy features (most of which C++ also has, but that's beside the point). The next second, the problem is that objects alone aren't a sufficiently powerful abstraction mechanism, and thus "pure" OO languages won't ever be the solution to the problem of large-scale developments. But that's exactly what many developers have been saying about Java all along -- not least those who are used to having objects, functions, templates and all the other abstraction mechanisms available in C++!
I agree with you completely that bad code often arises through innocent intentions. I disagree, however, that it's often not avoidable. It's almost always avoidable: if you wrote the same code from scratch, knowing what you know after writing it the first time, you would produce a much better result.
The problem is just that complete rewrites are very expensive, and most development teams/managers are too stubborn to do minor rewrites when they should, preferring to add hacks or workarounds instead of maintaining a relatively clean design. Sooner or later, that usually results in the need for a much more expensive major rewrite instead.
Requiring an e-mail address (with an opt-out radio button) is fine; do they really need all the other crap?
s/opt-out/opt-in
Opt-out is not an acceptable way for companies to use my e-mail address, ever.
(Said the person who had just once again received an e-mail, even acknowledging its source, claiming that he had given his permission for the e-mail address to be used for marketting purposes, when he had done nothing of the sort.)
Well, the moral of the story, boys and girls, is that you shouldn't trust information you find on-line if you can't verify the source as someone you trust. Simple as that, really...
As with many (all?) other skills, I think two things probably dominate developer ability:
Developer potential follows a curve, starting with many people having little or no aptitude for programming, and tailing off with few programmers being able to be Really, Really Good. Most people at the bottom end don't work as developers, or don't get hired much.
How close any given developer gets to his maximum potential is a combination of attitude and exposure to opportunities to learn.
Please note the key distinction there: one of these factors relates to a developer's potential, the other to what he can actually achieve in reality.
To determine a good strategy for building a team of developers, you then have to consider the relative work rates of developers of different abilities, and the nature of the work. For example, most code is developed from relatively straightforward design and programming tasks, but often you have small areas that require much more skill to design and implement effectively. These areas require a more able developer/team, but OTOH we also know that such people can be anything up to 10x as productive as a "typical" developer on the more mundane work. Of course, employing such people also costs rather more.
So what does this suggest about our choice of programming language? Well, if your development task is going to require any complex design or implementation work, you're going to need a sufficient number of top end people to do it, and you're going to need suitably powerful and flexible tools to help them.
For the remainder of the work, highly skilled developers will still be happy using those powerful, flexible tools, but they may be in short supply, and chances are most of your team will be more average in ability, and thus more average in their ability to avoid mistakes. Thus you may need a tool that reduces the possibility or impact of those mistakes, even at the expense of some power and flexibility (which those developers will rarely if ever use anyway).
Strangely enough, this has always been one of the reasons I've liked C++ as a practical, real-world language. While it has plenty of theoretical flaws, it does combine both raw power and flexibility with a decent set of abstraction tools to keep routine development away from the most dangerous areas. You can have your top developers write subsystems using all the cunning tricks they need, but keep everyone else using only clearly defined interfaces. Given a little basic training (sadly a lacking commodity in the C++ programming world, but not beyond any competent manager to arrange -- this is the second factor above) the vast majority of "typical" developers can avoid the really dangerous programming practices, and take advantage of the neat stuff the top guys made for them. When those top guys have finished developing really neat stuff, they can just become super-efficient people doing the mundane stuff using the same tool.
Bottom line: for most real world projects, you need to judge a language by both what it's capable of when used by a really good guy and how well it looks after Joe Developer. If one language isn't enough to do both and your project needs them, maybe you need more than one language and some good glue, but that's a whole different topic.:-)
One of the main reasons for governments to use Open Source is that they can train and employ their own people in it's use, mainenance, and development.
I'm not convinced that's true at all. I think some governments are moving to Open Source because (a) it's cheaper, and (b) it doesn't involve vendor lock-in to a corp with a history of sharp pricing policies.
I rather suspect that any philosophical or moral reasons to support Open Source are utterly lost on most of the governments who might adopt it, and that the chances of those governments -- who are doing this to save money, and probably for no other reason -- spending a fortune employing skilled software developers and QA people to vet the code they're using and future-proof themselves is rather small.
It's a nice hack but fails if I get login.c and the compiler from independent sources.
And Linux geeks never pride themselves on rebuilding everything from the kernel up using gcc, and even if they did do that, which they don't, they'd always download an independent C compiler to build gcc first, of course...;-)
He's talking about [...] implying that large projects are just going to have bugs.
But that's not necessarily true, if you think of a large project being made of small testable components.
But how do you know the tests are all correct on a system of that scale? For that matter, how do you know that your requirements weren't contradictory in some small way, so that even though the tests reflect them perfectly in isolation, there are still gaps that create problems in the real world?
The point is that getting the requirements bullet-proof for a large, complex system is hard. Creating a flawless test and verification system for such a system is hard. And then implementing perfect, bug-free code using those tests is hard. Human error is possible at all levels, and no matter how hard you try, there is always a chance of that happening. No doubt good design, skilled developers doing the implementation, and careful review processes all help. It's just a matter of how much time you invest to reduce the chances, given that you get diminishing returns the closer to bullet-proof you get.
Closed source will never be like that simply because the sheer price of developing millions of lines of code to near perfect standards is astounding, and no one will want to pay for the end result.
But if cost were all that mattered, open source wouldn't have a prayer, because the level of financial investment in it is nowhere near what the big commercial groups put into their closed source offerings. Even big names like IBM and Sun, who contribute significantly to the open source world, aren't investing as much as Bill's or Larry's pocket change. So there must be more to it than simple finance.
OK, since the standard CSS Zen Garden link has come up, I'll post the standard caveats: the content for that site is marked up much more than any "typical" web site, in order to provide maximum flexibility for the stylesheet designers; also, a lot of the really nice effects are actually based on images and not CSS. It's a great demonstration of what the technology can do. It's a lousy demonstration of what the technology can do in the real world.
Now go look at the site, keep it in perspective, and be impressed.:-)
I've been following WPDFD for years, and have used at least the last five versions of Moz on Windoze. I haven't read this month's editorial with Moz -- I'm using IE at work -- but I've never seen such a problem before, and Joe's always been pretty careful about standards compliance, cross-browser support, etc.
He does try new things occasionally, so if there's a glitch this month, mail him and tell him and he'll almost certainly look into it; I've contacted him a couple of times and always had at least a "Thanks for the feedback, I'll look into it" type of reply. I certainly wouldn't accuse him of being IE-centric, though; quite the contrary, in fact.
Hrm, can you do me a favor and post your IP address here?
Um... Nope. Firstly, I'm on dial-up, so it changes dynamically. Secondly, it wouldn't do you any good, because my (non-Microsoft) firewall will tell you no-one's home anyway if I haven't talked to you first. Thirdly, I have looked into all the updates, and installed those that would apply to me; if I haven't installed it, it won't do you any good to attack me with it anyway.
This is kinda my point: now every time I visit Windows Update, I'm bombarded with "critical" updates which, for me, are nothing of the sort. Then I'm likely to miss the one really important one and get screwed.
Please tell me Microsoft is not as inept as this. Please?
They're suffering from a buffer overrun vulnerability. There is absolutely no excuse for that; basic safe coding practices and elementary training should render such things nigh-on impossible, even in a so-called unsafe language such as C++. Draw your own conclusions.
Hmm... The BBC News site is all over it as well, with a completely substance-less article proclaiming the end of the world as we know it, yada yada. It doesn't actually tell you anything useful about the vulnerability, nor AFAICS where to download the patch, though.
Not that it much matters, of course. I just looked at Windows Update, which currently reports 16 "critical" updates I haven't downloaded for my Windows XP box. Most of them appear to be completely irrelevant to me: I don't use the programs in question, nor have my system set up in such a way that the vulnerability would affect me in the first place. More to the point, I'm on dial-up, with a quota of hours on-line each month, and there's no way I'm going to waste vast amounts of that allowance downloading irrelevant "critical" patches. The rating has become meaningless, like so many alerts in the security industry, because those with all day to peruse the relevant mailing lists cry "Disaster!" at the drop of the hat, and poor Joe User has no idea whether it's really worth downloading or not.
Still, the answer appears to be "not" for me. Windows Update has just told me that it's encountered an (unspecified) error and can't continue to download those update I saw on the critical list that might actually affect me anyway...
If you had to read a 20 page essay, would you prefer to read it on paper or on a computer screen?
I think that's probably a personal taste question today.
For me, I don't usually bother to print out long pages and I'm quite happy to read extended documents on my screen. Then again, I've grown up with computers all my life, and my screen is high quality and well-configured for good readability: sensible resolution, very high refresh rate, screen-optimised fonts in comfortable sizes with anti-aliasing, etc.
However, the research shows that most people taken from across the population as a whole still read much faster (around 1/3-1/2 as fast again, typically) from paper than from a computer screen. AFAIK, no-one has yet established whether that's down to the innately superior qualities of paper over backlit screens, poor configuration of most people's screens, the "what you're used to" effect, or just plain, old-fashioned personal taste.
Incidentally, I do find some documents much easier to read on-screen than others. Using well-hinted fonts like Verdana and Georgia really helps with web page reading ease, for example. On web sites or downloaded reports with nasty formatting, I do still fall back on printing the thing out occasionally, and probably would do so more often but for the lousy printing capabilities of nearly every major web browser.
Slashdot Mirror
There was an interesting documentary on the TV recently about, amongst other things, the simulators used by the military to train their people to use the new "digital battlefield" kit. Just the rooms used by the people supervising the training looked a bit like that 13-monitor set up; the aircraft simulators themselves were something else...
Alas, in this case, I suspect the answer is given away by the number of system cases under the desk: it's probably just a load of screen shots displayed on lots of different PCs.
Personally, I'd say the complete opposite. Gaming has been the driving force behind most of the major graphics card advances, and several of the other architectural improvements in PCs, for years, and bleeding edge gamers are always the first to buy the hot new stuff and thus keep the industry moving forward. Most people don't buy a swishy new graphics card more than once, having learned the expensive lesson that most software won't support it for a year anyway, and it'll be half the price and vaguely reliable by then. But the die-hards are the momentum of the graphics card business.
For quite some time, Carmack has been one of the few people who Microsoft paid attention to, because where iD went, the gaming population and thus the whole graphics card industry would follow. (And, rather amusingly, iD went for OpenGL and not DirectX at the time. But I digress...)
For my money, games supporting multiple monitors in a useful way would be a strong driver to getting better screens into more homes, rather than the other way around.
You think that's bad? The producer of the last Bond movie allegedly had to ring up his contact at Aston Martin, which had lent them several DB7s to play with, and explain that they'd just accidentally crashed a car with a six-figure price tag into an iceberg.
The first example on the article web site is a pretty good case: you don't span the main game view across two windows, you play with a full-size main view on one screen and far more of the supporting information/controls than normal visible on the other. Gives you a larger main display and more convenient access to the extras. Any RTS fan is going to appreciate that...
But do you have left, centre, right or top, centre, bottom...?
Really? Which governments have actually gone as far as setting up development teams to work with OSS? I might have missed them, but I'd have thought stories like that would have been front page news around here...
It was a bit hyped up, wasn't it? It's a shame. I was just starting to give her some credit, and then she committed the classic "pro in not-so-independent interview" faux-pas of blatant self-promotion, or in this case, Sun-promotion.
One second, Java is much better than its predecessor, C++, because of all these whizzy features (most of which C++ also has, but that's beside the point). The next second, the problem is that objects alone aren't a sufficiently powerful abstraction mechanism, and thus "pure" OO languages won't ever be the solution to the problem of large-scale developments. But that's exactly what many developers have been saying about Java all along -- not least those who are used to having objects, functions, templates and all the other abstraction mechanisms available in C++!
I agree with you completely that bad code often arises through innocent intentions. I disagree, however, that it's often not avoidable. It's almost always avoidable: if you wrote the same code from scratch, knowing what you know after writing it the first time, you would produce a much better result.
The problem is just that complete rewrites are very expensive, and most development teams/managers are too stubborn to do minor rewrites when they should, preferring to add hacks or workarounds instead of maintaining a relatively clean design. Sooner or later, that usually results in the need for a much more expensive major rewrite instead.
I'll just stop passing large objects by const reference in my C++ then, I guess. Passing by value would be much more intuitive, after all.
Please don't mistake a good rule of thumb for an absolute truth. In most fields, there is no such thing.
Thank you. I'm glad someone got it... :-)
s/opt-out/opt-in
Opt-out is not an acceptable way for companies to use my e-mail address, ever.
(Said the person who had just once again received an e-mail, even acknowledging its source, claiming that he had given his permission for the e-mail address to be used for marketting purposes, when he had done nothing of the sort.)
Well, the moral of the story, boys and girls, is that you shouldn't trust information you find on-line if you can't verify the source as someone you trust. Simple as that, really...
As with many (all?) other skills, I think two things probably dominate developer ability:
Please note the key distinction there: one of these factors relates to a developer's potential, the other to what he can actually achieve in reality.
To determine a good strategy for building a team of developers, you then have to consider the relative work rates of developers of different abilities, and the nature of the work. For example, most code is developed from relatively straightforward design and programming tasks, but often you have small areas that require much more skill to design and implement effectively. These areas require a more able developer/team, but OTOH we also know that such people can be anything up to 10x as productive as a "typical" developer on the more mundane work. Of course, employing such people also costs rather more.
So what does this suggest about our choice of programming language? Well, if your development task is going to require any complex design or implementation work, you're going to need a sufficient number of top end people to do it, and you're going to need suitably powerful and flexible tools to help them.
For the remainder of the work, highly skilled developers will still be happy using those powerful, flexible tools, but they may be in short supply, and chances are most of your team will be more average in ability, and thus more average in their ability to avoid mistakes. Thus you may need a tool that reduces the possibility or impact of those mistakes, even at the expense of some power and flexibility (which those developers will rarely if ever use anyway).
Strangely enough, this has always been one of the reasons I've liked C++ as a practical, real-world language. While it has plenty of theoretical flaws, it does combine both raw power and flexibility with a decent set of abstraction tools to keep routine development away from the most dangerous areas. You can have your top developers write subsystems using all the cunning tricks they need, but keep everyone else using only clearly defined interfaces. Given a little basic training (sadly a lacking commodity in the C++ programming world, but not beyond any competent manager to arrange -- this is the second factor above) the vast majority of "typical" developers can avoid the really dangerous programming practices, and take advantage of the neat stuff the top guys made for them. When those top guys have finished developing really neat stuff, they can just become super-efficient people doing the mundane stuff using the same tool.
Bottom line: for most real world projects, you need to judge a language by both what it's capable of when used by a really good guy and how well it looks after Joe Developer. If one language isn't enough to do both and your project needs them, maybe you need more than one language and some good glue, but that's a whole different topic. :-)
Do you have any idea how much that costs around this time of year?
I'm not convinced that's true at all. I think some governments are moving to Open Source because (a) it's cheaper, and (b) it doesn't involve vendor lock-in to a corp with a history of sharp pricing policies.
I rather suspect that any philosophical or moral reasons to support Open Source are utterly lost on most of the governments who might adopt it, and that the chances of those governments -- who are doing this to save money, and probably for no other reason -- spending a fortune employing skilled software developers and QA people to vet the code they're using and future-proof themselves is rather small.
And Linux geeks never pride themselves on rebuilding everything from the kernel up using gcc, and even if they did do that, which they don't, they'd always download an independent C compiler to build gcc first, of course... ;-)
But how do you know the tests are all correct on a system of that scale? For that matter, how do you know that your requirements weren't contradictory in some small way, so that even though the tests reflect them perfectly in isolation, there are still gaps that create problems in the real world?
The point is that getting the requirements bullet-proof for a large, complex system is hard. Creating a flawless test and verification system for such a system is hard. And then implementing perfect, bug-free code using those tests is hard. Human error is possible at all levels, and no matter how hard you try, there is always a chance of that happening. No doubt good design, skilled developers doing the implementation, and careful review processes all help. It's just a matter of how much time you invest to reduce the chances, given that you get diminishing returns the closer to bullet-proof you get.
But if cost were all that mattered, open source wouldn't have a prayer, because the level of financial investment in it is nowhere near what the big commercial groups put into their closed source offerings. Even big names like IBM and Sun, who contribute significantly to the open source world, aren't investing as much as Bill's or Larry's pocket change. So there must be more to it than simple finance.
I think we need a new meta-mod option for that (+1, Informative) moderation:
This post was:
OK, since the standard CSS Zen Garden link has come up, I'll post the standard caveats: the content for that site is marked up much more than any "typical" web site, in order to provide maximum flexibility for the stylesheet designers; also, a lot of the really nice effects are actually based on images and not CSS. It's a great demonstration of what the technology can do. It's a lousy demonstration of what the technology can do in the real world.
Now go look at the site, keep it in perspective, and be impressed. :-)
I've been following WPDFD for years, and have used at least the last five versions of Moz on Windoze. I haven't read this month's editorial with Moz -- I'm using IE at work -- but I've never seen such a problem before, and Joe's always been pretty careful about standards compliance, cross-browser support, etc.
He does try new things occasionally, so if there's a glitch this month, mail him and tell him and he'll almost certainly look into it; I've contacted him a couple of times and always had at least a "Thanks for the feedback, I'll look into it" type of reply. I certainly wouldn't accuse him of being IE-centric, though; quite the contrary, in fact.
Um... Nope. Firstly, I'm on dial-up, so it changes dynamically. Secondly, it wouldn't do you any good, because my (non-Microsoft) firewall will tell you no-one's home anyway if I haven't talked to you first. Thirdly, I have looked into all the updates, and installed those that would apply to me; if I haven't installed it, it won't do you any good to attack me with it anyway.
This is kinda my point: now every time I visit Windows Update, I'm bombarded with "critical" updates which, for me, are nothing of the sort. Then I'm likely to miss the one really important one and get screwed.
They're suffering from a buffer overrun vulnerability. There is absolutely no excuse for that; basic safe coding practices and elementary training should render such things nigh-on impossible, even in a so-called unsafe language such as C++. Draw your own conclusions.
Not that it much matters, of course. I just looked at Windows Update, which currently reports 16 "critical" updates I haven't downloaded for my Windows XP box. Most of them appear to be completely irrelevant to me: I don't use the programs in question, nor have my system set up in such a way that the vulnerability would affect me in the first place. More to the point, I'm on dial-up, with a quota of hours on-line each month, and there's no way I'm going to waste vast amounts of that allowance downloading irrelevant "critical" patches. The rating has become meaningless, like so many alerts in the security industry, because those with all day to peruse the relevant mailing lists cry "Disaster!" at the drop of the hat, and poor Joe User has no idea whether it's really worth downloading or not.
Still, the answer appears to be "not" for me. Windows Update has just told me that it's encountered an (unspecified) error and can't continue to download those update I saw on the critical list that might actually affect me anyway...
I think that's probably a personal taste question today.
For me, I don't usually bother to print out long pages and I'm quite happy to read extended documents on my screen. Then again, I've grown up with computers all my life, and my screen is high quality and well-configured for good readability: sensible resolution, very high refresh rate, screen-optimised fonts in comfortable sizes with anti-aliasing, etc.
However, the research shows that most people taken from across the population as a whole still read much faster (around 1/3-1/2 as fast again, typically) from paper than from a computer screen. AFAIK, no-one has yet established whether that's down to the innately superior qualities of paper over backlit screens, poor configuration of most people's screens, the "what you're used to" effect, or just plain, old-fashioned personal taste.
Incidentally, I do find some documents much easier to read on-screen than others. Using well-hinted fonts like Verdana and Georgia really helps with web page reading ease, for example. On web sites or downloaded reports with nasty formatting, I do still fall back on printing the thing out occasionally, and probably would do so more often but for the lousy printing capabilities of nearly every major web browser.