Rumours of VBScript's Death Have Been Greatly Exaggerated

Rumours of VBScript's Death Have Been Greatly Exaggerated

  • Comments 29

A reader recently left the following comment today which deserves a full and detailed response.  (Yep, I'm going to get prolix again.) 

I teach a Windows network administration scripting course to about 1500 admins and auditors each year.  I've been using VBScript all along mainly because it's a good transition language to VBA/VB.NET ... but I will likely switch the courseware to ActiveState's Win32 Perl instead. 

It seems like MS is going to let VBScript die a slow death and I'm doing a disservice to my students by making them invest their time in it.  I think MS should definitively state its intentions for the future of VBScript on the Script Center website and perhaps start doing all of its example administration and ResKit scripts in JScript (or Perl) instead so as not to trick new scripters into wasting their time. 

It's too bad, I still think VBScript is easy to teach and a gentle intro to VBA/VB.NET, but if the language isn't going anywhere, then I have to look out for my students' long-term interests.  Perl looks like it will become the de facto cross-platform administration language (if it isn't already) and there's a gigantic and solid community of support behind it (whereaas MS seems to just abandon its user base sometimes). 

If I'm wrong here about VBScript's future, then please tell me otherwise.  Thanks for being straightforward and honest in this blog. 

[emphasis added]

There's a lot to respond to in there. 

Let me first of all state categorically Microsoft's position on the COM Scripting technologies.  It's not often that I get to be The Voice Of Microsoft, but here we go:

We will continue to support VBScript and JScript for the foreseeable future.  Obviously VBScript, JScript, WSH, etc, must continue to be shipped with the operating system forever, as huge amounts of existing business-critical code depends upon them. To characterize that as "dying a slow death" is excessively melodramatic.  We expect that the unmanaged COM scripting languages will continue to be useful for many, many years.  The Visual Studio Sustaining Engineering Team presently is responsible for VBScript, JScript, Windows Script Components, Windows Script Host, etc. 

I'm looking at the logs right now, and there have been 702 file changes in the last three years, almost all bug fixes and security improvements. As we find bugs, security issues, etc, the Sustaining Engineering Team will investigate them and issue new releases with operating system service packs as necessary, as we have always done.  (And I will code-review their changes!) 

However, there will be no new features added to the languages -- indeed, there have been no new features in a long time.  The last person to actually add a new feature to any script team technology was me, on November 1st 2000!  (The feature was adding code signing support to WSF files.)

An analogy might be helpful.  I have plenty of old hammers in my toolbox, and they do their intended job today just as well as they always have.  To criticize a hammer for not being a cool new hydrogen-powered nailgun (yes, they do exist -- my kitchen contractors had one), or for being a bad tool to build skyscrapers, is to miss the rather important point that a hammer is still a useful tool for a broad variety of tasks!  There have been very few massive improvements in hammer technology in recent years, but it would be a serious mistake to say that hammers are dying a slow death.  It would also be a mistake to not teach people how to use hammers because hydrogen powered nailguns exist.  VBScript is a hammer, not a stone axe.  It'll be around for a long time.

I've been meaning to blog more about script languages as pedagogic tools, and now seems like as good a time as any.

First off, let's think about theory.  As I've blogged before, the important thing when you're learning how to program is to understand the semantics of the language, to understand what abstractions the language provides and use them appropriately to manipulate data correctly.  Therefore, the question "what is the future of VBScript?" is somewhat irrelevant.  If you're teaching people to program, pick a language that teaches people to program.  Once they know how to program, they'll be able to move from language to language with relative ease.  A loop is a loop is a loop, whether it is for(;;) or While Blah or some other goofy syntax.

From that approach, the sensible question to ask is "what language most easily teaches the concepts that I want the students to learn?"  and not "what language is going to have new features next year?"  When I was learning how to program over the years I used Commodore Pet BASIC, Waterloo Structured BASIC, Pascal, Lisp, Scheme, New Jersey Standard ML, Java, C, C++, Ada and Turing.  (The latter was a language specifically designed at the University of Toronto for teaching programming concepts.)  Aside from C++, I use none of those languages for anything practical, but I use the concepts that I picked up in each every day.  I often use functional programming techniques, for example.  If you want to teach someone functional techniques then it makes sense to pick a functional language. Teach the concept and then show how to do the same thing (much less elegantly, though it is improving!) in C# or whatever their language of choice is.

