VBScript : VB :: ping-pong : volleyball

VBScript : VB :: ping-pong : volleyball

  • Comments 12

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?"

  • Sometimes it does matter what glue you pick, and for those times, that's why we have www.thistothat.com.
  • I am yet to see any application written in JScript. Is it popular? I always thought it was created to confuse people. I once had to explain the difference between client and server VB script, VB, VBA, client and server JScript, Javascript, JSP, J2EE and Java. I don't think I did too good.
  • It depends on what you mean by "application", and "in". Is Visual Studio an application? Because portions of it are written in JScript. I know of zero standalone shrink-wrapped applications that were written in 100% JScript, but I know of lots of web applications, multi-tier applications, office programmability applications, and shrinkwrap applications where considerable portions are written in JScript and VBScript.
  • On a student project (hm.. don't know what it's called in English) we used JScript to create integrationtests. It's easy to do things there, such as check out the status of remote processes (we didn't use .NET :)), so we could focus on the tests instead of performance etc since we wasn't interested in how quick the _tests_ ran (I'm _not_ implying that JScript doesn't perform well here!). Also, having learnt Ada is very nice, since it's a bit different then the "standard" languages Java & C++.
  • You know, the main thing i got was volleyball is played with nine players... i've only ever played it for competition with six or less players. (yes, i know, it's not the main point of the posting, or even the main point of this blog, just had to say it) btw, love the blog, please keep going :)
  • Your analogy is quite apt. Was it your intention to make an allusion to George Carlin? Let's see if I can remember it.... "...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."
  • Dr. Thingo knows all my secrets. Incidentally, 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 its the same.
  • > "test run definition language"
    Interesting idea. Maybe it's aLL about data-driven testing? Honestly speaking i didn't understand it well until i've tried it myself.

    Actually, what have i learned is that it's mission critical to clearly separate testing data and code (even such a "light-weight" code as JS!). (Btw, that nice posting about Table-Driven programing is somewhat related to this, no?). Such separation enables us to define huge data matrices regardless of the code logic. But then i've got curious how can pure, raw, "dead" data drive the testing? Well, my little recent invention was to inject a reasonable amount of code directly into data. So sometimes instead entering huge amount of values it is better just to define general law for them:

    ///simply const.
    thisField:"20040629"
    ///"smart" value with memory...
    thatField:"javascript:lastValues['thatField']"

    Oh, it is already somehow unrelated to the subject... Nevertheless, i still remember that ``eval'' is evil..
  • Regarding the choice of a first language to learn, your point concerning what a novice needs to learn is bang on the money, but you don't quite carry the logic through all the way to the end. On the one hand, a novice programmer should "learn the object model cold", and she should also understand that "the language is...the thing that stands between you and the object model". Does it not then follow that the criteria for picking a language lies on just how much junk that language puts between you and the object model? I agree that "learning the syntax...is trivial" as far as understanding how to write software is true, but understanding the syntax of a given language is not equally trivial across all languages. By understanding the syntax, I mean "being able to ignore the syntax to the degree of concentrating on the object model".

    My own experience serves as a good example. I come from a small town that offered no ComSci credits in high school, and that didn't help my attitude when it came time to go to college or university; I never went. I tried twice to get employed as a programmer without those qualifications. Both times, someone threw a book and some software at me and told me to get back to them when I knew something useful. The first time I was handed some VB stuff (I don;t remember what version); the second time I got Java. The first time I got nowhere; the second time I was hired.

    Now, I'm not going to tell anyone that Java is the best language out there (it's not), but looking back on both learning experiences after reading the stuff in this blog, it's clear that the language I was learning is what made the real difference in my success. With VB, I spent all my time worrying about syntax because the syntax in VB is so goofy. Java's syntax is so consistent and clear that I found myself thinking in objects almost immediately. Isn't there a post about the differences between syntax and semantics elsewhere in this blog?

    Even if there were no live implementations of Java or C# anywhere, I'd recommend them to a newbie in order to make breaking through to that "Object Model" that much easier. The reverse would be true of C, C++ and any of the VB variations.

    Where this job thing will go, I can't say, but you'd be hard pressed to convince me that the language you choose to be the first you learn doesn't make any difference at all.
  • 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.







  • Well, perhaps I use the wrong word. Maybe I'll stick with your word: "oddities". Now, I'd like to point out that most other pieces of writing you've posted on the topic of learning have (rightly) been centered around use instead of familiarity.

    To quote: "Programming courses for beginners often concentrate heavily on getting the syntax right.". Now I agree that this is not the way to go, but for many it's a natural reaction to complexities in syntax.

    Since Mr. Carlin's sports diatribes make a difference to you, consider trying to explain the scoring systems for tennis and ping pong to a child that can count, but has no experience with either game. Tennis will be more complex (15-love, deuce) than ping pong (1-0, 14-14), and thus more difficult to learn. A child will react to misunderstanding the scoring system by ignoring a rally while she tries to figure out why she doesn't know what the score is ("40-15? Why isn't it 45-15? Daddy, did he really just say 40-15? Well, I know it's not 40-15 NOW, I can see that... etc.). A child will react to understanding the scoring system by observing how the game is played ("Oh, he just missed it, Daddy. Hey, how come he got a point for missing it? Oh, it wasn't on the table."). Only after they have explored how the game is played, and can express the result of the game accurately, will they begin to see the similarities between the two, and why Mr. Carlin's comments are funny.

    "Oddities" like the purely syntatical difference between Let and Set tend to produce the same effect in students of programming. It sure did in me, and I don't think it's because of any excessive stupidity on my part (the extent of which depends on whether you're speaking to my wife or an ex-girlfriend). Hence, I wouldn't recommend VB to anyone as a first language, much like (if I ever had the choice) I wouldn't recommend English to someone who knew no spoken languages.

    And I fail to see where baseball qualifies as a sport where hockey does not. After all baseball is actually four seperate activities: Hitting balls with a stick, throwing balls around, running, and standing around spitting on the ground. I can see interrupting a run to hit some balls with a stick, but not the other way around. Why stop doing something as satisfying as hitting anything with a stick, or spitting, in order to do something as pointless as running around in a circle? Also a bunch of activities that should be performed sequentially, with omissions.
  • Eric,

    The sports analogy is [IMHO] an excelltent one. You can easily follow the progression in understanding the rules [Lord Dust's comment on the "oddities" of expressing the score in Tennis not withstanding].

    HOWEVER, if you take an EXPERT in anyone of the games, and have them actually play one of the other ones, then very little will actually carry over, and the person is unlikely to even play a "decent" game the first few times out. In some cases the "details" of what makes a person great in one environment may actually hinder them in another (e.g. strength vs. agility).

    I believe that this differentiation carries back to the original topic of being able to program at an expert level in any specific language. Knowing the "rules" is only the very beginning. Intuitivaly knowing the subtle aspects so that you can react quickly and correctly take specific time; and the "right" approach in one language is often the "wrong" approach in another - even though the rules allow for it in both.

Page 1 of 1 (12 items)