It’s my girlfriend Leah’s 30th birthday today! Happy birthday Leah!
Leah is a tester in the Mobility division here at Microsoft, where she works on the software that moves email between servers and cellphones. Right now she and her fellow testers are boning up on their C# skills so that they can write better testing automation scripts. Surprisingly, a lot of the sync software testing is still done “by hand”, rather than writing a program to run the same test suites over and over again every day.
The other day Leah pointed out to me something that I’ve been intending to write about — that often it really doesn’t matter what language you learn. For many programmers, the language is just the thing that stands between you and the object model. People writing application automation need to be able to create instances of classes, call methods, listen to events, run loops, and dump strings to log files. Learning the syntax for those operations in JScript, VBScript, VB, C#, C++, perl (shudder), Python, etc, is trivial. The complexity lies in understanding the object model that you’re manipulating so that you can use it well to test the product.
The same goes for the vast majority of scripting applications. People ask me “Eric, I’m a newbie programmer — should I learn VBScript or JScript?” I tell them that script is glue and that what matters is that you glue the right things together, not that you pick the right glue.
That’s not to say that there aren’t important differences between languages. As I mentioned the other day, some languages are designed to support programming in the large, some are designed to facilitate rapid development of small, throwaway programs. Some are for writing device drivers, some are for research, some are for science, some are for artificial intelligence, some are for games. If you have complex structures that you wish to model, it’s a good idea to pick a language that models them well. Prototype classes (JScript) are quite different from inheritance classes (C#), which in turn are different from simple record classes (VBScript). But my point is that by the time you’re ready to write programs that require these more advanced features, you’ll be able to pick up new languages quickly anyway.
And this is also not to say that automation testing is just glue code. I’ve had many long conversations with the testers on my team on the subject of writing automation tools. When you move from the low level automation code (call this method, did we get the expected response?) to the higher-level (run tests 10, 13 and 15 against the VB and C# code generators for the Word and Excel object models on 32 and 64 bit machines but omit the 64 bit flavours of test 15, we already know that its broken) then you start to run into much deeper problems that may require their own object models to represent. Or even their own languages! One of the testers I work with is kicking around some ideas for a “test run definition language” that would cogently express the kinds of massive test matrices that our testers struggle with.
But these are not newbie programmer problems. If you’re just getting into this whole scripting thing, pick a language and use it to learn the object model inside-out. Once you know how the OM works, doing the same thing in a different language should be pretty straightforward.
It’s kind of like table tennis. If you know the rules of table tennis, learning the rules of real tennis is pretty easy — it’s table tennis, just with a larger board. And you stand on the board, and the ball is bigger, as are the racquets. But, as George Carlin said, it’s basically the same game. And if you know tennis, volleyball is pretty easy — it’s just tennis with nine people on a side and you can hit the ball three times and it can’t hit the ground. And there are no racquets, and the ball is bigger and the net is higher, and you play to 21 points. But it’s basically the same game.
OK, maybe that’s not such a good analogy. But you take my point, I’m sure. Don’t stress about choice of language, but learn the object model cold. The question shouldn’t be “what language should I learn” but rather “what object framework solves my problem, and what languages are designed to efficiently use that framework?”
Reflections from 2019:
Leah is of course no longer my girlfriend, as we’ve been married since 2005. The mobile devices division at Microsoft has been reorganized so many times that any vestige of its 2003 state is I’m sure long gone.
It was a fascinating time to be involved in mobile devices; the iPhone was still years away, and there was real competition for who was going to be a player in this market. There was always a tension between the hardware manufacturers, the operating system vendors like Microsoft, and the cell service providers; each one had an interest in differentiating their offerings from their competitors while commoditizing the others.
That is to say, AT&T wished desperately to be seen as different than, say, Sprint, but not differentiated at all on the basis of the quality of the hardware or the software; they wanted people to differentiate based on cell service, since that is what they provided. The hardware manufacturers were in the same boat; they wanted customers to differentiate on the basis of hardware features, not what networks were supported. And the same for Microsoft, which wanted customers to think about the OS provider as the differentiating factor when making a purchasing decision, not the hardware or the cell service.
This misalignment of interests led to some considerable lack of trust between the various parties — who ought to have been collaborating for each other’s mutual success.
This article produced a number of thoughtful reader responses:
Sometimes it does matter what glue you pick, and for those times, that’s why we have http://www.thistothat.com.
No doubt.
Explaining the difference between client and server programming for VBScript, VB, VBA, JScript, JavaScript, JSP, J2EE and Java to someone who doesn’t understand is too hard.
No doubt!
Are there any applications written in JScript?
My response was that I knew of zero shrink-wrapped applications that were 100% JS, and I new lots and lots of applications where some part of the application was written in JS. Of course, the idea of “shrink-wrapped app” is now hopelessly stone-aged.
That’s a George Carlin bit
When I originally wrote this article I had forgotten that the bit I’d alluded to was Carlin. The original was: “Tennis is nothing but a form of ping-pong. Tennis is ping-pong played while standing on the table. In fact, all net sports are just derivatives of ping-pong; even volleyball is racquetless team ping-pong played with an inflated ball and a raised net while standing on the table.”
I note that, golf is just ping pong with a huge, grassy board that you stand on, sand and trees instead of a net, you have clubs instead of paddles, the scoring system is slightly different, and you try to get the ball into a tiny hole rather than past the opponent. But basically it is the same.
If the novice programmer should focus on learning the object model, then surely a relevant question is “how much junk does the language make you put between you and the object model?” Syntax is not just trivial; it can make a difference. My experience is that Java is much easier to learn than VB, for instance.
I took five years of French in high school, and I recently took a beginner Spanish course. And you know what struck me? English is the only language in which the words come IN THE SAME ORDER THAT YOU THINK THEM! I mean, imagine the extra mental effort that French speakers have to go through — they think the thoughts for “the white dog” but then have to re-order those thoughts into “le chien blanc”.
Seriously now, I understand your point. But I came to professional programming having spent many years as a hobbyist using basic-like languages. At the time, languages like VB had a much more “natural” syntax to me; C-like languages were these godawful clunky messes with their |&^ operators and weird bracing rules. I mean, what’s clearer: “}” or “End Function”?
I agree that some languages are easier to learn than others. We designed VBScript and JScript to be easy for novices to pick up quickly, for example. But I don’t buy the argument that VB has a weird syntax. It has oddities, certainly, but in general I find it very pleasant and easy to read VB, given my long background in basic-like languages.
Your sports analogy can be extended; consider trying to explain soccer scoring to a novice compared to tennis scoring. Similarly, some languages go out of their way to be easier for novices to pick up, and some do not.
Sure, I’ll grant that.
Your sports analogy can be extended further; just because someone is an expert in one sport does not mean that their expertise will carry over into another.
Well, we can take analogies too far. I’m a much slower Java and Scala programmer than I am a C# programmer just because I constantly have to look up how to do simple things that I already know how to do in C#. But I don’t see programming in Java or Scala as in any way fundamentally different than programming in C#; the skills that I already have transfer over very well. Even if sometimes what is “the right way” in one language is the wrong way in another.
Fabulous adventures in coding 
Pingback: Porting old posts, part 4 | Fabulous adventures in coding