That was a fun title. Anyway...
At my job in addition to .NET bits I have been dutifully tasked with ongoing maintenance and updates projects for systems still running ASP Classic. That is, raw VBScript, with no MTS, no VB6 code reuse, just pure vanilla VBScript and ADO Classic. Mind you, I *can* use jQuery and the system does use SQL Server 2005. But I never dreamed I would ever say this--not in the eight years or so it's been since I abandoned ASP Classic and adopted Java and then .NET. Gosh, I'm still scratching my head wondering how it happened...
.. but I'm actually enjoying this. I'm enjoying VBScript. You heard me say it, right here. That lame language that has been given all kinds of names (a three-letter one that starts with a 'g' comes to mind), I am actually having fun with it.
In VBScript, a lot of time is saved by relying on variants and dynamic typing as such. Mind you, I'm fully aware of why the Variant was thrown out in .NET and how it is so evil in computer science. The fact that I don't have typed objects makes me pull my hair out more than it gives me pleasure. But this is script, and it almost forces me to be productive by refusing to get too formal. There's a difference between software and script, and it has nothing to do with technology.
I used to argue that what makes a "script" was that it isn't script if it doesn't run straight from the source code, which I think is close. Microsoft's definition of "script", after abandoning the Active Scripting runtime, was dynamic typing (which I think is also close, but also wrong). I've come to realize another differentiater: business use. A script is a piece of code that just gets the local, immediate, and temporary job done. A form is a classic scenario. A visitor to a web page fills out a form, the data gets collected to a database, the user is told "thanks, we'll get back to you, now go away", and a whole lot of nothing else happens in the short term. And in most business cases, you only have a tiny handful of people (like, three, at the most) filling out this form at the same time, so you don't need to worry a huge amount about performance. (If this was a page that was getting pounded on, you can scale up or scale out, hardware-wise. I am not solely impressed with people who go nuts about optimizing their systems for hundreds of thousands of hits per day but only keep two web servers up. Ten web servers on a farm and it's still slow, okay, then there's a problem with the code, or maybe the networking, otherwise, I mean, seriously. Mosso.com FTW.)
VBScript is very much a command-oriented language. Parentheses for function invocations are discouraged to make a more "command-like" syntax of "mow lawn" rather than "mow(lawn)". This doesn't account for or mean much, but after abandoning C# for a short period of a few days and spending a few days in VBScript I take a step back and realize how nice it is to be terse in my command-orientation; no futzing with parentheses and semicolons and brackets.
In my opinion, the best development language is the one that a) gets the job done reliably and effectively, b) is most productive for the developer (effort+time=productivity loss), and c) is most maintainable. VBScript is not the most stable language but it does get the job done, and on simple forms pages it is a great language. It is VERY productive, albeit it depends on what you're doing with it as there's no templating or scaffolding in ASP Classic, but I still admire ADO Classic at times. And last, on the maintainability side .... *cough* well .. no. It's not very maintainable. On the other hand, it all really depends on how you write your old code. Componentizing your code in #include's and using VBScript classes and functions where appropriate, one can produce maintainable code. I think where it gets messy is in the details. I still, always have, and always will, hate "Then", as in "If...Then". What a waste of four letters, two if you were to replace it with parentheses in other languages. And when you're using it inline with markup, you also can't leave out the "End If". It's usually not an issue, until you do something like ...
<input type="radio" <% If Request("mySel")="ABC" Then%> checked="checked"<%End If%>
name="mySel" id="mySel_dah" value="ABC" />
Ugly. This is why ASP.NET Web Forms was invented, to bury that logic into the ViewState. Personally, though, I think the trade-off isn't there, and in fact, kudos to my boss, who went around asking what we thought about him making the rule, "No ASP.NET Web Forms on public-facing pages, period. Use inline code or controls that don't require runat=server forms."
But despite the despicable fact that you can't initialize your variables when you declare ("Dim") them, I do really like the fact that everything is convertible. For example, you can always compare Request("xxx") to "" (empty string) because it automatically does a CStr() behind the scenes, which also converts Null. It's just less coding that way.
You do have to know what you're doing, and what the language interpreter is doing under the covers, to keep from making the messy language that VBScript already is into a sloppy codebase. Most of the horrors of VBScript in times past come from the fact that it was so approachable and easy to write code with that people who didn't know how to code made a big mess everywhere they went. You had crap lying around everywhere. And nobody likes smelling or cleaning that stuff up.
But the alternative of a strongly typed language, particularly when one considers Web Forms, doesn't look a whole lot better. You end up with a huge amount of boilerplating and architectural, lifecycle bloat that you typically don't even need.
I don't know why Microsoft hasn't come up with VBScript.NET, a VB-oriented scripting language, with fully dynamic typing, that runs on the CLR. But I'm not shedding any tears. They did adopt IronRuby, et al.
These things said, would someone please send me ASP.NET MVC weekend/moonlighting work?! I can only take so much of this "g" stuff uninterrupted!