Some further thoughts about permissiveness…

The discussion so far in the comments section of my entry on permissiveness has been interesting. Some thoughts about the comments so far:

  • I should be clear that my entry was more thinking about how the mission and capabilities of VB could be expanded, not narrowed. A key tenet of VB on .NET has been “full access to the power of the platform,” something that we will not compromise on, especially as Longhorn looms on the horizon. Or, to use the vernacular: there will be no dumbing down of the language.
  • I tend to agree with Eric that creating yet another language, even if it’s just a name, should be avoided if at all possible. Partially, this is my historical bias. For the first third of my career, I had to try and answer the question “Should I use Access or VB?” For the other two thirds of my career, I’ve had to try and answer the question “Should I use VB or C#?” I’m just reluctant to entertain the possibility of adding yet another question: “Should I use VBScript.NET or VB.NET?” Which, I should add, takes nothing away from the essential points of the discussion so far…
  • The more I think about it, one aspect of my question about strictness isn’t really whether it’s “good” or “bad” but whether there are some situations where less strictness is an advantage beyond making it easier for beginners. I think Don Box’s point in the past has been that strict type checking makes dealing with things like XML and web interfaces and data more difficult because they force a certain kind of brittleness onto the relationship. If I add or remove elements from my XML stream or my web interface or my SQL table, consumers will break – even if they don’t actually care about those elements! Could looser typing make programming against loosely structured data easier? Interesting question.

And, finally, I should say that we recognize that our goal to make VB the most accessible programming language on the .NET platform is still not completely realized. The process of consuming and digesting the vastness of the .NET platform has been a difficult, long-term process and one that we’re going to be working on for some time to come. The good news is that we’re going to make some huge strides in Whidbey, both in ways that have been talked about (such as the My hierarchy) and some ways that still haven’t been revealed.

3 thoughts on “Some further thoughts about permissiveness…

  1. Mike Schinkel

    I definitely see what you mean about point #3, and concur. Strictness isn’t always a good idea, even in the strictest sense. 🙂

    As for #2, I also see that point, and am good with it. Maybe what is really needed are more runtime and development options?

    For example:

    1.) an EXE that would compile and then run VB.NET code like cscript.exe does for VBScript,

    2.) Relaxed strictness and a simplified set of types,

    3.) A much easier and lightweight IDE targeted at beginners, and

    4.) IDE features that tutor like converting lax code to strict code based on the assumptions the compiler usings when strict options are not specified by the developer.

    That said, I look forward to all the improvements in Whidbey. The PDC version was definitely nicer than VS 2003 and I just got the VSLive version so I can’t wait to play with it.

    Reply
  2. Karl E. Peterson

    > For the first third of my career, I had to try and answer the

    > question “Should I use Access or VB?” For the other two

    > thirds of my career, I’ve had to try and answer the

    > question “Should I use VB or C#?”

    Did you get something backwards there? Two-thirds of your "career" amounts to a grand total of three years??? That helps explain the newbie (cavalier) attitude, shown in some of your decisions, that resulted in the destruction of others’ code assets.

    > I’m just reluctant to entertain the possibility of adding yet

    > another question: “Should I use VBScript.NET or VB.NET?”

    How about ClassicVB.net? That might bring back the hordes of hobbiests essential to the survival of an "accessible" language. Then again, it might already be too late for that.

    "Fool me once…"

    Reply
  3. paulvick

    The first quote was a bit of poetic license on my part. I worked for a little over four years on Access and have worked a little under eight years on VB. Of those eight years, a little under six years have been on VB.NET exclusively even though much of that was before public knowledge of C#.

    Reply

Leave a Reply