Apple's cinema displays do appear to rock: I've seen the smaller sizes in real life, and the image quality is stunning. The larger, 30" unit, is no longer Mac-only either, so PC owners can stop lusting. I would have bought one myself, except...
Well, just search the web before you spend too much on one of these. You'll find a lot of people with the same fault, and basically a stonewall/hand-wringing from Apple and their dealerships described in most places. After reading the same horror story for the 20th time, I pretty much decided my money had better uses, no matter how good the display is (when it works).
Of course, if you can source one through a local supplier with a good, long-term warranty thrown in, it's a fantastic bit of kit.
Fair enough. I hope last weekend worked out better for you!
pdfTeX (and the thinking in Thanh's thesis) are among of the more impressive recent additions to the TeX world, to be sure, and very welcome for it. In a sense, I think they reinforce my point, though: in order to get the improved typography, pdfTeX completely breaks away from standard TeX fonts and DVI output, in favour of Type 1/TrueType fonts and PDF.
I'll concede the point about the Pro font variations. I know of no automatic way to switch between what are effectively separate fonts by only changing the size under OpenType. I'm not sure how much of a problem I think this is in practice; the Pro variations are effectively different typefaces, albeit ones with a very similar appearance. But fair enough, that is something you can adjust in TeX, whereas you can't do much more than glorified hinting with OpenType.
My laptop already does 1920x1200 on smaller screen, but I find that completely unusable. So I guess we're going to see an increase in popularity of larger screens in the next few years.
I think we'll see an increase in operating systems that can scale a UI properly first. There are certain natural limits on the useful size of a screen for most purposes, and high-end screens are already around that mark.
What kills current systems with high resolutions on (relatively) small screens is the number of UI features that become almost unusable. Windows will scale some fonts, for example, but not always reliably and many applications get their dialog boxes and such messed up. Icons are still 32x32 or 64x64 bitmaps. Web browsers won't automatically scale up images to match the text zoom.
This is improving -- the new generation stuff from most of the big players starts to address the problem -- and once some of the basics are fixed, higher resolution but mid-sized screens will become a lot more useful. Then you can banish all the toolbars to normal size somewhere, zoom everything else to a useful size, and get on with whatever useful stuff you wanted to do.:-)
What is Word meant to do?
on
Office 12 Exposed
·
· Score: 2, Insightful
[Word is] designed to make your content look as good as it can on the device you're printing to, not to make the content layout as designed on the printer you're printing to.
The thing is, I'm not sure that's true. Word's presentation of the written word is nowhere near the level of a decent DTP program, or something like TeX: things like paragraph justification, kerning and ligatures are naive or missing altogether, and this sort of thing sets quality typography apart from its amateur cousin. Most people wouldn't know that quality if you showed it to them with red rings round the changes, but they would still be affected by it as they read.
As others have noted around here, Word isn't really a page layout program, either. Again, its facilities are far surpassed by even fairly basic DTP packages. Try doing a two-page spread in Word with an image split across the seam.
You'd think a world-class word processor would be good for dealing with long documents, at least, but I was once told in an official Microsoft reply that this wasn't what Word was meant to do. (This was after submitting a bug report about Word repeatedly taking out the whole PC while dealing with a 300 page technical manual with fairly extensive but unexceptional use of numbered lists, section headings, and the like.) Even if it can handle larger documents these days, the cross-referencing, indexing and such are nowhere near the power of a system like TeX, and again I can't think of anything it can do that a decent DTP package couldn't.
Word can produce basic web pages, but without the quality of HTML and site design/structure facilities routinely offered by more specialised web editors.
So it goes on. Word processors today are very much a jack of all trades, yet master of few. About the only thing they have going for them is relative ease of use and customisability. Even for ease of use, similar "hybrid" packages like Apple's Pages are overtaking the more overweight beasts, and I know few places that really use the kind of customisability today that Word is theoretically capable of offering.
Faced with this sort of position, it's hard to see how Microsoft can hold off the challenges against its flagship application from all sides for long based on pretty colours alone. Revamp the layout engine to produce decent typography (particularly the neat touches that require no user intervention), sort out the styles, templates and programming facilities so people can actually make good use of them, fix up the support for formal, structured documents to provide the best indexing, cross-referencing and numbering facilities available, and then we'll be getting somewhere.
What is really interesting, however, is that they fundamentally changed the usability of the application - the manner in which toolbars look and layout has changed, as have many of the other user-interaction elements.
They've fundamentally changed the interface, sure. Whether they've changed the usability, and if so whether it's better or worse in the new version, we'll only find out when real users start to play with it.
Personally, I think it's a shame they have changed so much and yet so little. For example, style-based formatting really should be the norm. They could have had a section of the toolbar for font formatting that had some sort of drop down for choosing a character style, and a single button to go to the full direct formatting dialog, and nothing else. But no, while they're willing to make the interface look and probably work completely differently, they're not willing to give up their trademark over-crowded and under-usable toolbars that waste half the screen space.
Your 35-40 hours thing is simplistic, though. It's completely down to the nature of the work.
Actually, according to the research, it usually isn't. For example, coders and manual workers both come in around that level. So do managers, incidentally, although overconfidence in their abilities while tired is widely noted.
Of course it's not a case of 40 hours or nothing works. As I noted before, gains have been seen up to around the 60 hour mark in some studies, though the extra hours offer diminishing returns, and the extra hours are much more productive if only worked occasionally rather than week in, week out. If they start affecting employees' ability to get a proper night's sleep, that's an instant performance killer, though, even in the short term. Managers also have to be wary of morale damage from expecting staff to spend more time on work and therefore less time on life. A discontent workforce is also an instant performance killer.
On the flip side, I remember reading a study about (IIRC) a software company, which was trying a 30 hour week and seeing surprising success. They found that their staff, working around 9-3 each day, had time outside working hours to do the shopping, visit the bank or pick up the kids from school. Consequently, they were much less distracted during the time they were at work, and their concentration and performance improved.
Really, you should read the research. BTW, I didn't mention that article because of the usual Guardian stance, but simply because it was one of the first links I turned up that provided several sources supporting my claims. I prefer not to post that sort of thing for a critical audience without at least some immediately accessible information to back it up, but Google is your friend.
Every programming language I know of is universal, and therefore interchangeable.
Then I'm sorry, but you are woefully unqualified to be in this discussion. Either that, or you're picking nits over something like Turing completeness while ignoring the point of the discussion.
If a language can't be learned in a day by anyone who understands algorithms (algorithms are language independent, in case anyone has forgotten that), then the language may be bad. Perhaps it has too many tricks and traps,
Algorithms are not language independent, or rather the choice of which to use and the way you implement it aren't. How do you implement an in-place quicksort in a pure functional language, exactly? How do you implement an algorithm that uses lazy evaluation in C? You first have to convert your algorithm into a form that makes sense in your target language, or choose a different algorithm.
I understand what you're saying, but you're seriously underestimating the impact your choice of programming language makes.
Don't confuse learning a language with deep knowledge of every function of the libraries of the day.
I'm not. But I think you're confusing learning a language with learning some basic syntax. The latter can be done in a day, but it's only 10% (at most) of what matters apart from the libraries.
I think you need a more realistic perspective before you rant like that.
For a start, I challenge your assumption about "most successful people". It's well-documented that working long hours for extended periods provides rapidly diminishing returns, and ultimately becomes counter-productive as the damage caused by mistakes made while tired takes longer to undo later on.
About 35-40 hours is the most productive sustained hourly rate, and it's remarkably consistent across different industries and workers. You can get additional returns up to about 60 hours in short bursts, though they become less the higher the hours get. By about 80 hours, you're back to being only as productive as you were in the first 40 again as they additional 40 have cancelled out.
Go ahead and Google for this, or just try this article for a fairly representative comment. There are plenty of scientifically conducted studies, right back to Ford's observations about the guys building cars in his factory. The five-day working week came about in much the same way, BTW.
Next up, perhaps Mr Seventy Hours will be lazy rich in his 50s and living over there with a big house and car. The difference between us is that I will have lived for 50 years already when I get to my 50th birthday, and I won't die young from burn out.
You don't have to bust your butt to be rich but your damn well going find out it is the faster way of getting there.
Perhaps, but I'll take working smarter over working harder any day, and I bet I get there as fast as the butt-buster.
Frankly if the government over there is as much of a pain in the ass to deal with as it seems, I'd be thinking hard about just pulling the plug on them as a market.
Most of the rest of Europe is the same, since we're generally much more protective of our workforce than the US is. And the combined European market is vastly bigger than that of the US.
Maybe the management should demonstrate that at the end of the day, you can only jerk a company around so hard before they just take their ball and find somewhere else to play.
Please tell them to mind the door on their way out. I'm betting we could live without US megacorps and their associated mess a lot more than they could live without us.
Besides, dealing with labor laws in France is a royal pain. I met a family there for whom it was more profitable to be voluntarily unemployed and live off welfare than it was to get a real job. Guess who pays for it? Yep, the poor folks who actually work for a living.
I'm afraid it's the same in the UK, too. We currently have something like two million people claiming disability allowance from the government, despite the fact that the vast majority of them are clearly perfectly capable of working for a living like the rest of us instead.
Now, if you'll excuse me, I have to go work for 12 more hours today, to pay for the trip to the dentist, since my current employer cut back health insurance.
Sorry, we caught you reading Slashdot while monitoring your communications. Please note that on page 347 of the employee handbook, it is clearly stated that privacy is a privilege that you do not have at any point in the day, because you're on salary so anything you do belongs to us. The bill for your use of company electrons in establishing the Internet connection will be arriving shortly. You no longer have any health insurance at all, because we're firing your ass without notice, any sort of severance package, or any guarantee of a reference. Armed security will be along in a moment to escort you from the building. Good luck finding new work to maintain your healthcare, but don't forget that you may not work for anyone else who can actually use your skills for the next year because of the anti-compete clauses in your contract, which will remain in force despite the termination of your employment. God bless America.
That's the thing -- they're not trying to be more productive. They're trying to be more happy.
Although since well-treated workers tend to be more productive anyway, that happiness has a convenient side effect.
(Before any pro-business fanatics start telling me how the US is the most productive nation in the world, please note that I measure productivity by how much useful stuff gets done/made. The only people who think a higher GDP is equivalent to a more productive society are bad economists.)
Anyone care to comment on MSVC's capabilities in the 64-bit arena?
Almost non-existent in 6, 7 (.Net 2002) and 7.1 (.Net 2003). We've switched some of our 64-bit test platforms at the office from using an SDK to using the beta of version 8 (VS 2005), which seems to be much better at targetting such a platform, but obviously it's unlikely you'll see the latest and greatest game today built with a compiler that's not due for release until 7 November...
you want a vocational system. CS is NOT like that, nor should it.
You should really read posts before you post a rant in reply. I have never claimed that CS should teach vocational skills; indeed, if you bothered to read any of my other posts in this thread properly, you'd see that I strongly disagree with that view.
I guarantee you that a CS grad will be productive in a totally alien language faster than some one who has exceptional training in one or two languages.
That depends on the CS grad. Someone who's good and knows the theory, whether formally or self-taught, will certainly pick up a lot of things faster. But you seem to be equating CS grads with someone in that position, which is a dubious claim in the industry today. I'd take an enthusiastic hacker who learned about this stuff on his own time over a top-flight CS grad who only chose that course because the career is well-paid any day.
I understand what you are saying, but we're talking about CS students/graduates that not only do they know one or two languages but also the underlying structure and concepts underneath a language.
That's not really true, though, is it? Sure, you'd hope a decent CS graduate would have some basic familiarity with various programming styles, and perhaps a brief introduction to an illustrative language or two. However, I've never encountered a full-length CS course that taught more than one common languages in the kind of detail I'd expect for a professional-grade programmer using that language. I don't even list most of the languages I studied during my CS course on my CV.
In the real world nobody will give a s**t whether you've taken numerical analysis.
Perhaps not if you drive a database, but they certainly will if you're working on any sort of scientific or engineering software. You can have the most trendy, pattern-based, OO design you like, but if you still compare two floating point numbers for equality without a tolerance, you're not worth the first day's pay.
I was going to write a critical response to the article here, but it's so completely missing the point that I didn't know where to start.
I'm sure you're right, that a few CS courses teach material that isn't really needed below research level today. OTOH, I've seen people who thought they were great programmers write this:
and not even realise why it was flawed. I've seen people who thought they were great programmers use a quicksort on data that was known to be nearly sorted already "because it's O(n log n) silly!" and not even realise that it's not, never mind knowing why not and when it is and isn't an appropriate choice of algorithm. I've seen numerous similar examples of incompetence during my professional career.
No-one who understood the underlying ideas -- basic CS material -- should be making those mistakes, and no-one who doesn't understand those ideas should be writing serious code. I don't care whether the knowledge itself comes from a formal CS education or being keen and learning it on your own, but that knowledge is important for real world work.
The fact that the guy writing this article is naive enough to think that knowing XML and design patterns is more important than this sound underlying knowledge of How Stuff Works demonstrates why he's totally unqualified to comment on this subject better than anything I could possibly write in a critique.
I am sorry, but once you know how to program, learning a new syntax, especially one that is so close to one that most CS students have had experience with, is easy to do.
Spoken like someone who thinks Java, C# and Visual Basic.Net are the only languages on the planet.
I don't care how good you think you are, you can't really learn a new programming language from scratch in half a day, or even a week, and be writing code to a good standard after that time. Sure, you can learn the basic syntax, but to write good code in a language you also have to appreciate the syntactic idioms, the libraries, the standard gotchas, how to use the underlying design ideas (structured programming, OO, functional programming, different kinds of type system, whatever), where to find good sources of extra information and additional libraries, etc. Even if you've programmed a broadly similar language using the same (buzzword warning...) paradigms before, the rest takes time, and not just for learning another library.
The GP post was right on the money about this. One of the problems today is that so many people think that because they know one or two languages, they're some super-programmer who's interchangeable to any other and can be as productive with a new language almost immediately. It just ain't so, although the world is full of crappy code written by people who thought it was.
I also don't see where the grandparent was claiming that GC should be rejected out of hand because it doesn't solve all memory problems.
Neither do I, and I wrote it!:-)
All he said was, it doesn't solve all memory problems. If you code like there isn't a safety net, you probably write better code. If a yeoman programmer grows up believing that merely using GC, or auto_ptr, or RAII, or popular-pattern-of-the-week will always save him, he stands to get sucked into the "aw, fuck it" (a.k.a. MaxRequestsPerChild) coding mentality. Broken windows, etc.
I happen to believe that that's often true as well, and it's a very bad thing. However, since it's much harder to prove the "negative education" effect than it is to demonstrate concrete errors where a GC will hide the symptoms of a problem without curing it, I've stuck to the latter in this subthread.
You acknowledge that some GCs do not collect at shutdown. But you also claim that GCs accomplish nothing useful except terminal reclamation.
No, I claimed that the only class of programmer error they fixed was failure to release memory before the program terminated. That doesn't necessarily mean at termination; in a system that relies on GC, it may be necessary to collect earlier in order to release memory for other uses.
However, GC-based systems are notorious for being memory hogs, because the requirements of other processes running concurrently may or may not be taken into account when deciding when to do this. They're also notorious for causing awkward delays, if the GC kicks in and does a whole load of housekeeping at an inopportune moment. These issues can make them a liability for either memory in a timely fashion or for managing other resource types at all, which rather constrains the classes of programmer errors they can possibly help to address.
And since programmers are rather loathe to do work for no reason (that would be absurd), it is much more likely that your earlier claim was simply wrong.
No, it would be a waste of time. It should be absurd in an ideal world, but since this kind of muppetry happens every day and there are even whole web sites devoted to programmers doing such daft things, apparently it isn't.
It can be really hard to explain something that's already been made self-evident, but I'll try. [...] Your claims have been unfounded, supported by nothing more than your personal authoritativeness.
For someone who obviously likes to argue logical fallacies, you're pretty much trying nothing but proof by intimidation. Go ahead, knock yourself out, but please don't imagine you're convincing anyone at this end.
Slashdot Mirror
Apple's cinema displays do appear to rock: I've seen the smaller sizes in real life, and the image quality is stunning. The larger, 30" unit, is no longer Mac-only either, so PC owners can stop lusting. I would have bought one myself, except...
Well, just search the web before you spend too much on one of these. You'll find a lot of people with the same fault, and basically a stonewall/hand-wringing from Apple and their dealerships described in most places. After reading the same horror story for the 20th time, I pretty much decided my money had better uses, no matter how good the display is (when it works).
Of course, if you can source one through a local supplier with a good, long-term warranty thrown in, it's a fantastic bit of kit.
No, silly, that's the fifth way. The fourth way is to middle-click on the tab you want to close.
Fair enough. I hope last weekend worked out better for you!
pdfTeX (and the thinking in Thanh's thesis) are among of the more impressive recent additions to the TeX world, to be sure, and very welcome for it. In a sense, I think they reinforce my point, though: in order to get the improved typography, pdfTeX completely breaks away from standard TeX fonts and DVI output, in favour of Type 1/TrueType fonts and PDF.
I'll concede the point about the Pro font variations. I know of no automatic way to switch between what are effectively separate fonts by only changing the size under OpenType. I'm not sure how much of a problem I think this is in practice; the Pro variations are effectively different typefaces, albeit ones with a very similar appearance. But fair enough, that is something you can adjust in TeX, whereas you can't do much more than glorified hinting with OpenType.
I think we'll see an increase in operating systems that can scale a UI properly first. There are certain natural limits on the useful size of a screen for most purposes, and high-end screens are already around that mark.
What kills current systems with high resolutions on (relatively) small screens is the number of UI features that become almost unusable. Windows will scale some fonts, for example, but not always reliably and many applications get their dialog boxes and such messed up. Icons are still 32x32 or 64x64 bitmaps. Web browsers won't automatically scale up images to match the text zoom.
This is improving -- the new generation stuff from most of the big players starts to address the problem -- and once some of the basics are fixed, higher resolution but mid-sized screens will become a lot more useful. Then you can banish all the toolbars to normal size somewhere, zoom everything else to a useful size, and get on with whatever useful stuff you wanted to do. :-)
The thing is, I'm not sure that's true. Word's presentation of the written word is nowhere near the level of a decent DTP program, or something like TeX: things like paragraph justification, kerning and ligatures are naive or missing altogether, and this sort of thing sets quality typography apart from its amateur cousin. Most people wouldn't know that quality if you showed it to them with red rings round the changes, but they would still be affected by it as they read.
As others have noted around here, Word isn't really a page layout program, either. Again, its facilities are far surpassed by even fairly basic DTP packages. Try doing a two-page spread in Word with an image split across the seam.
You'd think a world-class word processor would be good for dealing with long documents, at least, but I was once told in an official Microsoft reply that this wasn't what Word was meant to do. (This was after submitting a bug report about Word repeatedly taking out the whole PC while dealing with a 300 page technical manual with fairly extensive but unexceptional use of numbered lists, section headings, and the like.) Even if it can handle larger documents these days, the cross-referencing, indexing and such are nowhere near the power of a system like TeX, and again I can't think of anything it can do that a decent DTP package couldn't.
Word can produce basic web pages, but without the quality of HTML and site design/structure facilities routinely offered by more specialised web editors.
So it goes on. Word processors today are very much a jack of all trades, yet master of few. About the only thing they have going for them is relative ease of use and customisability. Even for ease of use, similar "hybrid" packages like Apple's Pages are overtaking the more overweight beasts, and I know few places that really use the kind of customisability today that Word is theoretically capable of offering.
Faced with this sort of position, it's hard to see how Microsoft can hold off the challenges against its flagship application from all sides for long based on pretty colours alone. Revamp the layout engine to produce decent typography (particularly the neat touches that require no user intervention), sort out the styles, templates and programming facilities so people can actually make good use of them, fix up the support for formal, structured documents to provide the best indexing, cross-referencing and numbering facilities available, and then we'll be getting somewhere.
They've fundamentally changed the interface, sure. Whether they've changed the usability, and if so whether it's better or worse in the new version, we'll only find out when real users start to play with it.
Personally, I think it's a shame they have changed so much and yet so little. For example, style-based formatting really should be the norm. They could have had a section of the toolbar for font formatting that had some sort of drop down for choosing a character style, and a single button to go to the full direct formatting dialog, and nothing else. But no, while they're willing to make the interface look and probably work completely differently, they're not willing to give up their trademark over-crowded and under-usable toolbars that waste half the screen space.
I guess they're not so like Apple after all. :-(
Actually, according to the research, it usually isn't. For example, coders and manual workers both come in around that level. So do managers, incidentally, although overconfidence in their abilities while tired is widely noted.
Of course it's not a case of 40 hours or nothing works. As I noted before, gains have been seen up to around the 60 hour mark in some studies, though the extra hours offer diminishing returns, and the extra hours are much more productive if only worked occasionally rather than week in, week out. If they start affecting employees' ability to get a proper night's sleep, that's an instant performance killer, though, even in the short term. Managers also have to be wary of morale damage from expecting staff to spend more time on work and therefore less time on life. A discontent workforce is also an instant performance killer.
On the flip side, I remember reading a study about (IIRC) a software company, which was trying a 30 hour week and seeing surprising success. They found that their staff, working around 9-3 each day, had time outside working hours to do the shopping, visit the bank or pick up the kids from school. Consequently, they were much less distracted during the time they were at work, and their concentration and performance improved.
Really, you should read the research. BTW, I didn't mention that article because of the usual Guardian stance, but simply because it was one of the first links I turned up that provided several sources supporting my claims. I prefer not to post that sort of thing for a critical audience without at least some immediately accessible information to back it up, but Google is your friend.
Too right! Send your woryers in to take out those pesky terrsts instead!
But do you mean your allies this year, or in five years' time?
Then I'm sorry, but you are woefully unqualified to be in this discussion. Either that, or you're picking nits over something like Turing completeness while ignoring the point of the discussion.
Algorithms are not language independent, or rather the choice of which to use and the way you implement it aren't. How do you implement an in-place quicksort in a pure functional language, exactly? How do you implement an algorithm that uses lazy evaluation in C? You first have to convert your algorithm into a form that makes sense in your target language, or choose a different algorithm.
I understand what you're saying, but you're seriously underestimating the impact your choice of programming language makes.
I'm not. But I think you're confusing learning a language with learning some basic syntax. The latter can be done in a day, but it's only 10% (at most) of what matters apart from the libraries.
I think you need a more realistic perspective before you rant like that.
For a start, I challenge your assumption about "most successful people". It's well-documented that working long hours for extended periods provides rapidly diminishing returns, and ultimately becomes counter-productive as the damage caused by mistakes made while tired takes longer to undo later on.
About 35-40 hours is the most productive sustained hourly rate, and it's remarkably consistent across different industries and workers. You can get additional returns up to about 60 hours in short bursts, though they become less the higher the hours get. By about 80 hours, you're back to being only as productive as you were in the first 40 again as they additional 40 have cancelled out.
Go ahead and Google for this, or just try this article for a fairly representative comment. There are plenty of scientifically conducted studies, right back to Ford's observations about the guys building cars in his factory. The five-day working week came about in much the same way, BTW.
Next up, perhaps Mr Seventy Hours will be lazy rich in his 50s and living over there with a big house and car. The difference between us is that I will have lived for 50 years already when I get to my 50th birthday, and I won't die young from burn out.
Perhaps, but I'll take working smarter over working harder any day, and I bet I get there as fast as the butt-buster.
Most of the rest of Europe is the same, since we're generally much more protective of our workforce than the US is. And the combined European market is vastly bigger than that of the US.
Please tell them to mind the door on their way out. I'm betting we could live without US megacorps and their associated mess a lot more than they could live without us.
And here's another one, wonderfully demonstrated by a group VP recently in a presentation to the software development teams:
1. Company spending less per developer than ever
2. Developers unimpressed
3. Developers leave
4. Hire cheaper devs
5. Goto 1
That side was great, but he forgot to look at the quality of the work being produced by the dev teams compared to the price being paid for it.
I'm afraid it's the same in the UK, too. We currently have something like two million people claiming disability allowance from the government, despite the fact that the vast majority of them are clearly perfectly capable of working for a living like the rest of us instead.
Sorry, we caught you reading Slashdot while monitoring your communications. Please note that on page 347 of the employee handbook, it is clearly stated that privacy is a privilege that you do not have at any point in the day, because you're on salary so anything you do belongs to us. The bill for your use of company electrons in establishing the Internet connection will be arriving shortly. You no longer have any health insurance at all, because we're firing your ass without notice, any sort of severance package, or any guarantee of a reference. Armed security will be along in a moment to escort you from the building. Good luck finding new work to maintain your healthcare, but don't forget that you may not work for anyone else who can actually use your skills for the next year because of the anti-compete clauses in your contract, which will remain in force despite the termination of your employment. God bless America.
Blockquoth the AC:
Although since well-treated workers tend to be more productive anyway, that happiness has a convenient side effect.
(Before any pro-business fanatics start telling me how the US is the most productive nation in the world, please note that I measure productivity by how much useful stuff gets done/made. The only people who think a higher GDP is equivalent to a more productive society are bad economists.)
Almost non-existent in 6, 7 (.Net 2002) and 7.1 (.Net 2003). We've switched some of our 64-bit test platforms at the office from using an SDK to using the beta of version 8 (VS 2005), which seems to be much better at targetting such a platform, but obviously it's unlikely you'll see the latest and greatest game today built with a compiler that's not due for release until 7 November...
You should really read posts before you post a rant in reply. I have never claimed that CS should teach vocational skills; indeed, if you bothered to read any of my other posts in this thread properly, you'd see that I strongly disagree with that view.
That depends on the CS grad. Someone who's good and knows the theory, whether formally or self-taught, will certainly pick up a lot of things faster. But you seem to be equating CS grads with someone in that position, which is a dubious claim in the industry today. I'd take an enthusiastic hacker who learned about this stuff on his own time over a top-flight CS grad who only chose that course because the career is well-paid any day.
That's not really true, though, is it? Sure, you'd hope a decent CS graduate would have some basic familiarity with various programming styles, and perhaps a brief introduction to an illustrative language or two. However, I've never encountered a full-length CS course that taught more than one common languages in the kind of detail I'd expect for a professional-grade programmer using that language. I don't even list most of the languages I studied during my CS course on my CV.
Perhaps not if you drive a database, but they certainly will if you're working on any sort of scientific or engineering software. You can have the most trendy, pattern-based, OO design you like, but if you still compare two floating point numbers for equality without a tolerance, you're not worth the first day's pay.
I was going to write a critical response to the article here, but it's so completely missing the point that I didn't know where to start.
I'm sure you're right, that a few CS courses teach material that isn't really needed below research level today. OTOH, I've seen people who thought they were great programmers write this:
and not even realise why it was flawed. I've seen people who thought they were great programmers use a quicksort on data that was known to be nearly sorted already "because it's O(n log n) silly!" and not even realise that it's not, never mind knowing why not and when it is and isn't an appropriate choice of algorithm. I've seen numerous similar examples of incompetence during my professional career.
No-one who understood the underlying ideas -- basic CS material -- should be making those mistakes, and no-one who doesn't understand those ideas should be writing serious code. I don't care whether the knowledge itself comes from a formal CS education or being keen and learning it on your own, but that knowledge is important for real world work.
The fact that the guy writing this article is naive enough to think that knowing XML and design patterns is more important than this sound underlying knowledge of How Stuff Works demonstrates why he's totally unqualified to comment on this subject better than anything I could possibly write in a critique.
Spoken like someone who thinks Java, C# and Visual Basic.Net are the only languages on the planet.
I don't care how good you think you are, you can't really learn a new programming language from scratch in half a day, or even a week, and be writing code to a good standard after that time. Sure, you can learn the basic syntax, but to write good code in a language you also have to appreciate the syntactic idioms, the libraries, the standard gotchas, how to use the underlying design ideas (structured programming, OO, functional programming, different kinds of type system, whatever), where to find good sources of extra information and additional libraries, etc. Even if you've programmed a broadly similar language using the same (buzzword warning...) paradigms before, the rest takes time, and not just for learning another library.
The GP post was right on the money about this. One of the problems today is that so many people think that because they know one or two languages, they're some super-programmer who's interchangeable to any other and can be as productive with a new language almost immediately. It just ain't so, although the world is full of crappy code written by people who thought it was.
Neither do I, and I wrote it! :-)
I happen to believe that that's often true as well, and it's a very bad thing. However, since it's much harder to prove the "negative education" effect than it is to demonstrate concrete errors where a GC will hide the symptoms of a problem without curing it, I've stuck to the latter in this subthread.
No, I claimed that the only class of programmer error they fixed was failure to release memory before the program terminated. That doesn't necessarily mean at termination; in a system that relies on GC, it may be necessary to collect earlier in order to release memory for other uses.
However, GC-based systems are notorious for being memory hogs, because the requirements of other processes running concurrently may or may not be taken into account when deciding when to do this. They're also notorious for causing awkward delays, if the GC kicks in and does a whole load of housekeeping at an inopportune moment. These issues can make them a liability for either memory in a timely fashion or for managing other resource types at all, which rather constrains the classes of programmer errors they can possibly help to address.
No, it would be a waste of time. It should be absurd in an ideal world, but since this kind of muppetry happens every day and there are even whole web sites devoted to programmers doing such daft things, apparently it isn't.
For someone who obviously likes to argue logical fallacies, you're pretty much trying nothing but proof by intimidation. Go ahead, knock yourself out, but please don't imagine you're convincing anyone at this end.