A Modest Proposal: VBScript.NET, aka “Helping Mort use .NET”

As I alluded to in my recent essay on Transitionality, this is the essay which proved one of the main catalysts for me to start blogging. But first a bit about the alternate title.

So Who is Mort, you ask?

I referenced him w/o explaining in my prior essay, though I linked to his “creator” Eric Lippert’s blog for those who take matters into their own hands when presented with ambiguity. Mort, according to Eric, is “the professional line-of-business programmer who lacks a degree in computer science but has a great deal of familiarity with Office and VBA, and who typically writes productivity applications shared amongst his coworkers..

Should Mort be allowed in Club .NET?

This essay is about how .NET currently excludes Mort from Club .NET and I make a proposal to Microsoft, or whomever, for how we could easily let Mort in the club’s back door without spoiling the club and having all the cool people get disgusted and leave to crash another club, like Club Java. According to Eric the “cool people (my term) are Elvis (the professional application developer) and Einstein (the expert on object-oriented architectures and/or low-level bit twiddling.)

And now what appears to be real brown nosing (but isn’t, honest!)

As an aside, I have to say that Eric’s blog is probably my current favorite blog. I particularly like his post on The Fundamental Question of Biology where he questions the wisdom of the world view that asks “If I put these two life forms in a jar, which one wins?” (maybe he’s been paying attention to the US political process as of late?) At one point he concludes “The two things in the jar don’t have to eat each other, they can work together. On decision making, he states “but please make your decisions based on a dispassionate evaluation of the pros and cons, not misinformation and myths. If only the rest of the world could be so rational. Refreshing.

Let’s Focus Now…A Kindler, Gentler IDE

The first time these thoughts crossed my mind what when I read Don Kiely’s article Navigate the Road to Whidbey on FTPOnline. The article’s intro summary was:

“The next version of VS.NET includes a plethora of enterprise and RAD features, but the tool remains geared more toward higher-end than occupational programmers.”

In the article Don went on to say:

“On the downside, I suspect that Whidbey will benefit higher-end users and leave programming novices even further behind…There are a lot of new features that target less experienced developers, but you still must have a good understanding of the .NET Framework and the various related tools to be productive with Whidbey, even in VB.NET.”

I thought about Don’s words and it occurred to me that what was needed for the occupational programmer (somewhere between Mort and Elvis, in my opinion) was not VS.NET but instead a new and much simpler entry-level IDE. I shot Don an email detailing this idea, but never heard back. (I’m sure it got caught in his spam-filter; Don’s not the kind of guy to ignore an email. Well, are you Don? :) But, I didn’t follow up either; too many things to do, too little time.

VB6+ Maybe?

Then more recently Bill McCarthy also on FTPOnline wrote the guest opinion It’s Time for VB6+ which got me thinking again. In this article Bill opines that:

“Microsoft’s end (of) mainstream support for VB6 in March 2005 (will leave) VB6 developers having their applications stranded.”

Bill feels:

“Microsoft’s loyal customers deserve better. They deserve another version of VB6. I’d call it VB6Plus, VB6+ for short.”

He further:

“envisions VB6+ as an upgrade to VB6 that bridges the gap with VB.NET. You would create VB6+ projects in the Visual Studio .NET IDE, enabling you to work on both VB6 and VB.NET projects as part of a unified solution.”

He continues on in his article explaining his proposal in depth and making very good points.

Like Don’s article, Bill’s got me thinking. However, my thoughts about Bill’s specific proposal were unfortunately:

“Great idea! … Ain’t gonna happen.“

As we all know, Microsoft abhors backtracking, and I think Microsoft would see VB6+ as backtracking. It certainly wouldn’t be built on their newer .NET architectures. So though I think it would be really great if Bill proposal were to see the light of day, I’m not holding my breath.

Call in the Cavalry Instead!

Rather than a full fledged VB6+ to solve the dilemma Bill’s editorial attempts to address, maybe Microsoft should deploy half its Microsoft Consulting Services army in service of customers with major VB6 applications that need to move to .NET. They could do all the heavy lifting to determine what, in the real world, it takes to convert a VB6 app. And from those experiences they could create the VB6 to VB.NET Conversion Kit kind of like the old Windows NT 4.0 Option Pack.

