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.

4 Replies to “Why .NET needs the (option of) less strictness”

  1. Man, you are right on about this topic. Please keep championing this cause because you’re absolutely right. I’m a VB.Net developer but when I need a quick and dirty test program, or some ADSI code, or I just want to try out a few lines of code to drive some existing COM object I always fire up VB6 because its so much easier and faster. Starting VS.Net is like getting in your monstrous Winnebago to run to the corner quicky mart for some milk. Just give me a moped or something, no what I mean?

  2. Mike,

    I agree with your overall comments. I’m not sure I agree with the idea of relaxing typing, which, unless I misunderstand you, you can do today. I do think beginners need fewer types – 6 – string, date, integer, fractional, boolean, and I don’t care. The difference between single, double, and decimal, or typed and untyped integers of different sizes just doesn’t matter to a beginner. However, I think it is helpful to get them started thinking about typing quite early.

    I completely agree that being able to run a few lines of VB code is very valuable. Among other places you may be able to run it from, I want to run from within the IDE to do quick things.

    Kathleen

  3. Paul: Thanks for the support. Microsoft is doing an otherwise great job with .NET, and though I don’t have to concern myself with all the they do hence I may not understand all the issues, but I hope they will agree with my arguments and consider offering something (sooner than later) that makes .NET easier for the newbie. The ironic thing is, they have already done the really hard part with .NET itself. Maybe if others agree and we all continue to blog about it the dev team at Microsoft will see it as relevent and provide us a solution.

  4. >> I do think beginners need fewer types – 6 – string, date, integer, fractional, boolean, and I don’t care.

    ABSOLUTELY!

    >> I think it is helpful to get them started thinking about typing quite early.

    I agree, though force it raises the bar, and I’m suggesting the lower the bar as much as possible. Writing these essays it has occurred to me that VB.NET doesn’t offer any tools that I’m aware of to help a someone gain skills move their untyped, undeclared, and uncast code to typed and declared and cast code (other than compiler errors.) Would be nice to have a process something that would go thru such code, update with a best guess, and put a "TODO" comment next to each location updated. I think that would help people transition upwards, but if there is a large app (that started as a small app) that uses untyped, undeclared, and uncast code, it is hard to actually convert up.

    >> I completely agree that being able to run a few lines of VB code is very valuable.

    I haven’t tried this yet, but Jeff Key’s snippet compiler looks interesting: http://www.sliver.com/dotnet/SnippetCompiler/
    Ignoring the language simplifications I suggested, from what I see on his web page this might be going the right direction, albeit with the need for a command line version, a good bit more functionality, and being offered by Microsoft so the demographic of interest would learn about it and be comfortable using it.

Leave a Reply

Your email address will not be published.