Clearly you understand the value of this approach, as you stated twice in your comment that VBScript is great because it is a good introduction to more complex languages such as VBA and VB.NET, which are useful for more heavy-duty application programming tasks.  But listen -- do you smell something?

I can smell the skepticism from here.  Why the heck would you or your students care about this kind of theory?  They're not writing dissertations on the theory of computing machinery, they're writing logon scripts.  They're not going to have to design massive applications, they're going to change directory permissions.

Why do you mention -- twice! -- that you use VBScript because it affords a smooth ramp up to VBA and VB.NET?  They are totally useless to you if your goal is to train administrators how to do administration tasks.  You are training possibly the most pragmatic set of IT professionals on the planet.  Administrators do not care about highfalutin' programming concepts like functional programming or object oriented programming.  Administrators do not need the language features afforded by VB.NET.  Administrators write thousand line scripts that look like this:

Directory.Create("CORPSERVER/BobSmith")
Directory("CORPSERVER/BobSmith").Permissions.Add("BobSmith", "ReadWriteDelete")
Directory("CORPSERVER/BobSmith").CreateFile("Logon.BAT")
Directory.Create("CORPSERVER/BillJones")
Directory("CORPSERVER/BillJones").Permissions.Add("BillJones", "ReadWriteDelete")
Directory("CORPSERVER/BillJones").CreateFile("Logon.BAT")
... a thousand more lines of this stuff

Now, perhaps our administrator could generate a more elegant and maintainable program by, say, abstracting away those operations into a function, putting the user names into a file, and writing a processing program that sucks the names out of the file one at a time and calls the function.  That would be great, but since this is a single-use script, any time spent making it elegant and maintainable before it is deleted this afternoon is rather wasted time. 

Administrators like to learn how to use one language well enough to get by, and then do everything in that language.