They could even recruit the services of 3rd party vendors to help. And the results might even deliver in part what Bill envisions for VB6+. But the kit wouldn’t be on the scale of releasing a backward stepping product, so it wouldn’t require the same polish (or resources), and it wouldn’t have any of the negative PR implications of a VB6+ (I can just hear Scott McNeely at the next JavaOne now “.NET sucked so bad they had to go back to VB6! Better to avoid that one.)

Anyway, back on topic, Bill’s editorial once again had me thinking about the need for a simpler entry into .NET. .NET is such a wonderful platform, but it just takes too damn long to become reasonably productive. But I didn’t email Bill as I’ve never met him personally, and, well, I was just too busy.

Better Late than Never

About the time Bill’s article came out, I started on the first full re-architecture of our websites in well over 5 years (I know, I know, I’m embarrassed; what can I say?) Part of the reason we waited so long was we wanted to move to .NET, but hadn’t been able to get over the hump. (Remember, as I said, I am Mort — you may need to get your browser to translate this.) Sure, we could have built a hacked together ASP.NET website, but I wanted an architected ASP.NET website, and I just couldn’t get it done part-time.

I just don’t like ASP.NET. There, I said it.

I alluded to it in my earlier essay but my collective experience with ASP.NET has me finally admitting to myself that I really don’t like ASP.NET. Don’t get me wrong; I absolutely love .NET in general. But a few small design decisions that permeate almost every aspect ASP.NET are, for me, the “too many cooks that spoil the broth. That doesn’t mean I don’t think many aspects of ASP.NET are great, but its hard to enjoy the fabulous view when downwind of the chicken farm.

So what exactly are the decisions with which I have issue? I’d really love to go into them now, but they deserve a full essay on their own, complete with at least one other essay as background. I’ll just have to leave that subject for another day. I hope from this admission my inbox doesn’t runneth over with nasty-grams; if I’ve angered anyone please let me first write my justifications because slamming me.

ASP with .NET Objects, what a combination!

Anyway, in building our new website infrastructure (which unfortunately is still not fully live yet) we decided to go with a .NET middle-tier and backend objects, and use ASP with VBScript objects for the front-end. Though it sounds quite bizarre, it has worked quite well, actually.

This process has had me pushing VBScript quite hard, hence one reason I’ve been enjoying Eric Lippert’s blog so much. I’ve created a pretty nice class library in VBScript, and I’ll post many of the classes showing what I’ve learned if I get much call for it.

But the one thing I haven’t been able to do well is ensure good error reporting when my class library is misused. There are several things that conspired against me; lack of “proper error handling, inability to access the call stack programmatically, and no way to test for a match in the number of parameters between caller and called routine. In some cases I can’t trap for errors which requires my class library user to delve deep into the guts of the library code and trace back to realize that it was just a simple parameter mismatch; what a waste of time! But I digress.

The reason I went into so much depth about our new website architecture is to emphasize my recent in-depth exposure to both .NET objects and VBScript on the same project. This experience added to my thoughts about the need for an easier route to .NET and what that route ideally might be.

Too much of a good thing?

Though I absolutely love the robustness features of .NET; the type safety, the namespace hierarchy, attributes, versioning, and so on, I also really like programming in VBScript because when I’m tired and just want to get something done so I can move on to that next urgent item that just hit my desk, VBScript doesn’t take that much effort.

But whenever possible (i.e. on any non-legacy code) I do use Option Explicit for VBScript, and would declare variable types if given the option. But sometimes it’s nice that I don’t have to. Sometimes it’s nice not to have to understand the type conversions. Sometimes it’s nice not to have to figure out how to get files into streams, or streams into text, or which collection to use. Especially if you are Mort and you just want to get something done.

But even though I am Mort, I’d like to do it the best way. In some cases I just don’t know how to yet. If I have to spend too much time learning before I can be productive, I’ll never do it the best way, let alone do it at all!

Is .Net Deficient?

Then Jon Udell of InfoWorld, one for whom I’ve grown to have much respect of late, wrote an article entitled Does .Net have a dynamic-language deficiency? which added to my thought on how to empower Mort to use .NET.

