Wow!

Several months ago I blogged about the need for a much simpler way to get into .NET, and I named my proposed solution VBScript.NET (in hindsight the name was a poor choice because people assumed I was proposing porting VBScript to .NET instead of providing a simplified VB.NET, but highsight often is 20/20…) And I was not the only one, lots of others blogged about the same topic (see here, here, here, here, here, and here to list a few.)

It looks like Microsoft was listening after all! Check out the New Visual Studio Express products, in beta at this point! I haven’t downloaded any of them yet, and I don’t know if they’ll address all the issues my proposal was meant to address, but even if not at least they are trying!

Kudos Microsoft!

UPDATE (2007-01-01): I’ve since come to the conclusion that the Express Edition still does not address the needs of the occupational programmer.

microsoft, mort, occupationalprogrammers, tools, transitionality, vbdotnet, vbscript, vbscriptdotnet, visualstudio

First, I’m honored Paul Vick was willing to read my long-winded essay, and second I’m honored he would blog about it.

In this blog post Paul wrote:

…Mike also raises the question of strictness. He makes the argument (echoed by Don Box and others) that many programmers would do better with a world that’s more typeless and less strict than the one they get on .NET. As someone who lives day to day in a strongly-typed world (so to speak), this seems somewhat counter-intuitive: less typing usually equals less performance and less compile-time checking, leaving problems to be discovered at runtime. In fact, one of the major features of this release, generics, is specifically about making it easier to have *more* type safety and better performance at runtime. So the persistent voices in favor of scripting appear to be swimming against the tide. The question is: are they right?

Is Strictness Bad?

Let me clarify my point about less strictness. I for one absolutely love strictness; I think it makes far more robust applications possible. .NET is fabulous; I still program some in ASP/VBScript and I see so many things about .NET that I wish I could use.

So the cry for less strictness (at least from me) is not a belief it does not have value but instead about the minimum skill requirements for someone to become minimally productive. Every additional bit of required strictness adds one more thing for the person with few or no skills to learn before they can get started. “Occupational“/”Hobbiest” programmers (Matts and Morts) have short attention spans (!) because they have to get a job done. If learning to IMPORT this or CTYPE() that takes more than a few minutes, they’ll most likely give up and do without or go elsewhere (god forbid!) 

I don’t want to let them become sloppy coders, I just want to see you lower the initial barrier that currently keeps them from getting started.

Strictness is Good, but we need Accessibility and Transitionality

No, it is not wanting less strictness, it is about wanting .NET to be more initially accessible. When your parents first taught you to ride a bicycle, didn’t they give you training wheels? It would have been a lot harder (with a lot more skint knees) without! Do you use training wheels on your bike today? Of course not. Did you ski the black diamond on your first ski trip? (I hope not.) Did you get a learner’s permit when learning to drive a car? Were you able to windsurf within the first minute you tried? Don’t governments require hours and hours of practice with a skilled instructor onboard before they allow you to fly a plane solo?

Life is full of things that require signficiant skill, but life has many ways to achieve those skills without requiring initial mastery. Programming in .NET requires a lot of knowledge and skill yet .NET offers no training wheels.

So I am not arguing against strictness, I’m arguing for the option of less strictness because that is what is needed to make .NET more accessible to hobbyists and occupational programmers.

But don’t Send them Adrift without a Paddle

However, I also believe the option for less strictness should go hand-in-hand with a strategy for providing transitionality. Many years ago a Microsoft Windows NT Server program manager whose name I cannot remember told me “scalability doesn’t just mean scaling up.” Similarly transitionality isn’t just about making it easy for the beginner. Transitionality is also about making it easy for the beginner to become an expert.

A transitionality strategy from Microsoft should incorporate messaging and education. It should not only promote how easy .NET is for building small solutions with lax strictness, but it should also promote how important it is for people to learn strictness and incorporate into their apps, especially if those apps will grow in scale. I think this education is important to pre-empt those not classically educated in computer science from developing ignorant biases against strictness.

