That's bad for any end user doing a search as it gives them wrong results. Why is that hard to understand?
So, if a user searching for the phrase that was repeated several times on the Googlebot version of the page -- the German for "BMW new car" -- is getting "wrong results", what site do you think should rank above the German BMW site?
No one makes the argument because BMW is taking advantage of another company, Google, at Google's expense.
That's rather a poor moral argument, given that companies like Google fundamentally take advantage of others for their entire business model.
I'm all for a reasonable balance between fair use and copyright protection, but there is a trend recently for services that just leach others' content and put it up there with their own advertising or other services attached, claiming that this falls under fair use or similar terms in law. Search engines do it. Usenet archives do it. Web archive/caching systems do it. Now we have news aggregators that do it, automatically copying not just headlines but also the first few words of a story from other sites.
Sites like these appear, at first glance, to provide obviously useful services. However, part of that is just familiarity: to many newer Internet users, web searches are simply The Way Things Are Done. And yet, the web developed quite happily for years with no automated search features; it is inherently a medium where content of interest to the reader links naturally to other related content. Who is to say that if the automated search engines disappeared tomorrow, something better wouldn't spring up in their place next week?
Moreover, there is the small matter of fairness. Is it morally right that any site can dramatically affect the success of another site based on whether and how it leaches that other site's own content? These automatic middleman sites don't really add anything in terms of creating content; at best they facilitate access to it, and the true value of that service is always less than the middleman makes it out to be (look at the major record labels or book publishers, and then look at the artists who actually make the music and the authors who actually write new books). However, because the big middleman deals with many little guys, he becomes disproportionately powerful, to the point where the little guy lives or dies by the treatment he receives, and there is little to ensure that that treatment will be fair and reasonable. So it has been for a while with those record labels and publishers, and so it is rapidly going with the web.
This is a rare area where I increasingly suspect that copyright laws don't go far enough. We are developing a culture where big name web sites (Google and DMOZ being two prime suspects here) can throw their weight around, with little or no effort to respect the wishes of those who actually provide the valuable content on which they rely. If the occasional little guy gets trampled in the rush, is that really just collateral damage, necessary for the greater good? I'm really not sure any more.
(Full disclosure: I once had a rather irritating discussion with a DMOZ editor, about a web site I maintain. I was asking for a minor change in the way the site's details were listed. The editor agreed that the change I was asking for was reasonable, and that leaving it as it was would potentially be inconvenient to several parties at a later date. However, DMOZ policies prevented the editor from making the change. The damage caused was hardly earth-shattering, just some minor inconvenience all round. However, I found the attitude displayed -- that the wishes of the webmasters volunteering useful content for others to read should be entirely subservient to the wishes of DMOZ users who are just consumers of that information and of DMOZ itself, a mere content-borrowing middleman -- deeply offensive.)
No, sorry, this is fraud pure and simple [...] BMW should be very grateful that Google just delisted them and didn't report them to the German prosecutors and financial authorities. Because you're right, this is criminal behaviour, and therefore is a matter for the police.
Oh, give me a break.
Fact 1: Google make bucketloads of cash by running automated algorithms that crawl the web. They have even used the fact that they are just running automated processes and they don't do any manual processing as a defence in court.
Fact 2: Google "terms of service" have no legal weight here. They cannot tell me what I may, or may not, put on my own web site. Whether they choose to list it, and if so how, might depend on what content I provide, but that's as far as their power goes (and even then, they would have certain obligations to be fair and representative in most jurisdictions).
Fact 3: Adjusting your web site to get more favourable results in automated search engine listings is industry standard practice, and there is a whole "search engine optimisation" sub-industry full of people who analyse these things for a living and tell you how to adapt your site to benefit from them. There is, as far as I am aware, nothing illegal about this in any jurisdiction; it is simply the flip-side of the coin. (The fact that BMW apparently aren't very good at SEO is irrelevant to this point.)
Note 4: My German is rusty and the page now seems to have disappeared, but from what I saw, the web page BMW was showing to customers who visited their site seems to have been a reasonable page, without undue emphasis or misleading information.
Conclusion: The fact that Google was getting served something else, after advertising that it was visiting the web site not as a potential customer but as a machine, is Google's problem rather than BMWs. Google can, and have, adjusted their listing as a consequence. However, what law, exactly, has BMW even come close to breaking here?
Whether Google should be allowed to react in the way they did, given their significance in the web world today but also BMW's apparent awareness of Google's mechanisms and their intent to circumvent Google's stated policy, is another question.
Perhaps more significantly, whether Google can ever again rely on the claim that their algorithms are purely automated as a justification for other actions is also a different question.
Of course I would still write tests. They're an extra safety net. But I won't need them to tell me what happens when an "invalid" input is being handled, because either I'll know exactly what happens for that input, or I'll know from the verification of other components that it can never happen.
The point is really that in everyday programming, you can "know" that something's "impossible", and yet it still happens sometimes because of bugs. In the kind of world we're walking in here, there's so much rigorous checking going on before we even get to the point of running any code that the odds of that happening are vanishingly small.
It is self serving pablum served up by people who love scripting languages, designed to pretend that users of scripting languages are somehow smarter or more gifted than those who use non-scripting languages.
Actually, it was my personal opinion. While I'm an experienced programmer, the only scripting language I use often is Perl, and since I currently write C++ for a living I'm hardly a scripting language evangelist. I do, however, program a fairly wide range of different languages, and I recognise that they are aimed at different jobs and/or different types of programmer. I also have an interest in programming language design, and I recognise that the underlying models in Java are (deliberately) comparatively weak.
Methinks someone's a little too sensitive on this subject...
You probably have different areas of interest than me. I've done research in neural networks, databases, networking, internet, operating systems, and data mining, and I haven't seen much ML or Prolog in those areas.
Perhaps the ML specifically is just a local quirk, since several of the big names behind that particular language are (or have been) based at Cambridge. My observation was intended to be more general than that; it seems like a lot of academics use fairly obscure operating systems and programming languages, often products of their own department's research and considerably ahead of the field in the technology they use. Then again, maybe that is also a quirk of the places I've been or the particular people I've known...
Of course it does. The whole philosophy of XP is based around the idea that the unit tests effectively become the specification. It is expected that code will be refactored often, assumed that this must produce the correct results as long as the unit tests still pass, and intended that any such refactorings be released quickly and in small chunks as long as the tests do still pass. To XP, the idea of having a big picture design that is planned out ahead of time is an anathema; it should be unnecessary, since the tests should ensure that everything always gives the correct results. In XP, there is no detailed specification ahead of time; you write the initial tests to get started, and then develop further tests in consultation with an ever-present customer. The problem with all of this is that the assumptions are only valid if you have an exhaustive test suite, and if having a customer rep on-site who makes decisions on the fly is sufficiently well-specified to guarantee completeness and correctness of specification.
Consider the simple example of a program that calculates the square of an integer. This can be formally specified with a few mathematical symbols on a single line. The code to implement it could be rigorously analysed to identify ranges over which the inputs would be accepted and correct outputs given. In general, this will be time-consuming, but such is the price of having truly reliable code. How many unit tests would an XP team have to create to get the same guarantees?
Sorry, but how is recognising that different languages are aimed at different target audiences and make different trade-offs as a result "self-serving"? Is it not in everyone's interests to know the strengths and weaknesses of each tool they have available, so they can choose the most suitable for any given job?
Less research-orientated univerisities are more interested in giving students an education that will be useful in the work force
I'm sorry, but if they're not research-orientated and they're more interested in vocational training than academic study, then they're not real universities, whatever the name on the badge says. I know it's becoming common to abuse the label, both in the US and the UK, in a politcally correct quest to prove that everyone can be qualified and get a degree. IMNSHO, that's a load of nonsense that will be damaging to society in a few years' time.
Also, most modern non-AI computer science research that involves programming will use C/C++ or Java.
That certainly doesn't match my experience. For example, there's a lot of support for functional programming, particularly the ML family of languages, at the Computer Lab in Cambridge, and it's not just used for AI (though Prolog is indeed used in teaching the AI courses).
Of course proper unit tests are necessary; I wouldn't dream of suggesting otherwise. My point was simply that for this kind of project, they aren't sufficient. The XP approach inherently assumes that they are, and is fundamentally unsuitable for this type of work.
Extreme programming is your worst enemy on this one. If you need a system that is truly reliable, you cannot take an approach that fundamentally bases its quality controls on a finite number of tests, unless you can test absolutely every possible set of inputs your program can ever receive (legitimately or otherwise).
Testing is good, of course, but for this sort of job, you must have a proper design, such that all components can be properly verified. (And of course, you must have a proper spec against which to verify.) The XP methodolgy is pretty much the antithesis of what's needed here.
"I'm sure Windows will be with us for a long time, but I'm also pretty sure that.NET won't."
You're fooling yourself if you think that is true.
History suggests otherwise. Why is this time different?
Microsoft's push to SOA includes putting all of their major application bases on the.NET framework.. Exchange, Office, BizTalk, SharePoint, CRM, etc.
Sure, and a couple of years ago there was a universal directive that managed code should be used for everything unless there was a very good reason not to... which was revoked a few months later. To date, pretty much everything that Microsoft really relies on does not depend on.Net for anything essential.
All of their verticles are normalizing on the same infrastructure to maximize interoperability between the platforms.
Not to mention that the pay [for plumbing] is NOT as good as programming
One of my work colleagues is trying to get something fixed at his house right now. The first time he can get an appointment with a local plumber is several weeks away, and it's going to cost him about half a day's pay just for the plumber to turn up. This is an experienced programmer with a PhD, working for a decent employer with a fairly average salary for someone with his credentials, BTW.
Don't knock people with essential practical skills. A lot of people need their house rewiring or their drain unblocking some time, they always will, and they'll pay a lot of money for someone who can do a good job.
Wow, it sounds like you guys in the US get at least half the legally-guaranteed minimum leave here in the UK (leaving aside the fact that most employers over here will pay professional staff on sick days or set up insurance policies to do so for them, and won't count public holidays as part of the leave allowance). And by European standards generally, our employers are fairly stingy; several other Euro nations have more public holidays and/or higher average leave allowances.
What you call "hard work" I call "putting up with being overworked". It's pretty well established that working long hours and getting little leave don't actually increase your real productivity, other than in very short bursts. Averaged over the long term, a typical knowledge worker gets dramatically diminishing returns beyond about 45 hours per week, starts going backwards around the 60 hour mark, and is actually negatively productive by about 80 hours. Similarly, those who work for several months without any signficant period of time off start to lose effectiveness, and ultimately to become counterproductive.
Good management has known this and taken advantage of it for a long time. This is one reason why smaller companies with more enlightened policies kick the average corporate ass when it comes to productivity. (Various other management incompetencies, typically related to poor procedures that get in the way rather than helping, explain much of the rest, but this is one of the biggies.)
The scariest thing is the mindset I see in so many US workers, that the work culture over there is actually normal and not so bad. I'm sure a lot of people there genuinely feel that way, but that doesn't mean they're right.
Why do you people have such a hard time understanding that.NET is great platform, its easy to use and scale and is so successful that companies are STILL having a hard time filling the demand?
Because we've seen it all before, my friend, and today we are older and wiser.
.Net is a decent platform for some types of development. So is Java, and so is LAMP, and they're much better established and with a much more solid track record. Moreover, all of them suck for some other types of development. If there really were one clearly superior platform for all kinds of development, don't you think everyone would be using it by now, since not doing so would be a major commercial handicap?
However, a diverse industry continues to exist. Many of the skilled people in that industry would rather stick with tried and trusted technologies rather than jumping on the latest young and relatively unproven buzzword, because they see no compelling advantage to justify the costs of switching. The fact that.Net may be easy to use and scalable, for some definitions of these terms, doesn't make it advantageous to use it unless it is easier to use and more scalable than the available alternatives. The fact that businesses are struggling to find enough good people for their.Net projects suggests to me that this may not be the case, and perhaps they've simply jumped on the wrong bandwagon.
See, the thing is: these days, real-world programming skill is partly about both the languages and the libraries, in the sense that you need some basic familiarity to find your way around each, and you need to know the parts you're using for any given project to a fair level of detail. However, you never really need to know all the details of either, since you can always ask the office guru about the really difficult bits*, and most good guys will be able to pick up most new tools to the necessary standard within a few weeks on a project, if given sufficient guidance by those who already know.
Other than that, the major real-world skills are all transferrable: understanding how to write clean code and good comments to implement a flexible and easily-maintainable design using whatever language/library/platform tools you happen to need, for example. You can never know too many ways to make designs cleaner and code simpler without compromising on the power or flexibility of either.
* Warning: Becoming the office guru for any particular tool typically requires years of use and knowing it inside out, a state most professionals never reach with any given tool, nor need to in order to do their job. Office gurus are to be valued appropriately, since without them, everyone else would need to know all those intricate little details in order to write efficient, safe, effective code within a reasonable period of time.
Just because you can't figure out the advanced techniques doesn't mean they don't exist.
Absolutely. It's the fact that the languages in question are nowhere near as expressive and have less powerful underlying models that prevents the use of more advanced techniques.
Languages like Java and the.Net clones were pretty much written the way they were to trade away power in exchange for making it harder to make mistakes. This was a deliberate design strategy, and it's absolutely the right direction to go if you're dealing with average programmers, who have historically made the kind of mistakes that you're guarding against. However, it's the wrong direction if you have programmers smart enough not to make those mistakes in the first place (which usually means realising that they would be stupid enough to make such mistakes sooner or later if they let themselves, and therefore adopting programming tools and practices that prevent that class of error from being a possibility).
Programmers wanting a language like Java and the.Net clones but with a power/safety balance that goes the other way will tend to favour C++. Alternatively, they'll choose a different kind of tool entirely, which might be a LISP dialect, or a "scripting" language, or some funky FP language, or any number of other things. This is just the old "choose the right tool for the job" scenario, nothing more.
.Net is a platform that removes the majority of the advantages/disadvantages of programming in any particular language. Once you know the platform, the only time required to switch from one language to another within the platform is the usual couple of weeks to pick up syntax differences.
Or, depending on your point of view,.Net reduces all programming languages it supports to a least common denominator, which looks like a heavily OO-biased, imperative language not dissimilar to Java. Attempts to support anything else are pretty much just hacks to allow other languages to use the.Net libraries without giving up any more than necessary (which might still be a lot).
The basic concepts of programming, as well as everything built on those concpts, are the same in any language.
No, they're really not. Programming in an imperative, procedural language is nothing like programming in a lazy functional language, for example. Even basic concepts like structuring a function and manipulating data structures are fundamentally different in many ways.
Sure, a lot of ideas in programming are common to many languages and many approaches/paradigms/whatever we're calling them today. But pretending they're all the same is just short-sighted.
Sure they can, as long as they can get hired by a decent organisation. The big problem for such people is that they're often competing for jobs with people who have a couple of years of industry experience. To the vast majority of employers, those two years are worth far more on a CV than pretty much any academic, hobbist or internship background. Whether they're worth more in terms of effectiveness once hired is a different question, and for the sort of person we're talking about here, the answer might be very different too.
Even then, the official syllabus can be rather misleading. For example, in the department where I studied CS a few years ago, Java is the language used for the kiddie introductory programming course. On the other hand, it's a good bet that 90% of the people who are taking that particular course for formality's sake already know pretty much everything in it and then some, and the more interesting courses use languages like ML, Prolog, etc.
99% of the time, it's business needs that drive technology, not the other way around.
Of course it is. Unfortunately, the business needs being served are often those of the companies supplying the new technologies or involved with derivative fields like training and consultancy. Whether any new technology serves the business needs of anyone actually using it is an entirely different question.
Just having a great idea for business plan isn't worth jack if you're not prepared to talk about it up-front with a potential collaborator. Ask any VC: if you go in with a great idea and ask them to sign a NDA before you talk about it, they'll thank you for your time and show you the door.
Slashdot Mirror
So, if a user searching for the phrase that was repeated several times on the Googlebot version of the page -- the German for "BMW new car" -- is getting "wrong results", what site do you think should rank above the German BMW site?
That's rather a poor moral argument, given that companies like Google fundamentally take advantage of others for their entire business model.
I'm all for a reasonable balance between fair use and copyright protection, but there is a trend recently for services that just leach others' content and put it up there with their own advertising or other services attached, claiming that this falls under fair use or similar terms in law. Search engines do it. Usenet archives do it. Web archive/caching systems do it. Now we have news aggregators that do it, automatically copying not just headlines but also the first few words of a story from other sites.
Sites like these appear, at first glance, to provide obviously useful services. However, part of that is just familiarity: to many newer Internet users, web searches are simply The Way Things Are Done. And yet, the web developed quite happily for years with no automated search features; it is inherently a medium where content of interest to the reader links naturally to other related content. Who is to say that if the automated search engines disappeared tomorrow, something better wouldn't spring up in their place next week?
Moreover, there is the small matter of fairness. Is it morally right that any site can dramatically affect the success of another site based on whether and how it leaches that other site's own content? These automatic middleman sites don't really add anything in terms of creating content; at best they facilitate access to it, and the true value of that service is always less than the middleman makes it out to be (look at the major record labels or book publishers, and then look at the artists who actually make the music and the authors who actually write new books). However, because the big middleman deals with many little guys, he becomes disproportionately powerful, to the point where the little guy lives or dies by the treatment he receives, and there is little to ensure that that treatment will be fair and reasonable. So it has been for a while with those record labels and publishers, and so it is rapidly going with the web.
This is a rare area where I increasingly suspect that copyright laws don't go far enough. We are developing a culture where big name web sites (Google and DMOZ being two prime suspects here) can throw their weight around, with little or no effort to respect the wishes of those who actually provide the valuable content on which they rely. If the occasional little guy gets trampled in the rush, is that really just collateral damage, necessary for the greater good? I'm really not sure any more.
(Full disclosure: I once had a rather irritating discussion with a DMOZ editor, about a web site I maintain. I was asking for a minor change in the way the site's details were listed. The editor agreed that the change I was asking for was reasonable, and that leaving it as it was would potentially be inconvenient to several parties at a later date. However, DMOZ policies prevented the editor from making the change. The damage caused was hardly earth-shattering, just some minor inconvenience all round. However, I found the attitude displayed -- that the wishes of the webmasters volunteering useful content for others to read should be entirely subservient to the wishes of DMOZ users who are just consumers of that information and of DMOZ itself, a mere content-borrowing middleman -- deeply offensive.)
Oh, give me a break.
Fact 1: Google make bucketloads of cash by running automated algorithms that crawl the web. They have even used the fact that they are just running automated processes and they don't do any manual processing as a defence in court.
Fact 2: Google "terms of service" have no legal weight here. They cannot tell me what I may, or may not, put on my own web site. Whether they choose to list it, and if so how, might depend on what content I provide, but that's as far as their power goes (and even then, they would have certain obligations to be fair and representative in most jurisdictions).
Fact 3: Adjusting your web site to get more favourable results in automated search engine listings is industry standard practice, and there is a whole "search engine optimisation" sub-industry full of people who analyse these things for a living and tell you how to adapt your site to benefit from them. There is, as far as I am aware, nothing illegal about this in any jurisdiction; it is simply the flip-side of the coin. (The fact that BMW apparently aren't very good at SEO is irrelevant to this point.)
Note 4: My German is rusty and the page now seems to have disappeared, but from what I saw, the web page BMW was showing to customers who visited their site seems to have been a reasonable page, without undue emphasis or misleading information.
Conclusion: The fact that Google was getting served something else, after advertising that it was visiting the web site not as a potential customer but as a machine, is Google's problem rather than BMWs. Google can, and have, adjusted their listing as a consequence. However, what law, exactly, has BMW even come close to breaking here?
Whether Google should be allowed to react in the way they did, given their significance in the web world today but also BMW's apparent awareness of Google's mechanisms and their intent to circumvent Google's stated policy, is another question.
Perhaps more significantly, whether Google can ever again rely on the claim that their algorithms are purely automated as a justification for other actions is also a different question.
Indeed. But, as the saying goes, you do get what you pay for.
Of course I would still write tests. They're an extra safety net. But I won't need them to tell me what happens when an "invalid" input is being handled, because either I'll know exactly what happens for that input, or I'll know from the verification of other components that it can never happen.
The point is really that in everyday programming, you can "know" that something's "impossible", and yet it still happens sometimes because of bugs. In the kind of world we're walking in here, there's so much rigorous checking going on before we even get to the point of running any code that the odds of that happening are vanishingly small.
Actually, it was my personal opinion. While I'm an experienced programmer, the only scripting language I use often is Perl, and since I currently write C++ for a living I'm hardly a scripting language evangelist. I do, however, program a fairly wide range of different languages, and I recognise that they are aimed at different jobs and/or different types of programmer. I also have an interest in programming language design, and I recognise that the underlying models in Java are (deliberately) comparatively weak.
Methinks someone's a little too sensitive on this subject...
Perhaps the ML specifically is just a local quirk, since several of the big names behind that particular language are (or have been) based at Cambridge. My observation was intended to be more general than that; it seems like a lot of academics use fairly obscure operating systems and programming languages, often products of their own department's research and considerably ahead of the field in the technology they use. Then again, maybe that is also a quirk of the places I've been or the particular people I've known...
Of course it does. The whole philosophy of XP is based around the idea that the unit tests effectively become the specification. It is expected that code will be refactored often, assumed that this must produce the correct results as long as the unit tests still pass, and intended that any such refactorings be released quickly and in small chunks as long as the tests do still pass. To XP, the idea of having a big picture design that is planned out ahead of time is an anathema; it should be unnecessary, since the tests should ensure that everything always gives the correct results. In XP, there is no detailed specification ahead of time; you write the initial tests to get started, and then develop further tests in consultation with an ever-present customer. The problem with all of this is that the assumptions are only valid if you have an exhaustive test suite, and if having a customer rep on-site who makes decisions on the fly is sufficiently well-specified to guarantee completeness and correctness of specification.
Consider the simple example of a program that calculates the square of an integer. This can be formally specified with a few mathematical symbols on a single line. The code to implement it could be rigorously analysed to identify ranges over which the inputs would be accepted and correct outputs given. In general, this will be time-consuming, but such is the price of having truly reliable code. How many unit tests would an XP team have to create to get the same guarantees?
Sorry, but how is recognising that different languages are aimed at different target audiences and make different trade-offs as a result "self-serving"? Is it not in everyone's interests to know the strengths and weaknesses of each tool they have available, so they can choose the most suitable for any given job?
I'm sorry, but if they're not research-orientated and they're more interested in vocational training than academic study, then they're not real universities, whatever the name on the badge says. I know it's becoming common to abuse the label, both in the US and the UK, in a politcally correct quest to prove that everyone can be qualified and get a degree. IMNSHO, that's a load of nonsense that will be damaging to society in a few years' time.
That certainly doesn't match my experience. For example, there's a lot of support for functional programming, particularly the ML family of languages, at the Computer Lab in Cambridge, and it's not just used for AI (though Prolog is indeed used in teaching the AI courses).
Of course proper unit tests are necessary; I wouldn't dream of suggesting otherwise. My point was simply that for this kind of project, they aren't sufficient. The XP approach inherently assumes that they are, and is fundamentally unsuitable for this type of work.
Extreme programming is your worst enemy on this one. If you need a system that is truly reliable, you cannot take an approach that fundamentally bases its quality controls on a finite number of tests, unless you can test absolutely every possible set of inputs your program can ever receive (legitimately or otherwise).
Testing is good, of course, but for this sort of job, you must have a proper design, such that all components can be properly verified. (And of course, you must have a proper spec against which to verify.) The XP methodolgy is pretty much the antithesis of what's needed here.
History suggests otherwise. Why is this time different?
Sure, and a couple of years ago there was a universal directive that managed code should be used for everything unless there was a very good reason not to... which was revoked a few months later. To date, pretty much everything that Microsoft really relies on does not depend on .Net for anything essential.
Did you read that here?
So was the last guy. And the one before him.
One of my work colleagues is trying to get something fixed at his house right now. The first time he can get an appointment with a local plumber is several weeks away, and it's going to cost him about half a day's pay just for the plumber to turn up. This is an experienced programmer with a PhD, working for a decent employer with a fairly average salary for someone with his credentials, BTW.
Don't knock people with essential practical skills. A lot of people need their house rewiring or their drain unblocking some time, they always will, and they'll pay a lot of money for someone who can do a good job.
Wow, it sounds like you guys in the US get at least half the legally-guaranteed minimum leave here in the UK (leaving aside the fact that most employers over here will pay professional staff on sick days or set up insurance policies to do so for them, and won't count public holidays as part of the leave allowance). And by European standards generally, our employers are fairly stingy; several other Euro nations have more public holidays and/or higher average leave allowances.
What you call "hard work" I call "putting up with being overworked". It's pretty well established that working long hours and getting little leave don't actually increase your real productivity, other than in very short bursts. Averaged over the long term, a typical knowledge worker gets dramatically diminishing returns beyond about 45 hours per week, starts going backwards around the 60 hour mark, and is actually negatively productive by about 80 hours. Similarly, those who work for several months without any signficant period of time off start to lose effectiveness, and ultimately to become counterproductive.
Good management has known this and taken advantage of it for a long time. This is one reason why smaller companies with more enlightened policies kick the average corporate ass when it comes to productivity. (Various other management incompetencies, typically related to poor procedures that get in the way rather than helping, explain much of the rest, but this is one of the biggies.)
The scariest thing is the mindset I see in so many US workers, that the work culture over there is actually normal and not so bad. I'm sure a lot of people there genuinely feel that way, but that doesn't mean they're right.
Blockquoth the AC:
Because we've seen it all before, my friend, and today we are older and wiser.
.Net is a decent platform for some types of development. So is Java, and so is LAMP, and they're much better established and with a much more solid track record. Moreover, all of them suck for some other types of development. If there really were one clearly superior platform for all kinds of development, don't you think everyone would be using it by now, since not doing so would be a major commercial handicap?
However, a diverse industry continues to exist. Many of the skilled people in that industry would rather stick with tried and trusted technologies rather than jumping on the latest young and relatively unproven buzzword, because they see no compelling advantage to justify the costs of switching. The fact that .Net may be easy to use and scalable, for some definitions of these terms, doesn't make it advantageous to use it unless it is easier to use and more scalable than the available alternatives. The fact that businesses are struggling to find enough good people for their .Net projects suggests to me that this may not be the case, and perhaps they've simply jumped on the wrong bandwagon.
See, the thing is: these days, real-world programming skill is partly about both the languages and the libraries, in the sense that you need some basic familiarity to find your way around each, and you need to know the parts you're using for any given project to a fair level of detail. However, you never really need to know all the details of either, since you can always ask the office guru about the really difficult bits*, and most good guys will be able to pick up most new tools to the necessary standard within a few weeks on a project, if given sufficient guidance by those who already know.
Other than that, the major real-world skills are all transferrable: understanding how to write clean code and good comments to implement a flexible and easily-maintainable design using whatever language/library/platform tools you happen to need, for example. You can never know too many ways to make designs cleaner and code simpler without compromising on the power or flexibility of either.
* Warning: Becoming the office guru for any particular tool typically requires years of use and knowing it inside out, a state most professionals never reach with any given tool, nor need to in order to do their job. Office gurus are to be valued appropriately, since without them, everyone else would need to know all those intricate little details in order to write efficient, safe, effective code within a reasonable period of time.
Absolutely. It's the fact that the languages in question are nowhere near as expressive and have less powerful underlying models that prevents the use of more advanced techniques.
Languages like Java and the .Net clones were pretty much written the way they were to trade away power in exchange for making it harder to make mistakes. This was a deliberate design strategy, and it's absolutely the right direction to go if you're dealing with average programmers, who have historically made the kind of mistakes that you're guarding against. However, it's the wrong direction if you have programmers smart enough not to make those mistakes in the first place (which usually means realising that they would be stupid enough to make such mistakes sooner or later if they let themselves, and therefore adopting programming tools and practices that prevent that class of error from being a possibility).
Programmers wanting a language like Java and the .Net clones but with a power/safety balance that goes the other way will tend to favour C++. Alternatively, they'll choose a different kind of tool entirely, which might be a LISP dialect, or a "scripting" language, or some funky FP language, or any number of other things. This is just the old "choose the right tool for the job" scenario, nothing more.
Or, depending on your point of view, .Net reduces all programming languages it supports to a least common denominator, which looks like a heavily OO-biased, imperative language not dissimilar to Java. Attempts to support anything else are pretty much just hacks to allow other languages to use the .Net libraries without giving up any more than necessary (which might still be a lot).
No, they're really not. Programming in an imperative, procedural language is nothing like programming in a lazy functional language, for example. Even basic concepts like structuring a function and manipulating data structures are fundamentally different in many ways.
Sure, a lot of ideas in programming are common to many languages and many approaches/paradigms/whatever we're calling them today. But pretending they're all the same is just short-sighted.
Bodyguard at Google.
Sure they can, as long as they can get hired by a decent organisation. The big problem for such people is that they're often competing for jobs with people who have a couple of years of industry experience. To the vast majority of employers, those two years are worth far more on a CV than pretty much any academic, hobbist or internship background. Whether they're worth more in terms of effectiveness once hired is a different question, and for the sort of person we're talking about here, the answer might be very different too.
Did you look at any universities outside the US?
Even then, the official syllabus can be rather misleading. For example, in the department where I studied CS a few years ago, Java is the language used for the kiddie introductory programming course. On the other hand, it's a good bet that 90% of the people who are taking that particular course for formality's sake already know pretty much everything in it and then some, and the more interesting courses use languages like ML, Prolog, etc.
Of course it is. Unfortunately, the business needs being served are often those of the companies supplying the new technologies or involved with derivative fields like training and consultancy. Whether any new technology serves the business needs of anyone actually using it is an entirely different question.
Just having a great idea for business plan isn't worth jack if you're not prepared to talk about it up-front with a potential collaborator. Ask any VC: if you go in with a great idea and ask them to sign a NDA before you talk about it, they'll thank you for your time and show you the door.