It has been asked several times which language is better for a test developer at Microsoft, C# or C++? The answer really depends on what group you will be working in. Different groups require different skills. It is my perception that C++ is by far the dominant language today but that will not always be the case. I have friends that are SDE/Ts who work exclusively in C#. I'm sure there are some on the VB.Net team who do all of their work in VB. There are probably some on the Office team who use VBA for most of their work.
For now most things are being written in C++ because of the extra runtime speed and the availability of libraries and APIs in the language. In theory C# could become as fast as or faster than C++. It has the ability to dynamically compile and thus take advantage of processor and system features not available to the least-common-denominator approach of a traditional compiler. Most likely, in the real world, it will never quite catch up. The C# team is working hard to minimize the difference between the two. See Rico Mariani’s blog for some posts on the subject.
This isn't to say that C# won't become the dominant language though. Hand-tuned assembly is often faster than C code and C code can be faster than C++. Those advantages didn't stop C++ from becoming the dominant language, however. Why is that? It is because C++ is faster to code in. It offers native support for object-oriented coding and abstract data types. These increase the efficiency of the programmer. This increase in efficiency is accepted at the price of code that runs a bit slower. C# offers a similar bargain. Coding efficiency is up but performance is down. As processors continue to increase in speed, the need for that extra ounce of speed will be less and less advantageous and the increased coding efficiency relatively a greater and greater advantage. When the APIs for coding Windows applications become managed with Avalon and WinFX, the usefulness of C# will be magnified.
Over the long term, I expect that C# will become a dominant language. Will it fully displace C++? That is hard to say. Certainly not in the near term.
I must end this by saying that I am no expert on C#. I've done some coding in it but nothing too serious. There are others on blogs.msdn.com that know a lot more about the subject.
Do you guys use Perl anywhere for testing?
ReplyDelete@Steve: Do you mean unmanaged C++ or C++/CLI (the newer, better managed C++)? Something else to consider - Cw sounds really promising, although it's only a MSRC toy at the moment. It's supposed to make it easier to code for the multicore chips that will be standard sooner or later. Anyone wanting to eventually migrate to Cw might be better off choosing C# now than C++ (either flavor).
ReplyDelete@Alex: Yes, we (Windows testers) use Perl. It's used in the build environment. I personally use it to auto-generate some of the input test cases for my current test engine. There are Perl mods for doing lots of useful things from talking to sockets to calling Win32 APIs. I wrote one of the many tests for my last component (EFS) in Perl using some of those .pm's. And I use it fairly often for quick little scripts to do regexes, but that's probably because I already understand the regex syntax in Perl and I'm too lazy to learn it in VBScript.
Unfortunately, there isn't a Perl interpreter that ships with Windows. It's often easier to script in VBScript or ECMAScript (JavaScript) or even batch files because it confuses people less when we hand them one file to install instead of a whole directory full. Don't ask me to explain that line of reasoning - I can't. Most existing scripts aren't going to be Perl and as a tester you inherit code. We're usually not as tied to legacy test code as devs (or "dev-developers" in Stevespeak) are to legacy product code, though, thankfully. But even if you write a new test it's worth considering what languages the next tester will know - the tester who is your backup when you're on vacation or the one who will inherit your code when you move on to something else. Around here, Perl knowledge isn't as common as, again, VBScript, ECMAScript, or batch file knowledge is.
If you search for "Perl site:blogs.msdn.com" you'll find a couple hundred hits. In the first hit, I just learned that Perl is used test the C# compiler. In another, not a big surprise, the Services for Unix folks use Perl (really cool jobs there if you're a systems geek, IMHO).
When I mention C++ I'm referring to the vanilla C++ language, not any variant of managed C++. I suspect that if managed code really takes off, a language like C# that is built from the ground up for the managed world will become dominant. Managed C++ is likely to be just a transitionary language.
ReplyDeleteBy the way, if anyone is interested in Cw (or Comega), you can find it's research page here: http://research.microsoft.com/Comega/. There is also a Channel9 movie which touches the subject here: http://channel9.msdn.com/ShowPost.aspx?PostID=20495#20495.
ReplyDeleteOld languages never die, but experienced programmers do. For example, the only thing that threatens the massive existing COBOL code-base is that nobody is making new COBOL programmers. One day we may run out of them. Perhaps the day will come when Fortune 500 companies scour retirement homes for people who can read their code.
ReplyDeleteOnly geeks would even consider arguing the merits of one language over another. Can you imagine a mechanic positing that box-end wrenches are better than open-ends?
How about artists arguing over oils vs. acrylics?
Languages are the tools we use to express our ideas to the computer. Some tools do better at certain tasks than others, which is why I have a shed full of various implements.
The good engineer will be an expert at one language and proficient at a few others so that when he can't solve the problem efficiently with one he can easily turn to another.
Well, except for VB. ;-)
I should clarify that I understand Steve wasn't arguing which language was best, but which language is most used. There are, as we all know, plenty of discussions of one language vs. another (C++ vs. java, for example).
ReplyDeleteThere are programmers who I wish didn't comprehend the syntax of C++ well enough to pass technical interviews. It would have saved a great deal of work, money, and late nights. Better that they had stuck with VB where they could do less harm.
In other words, if C++ gives you grief then get your mind around C# and be happy about doing well with it. C++ ain't for everybody or every task.
Factors that I consider in choosing a language, in no particular order:
1. Performance requirements
2. Level of control needed
3. Target platform(s)
4. Dev speed needed
5. Type of application (web, service, desktop, etc.)
6. Personal bias (no sense pretending)
7. Department standards/requirements
8. Team skill sets (who will maintain the code when I'm done?)
Personally, I like C++ for high-performance servers and C# for UI and web work, even quick one-off console apps. If I never have to write another line of MFC code that will be fine with me (odds of that are going up every day).