tag:blogger.com,1999:blog-736810000699453506.post20539764373671051..comments2023-05-11T00:49:36.314-07:00Comments on Ruminations on Computing: Language ChoicesSteve Rowehttp://www.blogger.com/profile/17905356014908630180noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-736810000699453506.post-92027289942563993962005-01-20T03:41:00.000-08:002005-01-20T03:41:00.000-08:00Do you guys use Perl anywhere for testing?Do you guys use Perl anywhere for testing?<br><br>Alex Moskalyukhttp://www.moskalyuk.com/blognoreply@blogger.comtag:blogger.com,1999:blog-736810000699453506.post-35059402542422654042005-01-20T15:10:00.000-08:002005-01-20T15:10:00.000-08:00@Steve: Do you mean unmanaged C++ or C++/CLI (the ...@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).<br><br><br>@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.<br><br>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.<br><br>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).Drewhttp://blogs.msdn.com/steverowe/archive/2005/01/20/357425.aspx#357930noreply@blogger.comtag:blogger.com,1999:blog-736810000699453506.post-85181193875686668742005-01-21T02:29:00.000-08:002005-01-21T02:29:00.000-08:00When I mention C++ I'm referring to the vanill...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.Steve Rowehttp://blogs.msdn.com/steverowenoreply@blogger.comtag:blogger.com,1999:blog-736810000699453506.post-80611564840938973332005-01-21T02:43:00.000-08:002005-01-21T02:43:00.000-08:00By the way, if anyone is interested in Cw (or Come...By 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.Steve Rowehttp://blogs.msdn.com/steverowenoreply@blogger.comtag:blogger.com,1999:blog-736810000699453506.post-41100473593882539382005-01-25T04:35:00.000-08:002005-01-25T04:35:00.000-08:00Old languages never die, but experienced programme...Old 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.<br><br><br>Only 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? <br><br>How about artists arguing over oils vs. acrylics? <br><br><br>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.<br><br><br>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.<br><br><br>Well, except for VB. ;-)<br><br>Greg Miskinhttp://blogs.msdn.com/steverowe/archive/2005/01/25/357425.aspx#360361noreply@blogger.comtag:blogger.com,1999:blog-736810000699453506.post-58954340258901760632005-01-25T05:52:00.000-08:002005-01-25T05:52:00.000-08:00I should clarify that I understand Steve wasn'...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).<br><br><br>There 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.<br><br><br>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.<br><br><br>Factors that I consider in choosing a language, in no particular order:<br><br><br>1. Performance requirements<br><br>2. Level of control needed<br><br>3. Target platform(s)<br><br>4. Dev speed needed<br><br>5. Type of application (web, service, desktop, etc.)<br><br>6. Personal bias (no sense pretending)<br><br>7. Department standards/requirements<br><br>8. Team skill sets (who will maintain the code when I'm done?)<br><br><br>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).<br><br>Greg Miskinhttp://blogs.msdn.com/steverowe/archive/2005/01/25/357425.aspx#360407noreply@blogger.com