(Actually, it's even moreso than that.  When I write an administrative script that, say, copies a thousand files from one dev box to another, you know what I do?  I get a file list in my editor and then type a vi macro that turns the line of code into a legal statement in some script language, then I run that macro a thousand times, run the resulting script, and delete it.  My leet skillz in the admin space are a function of my mastery of my editor, not my deep knowledge of programming languages!)

The theoretical approach gets us nowhere.  The theoretical approach says "the semantics are the program; all languages are basically just variations on ways to abstractly express those semantics. Get the semantics right in your head and you'll be able to write the program in the language of your choice."  But for administrators, the semantics are NOT in the program nearly so much as the semantics are in the object models.  As I've said  before, for most administrative jobs, the programming language is the thing that mediates between you and the object model. 

Therefore, let me make the same argument from a completely opposite standpoint.  The language is unimportant because you're not going to be using nine tenths of the language features anyways.  Spend enough time to get the basics down on some language, any language, and then spend the whole time studying really kick-ass administrator object models like WMI.

The question is now neither "what's the best pedagogic language?" nor "what language will have new features?" The question to be answered now is "What language best mediates between administrators and today's object models?" 

And, if you're future-proofing, another good question is "what language best mediates between administrators and future object models?"

Clearly your choice depends on what object models you think that your students will be using to do their jobs.  Do you think that people will continue to use COM-based object models like WMI for a while?  Then a COM-based scripting language like VBScript or ActiveState's Perl might be a good idea.  Whether I'm going to add new features to VBScript is irrelevant to that decision -- VBScript exists now, Perl exists now, and if either of those are useful languages to call WMI, then by all means, teach whichever one you think your students will pick up on better.

But what about the future?  You wisely asked these questions in the first place with an eye to the future.  Let me again be the Voice of Microsoft here and say what the future is:

Managed programming, the .NET Framework and the Longhorn WinFX classes are the way of the future.  We are betting the entire company on it.  That's why I haven't been adding new features to VBScript for the last three years!  Yes, we will continue to support COM and VBScript forever, but if you want to enable people to take full advantage of all the incredible coolness that is coming in Longhorn, start thinking hard about managed code and the .NET Framework right now.  Learn as much as you possibly can about Monad and the Longhorm APIs, and start laying the groundwork for that curriculum.  Administrators in the future will use Monad and other managed languages to mediate between them and the WinFX framework, I guarantee it.

As I've blogged before, it is sometimes hard to know what tool to choose for a particular task.  Clarify your requirements.  Put these in priority order -- a good language for my curriculum

  1. works well with existing object models (VBScript)
  2. works well with future object models (any .NET language)
  3. affords a smooth ramp up to some other more complex language technology (VB.NET, C#...)
  4. is available on every platform (perl)
  5. makes it easy to learn basic general-purpose algorithmic programming techniques (your choice)
  6. makes it easy to learn specific advanced programming techniques (OOP, functional programming, etc.) (JScript)
  7. has a large installed base, lots of documentation, etc (any established language)
  8. has lots of new features planned (C#, VB.NET)
  9. is cool (C#, VB.NET…)

Once you've got those in priority order, it should become easier to pick the right tool.  If #4 is the most important to you, we shouldn't even be talking about this.  Use perl and be done with it if you want admins to be able to write programs for Solaris boxes! 

If you have multiple conflicting priorities, well, not much I can do to solve that problem except by providing as many facts and as much analysis here as I can. 

My aim is and has always been to make the Windows platform as attractive as possible to all programmers, from administrative scripters to game designers to developers of multi-tiered enterprise developers.  If perl on Windows is the best tool for your students, by all means, use it.  I'll be happy as long as that "on Windows" is in there!

  • When I first began getting interested in computers I would always 'worry' about what language/application/path to choose. I was really concerned about being ready for the future, the 'next big thing'. What I've found is that using what works today-- works best. In that regard vbscript and vb6 have served me well. Now when I consider what path I should take it is like canoeing down a river. I don't try to push it and I don't fight the current; instead, the 'next big thing' will be ready when it's ready and I'll simply enjoy the benefit of using a technology that has matured to the point of being useful, without the worry of taking the wrong path. vb.net c# something else? I'm sure, I'll enjoy it when it's ready and it looking better everyday to me.
  • I work for a large organization that uses Perl on Windows extensively for sysadmin scripting.  If you're a sysadmin then Perl is the best language to learn.  Perl has features like regular expressions and a huge quantity of libraries that enable a sysadmin to create very powerful scripts.  All the COM stuff you do with vbscript you can do with Perl.  It's also cross platform which is essential when working in large environments with more than one type of os.  It makes sense to teach Perl instead of vbscript.  The biggest problem with Perl on Windows is ignorance.  Many sysadmins assume that Perl is just a unix thing.
  • It feels really, really good to see someone at Microsoft start to understand Administrator priorities in writing code!

    A couple other things that you might add to your list of things "to help make a language choice" - a couple have to do with a different class of administrator scripts than were discussed in the article - that is "those that run on hundreds or thousands of production machines - not on the scripter's workstation for a centralized maintenance task of some type"

    *) No need to buy and install special tools to write code - compiled environments require this.
    *) No need to distribute runtimes for scripts that run on all client comptuers (especially if one-time use) - .MSH requires .NET 2, which requires MSI 3.  By contrast VBScript is on and up to date on almost every computer around and I have written quite  few lines in the past to avoid distributing even a single activeX object (need admin rights to do most installs)  Also if some cool .NET thing MSH has access to requires a .NET Assembly that is not on every system, it likely will not be used for a throw away script.
    *) No need to install tools to debug problems on production computers that run the code - since the code is the source, it is easy to insert a couple statements to output to the screen for simple debugging.

    _____________________
    Darwin Sanoy
    Principal Consultant
    DesktopEngineer.com
  • Nice to see some articles persist in their value over time.

    The fact that products like VBscript  and classic ASP aren't evolving isn't all bad.  They are locked down,  rock solid and available everywhere with Windows.  

    This makes them easy to learn, readily available, and reliable for use.

    Sounds pretty good to me :)

  • If anyone actually cares: What I don't understand is why Microsoft continues to use it (VBScript) in brand new products, comes out with new books on it, has a heavily used site for it (Scripting Guys) and says that will support it for years to come in Longhorn/IIS 7 - but won't take the time to update one freaking dll to optimize it and add some new features that would benefit hardcore scripters/programmers. Example: Sorting for arrays.

    If they did that, with the new security features for ActiveX controls and IE 7, maybe, just maybe the standards community would consider bring VBScript back into the fold for other browsers and platforms. Yeah, I could learn ASP.NET, C#, Javascript and PowerShell or I could do everything I need to do with one language that covers almost all areas in Windows - VBScript. There are reasons why tons of administrators, developers and application support people use it everyday. It's easy to learn, yet powerful enough to manage the command line, build GUI interfaces for the desktop and server-side web applications as well as complex systems management utilities.

    I apologize for rambling, but it just boils my blood to see Microsoft basically turn their back on a scripting language that should've been upgraded instead of left the wayside for something totally different in PowerShell. I think Jeffrey Snover is doing a great job, but how much would it cost M$ to stick a couple people on a team and bring VBScript up to speed while maintaining the same flexible programming model as before?

  • Jay, how about some sort of efficient string builder? Doing things like creating ADODB.Streams and writing to them does not pay off unless you are doing a crapload of writes. How about the ability to impersonate/log-in as another user without having to rely on 3rd party software (e.g. Persits.ASPUpload). I know... .NET is the future and does what I need in those regards (although I am thinking for some reason I need to use P/Invoke for the impersonation thing). Just a reminder to Microsoft that people other than admins are stuck using VBScript still (I believe we were supposed to move to .NET like... 4 years ago, but crap kept coming up). A LOT of code is written in VBScript and it seems like quite an undertaking to convert it the *right way* to VB .NET or C#. Dollars and cents are still against it, so we're in legacy hell.

    The language has its quirks, but its still useful and the people stuck with it would love some sort of update (especially if its effiency-related, or if it gives the VBScript language a feature that JScript has but it does not). I will quit complaining now.

  • Just come from the boss his office. Looks like today i'm gonna write a VBScript. Creating some directories, records in a db. I'm verry happy after months in .Net to get back to the language with what it all started (for me).

    Over years learning script i could do more then ever thought that was possible in vbscript,.

    GUI's using internet explorer object or hta(also ie object)

    TCP/IP, UDP, FTP, HTTP, SMTP, POP3 and other protocols

    parse HTML, XML

    WMI and other management scripts

    So building up all this "knowledge" was a waste of time, because now writing in VB.Net, i'm trying to do as less calls possible to the Microsoft.VisualBasic namespace, to learn the .Net language better. I almost never use COM in .Net.

    I did read the whole thread and what i can say is, i miss simple VBScript, flying low, dying slow...

  • I think Python (http://www.python.org) is an excellent replacement for vbscript. It is well-known to be easy to use, has superior library support, and interops with Windows technologies (COM, win32 API, etc..) far better than vbscript. It is even available under .Net (IronPython) and Java (Jython).

  • powershell script OLE Automation ?

    Using IActiveScriptSite and  CcmdTarget we can write our own script engine

    for parsing VBscript code.

    This approch help us to write businus logic in script  

    like wise How we can write powershell script parsing engine

    using VC++ automation or other technology?

    (Active Scripting based on OLE Automation)

  • I second Eugene that Python is a great replacement for VBS.  I think rumors about VBS death have become true, I don't see a reason to continue that language. VBS has great syntax but what is the use of that if it is not supported cross-browser. <a href="http://www.getbest.info/">Quality reviews and articles</a>.

  • I had never head of Python. I am going to check it out.

  • Perl / Python /

    Why would you want to install another app to do scripting work?

    You must have way too many free time.

    Learn to use what comes with the OS and be done with it.

    New OS version might lead to new "cool" language to learn... <ha> <ha.

  • @Eric: "there will be no new features added to the languages"

    We are in 2010 (6 years after your post) and IE9 is in beta with an updated JavaScript engine supporting EcmaScript 5th edition.

    Will this engine be the one in WSH once IE9 is installed on a machine?

    I have no idea. I haven't been on the JScript team for almost ten years now. You should probably ask someone on the JScript team. - Eric

  • Hi Eric,

    Do you have any update on this. i heard that Microsoft is going to stop supporting the VBScript. Date is not finalized yet. Can you please provide some information on this?

    Thanks in advance

    Abhinav

Page 2 of 2 (29 items) 12