A transitionality strategy should also incorporate methods of helping the beginner learn by example. In my VBScript.NET essay, I talked about an IDE and/or script-processing EXE that would show VBScript.NET code after it was converted to fully decorated VB.NET code complete with all strictness options so people can easily see how it could/should be done using their own code as the example. If you’d like more examples, see any of my other posts on transitionality as they all cover this concept in one way or another.

And don’t Fragment Expertise

One last point I think it is important to make based on some of the response I’ve seen to my VBScript.NET essay. It is critical that whatever Microsoft offers to make .NET more acccessible is also compatible with its core .NET programming languages, and minimally I think that means VB.NET.

As I tried to get across in my essay, my concept for VBScript.NET was not a new language. It was not a proposal for a .NET version of VBScript. Instead I proposed a lexically simple dialect of VB.NET layered on top of VB.NET with tools that made it easy to use. Tools such as a simple IDE that would show VBScript.NET code converted to VB.NET and a “script processing” EXE that would minimally execute just one or line of code without requiring projects or namespaces or references or that big honkin VS.NET.

Everything a .NET beginner learns should add to his .NET skill, especially in the library and language, though less so with the IDE and tools. That is where I believe VBScript, VBA, and VB6 went astray; expertise in one did not necessarily translate to expertise in the others.

The Bottom Line Goals

I’m not married to my idea for VBScript.NET. The same goals can be acheived numerous ways. I’ll summarize the goals I see:

• Make .NET more accessible to beginners by relaxing strictness
• Provide transitionality to allow .NET beginners to become .NET experts
• Offer tools that simplify use and “tutor” .NET beginners toward .NET expertise “by example”
• Ensure beginner .NET offerings are upwards compatible with expert .NET offerings
• Ensure everything a .NET beginner learn adds to their .NET expertise

So Paul, does this not shine a new light on what I have been proposing? BTW, I really do like your longer posts. They are much more interesting than the short “look there!” type of post by most bloggers.

dotnet, mort, occupationalprogrammers, paulvick, people, transitionality, vbdotnet, vbscriptdotnet

Thanks Eric for acknowledging my post.

Eric, sorry about misusing Mort and Matt. I didn’t see the comments of Peter Torr and your responses until after I wrote my long rambling post (yes I agree, it was long and rambling, intentionally.)

Actually, I feel my comments apply both to Matt and Mort. Mort still has to deal with learning curves; I’ve seen many Morts stuck in a rut of doing something that same old way simply because they don’t have time or won’t take the initiative to learn newer techniques. Making those newer techniques easier to learn would minimize this problem.

Further, you reference that you are going to eschew whimsical names in the future. I for one think they help, but then I am probably heavily influenced by Geoffrey Moore’s Crossing the Chasm which has oft been referred to as "The High Tech Marketer’s Bible." Moore recommends segmenting prospective customers and then naming each one so that it is easier to get a mental picture when discussing. Clearly that is what you at MS have done internally, and I think it helps.

Next, you said:

"And Mike has good ideas — of course, I only say that because I proposed most of them to the VB.NET team years ago. :)"

My response: "Only?!?" :)

And you further state:

"Based on that experience, I absolutely 100% disagree that fracturing VB into a FOURTH variant — VB6, VBScript, VB.NET and the proposed VBScript.NET — is a good way to achieve the laudable goal of lessening the VB learning curve. We can improve VB without fracturing it into yet another variant."

I’m not necessarily going to disagree. Maybe the things I suggested can just be added to VB.NET? Really all I was suggesting was a layer on top of VB.NET anyway. I definitely don’t want to see a VBScript.NET that forks off  VB.NET.

However, you didn’t address the IDE. VS.NET is just far too difficult for many, and I honestly can’t see it ever being easy enough for the occupational programmer and and powerful enough for the professional programmer. Just like there was a need for WebMatrix, there is a need for something for would-be scripters.

So in summary, though I think it would be cool to have a VBScript.NET as I proposed, I more just wanted to bring the issues to the surface because I hadn’t seen anyone address the issue of the .NET and the occupational programmer anywhere else. Thanks again Eric for your comments.

crossingthechasm, geoffreymoore, matt, mikelippert, mort, people, petertorr, transitionality, vbdotnet, vbscript.net