In his article Jon states:

“Often labeled “…scripting languages and regarded as useful mainly for data mining and automated system administration, their well-kept secret is that these highly-productive languages power more mission-critical services than enterprises like to admit. The .Net world lacks a(n) … equivalent.“

He goes on to further state:

“Despite lots of second-guessing, there’s no consensus that the CLR is inherently unfriendly to dynamic languages … Such projects always seem to spring from an inspired individual or small team. In fact, Microsoft has such a team. It created JScript .Net, the most dynamic of Microsoft’s .Net languages. But JScript .Net is the unloved stepsister of C# and VB .Net. Dynamic languages are rooted in a culture that is simply not indigenous to Redmond. That may change, but for the time being, the future of dynamic languages in .Net lies with non-Microsoft innovators.”

That reminded me of talks I’d had with Paul Lamoreux and Jonathan Hooten of Sapien, publisher of PrimalScript and PrimalCode. The former is a text editor for scripters (VBScript, Jscript, etc.) and the latter is a lightweight alternative to Visual Studio.NET. They confided in me that, whereas the latter hadn’t met their sales expectations, the former sells like hotcakes. Their primary market for PrimalScript? Networks administrations writing stuff like ADSI code.

Let’s ask ourselves: are network administrators going to buy VS.NET and learn to program ADSI in .NET? Heck no! A net admin is a Mort too. What else is clear: they aren’t buying PrimalCode to switch to .NET either. PrimalCode is lighweight compared to VS.NET, but it’s still the same languages: C# and VB.NET. And it is still hard. Network admin scripters have been disenfranchised by .NET. All Morts have been disenfranchised by .NET.

