Why .NET needs the (option of) less strictness

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.