I appreciate the reply, but you still seem to be making the mistake of assuming that the rest of us haven't tried your approach and don't know what we're talking about. Please understand that you are not the only conscientious programmer on the planet, nor are the ideas you advocate particularly original.
As I mentioned, the project I work on has thousands of automated tests. We write code in small chunks, and run the tests before releasing it. We also have a clear idea of what we're aiming for, courtesy of the design docs, we freely bring in fellow developers for second opinions if anything is looking doubtful, etc.
And we still get bugs.
What your post says to me is that you have defined a project that passes all of your tests to be bug-free. That's one possible definition, but it's only viable if you can define a test suite that truly enumerates every single possible action your program will ever have to take. Otherwise, you don't know that it's bug free, you just know that you haven't found any bugs yet.
Now, perhaps you're lucky enough to work in a field where such a test suite is possible. (What field do you work in, BTW?) Unfortunately, in my field it is trivially provable that you can't enumerate all of the possible inputs into our programs, and therefore you can't construct a set of tests to verify that the program always behaves correctly for all inputs. All you can do is try to have a reasonably comprehensive and representative sample of inputs, and use it as another tool in the correctness toolbox. Whether the program is actually correct depends on the rules specified in the requirements, which cannot be universally tested in a finite amount of time.
I frequently argue against excessive commenting and overly verbose languages, but for a quite different reason: too many redundant comments obscure those that really matter.
Which brings me to the final point: if a block of code is complex enough to need 1) a comment, and 2) a big comment to explain its inner workings, then you probably should refactor and simplify.
Which may or may not be possible. Not every algorithm is as trivial as a binary search or heap sort.
I've read all the other replies to this comment at the time of writing, and it's a fascinating discussion. Initially I thought you were just a troll, given that you claim to have produced completely bug-free projects and never to use comments, but now I think you've just had a little too much of the agile kool-aid, so I'll address some recurring points one by one.
On the trustworthiness of documentation (comments, paper or otherwise): no, you shouldn't absolutely trust them above all else. The final authority about what is happening is always the code. But if your documentation is any good at all, it's not the sort of thing that you refer to last, it's the sort of thing you refer to first. The documentation isn't the implementation, it's just a map of it, telling you what should be happening. Comments are the guidebook, highlighting the major attractions as you reach them and pointing out the subtleties that aren't apparent at first.
The most successful projects I've worked on have relatively little documentation, but it's well-written and useful. My current project, for example, has perhaps 200,000 lines of code. We have maybe 20-30 reference documents, each electronic and running only to a handful of pages, describing the overall design of the major subsystems and broadly speaking how they're intended to interact. The implementation speaks for itself, with explicit comments generally reserved for things like dividing up longer functions into logical sections, citing references that describe how the algorithm works (from our own documentation or otherwise), or clarifying intent on the odd occasion that the code isn't completely self-documenting. Notice that none of these things, except possibly the last, are likely to need amending just because you change the code.
You also seem to be arguing that it is unnecessary to maintain any sort of coherent overall design in an "agile" project, because your automated tests guarantee correctness. Sorry, but I think you're seriously misguided on both counts.
Automated tests are a useful mechanism for increasing reliability, but they're no substitute for a logical design, code review, or any of the other things that contribute to code quality. Unless your tests cover every code path with every conceivable set of inputs, they simply can't do that. My current project has an automated test suite that runs to 1,000s of tests, and yes, they're very useful for spotting major errors and regressions, but they still don't catch anything like all the bugs. No test suite for a large scale application ever has 100% coverage. And even if the test suite does pass in its entirety, it's no guarantee that you got the answer the way you intended and all your code is working. Two wrongs do make a right, if you incorrectly multiplied by -1 twice.
As for the presence or otherwise of an over-arching design, what you say is true: your code and tests are indeed guaranteed to give you the results your tests say you will get for as long as the tests pass. Of course, that doesn't mean that you can easily extend, modify or reuse that code. In fact, my experience of projects developed with the methodology you describe is that they're written very quickly, but rapidly become almost unmaintainable; someone will find a bug that your tests didn't, and you'll dutifully write a new test, and then it will take you a week to refactor this and elevate that until you can get the test to pass without breaking anything else. The guys who had a carefully planned, well-maintained and systematic design would probably have fixed that bug in five minutes, and without breaking anything else, because the problem would have been localised, easy to track down, and unable to adversely affect other areas of the system.
Speaking of code reuse, I notice that you're very keen not to bring context into things. I hate to break this to you, but code without context is meaningless, no matter how "reusable" it may be. When context starts to interfere with your reality, a lot of
I think we're talking about entirely different things here. The UK on-line filing system that I'm aware of is essentially just an electronic application form for a small claims court action -- something you can do exactly the same in meatspace, but usually saving the hassle of physically going to court over a relatively minor grievance.
I occasionally use the toolbar for open/save/save all (particularly the latter) if I happen to be shifting things around with the mouse already. I also use the various find tools quite frequently, again if I happen to be using the mouse at the time. I can't say I ever use much else on the toolbar, and I remove things like the clipboard stuff as soon as I install VS.
As for the panels thing, yes, you certainly can turn most of them off. I have most set to auto-hide during normal editing. However, if you're doing reasonably thorough investigation so you have a couple of windows open showing find results, the solution explorer, etc. then it adds up fast. More to the point, if you're debugging then you might well want several of the windows open simultaneously as well as the code view; I use the call stack, several of the variable examination windows, breakpoints, and more quite routinely, and often in combination.
The point isn't what fills your view. On the contrary, using too large a monitor can be dangerous. You have to keep turning your head to see the outer areas, which can lead to all sorts of problems if you're maintaining a funny angle in the neck for extended periods. If you're using a very wide window, you may also have to scan long lines of text, which again can cause discomfort quickly and long-term problems.
In the "What resolution should I target my webpages to?" post on "Ask Slashdot", it seems that a lot of people run all of their prgrams maximized. Why?
Because:
it makes the positions of widgets predictable, so you can interact with your software much faster using a mouse once you learn where things are
using the physical limits of screen edges has advantages for usability, e.g., I know that I can throw my mouse point to top-right and click and I'll get the close button for the current window
using non-maximised windows adds even more window dressing
it's annoying if you keep accidentally moving or resizing a window, e.g., when trying to select text near the end of a line in an editor
personally, I find overlapping windows to be confusing and unhelpful, transparency effects to be really distracting
switching the active window based on where the mouse pointer is on most UNIX systems rates among my top-ten most annoying UI mistakes ever
and that's just off the top of my head.
As another poster mentioned, a window manager that could let you have some of these advantages while using a non-maximised window would be a great help, but I know of no platform today that will, e.g., slow the mouse down as it nears the edge of a window to emulate the hard edge of the screen. It would be interesting to measure the usabilty of such features, but intuitively I'd guess it would help a lot once people got used to it.
FWIW, I've been looking into buying a widescreen TV recently, and the usual recommendation seems to be that you want to sit about 3x the screen diagonal away (i.e., about 10-11' away for your screen). My more responsible friends and other half have talked me out of buying a stunning Sagem 45" DLP TV on this basis; while the image is fantastic and wold be great for movie nights, it's simply too big to fit in my lounge, and something more modest like a 32" LCD is a much better fit.
I know you created the site (CmdrTaco), so all much respect goes out to you and this rather large accomplishment, but lately you've been posting lots of dupes and fluff like this... what's going on?
There's not that much exciting stuff happening at the bleeding edge this time of year, so they're spending more editorial space on general interest issues where formerly bleeding edge things are going mainstream, which might be of interest to anyone looking to buy in the near future?
I'm guessing it's a combination of native resolution and poor support in OSes for high resolution displays. On a typical machine today, most OS widgets will be pretty tiny on something like a 17" TFT running at 1600x1200, and I'm not sure any of the big name OSes has yet reached the point where simple things like icons and widgets scale nicely (and don't even mention fonts and dialog box layouts). If you're using a CRT, this isn't such a problem, because CRTs can scale to different resolutions with relatively little loss of image quality, so you can always use high res for detail work and switch to a lower resolution for other things. On TFTs, however, using anything other than the native resolution typically results in a dramatic reduction in image quality, to the point where most users would rather have a lower, native resolution than a higher but poorly scaled one.
We've had a few problems at work with lighting issues, as several of us people are quite sensitive either to typical office lighting or to particular types of monitor.
At the risk of asking the obvious, have you tried rearranging your workspace? I have quite a nice Dell 19" CRT at work, which was almost unusable when I first started due to screen flicker. (I'm the kind of guy who can tell the difference between 85Hz and 100Hz, never mind 75 and 85.) I have two desks in an L-shape, and shifting the PC to the other desk so the monitor was in a different position fixed everything. It later turned out that there's a fairly major power source on the floor below, which we figure might have been interfering before, so the solution is simple but effective.
We also tend to leave the overhead strip lights off, and use uplighters and desk lamps instead. It's not as bright, but it's also not susceptible to the kinds of flickering effects you can get from typical office lighting, and doesn't cause problems for the guys who have overhead lights just behind them that can glare off the screen.
Despite dealing with an unusally high number of vision-sensitive guys at work, I think you're the first person I've ever come across who actually prefers CRTs to a good flat panel unit, so I wonder whether something simple like the suggestions above might allow you to benefit from a flat panel. YMMV, of course, but maybe that'll help.
I see someone's already mentioned the issue of dead pixels, particularly in light of other vendors offering comparable screen space with no-dead-pixel guarantees. I think this is the example of a more general problem: no matter how fantastic a large screen like this may be, it's a single point of failure. Apple's cinema displays look gorgeous... until the infamous back light failure kicks in, and Apple's equally infamous denials/poor customer support leave you with a very expensive piece of useless hardware that's almost beyond economic repair. (I'm told the situation with that particular example may have improved, but there's nothing to stop another problem of similar magnitude occurring instead.)
I've never actually used a monitor this big, but I'm guessing it's of most value to people who are displaying large images with lots of screen-wasting toolboxes etc. (or using Visual Studio, which seems to waste well over 50% of the available screen space on things other than code these days). In that case, given the near-universal support for multiple desktops/monitors with modern graphics cards and drivers, choosing two smaller monitors seem like a safer and more flexible option to me, not to mention probably cheaper and more upgrade-friendly.
I suppose it could be worth it to professional staff working on double-page spreads who can see a spread at full size, in which case having some competition for Apple's 30" cinema display must surely be good for the market.
Ideally, you could program in a manner that provides the most understandable and modifable (ie, well-factored) implementation of the behavior, and leave low-level tuning of size/speed up to the compiler (possibly with hints in compiler switches or pragmas).
Sure. I don't see how anyone could reasonably argue with that, other things being equal. But the problem is that other things aren't equal: as you say, the problem isn't solvable in general. I'm aware of no language in use today that achieves anything like the performance you can get with C++ while still isolating the programmer from the kind of decision we're talking about. In fact, I'm not sure you can ever truly achieve that isolation, because any artist or craftsman will achieve better results if he has more understanding of his tools and techniques, and programmers are no exception.
In any case, I'll respectfully disagree with your example. My personal view is that using templates and using class-based polymorphism are quite orthogonal techniques in C++, and suitable for solving rather different types of problem. While I suppose you could implement some concepts either way, I've always found the decision about which to use to be easy, usually based on whether I want to consider the static or dynamic type of the object I'm dealing with -- something that is inherently related to the big picture design of the program, and unlikely to change later on. I honestly can't think of a time I've wished I could change my mind later, so IME any theoretical lack of flexibility doesn't really make any difference in practice in this case.
You seem to have some specific example(s) in mind here. Perhaps you could give us more of an idea of what they are?
If the compiler were able to consider all source files when producing an executable (rather than producing multiple object files at intermediate stages) then it would have equal type knowledge with both approaches.
In fairness, C++ implementations increasingly do look at the entire code base when performing optimisations. But the problem with languages with RTTI-based generics, Java for example, is that many of them can't examine the whole code base at compilation time, because they have dynamic loading behaviour that means they can't tell whether they've got everything or not at compile-time.
I've always assumed this is why JIT compilation at load-time makes such a huge difference to performance with some languages: they're not just compiling to native code rather than interpreting pseudo-code; they're also able to see pretty much the whole code base at once for the first time and can optimise accordingly.
The thing that really annoys me about some DVDs today is that you can't skip certain protected content on many players. There's simply no reason that's necessary. Sure, put the studio logo up or whatever by default when I first put it in the drive, but don't disable the damn menu and skip forward keys.
I haven't yet encountered the rumoured 15-minute ones (I've heard several claims about trailers on recent Disney DVDs being this bad) but I've certainly run into annoying legal notices in multiple languages that can take a minute to play through every time you load a disc. Can anyone tell me which distributers/specific movies do this now, and/or any reliable information about what we can expect here from Blu-Ray and/or HD-DVD?
On a related note, does anyone know whether they've abandoned the whole multi-region thing with either or both of the new standards?
I bought one of the 9700 Pros a few years back, and was very disappointed. It turned out that there was a compatibility problem with my motherboard, which meant the power supply wasn't in spec somewhere and led to all sorts of instability.
To their credit, Crucial honoured their motherboard compatibility guarantee even though it was something like 7-8 months after I bought the card that the incompatibility became widely known. They let me trade the card up to a new 9800 Pro, which has a much better auxiliary power input, for only the difference in price (which was almost nothing). The latter card has had no problems and remains in my PC to this day.
That was the only time I ever bought a near-top-end graphics card with a new PC, since at the time a couple of games I was expecting to want were due out very shortly and expected to need the extra power immediately. Ah, well. I'll be smarter than to believe anyone's anticipated release dates next time...
if they didn't get the VC before they started, they wasted a humongous amount of time/effort/money in the months they've been "developing" the game.
That seems to be giving too much credit to VC. There is nothing that says you have to fund a start-up with the help of venture capitalists, and indeed it's usually about the worst possible way to get funding because of the strings that come attached.
The problem, it seems to me, is if you think you're going to be able to fund our own start-up on a reasonable business plan but then something goes wrong, and you haven't got any connections to pull in additional resources and make good on your efforts to date.
While it's certainly true that you can find most or all of the material in books like this on-line, I think there's still a solid place for books in the programmer's world. Most of the on-line information is poorly organised, poorly written, poorly edited and often of dubious accuracy, and that's assuming that you can rely on it to stay in the same place and not to change anyway.
MSDN is a prime example: it used to be a great resource, but these days it's got so much bad content and so little organisation that I no longer even bother looking at it when I need to know something, or reading the web pages for the specific programming tools and languages I use. Most of the good articles I once bookmarked now give back 404s and redirect to some generic Microsoft ad for something irrelevant, on a page with hundreds of links to other equally irrelevant things.
The web generally suffers from information overload in programming-related fields. If you want a clear, concise, well-structured, and comprehensive look at a subject, a good book is still hard to beat.
If I may interrupt for a moment, I'd just like to pick up on one of the points you made:
For example, the code for sorting a list of integers in C++ may be comparable in size to the C one, but this is not the case if one is sorting various different types via templates; here, the fact that the compiler will generate what amounts to an entirely separate set of routines for each type can quickly bloat C++ code far beyond that of its C equivalent, and that may not be something that people working in (for example) embedded systems can afford.
While it's clearly true that using templates with many types can increase the size of your code, I think the problem is overstated.
Consider that the size of an executable file can easily run to several megabytes these days on any of the mainstream platforms. (That in itself is a pretty damning indictment of the state of the art, but that's another matter.) Even if I instantiate a fairly substantial class template and several of its member functions for a dozen different types, the extra compiled code that results is unlikely to run to more than a few kilobytes, if that. If we're talking about something like a simple sort function, the extra is probably measured in hundreds of bytes at most.
Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller. However, we should remember that the RTTI itself imposes overheads, and there's far less scope for deep optimisations without the exact type knowledge you have with templates, so the ratio certainly won't be N:1 where N is the number of types over which our template was instantiated.
On the flip side, of course, template code can often be much faster than RTTI-based generics, and there are all sorts of tricks for reducing the number of separate instantiations required without giving up those performance benefits if the context is right.
As you say, in a field like embedded software, it's possible that the extra code size could make a real difference, but in most fields, I suspect it's negligible.
Is there some reason you can't use std::vector<char> array(size); for your purposes? The performance overhead would be negligible for just about any purpose, and it avoids putting large objects on what could be quite a limited amount of stack as well.
Big integers would be useful, though, as would fixed point arithmetic.
As a linux kernel hacker said: "a language where '+' is allowed to do something that it's not really '+' is not a good choice for a kernel"
Then again, a programmer who would define '+' to mean anything other than the natural sum of its operands probably isn't a good choice for a kernel programmer, either.
Slashdot Mirror
I appreciate the reply, but you still seem to be making the mistake of assuming that the rest of us haven't tried your approach and don't know what we're talking about. Please understand that you are not the only conscientious programmer on the planet, nor are the ideas you advocate particularly original.
As I mentioned, the project I work on has thousands of automated tests. We write code in small chunks, and run the tests before releasing it. We also have a clear idea of what we're aiming for, courtesy of the design docs, we freely bring in fellow developers for second opinions if anything is looking doubtful, etc.
And we still get bugs.
What your post says to me is that you have defined a project that passes all of your tests to be bug-free. That's one possible definition, but it's only viable if you can define a test suite that truly enumerates every single possible action your program will ever have to take. Otherwise, you don't know that it's bug free, you just know that you haven't found any bugs yet.
Now, perhaps you're lucky enough to work in a field where such a test suite is possible. (What field do you work in, BTW?) Unfortunately, in my field it is trivially provable that you can't enumerate all of the possible inputs into our programs, and therefore you can't construct a set of tests to verify that the program always behaves correctly for all inputs. All you can do is try to have a reasonably comprehensive and representative sample of inputs, and use it as another tool in the correctness toolbox. Whether the program is actually correct depends on the rules specified in the requirements, which cannot be universally tested in a finite amount of time.
I frequently argue against excessive commenting and overly verbose languages, but for a quite different reason: too many redundant comments obscure those that really matter.
Which may or may not be possible. Not every algorithm is as trivial as a binary search or heap sort.
I've read all the other replies to this comment at the time of writing, and it's a fascinating discussion. Initially I thought you were just a troll, given that you claim to have produced completely bug-free projects and never to use comments, but now I think you've just had a little too much of the agile kool-aid, so I'll address some recurring points one by one.
On the trustworthiness of documentation (comments, paper or otherwise): no, you shouldn't absolutely trust them above all else. The final authority about what is happening is always the code. But if your documentation is any good at all, it's not the sort of thing that you refer to last, it's the sort of thing you refer to first. The documentation isn't the implementation, it's just a map of it, telling you what should be happening. Comments are the guidebook, highlighting the major attractions as you reach them and pointing out the subtleties that aren't apparent at first.
The most successful projects I've worked on have relatively little documentation, but it's well-written and useful. My current project, for example, has perhaps 200,000 lines of code. We have maybe 20-30 reference documents, each electronic and running only to a handful of pages, describing the overall design of the major subsystems and broadly speaking how they're intended to interact. The implementation speaks for itself, with explicit comments generally reserved for things like dividing up longer functions into logical sections, citing references that describe how the algorithm works (from our own documentation or otherwise), or clarifying intent on the odd occasion that the code isn't completely self-documenting. Notice that none of these things, except possibly the last, are likely to need amending just because you change the code.
You also seem to be arguing that it is unnecessary to maintain any sort of coherent overall design in an "agile" project, because your automated tests guarantee correctness. Sorry, but I think you're seriously misguided on both counts.
Automated tests are a useful mechanism for increasing reliability, but they're no substitute for a logical design, code review, or any of the other things that contribute to code quality. Unless your tests cover every code path with every conceivable set of inputs, they simply can't do that. My current project has an automated test suite that runs to 1,000s of tests, and yes, they're very useful for spotting major errors and regressions, but they still don't catch anything like all the bugs. No test suite for a large scale application ever has 100% coverage. And even if the test suite does pass in its entirety, it's no guarantee that you got the answer the way you intended and all your code is working. Two wrongs do make a right, if you incorrectly multiplied by -1 twice.
As for the presence or otherwise of an over-arching design, what you say is true: your code and tests are indeed guaranteed to give you the results your tests say you will get for as long as the tests pass. Of course, that doesn't mean that you can easily extend, modify or reuse that code. In fact, my experience of projects developed with the methodology you describe is that they're written very quickly, but rapidly become almost unmaintainable; someone will find a bug that your tests didn't, and you'll dutifully write a new test, and then it will take you a week to refactor this and elevate that until you can get the test to pass without breaking anything else. The guys who had a carefully planned, well-maintained and systematic design would probably have fixed that bug in five minutes, and without breaking anything else, because the problem would have been localised, easy to track down, and unable to adversely affect other areas of the system.
Speaking of code reuse, I notice that you're very keen not to bring context into things. I hate to break this to you, but code without context is meaningless, no matter how "reusable" it may be. When context starts to interfere with your reality, a lot of
I think we're talking about entirely different things here. The UK on-line filing system that I'm aware of is essentially just an electronic application form for a small claims court action -- something you can do exactly the same in meatspace, but usually saving the hassle of physically going to court over a relatively minor grievance.
I occasionally use the toolbar for open/save/save all (particularly the latter) if I happen to be shifting things around with the mouse already. I also use the various find tools quite frequently, again if I happen to be using the mouse at the time. I can't say I ever use much else on the toolbar, and I remove things like the clipboard stuff as soon as I install VS.
As for the panels thing, yes, you certainly can turn most of them off. I have most set to auto-hide during normal editing. However, if you're doing reasonably thorough investigation so you have a couple of windows open showing find results, the solution explorer, etc. then it adds up fast. More to the point, if you're debugging then you might well want several of the windows open simultaneously as well as the code view; I use the call stack, several of the variable examination windows, breakpoints, and more quite routinely, and often in combination.
The point isn't what fills your view. On the contrary, using too large a monitor can be dangerous. You have to keep turning your head to see the outer areas, which can lead to all sorts of problems if you're maintaining a funny angle in the neck for extended periods. If you're using a very wide window, you may also have to scan long lines of text, which again can cause discomfort quickly and long-term problems.
Because:
- it makes the positions of widgets predictable, so you can interact with your software much faster using a mouse once you learn where things are
- using the physical limits of screen edges has advantages for usability, e.g., I know that I can throw my mouse point to top-right and click and I'll get the close button for the current window
- using non-maximised windows adds even more window dressing
- it's annoying if you keep accidentally moving or resizing a window, e.g., when trying to select text near the end of a line in an editor
- personally, I find overlapping windows to be confusing and unhelpful, transparency effects to be really distracting
- switching the active window based on where the mouse pointer is on most UNIX systems rates among my top-ten most annoying UI mistakes ever
and that's just off the top of my head.As another poster mentioned, a window manager that could let you have some of these advantages while using a non-maximised window would be a great help, but I know of no platform today that will, e.g., slow the mouse down as it nears the edge of a window to emulate the hard edge of the screen. It would be interesting to measure the usabilty of such features, but intuitively I'd guess it would help a lot once people got used to it.
FWIW, I've been looking into buying a widescreen TV recently, and the usual recommendation seems to be that you want to sit about 3x the screen diagonal away (i.e., about 10-11' away for your screen). My more responsible friends and other half have talked me out of buying a stunning Sagem 45" DLP TV on this basis; while the image is fantastic and wold be great for movie nights, it's simply too big to fit in my lounge, and something more modest like a 32" LCD is a much better fit.
There's not that much exciting stuff happening at the bleeding edge this time of year, so they're spending more editorial space on general interest issues where formerly bleeding edge things are going mainstream, which might be of interest to anyone looking to buy in the near future?
I'm guessing it's a combination of native resolution and poor support in OSes for high resolution displays. On a typical machine today, most OS widgets will be pretty tiny on something like a 17" TFT running at 1600x1200, and I'm not sure any of the big name OSes has yet reached the point where simple things like icons and widgets scale nicely (and don't even mention fonts and dialog box layouts). If you're using a CRT, this isn't such a problem, because CRTs can scale to different resolutions with relatively little loss of image quality, so you can always use high res for detail work and switch to a lower resolution for other things. On TFTs, however, using anything other than the native resolution typically results in a dramatic reduction in image quality, to the point where most users would rather have a lower, native resolution than a higher but poorly scaled one.
We've had a few problems at work with lighting issues, as several of us people are quite sensitive either to typical office lighting or to particular types of monitor.
At the risk of asking the obvious, have you tried rearranging your workspace? I have quite a nice Dell 19" CRT at work, which was almost unusable when I first started due to screen flicker. (I'm the kind of guy who can tell the difference between 85Hz and 100Hz, never mind 75 and 85.) I have two desks in an L-shape, and shifting the PC to the other desk so the monitor was in a different position fixed everything. It later turned out that there's a fairly major power source on the floor below, which we figure might have been interfering before, so the solution is simple but effective.
We also tend to leave the overhead strip lights off, and use uplighters and desk lamps instead. It's not as bright, but it's also not susceptible to the kinds of flickering effects you can get from typical office lighting, and doesn't cause problems for the guys who have overhead lights just behind them that can glare off the screen.
Despite dealing with an unusally high number of vision-sensitive guys at work, I think you're the first person I've ever come across who actually prefers CRTs to a good flat panel unit, so I wonder whether something simple like the suggestions above might allow you to benefit from a flat panel. YMMV, of course, but maybe that'll help.
I see someone's already mentioned the issue of dead pixels, particularly in light of other vendors offering comparable screen space with no-dead-pixel guarantees. I think this is the example of a more general problem: no matter how fantastic a large screen like this may be, it's a single point of failure. Apple's cinema displays look gorgeous... until the infamous back light failure kicks in, and Apple's equally infamous denials/poor customer support leave you with a very expensive piece of useless hardware that's almost beyond economic repair. (I'm told the situation with that particular example may have improved, but there's nothing to stop another problem of similar magnitude occurring instead.)
I've never actually used a monitor this big, but I'm guessing it's of most value to people who are displaying large images with lots of screen-wasting toolboxes etc. (or using Visual Studio, which seems to waste well over 50% of the available screen space on things other than code these days). In that case, given the near-universal support for multiple desktops/monitors with modern graphics cards and drivers, choosing two smaller monitors seem like a safer and more flexible option to me, not to mention probably cheaper and more upgrade-friendly.
I suppose it could be worth it to professional staff working on double-page spreads who can see a spread at full size, in which case having some competition for Apple's 30" cinema display must surely be good for the market.
Sure. I don't see how anyone could reasonably argue with that, other things being equal. But the problem is that other things aren't equal: as you say, the problem isn't solvable in general. I'm aware of no language in use today that achieves anything like the performance you can get with C++ while still isolating the programmer from the kind of decision we're talking about. In fact, I'm not sure you can ever truly achieve that isolation, because any artist or craftsman will achieve better results if he has more understanding of his tools and techniques, and programmers are no exception.
In any case, I'll respectfully disagree with your example. My personal view is that using templates and using class-based polymorphism are quite orthogonal techniques in C++, and suitable for solving rather different types of problem. While I suppose you could implement some concepts either way, I've always found the decision about which to use to be easy, usually based on whether I want to consider the static or dynamic type of the object I'm dealing with -- something that is inherently related to the big picture design of the program, and unlikely to change later on. I honestly can't think of a time I've wished I could change my mind later, so IME any theoretical lack of flexibility doesn't really make any difference in practice in this case.
You seem to have some specific example(s) in mind here. Perhaps you could give us more of an idea of what they are?
In fairness, C++ implementations increasingly do look at the entire code base when performing optimisations. But the problem with languages with RTTI-based generics, Java for example, is that many of them can't examine the whole code base at compilation time, because they have dynamic loading behaviour that means they can't tell whether they've got everything or not at compile-time.
I've always assumed this is why JIT compilation at load-time makes such a huge difference to performance with some languages: they're not just compiling to native code rather than interpreting pseudo-code; they're also able to see pretty much the whole code base at once for the first time and can optimise accordingly.
The thing that really annoys me about some DVDs today is that you can't skip certain protected content on many players. There's simply no reason that's necessary. Sure, put the studio logo up or whatever by default when I first put it in the drive, but don't disable the damn menu and skip forward keys.
I haven't yet encountered the rumoured 15-minute ones (I've heard several claims about trailers on recent Disney DVDs being this bad) but I've certainly run into annoying legal notices in multiple languages that can take a minute to play through every time you load a disc. Can anyone tell me which distributers/specific movies do this now, and/or any reliable information about what we can expect here from Blu-Ray and/or HD-DVD?
On a related note, does anyone know whether they've abandoned the whole multi-region thing with either or both of the new standards?
Warning: Prolonged exposure may cause cancer^Wviruses.
I bought one of the 9700 Pros a few years back, and was very disappointed. It turned out that there was a compatibility problem with my motherboard, which meant the power supply wasn't in spec somewhere and led to all sorts of instability.
To their credit, Crucial honoured their motherboard compatibility guarantee even though it was something like 7-8 months after I bought the card that the incompatibility became widely known. They let me trade the card up to a new 9800 Pro, which has a much better auxiliary power input, for only the difference in price (which was almost nothing). The latter card has had no problems and remains in my PC to this day.
That was the only time I ever bought a near-top-end graphics card with a new PC, since at the time a couple of games I was expecting to want were due out very shortly and expected to need the extra power immediately. Ah, well. I'll be smarter than to believe anyone's anticipated release dates next time...
That seems to be giving too much credit to VC. There is nothing that says you have to fund a start-up with the help of venture capitalists, and indeed it's usually about the worst possible way to get funding because of the strings that come attached.
The problem, it seems to me, is if you think you're going to be able to fund our own start-up on a reasonable business plan but then something goes wrong, and you haven't got any connections to pull in additional resources and make good on your efforts to date.
What la
Your entire army has been gibbed by L337-LPB-h8r's slow moving but obscenely powerful combat units
g?
Can't see your problem myself. :-)
While it's certainly true that you can find most or all of the material in books like this on-line, I think there's still a solid place for books in the programmer's world. Most of the on-line information is poorly organised, poorly written, poorly edited and often of dubious accuracy, and that's assuming that you can rely on it to stay in the same place and not to change anyway.
MSDN is a prime example: it used to be a great resource, but these days it's got so much bad content and so little organisation that I no longer even bother looking at it when I need to know something, or reading the web pages for the specific programming tools and languages I use. Most of the good articles I once bookmarked now give back 404s and redirect to some generic Microsoft ad for something irrelevant, on a page with hundreds of links to other equally irrelevant things.
The web generally suffers from information overload in programming-related fields. If you want a clear, concise, well-structured, and comprehensive look at a subject, a good book is still hard to beat.
If I may interrupt for a moment, I'd just like to pick up on one of the points you made:
While it's clearly true that using templates with many types can increase the size of your code, I think the problem is overstated.
Consider that the size of an executable file can easily run to several megabytes these days on any of the mainstream platforms. (That in itself is a pretty damning indictment of the state of the art, but that's another matter.) Even if I instantiate a fairly substantial class template and several of its member functions for a dozen different types, the extra compiled code that results is unlikely to run to more than a few kilobytes, if that. If we're talking about something like a simple sort function, the extra is probably measured in hundreds of bytes at most.
Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller. However, we should remember that the RTTI itself imposes overheads, and there's far less scope for deep optimisations without the exact type knowledge you have with templates, so the ratio certainly won't be N:1 where N is the number of types over which our template was instantiated.
On the flip side, of course, template code can often be much faster than RTTI-based generics, and there are all sorts of tricks for reducing the number of separate instantiations required without giving up those performance benefits if the context is right.
As you say, in a field like embedded software, it's possible that the extra code size could make a real difference, but in most fields, I suspect it's negligible.
Is there some reason you can't use std::vector<char> array(size); for your purposes? The performance overhead would be negligible for just about any purpose, and it avoids putting large objects on what could be quite a limited amount of stack as well.
Big integers would be useful, though, as would fixed point arithmetic.
Or even, for those of us who use overloaded operators like sensible people ;-)
customers[0].contacts["foo"].emailAddress[0]
True, but since we're talking about const data here, overwriting the end of the array isn't very likely, is it?
Then again, a programmer who would define '+' to mean anything other than the natural sum of its operands probably isn't a good choice for a kernel programmer, either.