Anyway, reading Jon’s article and comparing to my conversations with Sapien and my earlier thoughts on Don’s and Bill’s article it hit me clear as day: What .NET needs is a VBScript.NET! I shot off an email to Jon with the idea, and a mentioned I’d possibly post “on a future blog and he replied: “Great, post it and I’ll link to it! (Jon, its here now; where’s that link? :) (There you have it; the foot-in-mouth that actually got me started down this blog-of-no-return! Well, anyway…

A few days later I was talking to Robert Scoble with the goal of telling him VBScript.NET idea, and besides suggesting a few Softies to ping on the subject (Eric Lippert being one), he shamed me into starting the blog! So here I am.

What is VBScript.NET?

Finally to the meat. I can envision you probably have a preconceived notion about what would be VBScript.NET. That’s not what I’m envisioning! Seriously though, I’m not exactly envisioning VBScript ported to.NET. Instead I’m thinking of a dialect of VB.NET. This dialect would be designed to be as easy as possible yet would still ultimately be 100% .NET compatible.

When I emailed Eric Lippert, he answered with a long and detailed reply telling me how my email “brings back many fond memories and how a group of Softies had considered VBScript.NET at length but buried it for numerous reasons prior to asking anyone in management to champion the idea. He even went on to say he

“Actually spent a weekend writing a parser (in C#) that takes any currently legal VBScript program and translates it into a VB.NET program!”

We discussed for a few more emails, but in final he said

“I don’t think you’re likely to find anyone who’d be willing to champion this cause to management.”

Bummer.

But wait!

What Eric and his team pursued was porting VBScript to .NET. That is explicitly not what I’m proposing. Instead what I’m proposing is a new dialect of VB.NET that has only the flavor of old VBScript but borrows the name because VBScript’s lineage as-it-exists-today is essentially neutered, using the name has a nice orthoginality to it, and finally using the name lets VBScript live on, albeit in a new form.

I’m proposing a VBScript.NET that is not designed to be compatible, but designed to provide “transitionality (see previous essay) from beginning scripter to expert VB.NET developer. Backward compatibility be damned.

What is VBScript.NET? Revisited.

I envision VBScript.NET to be a simplified dialect of VB.NET that is fully upward compatible with VB.NET (i.e. VBScript.NET would run any valid VB.NET code, but not vice versa.)

VBScript.NET would not be implemented as a pre-preprocessor. Instead, VBScript.NET would have a full lexical parser that would read VBScript.NET code, perform analysis, and then decorate the parse tree with that required to generate valid VB.NET code. VBScript.NET would make well defined assumptions anywhere it allowed the programmer to be ambiguous, something VB.NET only does sparingly.

VBScript.NET would take most of the difficultly out of learning .NET, and a current VBScript programmer could learn it in an afternoon. What do I think makes programming in.NET difficult when compared to using a scripting language like current VBScript? The following:

• The Common Language Runtime – The CLR is a very rich object-oriented library that is beautifully designed with an incredible level of power. But it is overwhelming for Mort to learn when all Mort wants to do is just accomplish one little task, like reading from a text file.
• IMPORTS statements – The Namespace hierarchy is a beautifully elegant implementation that helps manage the tremendous complexity of the CLR combined with third party components, and developer’s own components, but it is overwhelming for the novice to understand what is where in what namespace and in what DLL.
• Data-type declaration and CType() conversions – The rich collection of data types and the type safety in .NET is brilliantly implemented and ensures the vast majority of code has been verified correct at compile time which is essential for hugely complex enterprise level applications. But for the net admin trying to write some ADSI code to create 100 new AD user accounts, it is overwhelming.
• Project Files and Entity Declarations – The project structure in VS.NET and the requirement for entity declarations (class, sub, function, etc.) really helps manage code on large projects, but is overwhelming when all someone wants to do is execute five lines of code.

Did you happen to notice the repetition of the word “overwhelming?” I thought so.

How would we eliminate the things that make diving into .NET difficult for Mort? In the following manner:

• VBScript.NET would have a Namespace called Microsoft.VBScript which would be automatically IMPORTed and would contain essentially all the same functionality that VBScript contains by default. Developers could use the IMPORT statement for other namespaces, but if they are using VBScript.NET in the same manner people use VBScript today, they would almost never have to.
• VBScript.NET would also provide a Simplified Type System to provide a half step between no typing and full typing:
  • • VBScript.String (same as System.String),
    • VBScript.TrueFalse (maps to System. .Boolean; could also be called VBScript.Boolean),
    • VBScript.DateTime (same as System.DateTime),
    • VBScript.Number (morphs between VBScript.Integer and VBScript.Real based on need),
    • VBScript.Integer (same as System.Int32),
    • VBScript.Real (same as System.Double),
    • VBScript.Money (compatible to System.Decimal)
• VBScript.NET would not require project files or even entity declarations. VBScript.NET would execute lines of code without the need for Sub or Function, or Class declarations. An option to generate the VB.NET output showing how VBScript.NET wrapped the code in declarations would give transitionality to help Mort increase his .NET skills.
• Like VB.NET without Option Explicit, VBScript.NET would not require variable declarations. However, when the lexical analyzer found undeclared variables, it would automatically declare in the resultant VB.NET form in the most local scope. An option to generate the VB.NET output with the undeclared variable shown to be declared as it was assumed declared would aid transitionality helping the beginner become better.
• Like VB.NET without Option Strict, VBScript.NET would not require data-type declarations. However, when the lexical analyzer found un-typed variables or non-explicit type conversions, it would respectively declare in the resultant VB.NET form as object unless if could determine the exact data type, or it would implement the assumed type conversion. An option to generate the VB.NET output with un-typed variables and type conversions shown as assumed would provide transitionality to aid in helping the newbie learn..

Surely something will be difficult?

Probably the most difficult implementation detail would be simulating the Execute(), ExecuteGlobal(), and Eval() functionality. Assuming 100% compatibility is not an issue, I believe the essense of the functionality Execute(), ExecuteGlobal(), and Eval() could be addressed by reflection and delegates, possibly by providing both VBScript and VB.NET some simplified syntax for in-line delegates (i.e. essentially anonymous functions.)

How would VBScript.NET be delivered?

Minimally, VBScript.NET script would simply be implemented in a pair of console apps called cscriptnet.exe or wscriptnet.exe in the same manner as VBScript. By default they would simply execute any .VBSX file given, but would have command line switches to allow compilation to DLL and generation of the VB.NET code it created behind-the-scenes. Assuming certain rules were followed, VBScript.NET DLLs could be used by any .NET language. If not, they could only be used by another VBScript.NET script. They could even be implemented such they would throw an error with a detailed error message if an unsafe call was attempted.

What about an IDE?

Eric Lippert told me about the Visual Studio .NET IDE: “I’m a professional developer ON THE VS TEAM and I don’t know what half of that stuff is for. It’s like an airplane cockpit. when he described what he thought the team could do to improve it. I completely agree; VS.NET is just too damn hard for Mort. Ideally, Microsoft would position VS.NET as the “Professional Developer’s IDE and create a new IDE for VBScript.NET that is super simple to use without most of the bells and whistles of Visual Studio.NET. This IDE would also ideally be free like WebMatrix (maybe it would even be WebMatrix?)

While I’m envisioning, I’d like this IDE to let me highlight lines of code in a script and just run them with a keystroke just like one can do using SQL Query Analyzer. This IDE would behind-the-scenes wrap that highlighted code in a “Sub Main”, call the codedom to compile it, then load the IL to execute it. This IDE, unlike SQL Query Analyzer, would also follow the file open/save/close metaphor like any other text editor.

Further the IDE could generate the behind-the-scenes VB.NET by having the user simply highlight the code and press a hot key. Options would be copy-to-clipboard, replace highlighted VBScript.NET code with VB.NET code, or create in another window. This would be an enormously helpful transitionality feature for teaching Mort how to become a better .NET programmer.

But isn’t 100% Compatibility with VBScript a Must?

Clearly to provide 100% compatibility with VBScript would be a huge effort in development but even more so in testing. But contrary to Eric Lippert’s assertion, I don’t think that level of compatibility is needed. After all, the smaller the project, the easier it is to port and/or rewrite, and by its very definition most VBScript apps are pretty small. Sure there are some pretty large VBScript code bases for ASP websites, but most of that code is going to be very straightforward VBScript. The remained shouldn’t be hard to isolate. This differs from VB6-to-VB.NET where practically everything changed; the Ruby forms model disappeared and in its place appeared WinForms. Big difference.

If you consider the goals I’m setting forth for VBScript.NET -– providing an easy entry into .NET for the occupational programmer, and a transitional path to allow them to grow their skills over time -– ensuring compatibility with VBScript.NET is not really a requirement, is it?

There would be those who complain. There always are. But what programmer has never refactored code and not broken code on which a prior version depended? You can rarely significant improve old code without breaking something. Breaking old VBScript is a small price to pay, especially given the birth of VBScript.NET wouldn’t require old VBScript to go away. Heck, VBScript.NET could be configured to be an Active Scripting Host so it could call VBScript in the rare case compatibility with some language features was absolutely required.

Compared to the number of VB6 apps in current use, the difficulty to port them to .NET, and their collective value to their owners, I would assert there would be orders of magnitude less problem with having a VBScript.NET that is not compatible with past versions of VBScript then there was with VB.NET.

What’s the likelihood?

Now that I’ve provided my visions for VBScript.NET you may ask: What’s the chance? Well, Eric already prepped me that there are few Softies likely to champion the idea. But I’m hoping that’s because they viewed it as moving VBScript to .NET and not as a VIP pass to Club .NET for our old friend Mort. Maybe this essay will change their mind?

But probably not. (That is unless of course this essay becomes overwhelming the most popular essay among Microsoft developers in blogspace, and a groundswell of support arises to demand that Bill Gates himself bless VBScript.NET. But then I doubt that too.)

Or maybe Sapien will grab the bait and update PrimalCode to offer VBScript.NET support?

Or maybe some other vendor will grab this ball and run with it? Hmm. I dunno.

Eric did say:

“I still have the source code for the VBScript .NET lexer/parser around. Maybe some day I’ll see if I can give that thing away in case anyone is interested. It would make an interesting series of blog entries.”

That’s probably the best chance. Anyone want get Eric’s source, to band together, and start an open source project at GotDotNet called VBScript.NET? Whose with me…?

In a Nutshell. Or am I just Nuts?

So that’s it, in a nutshell. Well, a really big nutshell. Don’t know what anyone else thinks about this proposal, or if there is any chance it or even any of the features I mention will ever see the light of day, but if nothing else, I’ve enjoyed the brain dump. If you’ve got comments, please post or email as I would love to hear them.