Well, you may want not to call a spade a spade, and maybe it's not racism, but it's certainly something, and it's also entirely wrong.
Looking at my original post again, I concede that I phrased it as if my opinion were rather more universal than it seems to be around here. Obviously it can only be my opinion from my experiences, but perhaps I should have stated that explicitly at the time. However...
Just because you can't communicate with someone doesn't mean they're stupid -- usually and probably the opposite, looking at your comments.
We're not just talking about me and communication, though. We're talking about (for example) a project that ran for nearly six months with a dozen or so outsourced developers, with all the cost that entails, which never produced a product. The product was then produced in around a month by a UK-based team half the size. I was not involved in either group, so I have no personal axe to grind, and there is nothing subjective about the fact that one group produced the goods and the other simply didn't (though costing several times as much nonetheless).
As I have noted elsewhere in this thread, I have met and worked with some very good programmers from India and other countries. A couple of the best guys I've ever worked with have been Indian. I simply find them to be in a pretty small minority, and I've had to clear up the mess personally, or seen my colleagues do so, in too many other cases to believe people around here who tell me I'm making it all up. Looking at the replies to my post, although pretty much all are inevitably anecdotal in a forum like this, I am clearly not alone in having formed this view.
At the end of the day, though, I'm far more interested in experiences like your own, whether they agree or disagree with mine, than in people who can't possibly know deciding that I'm a poor communicator, racist, in denial or otherwise necessarily the cause of all the problems I've seen.
I wish I could remember where I'd seen the information; it was definitely a formal study, and dated from somewhere in the mid-'90s if memory serves.
The thing about it was, I'm very critical of material that offers a firm opinion, so I always tend to question sources. Anecdotal evidence is fine if that's all it claims to be, but if you want to make a firm point rather than just start a discussion, then you've got to offer hard facts. And yet, the results of that particular study made perfect sense to me, and almost perfectly agreed with my own observations at the offices where I'd worked. If it had been commissioned by an obviously biased source, I would probably have noticed and questioned that.
I don't suppose anyone reading this happens to have encountered the same study and could provide a link? It must have been fairly widely known if I came across it when I did...
I have formed an opinion from several years of fairly consistent experience with this issue. I offered it here as a point for discussion. It is not a universal truth, nor advertised as such. I do not claim that there are two opinions, mine and the wrong one. I do not claim that anyone else's opinion is less valid, or that anyone else's experience is more or less representative.
Some people have come to this thread and offered their own experiences, some agreeing with me, others with a different view. It is interesting to read such things, which is why I posted in the first place.
Other people seem to think it's clever to brand me a racist, tell me I'm in denial, throw names about or otherwise have a go. Anyone who knows me could tell you immediately how absurd those claims are. I could recount numerous anecdotes that would demonstrate how realistic I am about the world of programming jobs, how strongly I have defended friends against genuine racism in the past and so on. But there would be no point; those who know me already know, and people here could either choose to believe them or dismiss them as unsubstantiated anecdotes, so it changes nothing either way. I just don't understand the point of replying to a post like mine and flaming rather than offering an alternative point of view or some personal experience of your own.
So I think you're wrong to say that foreign workers aren't as good.
I didn't; you selectively quoted me in a way that changed my meaning.
What I said was that most of the time, they don't do as good a job. Furthermore, I've got several years of first-hand experience working with such people and the material they produce to back me up, and I'm afraid I'm going to give that more credit that a single anecdote from your best friend about one group of developers in one company.
The cost of living in India is far less than the cost of living in Silicon Valley. The salaries in the States are high by necessity, it isn't just greed.
Of course, what you say is true today. In a few years, though, if the international markets pick up along the lines they follow now, then someone is going to need to reevaluate their worth. I'm hardly a master economist, but it seems likely that the exchange rate will simply become much more balanced between countries sharing work this way, and the cost of living will become comparable. Workers in the US and UK will have to get used to having more competition from India with all that entails, workers in India will have to get used to the standards expected in the US and UK if they want to compete and increase their ability accordingly, and a balance will be reached where everyone gets a reasonable opportunity to be paid fairly for doing a decent job.
But we aren't there yet, and I stand by my claim that right now, you usually get what you pay for (if you're lucky).
I am a programmer, and one with a decent reputation amongst his peers for getting a job done well and on time.
Why do you say I'm wrong? I certainly have days where the code streams from my fingers, but usually they take the form of a few minutes of inspiration where an idea "clicks" and I work through it in my head, followed by several hours of implementing that idea while driven by it.
Maybe we're just using the word differently, but I consider those first few minutes where I arrange my thoughts to be the "zone" part, and the rest just to be solid work based on a good plan. If you interrupted me during the "working out" phase it would be really annoying and I might lose my trail of thought, but once I've got the plan, a few minutes talking to a colleague about something else won't affect how fast I work when I get back to what I was doing.
I see your point about Mathematica, but (and this is my field of expertise) there is still a lot of mathematical software developed. Packages like Mathematica and Matlab are constantly being extended, of course, and then there are numerous other mathematical libraries, each with their own little niche, behind much of the scientific and technical software you see today. Obviously the users of such software may be researchers rather than programmers, but someone still has to program all of it first. (And actually, many of the users of these things are programmers. They're just using what is effectively a higher level language to write their code, and who'd blame them?)
I disagree with your position on the future of the embedded market. For as long as people are inventing new hardware to do new things, there will be a need for new software to drive it, whether embedded in the hardware itself, or via some sort of serial link to a PC or similar kit. And for as long as there is a need for that, there will be a need for people to produce new algorithms to use the hardware correctly and efficiently. That necessarily requires creativity, QED.:-)
I confess that I'm confused. You claim that I'm wrong when I say that, mostly, the "imported labour" don't do as good as job. You then cite a couple of examples of very good guys (the reason I said "mostly") and then a project with precisely the problem I described, where it wound up costing more because the foreign developers took much longer to get it done (the reason I said "aren't as good at it"). Maybe I'm just being slow today, but I don't see how your anecdote isn't a perfect example of exactly the point I was trying to make...
This just isn't true. In fact, despite the fact that you're arguing that you're not racist, you quite clearly are.
Alas, this is a predictable response to my post. Let me attempt to justify my position for you in more detail.
First, let me clarify my views on Indian people as a whole. I have nothing personal against them, and a couple of my very close friends are Indian. For several years I've gone out with a girl who, while English, loves India so much that she's doing a PhD on a related subject, and is there as I write. Obviously many of her friends are Indian as well. Two of the most talented developers I've ever worked with are Indian, though now living in the UK, and I have nothing but respect for them and the job that they do. If you truly feel that this position makes me a racist, then so be it, but obviously I disagree.
On the other hand, I have been involved with "imported labour" in a variety of ways during my professional career. My opinion that most (not all) of the time the foreign workers do a much worse job was not pulled out of the air on a whim. It is based on having to work with these people, having to maintain code written by these people, and having to clear up the mess after these people failed to produce a useful product after considerable amounts of time invested in developing it.
As a general pattern, from my observations, there are a few good guys, and lots of mediocre->bad ones. The good guys can hold their own with the good guys over here, without a doubt. But the average standard -- the set that makes up most of the workforce -- cannot hold their own with a typical software developer in the UK. Your own example doesn't disagree with this; if you were choosing the top 0.5% of the field, you're getting the cream of the crop, not a representative sample.
I freely admit that I could have been been extraordinarily lucky in who I've worked with throughout my professional career, or extraordinarily unlucky in my encounters with developers from India and such places, and I acknowledge that the plural of "anecdote" is not "data". But all I can do is call it as I see it, and my comments were based on several years of professional experience, not a single unfortunate incident. Clearly YMMV, but I still don't see how this makes my comment "bullshit" as one poster replied, or how I've suddenly renounced my massively pro-integration philosophy and turned into a racist.
I am not sure what you mean by "back-end" though -- can you give an example ?
I meant "back-end" programming, as opposed to boilerplate UI or database access code. That covers everything from a smart spell-checking algorithm in a word processor through state of the art mathematical algorithms in a scientific calculation app to hardware control logic in instrument control and embedded software, and much more besides. In other words, it includes most of the programming industry outside of writing database front-ends using standard UI tools.
I mentioned the other things because not all UI programming is boilerplate drawing of text and check boxes, and not all database schemas are routine and obvious. I suspect the back-end stuff makes up a much larger part of the creative programming world, though.
He didn't actually say that the programmers needed to be in their own offices, or even that all interruptions are bad.
True, the "getting my own office" comment was made by the person who submitted the article, not in the article itself. You have to admit that the article seems to support the idea pretty strongly, though.
I think you overgeneralise. Some development tasks (writing dumb database front-ends, principally) require little creative input. However, much of the back-end stuff requires creativity. Writing a good UI requires creativity. Even designing good database schemas requires creativity.
It's true that a significant fraction of "software development" today just involves using VB, Java and/or web scripting to put together McDatabase code, and that's probably fairly easily automated. But there's a whole world, a much larger world, of programming beyond that, where skill and creativity are still far more important than ability to read a cookbook.
No use of gender, and perfectly correct English too.
No, it's not. In fact, I know several people who find this usage really irritating. It is a common usage, but it still reads awkwardly.
But at the end of the day, who really cares? The meaning is clear either way, and the subject of the article is much more interesting than English grammar.:-)
The problem with this whole "exporting work" argument is that, the vast majority of the time, the foreign workers simply aren't as good at it, or even close. I'm sorry, I'm no racist, but this is simply the way things are.
It's true of call centres, where people reading from a script with no concept of the product and English as a second or third language just don't project a good impression or offer much help. If you doubt this, ask Carly about how HP did when they moved much of their call centre work abroad.
It's also true of programmers. If someone in India can do the same job as me, for 1/10 of the price but just as well, then apparently at least one of us has got our expectations wrong. OTOH, if a programmer in India has the same job title as me, charges 1/10 of the price but does 1/20 of the work, is this an improvement? Of course not. And I think it's fair to say, quite objectively, that the vast majority of foreign developers lack the education, industrial experience and professionalism exhibited by decent programmers in places like the US or UK.
In the long run, companies will have to adapt to this. They will either recognise that the cheap option doesn't stay cheap when your quality, and consequently your business, suffers, or they will see the need to invest in proper training and support of the foreign labour to raise standards, which will cost them more. Either way, you do get what you pay for. It's just a matter of time until corporate greed starts losing to smart management on this one.
I think the article has an interesting perspective, and I totally understand the "in the zone" argument. Sometimes you have it, sometimes you don't, and sometimes an interruption really is just soooo irritating.
However, I'm not sure the suggestions are really the way forward. In particular, such research as I've seen (sorry, can't cite a link off the top of my head) suggested that actually, a small team of programmers was much more productive in their own open-plan-like "team space". There are several logical explanations for this, not least the fact that if you do get stuck with a mental block, help is just a question away. You also get interaction with conversations other members of the team have, and either learn something yourself or offer them a solution neither of them knew about but you did.
Sure, you need to have a team who get on, and realise when someone is really going for it so they don't interrupt at just the wrong moment. But all that really takes is having a little consideration for your team-mates, and a willingness to say "Can I get back to you in half an hour?" without being distracted, neither of which is hard to do. No-one really sits in the zone all day, it's more like a few minutes when the germ of an idea comes to you and you want to flesh it out, and that's the time when it's bad to be interrupted.
Other than that, I find it's much more helpful to have the interaction for the remaining 90% of the day, so you don't get "programmer's block" and just sit there thinking about a problem but not really getting anywhere. I guess this is one of the major advantages of "pair programming", too, if you've got people who are happy working together that closely.
I agree that programmer comforts are generally a smart move: where I work we have a decent flexitime system, concern over things like chairs and lighting, headphones so people can listen to CDs while they work and, yes, even a shower. These are all good things, appreciated by the developers, and so the developer productivity and loyalty is very high. But we still work in an open plan office, even if everyone does have "their space" in it.:-)
Well, I confess that I've never really used Lisp in anger, the way I have with something like C++ or, to a lesser extent, Java. It just struck me that when looking at C++'s approach to generics, Lisp's S-expressions seem to have a rather firmer underlying base (lambda calculus) whereas C++ is crying out for one but doesn't currently have it (hence all the expression template libraries, and the presence of an incomplete mess of function objects in the standard library for binding and such).
The "will be used" vs "can be used" arguement is somehow diminshed to me by the fact that it "is being used" in a poor manor in most cases.
How can you possibly know that? What is your sample?
I've worked in a variety of places using C++ to develop application code (as opposed to systems software, etc). The place I'm currently at writes mathematical components that are used by many of the leading products in our industry worldwide. It's mostly written in C++, because performance counts amongst other reasons. We don't have memory leaks and crashes all over our code, because we have smart people writing it, and we use smart automated testing tools to check for such things just in case.
Admittedly, my 25% is also just a figure based on personal experience, but I stand by it.
If you argue that C/C++ should be used for services, you are argueing that services should be faster, and not neccisarily secure.
#include <standard_no_such_language_argument.h>
That said, yes, many services do require such a level of performance, and no, Java-based versions often do not provide it. There is no point shipping me a 100% secure product if it doesn't do its job.
Only a language biggot would even bother argueing for C/C++ in these situations. There is no justification for the lack of security implementations in C/C++. There have been remote root exploits found in every popular package that ships with a computer.
Language bigot? Hardly. If you read my previous few hundred comments here, you'd note that I do often defend C++ against unjustified or ill-informed criticism, but I'm equally happy to have a go about its weaknesses. I've posted both for and against aspects of it in this very thread. I've also advocated diverse other languages here on many occasions, for different purposes. They're just tools, not divine gifts, FFS.
Security implementations? There is every excuse: C and C++ are based on being low-level, high-performance first and foremost, and then building on top of that framework. You can build whatever you like there, including secure systems, particularly in C++. You can take a powerful, low-level base and make it safe, but you can't take a Fort Knox-like, high-level system and make it powerful.
And remote root exploits in every popular package? What kind of popular packages? Under what OS? With what other security arrangements? That's a pretty meaningless blanket statement.
If you can quote some other software that is popular and hasn't been on security focus and is written in C/C++ and opens a socket, you let me know, and I'll start using it tomorrow.
Sure, just as soon as you start quoting me equivalents to all that C and C++ software that exist at all in a "secure" language so we can have an objective comparison of vulnerability counts.
BTW, who told you writing something in Java necessarily made it secure?
If your suggesting that it requires just as much work to program in Java as C++ [...]
I wasn't as such, but since you mention it, I think it requires more work for a typical programmer to get many things done in C++, but more work for a very good programmer to get many things done in Java. C++ is a more powerful tool but needs much skill to use; Java is simple(r) but effective.
I don't think you'll find many people that would even run a known buggy program. If someone wrote BIND and Sendmail in Java, I would be using it! (Insert any buggy package in the place of BIND and Sendmail.)
That was an unfortunate sequence of sentences.:-)
I think you'll probably find, on close inspection, that every single computer user in the world runs known buggy software. The issue isn't black and white. It's a matter of how bad the bugs are, and how much of a liability that makes using the software, compared to whatever benefits it may offer.
(I don't know how you meant your post since it's only one line... so I thought I would just clarify my position.)
My original point was simply that you can judge a language by what it does in typical hands, or what it does in skilled hands. Most of the accusations levelled against many popular programming languages ("C++ is insecure!", "Java is slow!", "Perl is incomprehensible!") are untrue if the language is programmed by someone who has a good level of skill with it.
They don't even have to be a true expert, top 1% user, but they probably have to have made the effort to reach the standard of, say, the top 25% of programmers today. Alas, the majority of programmers don't make that effort, and then it just reflects badly in some way on whatever language they use.
The interesting question, and one which is often overlooked, then becomes whether it's best to judge a language by how it can be used, or by how it will be used. The answer, obvious to me, is that you should just a language by how it will be used by the particular programmers who will be using it. That gives different answers, depending on who the developers are, but such is life in the real world, and hence my comment at the top of this post.
The point is you end up spending a non-trivial amount of your time and effort doing string type conversions. The idea that the STL is a "defacto standard" is just wrong.
True; the only realistic standard is a null-terminated character array. However, you can get one of those from a std::string (or a std::wstring) with a trivial function call.
I'll leave the answer to this question to the experts:
Oh dear. I'm sorry, but that is possibly the worst string class I have ever seen. It has all the bad bits of C++'s std::string, Java's String and StringBuffer, etc:
bloated interface
size-specific interfaces and confusion over multi-part characters
lots of case handling that won't work in general
a silly class hierarchy.
I'm guessing it was designed by committee?:-)
And I'm still waiting to hear what you think that lot can do that a straightforward std::wstring and some common sense can't...
This is somewhat off-topic, but since the discussion has drifted this way...
Can you show me a high level language that duplicates the flexibility and performance of C++ templates? Once you realize that you cannot, youll understand that C++ is still the only game in town.
Don't get me wrong, I like C++ as a practical development tool, and I post here fairly often in its defence. But truth be told, templates aren't its strongest point. The feature is valuable -- C++ would be a much weaker language without it -- but it is clumsy and underpowered compared to alternatives available elsewhere.
Advanced template techniques in C++ have their uses, but often what they actually do would be routine in a higher level language anyway. Look at the standard library algorithms, expression templates, policies and such, and compare with routine programming technique using, say, the LISP or ML language families. Note also that performance isn't necessarily hit here; on such verifiable evidence as there is, several languages in the families I mention can hold their own against C.
It's not the fault of the VM if the applications programmed in the language suck. [...] it's often a horrible mess with people doing non-buffered IO, creating millions of temporary objects every second [...] It has given the VM a much worse reputation than is warranted.
Kinda like the reputation C++ has for buffer overruns and poor memory management, because so many C++ programmers never bothered to learn about the tools it provides to fix them, you mean?:-)
The fact that so many bugs and security holes exist in C/C++ programs is evidence that the language doesn't do enough to prevent those things.
That depends. It's also evidence of the fact that so many such programs exist, and of the fact that the languages aren't used as well as they should be. The vast majority of such bugs in C++ programs are totally unnecessary, but since most people appear read a 10 year old book on C++ and then call themselves an expert, it's not surprising that they still use raw arrays, pointers, str... functions, and all that jazz in high level code where it has no place.
If, like 99.9999% of the programs in existence, your C++ program contains bugs, then C++ allows those bugs to be exploited to take over your server
FUD. The vast majority of bugs in programs would not allow any sort of remote exploit. Most of the ones that do are mechanical, and could be prevented by (a) using programming practices less than a decade old, and/or (b) using automated tools to check over the code before you ship it.
It's a curious fact that people who program exclusively in higher level languages have a tendency to overestimate their safety, hence resource leaks in Java apps, logic errors causing millions of Perl CGI/PHP/whatever web pages every day to be served incorrectly, etc.
There are tons of popular C++ libraries that don't use the STL...to say nothing of all of the C libraries that you must call into.
That may be true, but I think your argument is bogus. We're talking about programmers developing their own code, here. Any code you write, in any language, is potentially at risk from other code it links to that you did not write. It doesn't matter whether it's a C library, the.NET or Java run-time stuff, a flaw in your Python interpreter or a bug in your OS's memory management. The only way to avoid this is to sandbox everything you link to in some way, and the performance penalties associated with that are non-trivial.
Plus, I don't think that STL has decent unicode support. Wstring is not enough. Unicode has a bunch of semantics that are built-into the string classes of languages like Python and Java.
What are the problems you see with it? C++ string handling certainly sucks at times, as anyone who's tried to write an internationalised application can tell you, but what mysterious bunches of semantics are you thinking of here?
Slashdot Mirror
Looking at my original post again, I concede that I phrased it as if my opinion were rather more universal than it seems to be around here. Obviously it can only be my opinion from my experiences, but perhaps I should have stated that explicitly at the time. However...
We're not just talking about me and communication, though. We're talking about (for example) a project that ran for nearly six months with a dozen or so outsourced developers, with all the cost that entails, which never produced a product. The product was then produced in around a month by a UK-based team half the size. I was not involved in either group, so I have no personal axe to grind, and there is nothing subjective about the fact that one group produced the goods and the other simply didn't (though costing several times as much nonetheless).
As I have noted elsewhere in this thread, I have met and worked with some very good programmers from India and other countries. A couple of the best guys I've ever worked with have been Indian. I simply find them to be in a pretty small minority, and I've had to clear up the mess personally, or seen my colleagues do so, in too many other cases to believe people around here who tell me I'm making it all up. Looking at the replies to my post, although pretty much all are inevitably anecdotal in a forum like this, I am clearly not alone in having formed this view.
At the end of the day, though, I'm far more interested in experiences like your own, whether they agree or disagree with mine, than in people who can't possibly know deciding that I'm a poor communicator, racist, in denial or otherwise necessarily the cause of all the problems I've seen.
I wish I could remember where I'd seen the information; it was definitely a formal study, and dated from somewhere in the mid-'90s if memory serves.
The thing about it was, I'm very critical of material that offers a firm opinion, so I always tend to question sources. Anecdotal evidence is fine if that's all it claims to be, but if you want to make a firm point rather than just start a discussion, then you've got to offer hard facts. And yet, the results of that particular study made perfect sense to me, and almost perfectly agreed with my own observations at the offices where I'd worked. If it had been commissioned by an obviously biased source, I would probably have noticed and questioned that.
I don't suppose anyone reading this happens to have encountered the same study and could provide a link? It must have been fairly widely known if I came across it when I did...
I have formed an opinion from several years of fairly consistent experience with this issue. I offered it here as a point for discussion. It is not a universal truth, nor advertised as such. I do not claim that there are two opinions, mine and the wrong one. I do not claim that anyone else's opinion is less valid, or that anyone else's experience is more or less representative.
Some people have come to this thread and offered their own experiences, some agreeing with me, others with a different view. It is interesting to read such things, which is why I posted in the first place.
Other people seem to think it's clever to brand me a racist, tell me I'm in denial, throw names about or otherwise have a go. Anyone who knows me could tell you immediately how absurd those claims are. I could recount numerous anecdotes that would demonstrate how realistic I am about the world of programming jobs, how strongly I have defended friends against genuine racism in the past and so on. But there would be no point; those who know me already know, and people here could either choose to believe them or dismiss them as unsubstantiated anecdotes, so it changes nothing either way. I just don't understand the point of replying to a post like mine and flaming rather than offering an alternative point of view or some personal experience of your own.
I didn't; you selectively quoted me in a way that changed my meaning.
What I said was that most of the time, they don't do as good a job. Furthermore, I've got several years of first-hand experience working with such people and the material they produce to back me up, and I'm afraid I'm going to give that more credit that a single anecdote from your best friend about one group of developers in one company.
Of course, what you say is true today. In a few years, though, if the international markets pick up along the lines they follow now, then someone is going to need to reevaluate their worth. I'm hardly a master economist, but it seems likely that the exchange rate will simply become much more balanced between countries sharing work this way, and the cost of living will become comparable. Workers in the US and UK will have to get used to having more competition from India with all that entails, workers in India will have to get used to the standards expected in the US and UK if they want to compete and increase their ability accordingly, and a balance will be reached where everyone gets a reasonable opportunity to be paid fairly for doing a decent job.
But we aren't there yet, and I stand by my claim that right now, you usually get what you pay for (if you're lucky).
I am a programmer, and one with a decent reputation amongst his peers for getting a job done well and on time.
Why do you say I'm wrong? I certainly have days where the code streams from my fingers, but usually they take the form of a few minutes of inspiration where an idea "clicks" and I work through it in my head, followed by several hours of implementing that idea while driven by it.
Maybe we're just using the word differently, but I consider those first few minutes where I arrange my thoughts to be the "zone" part, and the rest just to be solid work based on a good plan. If you interrupted me during the "working out" phase it would be really annoying and I might lose my trail of thought, but once I've got the plan, a few minutes talking to a colleague about something else won't affect how fast I work when I get back to what I was doing.
OK, s/spell checking/grammar checking/, then. :-)
I see your point about Mathematica, but (and this is my field of expertise) there is still a lot of mathematical software developed. Packages like Mathematica and Matlab are constantly being extended, of course, and then there are numerous other mathematical libraries, each with their own little niche, behind much of the scientific and technical software you see today. Obviously the users of such software may be researchers rather than programmers, but someone still has to program all of it first. (And actually, many of the users of these things are programmers. They're just using what is effectively a higher level language to write their code, and who'd blame them?)
I disagree with your position on the future of the embedded market. For as long as people are inventing new hardware to do new things, there will be a need for new software to drive it, whether embedded in the hardware itself, or via some sort of serial link to a PC or similar kit. And for as long as there is a need for that, there will be a need for people to produce new algorithms to use the hardware correctly and efficiently. That necessarily requires creativity, QED. :-)
I confess that I'm confused. You claim that I'm wrong when I say that, mostly, the "imported labour" don't do as good as job. You then cite a couple of examples of very good guys (the reason I said "mostly") and then a project with precisely the problem I described, where it wound up costing more because the foreign developers took much longer to get it done (the reason I said "aren't as good at it"). Maybe I'm just being slow today, but I don't see how your anecdote isn't a perfect example of exactly the point I was trying to make...
Alas, this is a predictable response to my post. Let me attempt to justify my position for you in more detail.
First, let me clarify my views on Indian people as a whole. I have nothing personal against them, and a couple of my very close friends are Indian. For several years I've gone out with a girl who, while English, loves India so much that she's doing a PhD on a related subject, and is there as I write. Obviously many of her friends are Indian as well. Two of the most talented developers I've ever worked with are Indian, though now living in the UK, and I have nothing but respect for them and the job that they do. If you truly feel that this position makes me a racist, then so be it, but obviously I disagree.
On the other hand, I have been involved with "imported labour" in a variety of ways during my professional career. My opinion that most (not all) of the time the foreign workers do a much worse job was not pulled out of the air on a whim. It is based on having to work with these people, having to maintain code written by these people, and having to clear up the mess after these people failed to produce a useful product after considerable amounts of time invested in developing it.
As a general pattern, from my observations, there are a few good guys, and lots of mediocre->bad ones. The good guys can hold their own with the good guys over here, without a doubt. But the average standard -- the set that makes up most of the workforce -- cannot hold their own with a typical software developer in the UK. Your own example doesn't disagree with this; if you were choosing the top 0.5% of the field, you're getting the cream of the crop, not a representative sample.
I freely admit that I could have been been extraordinarily lucky in who I've worked with throughout my professional career, or extraordinarily unlucky in my encounters with developers from India and such places, and I acknowledge that the plural of "anecdote" is not "data". But all I can do is call it as I see it, and my comments were based on several years of professional experience, not a single unfortunate incident. Clearly YMMV, but I still don't see how this makes my comment "bullshit" as one poster replied, or how I've suddenly renounced my massively pro-integration philosophy and turned into a racist.
I meant "back-end" programming, as opposed to boilerplate UI or database access code. That covers everything from a smart spell-checking algorithm in a word processor through state of the art mathematical algorithms in a scientific calculation app to hardware control logic in instrument control and embedded software, and much more besides. In other words, it includes most of the programming industry outside of writing database front-ends using standard UI tools.
I mentioned the other things because not all UI programming is boilerplate drawing of text and check boxes, and not all database schemas are routine and obvious. I suspect the back-end stuff makes up a much larger part of the creative programming world, though.
True, the "getting my own office" comment was made by the person who submitted the article, not in the article itself. You have to admit that the article seems to support the idea pretty strongly, though.
I think you overgeneralise. Some development tasks (writing dumb database front-ends, principally) require little creative input. However, much of the back-end stuff requires creativity. Writing a good UI requires creativity. Even designing good database schemas requires creativity.
It's true that a significant fraction of "software development" today just involves using VB, Java and/or web scripting to put together McDatabase code, and that's probably fairly easily automated. But there's a whole world, a much larger world, of programming beyond that, where skill and creativity are still far more important than ability to read a cookbook.
No, it's not. In fact, I know several people who find this usage really irritating. It is a common usage, but it still reads awkwardly.
But at the end of the day, who really cares? The meaning is clear either way, and the subject of the article is much more interesting than English grammar. :-)
The problem with this whole "exporting work" argument is that, the vast majority of the time, the foreign workers simply aren't as good at it, or even close. I'm sorry, I'm no racist, but this is simply the way things are.
It's true of call centres, where people reading from a script with no concept of the product and English as a second or third language just don't project a good impression or offer much help. If you doubt this, ask Carly about how HP did when they moved much of their call centre work abroad.
It's also true of programmers. If someone in India can do the same job as me, for 1/10 of the price but just as well, then apparently at least one of us has got our expectations wrong. OTOH, if a programmer in India has the same job title as me, charges 1/10 of the price but does 1/20 of the work, is this an improvement? Of course not. And I think it's fair to say, quite objectively, that the vast majority of foreign developers lack the education, industrial experience and professionalism exhibited by decent programmers in places like the US or UK.
In the long run, companies will have to adapt to this. They will either recognise that the cheap option doesn't stay cheap when your quality, and consequently your business, suffers, or they will see the need to invest in proper training and support of the foreign labour to raise standards, which will cost them more. Either way, you do get what you pay for. It's just a matter of time until corporate greed starts losing to smart management on this one.
I think the article has an interesting perspective, and I totally understand the "in the zone" argument. Sometimes you have it, sometimes you don't, and sometimes an interruption really is just soooo irritating.
However, I'm not sure the suggestions are really the way forward. In particular, such research as I've seen (sorry, can't cite a link off the top of my head) suggested that actually, a small team of programmers was much more productive in their own open-plan-like "team space". There are several logical explanations for this, not least the fact that if you do get stuck with a mental block, help is just a question away. You also get interaction with conversations other members of the team have, and either learn something yourself or offer them a solution neither of them knew about but you did.
Sure, you need to have a team who get on, and realise when someone is really going for it so they don't interrupt at just the wrong moment. But all that really takes is having a little consideration for your team-mates, and a willingness to say "Can I get back to you in half an hour?" without being distracted, neither of which is hard to do. No-one really sits in the zone all day, it's more like a few minutes when the germ of an idea comes to you and you want to flesh it out, and that's the time when it's bad to be interrupted.
Other than that, I find it's much more helpful to have the interaction for the remaining 90% of the day, so you don't get "programmer's block" and just sit there thinking about a problem but not really getting anywhere. I guess this is one of the major advantages of "pair programming", too, if you've got people who are happy working together that closely.
I agree that programmer comforts are generally a smart move: where I work we have a decent flexitime system, concern over things like chairs and lighting, headphones so people can listen to CDs while they work and, yes, even a shower. These are all good things, appreciated by the developers, and so the developer productivity and loyalty is very high. But we still work in an open plan office, even if everyone does have "their space" in it. :-)
Well, I confess that I've never really used Lisp in anger, the way I have with something like C++ or, to a lesser extent, Java. It just struck me that when looking at C++'s approach to generics, Lisp's S-expressions seem to have a rather firmer underlying base (lambda calculus) whereas C++ is crying out for one but doesn't currently have it (hence all the expression template libraries, and the presence of an incomplete mess of function objects in the standard library for binding and such).
No, no... They stopped fixing it. That's different, y'see. :-)
How can you possibly know that? What is your sample?
I've worked in a variety of places using C++ to develop application code (as opposed to systems software, etc). The place I'm currently at writes mathematical components that are used by many of the leading products in our industry worldwide. It's mostly written in C++, because performance counts amongst other reasons. We don't have memory leaks and crashes all over our code, because we have smart people writing it, and we use smart automated testing tools to check for such things just in case.
Admittedly, my 25% is also just a figure based on personal experience, but I stand by it.
#include <standard_no_such_language_argument.h>
That said, yes, many services do require such a level of performance, and no, Java-based versions often do not provide it. There is no point shipping me a 100% secure product if it doesn't do its job.
Language bigot? Hardly. If you read my previous few hundred comments here, you'd note that I do often defend C++ against unjustified or ill-informed criticism, but I'm equally happy to have a go about its weaknesses. I've posted both for and against aspects of it in this very thread. I've also advocated diverse other languages here on many occasions, for different purposes. They're just tools, not divine gifts, FFS.
Security implementations? There is every excuse: C and C++ are based on being low-level, high-performance first and foremost, and then building on top of that framework. You can build whatever you like there, including secure systems, particularly in C++. You can take a powerful, low-level base and make it safe, but you can't take a Fort Knox-like, high-level system and make it powerful.
And remote root exploits in every popular package? What kind of popular packages? Under what OS? With what other security arrangements? That's a pretty meaningless blanket statement.
Sure, just as soon as you start quoting me equivalents to all that C and C++ software that exist at all in a "secure" language so we can have an objective comparison of vulnerability counts.
BTW, who told you writing something in Java necessarily made it secure?
I wasn't as such, but since you mention it, I think it requires more work for a typical programmer to get many things done in C++, but more work for a very good programmer to get many things done in Java. C++ is a more powerful tool but needs much skill to use; Java is simple(r) but effective.
That was an unfortunate sequence of sentences. :-)
I think you'll probably find, on close inspection, that every single computer user in the world runs known buggy software. The issue isn't black and white. It's a matter of how bad the bugs are, and how much of a liability that makes using the software, compared to whatever benefits it may offer.
My original point was simply that you can judge a language by what it does in typical hands, or what it does in skilled hands. Most of the accusations levelled against many popular programming languages ("C++ is insecure!", "Java is slow!", "Perl is incomprehensible!") are untrue if the language is programmed by someone who has a good level of skill with it.
They don't even have to be a true expert, top 1% user, but they probably have to have made the effort to reach the standard of, say, the top 25% of programmers today. Alas, the majority of programmers don't make that effort, and then it just reflects badly in some way on whatever language they use.
The interesting question, and one which is often overlooked, then becomes whether it's best to judge a language by how it can be used, or by how it will be used. The answer, obvious to me, is that you should just a language by how it will be used by the particular programmers who will be using it. That gives different answers, depending on who the developers are, but such is life in the real world, and hence my comment at the top of this post.
True; the only realistic standard is a null-terminated character array. However, you can get one of those from a std::string (or a std::wstring) with a trivial function call.
Oh dear. I'm sorry, but that is possibly the worst string class I have ever seen. It has all the bad bits of C++'s std::string, Java's String and StringBuffer, etc:
I'm guessing it was designed by committee? :-)
And I'm still waiting to hear what you think that lot can do that a straightforward std::wstring and some common sense can't...
This is somewhat off-topic, but since the discussion has drifted this way...
Don't get me wrong, I like C++ as a practical development tool, and I post here fairly often in its defence. But truth be told, templates aren't its strongest point. The feature is valuable -- C++ would be a much weaker language without it -- but it is clumsy and underpowered compared to alternatives available elsewhere.
Advanced template techniques in C++ have their uses, but often what they actually do would be routine in a higher level language anyway. Look at the standard library algorithms, expression templates, policies and such, and compare with routine programming technique using, say, the LISP or ML language families. Note also that performance isn't necessarily hit here; on such verifiable evidence as there is, several languages in the families I mention can hold their own against C.
Sorry, your comment is far too rational and reasonable to be posted on Slashdot. Please withdraw it and dock yourself 20 karma points at once. :-)
Kinda like the reputation C++ has for buffer overruns and poor memory management, because so many C++ programmers never bothered to learn about the tools it provides to fix them, you mean? :-)
That depends. It's also evidence of the fact that so many such programs exist, and of the fact that the languages aren't used as well as they should be. The vast majority of such bugs in C++ programs are totally unnecessary, but since most people appear read a 10 year old book on C++ and then call themselves an expert, it's not surprising that they still use raw arrays, pointers, str... functions, and all that jazz in high level code where it has no place.
FUD. The vast majority of bugs in programs would not allow any sort of remote exploit. Most of the ones that do are mechanical, and could be prevented by (a) using programming practices less than a decade old, and/or (b) using automated tools to check over the code before you ship it.
It's a curious fact that people who program exclusively in higher level languages have a tendency to overestimate their safety, hence resource leaks in Java apps, logic errors causing millions of Perl CGI/PHP/whatever web pages every day to be served incorrectly, etc.
That may be true, but I think your argument is bogus. We're talking about programmers developing their own code, here. Any code you write, in any language, is potentially at risk from other code it links to that you did not write. It doesn't matter whether it's a C library, the .NET or Java run-time stuff, a flaw in your Python interpreter or a bug in your OS's memory management. The only way to avoid this is to sandbox everything you link to in some way, and the performance penalties associated with that are non-trivial.
What are the problems you see with it? C++ string handling certainly sucks at times, as anyone who's tried to write an internationalised application can tell you, but what mysterious bunches of semantics are you thinking of here?