Will Microsoft Meet Occupational Programmer’s Needs?


Defining “Occupational Programmer

I made two posts recently that muddled serveral issues so I am creating a seperate post here to isolate them and provide a location for comments specific to this issue:

Microsoft is not meeting the needs of “Occupational Programmers.”

The first thing I should do is define the term “Occupational Programmer:

“An Occupational Programmer is one whose job is something besides programming. The programs they write are related to their main job such as streamlining tedious processes or automating labor intensive tasks. These people only spend a small percentage of their time programming.”

Professionals need Industrial Strength

Occupational programmers have significantly different needs than professional programmers or even hobbyists. Professional programmers need industrial strength developer tools. I could blather on forever defining that but I think most professional programmers know what they need as that’s what they focus all their time doing.

Hobbyists need to Learn

Hobbyist programmers main need is to learn. For them each learning experience grows on the past. Further, I would argue most hobbyist programmers are either younger (i.e. in elementary school, high school, or even college with a lot of free time on their hands) or older (i.e. retired and looking for something fun to exercise their brain.) I’m sure there are many hobbyists in between but I’d argue they are not the majority. Hobbyists goal is often to get better at programming, and I believe they are by definition both passionate about it and interested in learning in ways that occupational programmers simply are not.

Occupational Programmers need Productivity

Occupational programmers don’t have time to learn; they’ve got a real job to worry about. And occupational programmers often don’t care about learning the intricasies of programming at a professional level. Most importantly, occupational programmers don’t program frequently enough to transfer their learning from short to long term memory. Tellingly, Microsoft has a Coding4Fun website for hobbyists, but doesn’t have a Coding4Work website for occupational programmers!

Occupational Programmers need Discovery

Occupational programmers also need to be able to discover how to do things without lots of prerequisite knowledge. They need to be able to be highly productive every time the sit down to code. In that vein Microsoft’s “My” object is intuitive enough and addresses discovery.

Occupational Programmers need to Experiment

On the other hand, occupational programmers need to painlessly try things to see what works and not be distracted by lots of complexity. It is here where even Microsoft’s Express Editions fall short. They need a far simplier environment that allows them to type in a single line of code, highlight it, and then press a key to run it; no other prerequisites required. And if, for example, the code won’t run because of a missing reference the environment should pop up a suggestion based on an index of all available components on the user’s system, the occupational programmer should never be left trying to figure out where to go next to solve his problem.

In other words the occupational programmer needs a powerful interpreter but one that works more like SQL Query Analyzer than a command line interpreter. SQL Query Analyzer’s is it’s “canvas” that allows one to leave lots code lying around in various states of completion while it only executes the code that the user has currently highlighted.

Occupational Programmers need Progressive Disclosure

occupational programmers need Progressive Disclosure. They shouldn’t open up a development environment with numerous items competing for their attention. They shouldn’t have to worry about projects or properties or toolboxes, they should have a screen where they can start writing code and the equivalent of a (well designed) “Start” button and menu/wizard system.

Occupational Programmers need their Skills Grown

Additionally, the languages and tools used by occupational programmers should empower they to continually improve their skills without even trying, as they end up building significant systems over time. Some will even change careers to become full-time professional programmers eventually. If they are sandboxed with dead-end language and environment, think VBA or Visual Studio Tools for Applications, that’s no good either.

But Don’t Sandbox Occupational Programmers

And occupational programmers should be given the same languages professional developers use, but in a less-restrictive form; one potential example being a dynamic version of VB.NET with duck typing, etc. This is so professional developers can reuse and refactor the occupational programmer’s components and code. Occupational programmers have specialized knowledge that professional developers simply don’t have and putting them in two different sandboxes doesn’t make sense.

Focus on Languages and Frameworks, not GUI Tools

Further, the tool builders should focus on language and framework first, not the visual tools. Although this applies across the board for developer tools, it’s especially important to state related to occupational programmers because the tendancy is to just throw lots of GUI at less experienced developers, but that approach is fraught with peril (anyone remember Visual InterDev Design Time Controls?) I can acutally write a long post on this topic alone, and plan to, but suffice it to say that the focus should be on making it very easy to implement something in code using the language and the framework, and then create the visual tools to streamline this last.

Not Hard to Serve this HUGE Market

I believe there are tremendous number of occupational programmers out there whose needs are not being served and the irony is that I’m not proposing anything complex. On the contrary, Microsoft has partically all the technology it needs to build and ship the first version of what I’m envisioning within six months or less assuming a 3 to 5 person “SWAT team” that’s sheltered from politics (by 3 to 5 people I mean everyone; development, testing, documentation, marketing, etc.) It would be a tiny investment, and if it was released below the radar and sans Microsoft’s full hype machine it’s benefit to prospective users could be evaluated before they committing Microsoft to supporting any legacies it might create. And Microsoft could call this tool “Power Developer” (I chose that name because of PowerShell.)

There’s a lot more I could say on this issue (and I’ve said some of it in the past), but I’ll leave it at this and await your comments.

Other References

P.S. Here are some posts I made over 2.5 years ago on this and related subjects:

And these are some posts over people have made and/or posts with related comments, in no particular order:

I’m Available…

P.P.S. If any decision makers at Microsoft are listening but don’t currently have the right person on the inside to champion this idea, they should be aware that I am, at the time of this writing, available to help. :)


Clarifying my Microsoft Developer Division Rant


I Ranted and Eric Rebutted

The day before yesterday I wrote a long winded and rambling rant about how Microsoft’s release cycle and process for creating developer tools. I commented on how I believe it is making them fall behind and causing many formerly loyal Microsoft developers to look at open source solutions on non-Windows platforms. I referenced a post that Microsoft’s Eric Lippert wrote over 2.5 years ago titled Top Minds Are Working On It[1]. In retrospect it might have appeared I was being critical of Eric but that wasn’t my intention, and if that’s how I came across I apologize. Instead I was referencing Eric’s comments as symptomatic of the Microsoft culture at large. And yesterday I awoke to find that Eric had issued a rebuttal.

While I Respect the People at Microsoft…

But before I address his comments let me talk about Eric and all the others I’ve met from Microsoft. Eric is actually a brilliant guy, and very likeable. I’ve met Eric face-to-face and it’s obvious he’s much smarter than me. But then I could say that about most of those I’ve met from Microsoft; they don’t hire dummies. As a rule I’ve been impressed with every Microsoft employee I’ve met. They are super bright and AFAICT they do really want to do "Good Things(tm)".

…They Become Detached

But group dynamics being what they are, when you get a group of super-bright people together they become competitive, hone their debate skills, and learn to be strong advocates for whatever their own positions. And they can become detached from the outside world, much like politicians in high office. Politicians are also typically super bright, and most enter office wanting to do Good Things(tm), but once "on the inside" they loose touch with the concerns of their constituents. So I am not condemning Eric and his Microsoft colleagues, I am merely commenting on the culture that results and collectively channels them.

Eric Unconsciously Supports my Thesis!

So I started yesterday’s post saying I’d been planning to blog on the topic for a while but the reality was I still didn’t know how best to explain my concerns. But for better or for worse I did write a rambling essay yesterday, but ironically Eric’s comments made my points far better than I! My central thesis was that Microsoft isn’t meeting developer’s needs because of their processes and infrequent releases and consequently open-source alternatives are meeting developer’s needs instead. Eric’s both debated my examples and pointed out they now plan to address some issues I referenced. But not only did Eric not address my central thesis, he ironically supported it given his rebuttal’s choice of focus! In my post I wrote the following:

"Microsoft’s culture is to argue semantics when reality doesn’t match their world view"

And Eric’s comments proceeded to do exactly that! In my post from 2.5 years ago[1] I called for Microsoft to address things that PHP, Ruby, and Python are addressing today, which Eric rebutted at the time. In yesterday’s rebuttal Eric referenced his earlier comments stating (emphasis mine):

"Second, my ‘esoteric’ reasons for not implementing a scripty version of VB on the .NET platform were hardly esoteric then and are hardly esoteric now. They are (1) fracturing the language further causes confusion amongst customers and is massively expensive for little gain, …"

Dismissing the Proposal, Not Solving the Problem

Now I’ll freely admit Eric is far more qualified to evaluate my suggestion on technical merit, but that wasn’t the point of my 2.5 year old post. Customers with needs a company’s not addressing will often propose solutions they believe will address their needs, yet often their suggestions aren’t workable for whatever reason. People who specialize in addressing customer needs know that rather than dismiss suggestions as unworkable it’s far better to determine the customer’s actual needs and implement a workable solution instead. And often, many other customers have those same needs. So Eric dismissed my proposed solution but didn’t address my unresolved needs that prompted the proposal. I don’t attribute this failing to Eric, I attribute it to Microsoft’s current culture.

Not More Power; Transitionality!

Eric then went on to say:

"(2) we can do things to make VB.NET more powerful without fracturing the language,…"

Ironically, I didn’t ask for a more powerful VB.NET; I asked for one that was easier to start using and one that developers could then easily transition to more powerful usage. Though they believed they were providing an easier to use Visual Basic 2005, they addressed the language but not how people develop applications. Though they made strides with the Express Edition, my biggest concern was with the complexity of the development environment and the language. I suggested an interpretive environment with a transitional language design that allowed new developers to start easily yet be able to effortlessly grow their expertise with use. What I envisioned was something like Boo, but I wanted it 2.5 years ago with a simple interpretive environment, and I wanted it from Microsoft so that it could possibly generate a large and immediate and user base with a thriving community and significant peer support.

Today’s Potential Didn’t Address Yesterday’s Deficiency

Eric continued with the following…:

"(3) Microsoft makes scripting languages like Iron Python"

…but omitted the fact that a robust Iron Python was just a gleam in Jim Hugunin’s eye 2.5 years ago and is still not ready for prime time. Further, Microsoft’s approach is to host IronPython in Visual Studio which does nothing to bypass the complexity of Visual Studio!

Nor Does an Orphan Address Yesterday’s Deficiency

Eric then said:

"…and JScript .NET, use the right tool for the right job."

To which I did a double take wondering if he were really serious! JScript .NET is such the orphan that I can’t even believe he suggested it! The JScript .NET newsgroup has less than a screen full of messages, JScript .NET hasn’t been updated since 2003, and nobody’s even written about JScript .NET in years! So could Eric really have been serious when he suggested JScript .NET? Well, assuming he was, then:

  • JScript .NET does NOT have an easy-to-use interpretive environment, and
  • JScript .NET is a complex language; NOT simple-to-use, and
  • Again, JScript .NET has NO user-base!

And a Potential isn’t a Solution

Moving on Eric said:

"The .NET framework is already amenable to the development of scripting languages."

So why do we still not have a viable scripting solution for .NET supported from Microsoft more than half a decade after the .NET Framework’s first release?

Yes, there’s Powershell, but…

Okay, that’s not quite true. Eric didn’t mention it but in the spirit of honest debate, there is Microsoft’s PowerShell. But while I will freely admit PowerShell is really nice, PowerShell:

  1. Was only just released so doesn’t address the past 2.5 years,
  2. Doesn’t have a development environment,
  3. Can’t be used for web development,
  4. Doesn’t have a compiler for creating components for use in other .NET languages.
  5. Doesn’t have transitionality allowing it to scale up for much more complex projects as the developer’s experience grows.

A Correct yet Irrelevant Point

Eric then makes a point about "scripting languages" vs. "dynamic languages" (emphasis mine):

"Third, I want to make a distinction between scripting languages (languages intended to script things) and dynamic languages (languages which admit a type system which cannot be deeply analyzed at compile time.) Scripting languages are often dynamic languages, however it is entirely possible to use dynamic languages for tasks other than scripting. "

Okay… So Eric’s points are very technically valid, but they are totally irrelevant! Frankly I wasn’t asking for a language that was "intended to script things," I was proposing a language (and IDE) that would be:

  1. Productive,
  2. Easy to start using, and
  3. Scalable as one’s skills evolve.

Call it "scripting", call it a "dynamic language", call it whatever; it’s irrelevant. What is relevant is for it to be productive, easy, and scalable. Microsoft could choose to get there however they will, bit like arguing the semantics of "Car" vs. "SUV" with someone who just needs transportation, Eric’s distinctions were simply irrelevant to the needs. Totally unrelated, I ran across this joke yesterday. What could be more ironic?

Interest Doesn’t Necessarily Change Process

Eric finishes his prior point with:

"The VS team is VERY interested in understanding how to make the platform more amenable to dynamic languages."

Great! But are they going to actually engage people who are not .NET developers in the design of said dynamic languages and their respective development environments and then incorporate their feedback? Or is the VS Team just going to plug another dynamic language into Visual Studio? If the latter they will do so ignoring that Visual Studio users already have the language(s) they need and that there are at least an order of magnitude more people for whom Visual Studio is too overwhelming.

A Solution Offered; Wrong Product, Years from Now

A couple other comments Eric made were:

"C# 3.0 will have the "one line auto-implemented properties" feature you requested for VB. Enough people asked for it, we put it in. I do not know if VB will be doing the same. You’re welcome. "


"Current C# 3.0 features move in the direction of dynamic languages without actually making the language dynamic (lambdas, improved generic method type inference, extension methods, implicitly typed locals, anonymous tuple types). All of these however are implemented so as to keep the language statically analyzable. We are considering features for C# 4.0 which would make the language more dynamic without losing that important statically analyzable core."

That’s well and good, but it doesn’t address VB.NET, and it also makes my own point that Microsoft’s release cycles are too far apart! There are badly needed enhancements and they need to get them to developers more often than once every three years. C# 3.0 is still a way’s out, people need something today, and I personally wonder if I’ll even care about programming by the time C# 4.0 is released. Hell, I hope to have made my fortune and be retired by then! :-) But seriously, C# is a professional developer’s language and adding features to a professional developer’s language wasn’t even close to what I was proposing.

Too Little, Too Late: Acknowledged

In the last paragraph, Eric finally gives tacit acknowledgement of the concerns I raised in yesterdays post:

"Now, maybe these features aren’t what you want, or are too little too late, or the release schedule is too long for your liking, or whatever. That’s unfortunate."

Exactly. The release cycle needs to be compressed by an order of magnitude as it has been at the competition. More on this in a bit.

Studying Users Isn’t Feeling their Pain

Eric then signs off with:

"However I take exception to the claim that we do not study what real users are doing and try to provide tools that do what they want. We do that every day."

With this Eric either misunderstood my point, or more likely I didn’t state my point in a manner that was understandable. Whichever the case, let me clarify. I know the VS Team works hard to study real user’s needs every day. But what I also know is that the people who make the decisions about what gets released and when have considerations that are far different from the needs of developers. And it is human nature for one to place solving one’s own pains ahead of solving the pains of others as people simple can’t fully comprehend pains they don’t experience.

Trade-offs that Shortchange Developers

Eric let’s be concrete; if solving a customer problem today will cause the VS team a problem tomorrow they won’t do it. For example if the VS Team plans to rearchitect something next version they won’t provide an interface that developers need in this version if doing so will make that rearchitecture difficult. Some would say this is good product engineering to which I would actually agree, but it is nonetheless a trade-off that keeps developers from getting what they need today.

Experiencing Pain Empowers Real Solutions

So, if you’ll reread my post from yesterday you’ll see that I didn’t say "Microsoft doesn’t listen to customers"; I know damn well they do. On the contrary, I said that Microsoft’s Developer Division "Don’t solve real world problems." And the reason you don’t is because you don’t experience the pain that those real world problems cause. By comparison most developers contributing to open-source projects are doing so to solve pains which they themselves have, and that is why they are addressing developer needs much faster than Microsoft’s Developer Division.

Yes it is a Paradox…

An observant person would say that I’ve present a rather intractible dichotomy for Microsoft’s Developer Division; i.e. they need to use the developer tools they build to solve real world problems yet they also need to to develop those tools ten times faster! Now I’m sure these comment will cause the blood of those in Microsoft’s Developer Division to boil thinking I believe it’s possible they do their work ten times faster and do real world projects. But I was not advocating that; I’m fully aware of the myth of the "man-month" in software development projects.

…But Solve it You Must, Or Else

What I was pointing out, however, is if Microsoft’s Developer Division maintains its status quo they will slip farther behind and the loss of developers to other platforms will accelerate. And since developers, developers, developers have always been Microsoft’s life blood it is critical they address this issue. Every developer they loose to Linux or the Mac doubly weakens Windows. Microsoft must address this issue if they are to maintain the same level of relevancy during the next twenty years that they’ve had for the past twenty years. And most of what I’m suggesting isn’t complex, and it isn’t new. They probably have most of what they need already written and used internally. They just need to rethink what they are offering.

Change, or Be Changed

So to wrap up this second long-winded essay:

Microsoft’s Developer Division needs to implement drastic changes sooner than later. If they do not, outside forces will soon impose drastic changes upon them and it’s certain they will find those imposed changes to be far more painful. Or as the mechanic on the old Fram Oil Filter commercial used to say "Pay me now, or pay me later."

What if I’m Not Wrong?

P.S. If you’re from Microsoft’s Developer Division and choose to dismiss my concerns, just ask yourself this: What’s the downside for you if I’m right?

  1. Eric Lippert’s post was in response to my post entitled A Modest Proposal: VBScript.NET, aka "Helping Mort use .NET".


Mort, the “Hobbyist”, and the “Occupational” Programmer get their due


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.

Video Interview about the “My” Classes

As I just posted, I was inspired by Channel 9’s video interviews so decided to get a digital camcorder to film interviews with our vendors about their products for posting on Xtras.Net.  However, when I get the opportunity I’ll interview anyone related to the .NET development and post those interviews on my blog.

Case in point, one of my first interviews was with Joe Binder, the program manager at Microsoft for the “My” classes in VB 2005 that I blogged about a few days ago. Anyone familar with Channel9 will note that I learned a lot from studying their HTML and Javascript! :)

Without further ado, here’s Joe (video is just short of 10 minutes long):

Well…..I thought I was going to be able to post it INLINE, but after many hours of trying, a combination of dasBlog and Javascript conspired to keep me from it.  Anytime I tried to post anything to dasBlog, it would strip required syntax from my JavaScript.  I tried updating the underlying XML files, but it wouldn’t recognize it (actually it did for a while, but then it stopped.)  The other problem was Javascript wasn’t recognizing a DIV tag as an offsetParent and hence the Javascript I so carefully scarfed failed!

Grrrrr!!!  Sometimes I really hate programming!

If anyone knows how to help me debug either the dasBlog problem or the Javascript issue, it will be *greatly* apreciated.

Anywho, rather than providing inline, there is a hyperlink to the video here.

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.

Make MS-Office Programming More Accessible

In a earlier blog I spoke the need for transitionality in development tools. One area of greatest need is in Microsoft Office; Outlook, Word, Excel, et. al.

Why Office? Recent versions of Office have provided almost full programmability, a nice object model, a macro recorder, and so on which helps power users automate processes and allows programmers to create applications using components of Office. However there are a woefully small number of people who actually program Office apps given the number of Office users. I believe that although Microsoft gave us great power by making Office programmable, they did not make programming Office accessible. They did not provide transitionality.

Case in point: I was just using Word 2003 and I needed to do a search & replace but search and replace didn’t work for what I needed so I decided to use a macro.

By the way, I was creating a mail merge document and I could not get Word to replace my placeholder text (i.e. ““) with a merge field (i.e. “«CompanyName»”) because a merge field is special. I needed to use a placeholder text because Word 2003 won’t let me add or change fields in my Access database unless I close the Word doc and firing up Access. What a PITA! And definitely a step backward from prior versions.

I recorded the following macro that did a “find” on my placeholder and then inserted the appropriate merge field:

   Sub Macro1()
With Selection.Find
.Text = “
.Forward = True
.Wrap = wdFindAsk
.Format = False
.MatchCase = False
.MatchWholeWord = False
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
End With
ActiveDocument.Fields.Add _
Range:=Selection.Range, _
Type:=wdFieldMergeField, _
End Sub

I tied this macro to Alt-Z and if worked fine. Except I wanted to have it pop-up and ask me for the name of the merge field. And if it didn’t find the placeholder, I did not want it to insert the merge field.

Now I view myself as a pretty good programmer; not the best, but decent. I taught object-oriented programming before it was fashionable (over 10 years ago.) I studied programming as a sideline in college, I’ve programmed in over 10 languages, I wrote a 1000 page book on a programming language product called Clipper, and taught corporate and government developers how to program for seven years, and written a good portion of the VBxtras and Xtras.Net websites over the years, include both the front-end ASP and back-end SQL. So I’m not the typical occupational/hobbyist developer, but my role and position only allow me to program occassionally.

It took me 30 minutes reading help files to learn how to add my desired features to my macro. It shouldn’t have taken me that long. What about the power Word user who doesn’t have the same experience I have? They would have given up (I certainly should have because I didn’t get 1/2 hour of value out of my macro.) Of course a programmer who has worked with the Word object model might say “Duh?!? That is soooo easy! How could you not figure that out in 2 seconds?” But that is the point.

My point is the people most likely to make best use of programming Office are the ones for whom programming Office is generally over their heads: power users. And programmers generally only use Office as a component within other applications; they don’t know what really needs to be automated when using Office; power end users do. If power users were empowered to easily program Office, thousands of freeware, shareware, and commerical add-ons would be developed some of which would form the foundation of new 3rd party add-ons companies. For the most part this hasn’t happened, and all Office users miss the opportunity to use add-ons that were never developed. Microsoft went to tremendous expense to make Office programmable, and are getting a pitiful return on that investment.

What to do? Though I don’t have the answer, I do have some suggestions:

  • When recording macros, include commented-out code that would show how to do something a user might obviously want to do if they edit the macro (i.e. after a “Find”, put a comment in showing how to test to see if the item was found.)

  • Implement toolbar options using short macros and make it brain-dead easy for people to view the source code such by providing a “View Source” option on right click.

  • If using short macros to implement most toolbar options is not viable, do customer research to find out the most common small tasks for which people could use macros and add special macro toolbars for those, with brain-dead easy access to view source.

  • Do research to find out what the most common needs are when coding and create drill-down wizards that insert snippets of code for those common needs (i.e. “Need to ask user for some information and store for use in macro?” for which the wizard would insert compelete code for using InputBox)

  • Do research to find out what higher level needs are and let power users run wizards to write complete macros for those higher level needs.

My hope is someone at Microsoft involved in programmability for Office will see these things and realize that if they could make programming Office more accessible, a lot more people would start programming Office. In future blog posts I’ll give new example of when I find difficulty doing something quick and dirty with Office macros as I run into the inspiration for them (I know I will.)

By the way, here is the updated version:

   Sub Macro1()
Dim strFieldName As String
strFieldName = InputBox(”Field Name:”)
With Selection.Find
.Text = “<” & strFieldName & “>”
.Forward = True
.Wrap = wdFindAsk
.Format = False
.MatchCase = False
.MatchWholeWord = False
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
End With
If Selection.Find.Found Then
ActiveDocument.Fields.Add _
Range:=Selection.Range, _
Type:=wdFieldMergeField, _
Text:=”"”" & strFieldName & “”"”
End If
Loop While Selection.Find.Found
End Sub

Woe be it for the Hobbyist Programmer

I just came across a blog entry that disturbed me entitled Should the hobbyist programmer matter to Microsoft? by Rory Blyth of Neopolean.com. It was not so much the blog entry by Rory that really disturbed me, but the tone of the comments he received (over 100 at the time.) As I started writing this post, I planned to comment on those comments. Instead, all my comments instead focused on Rory’s post. Maybe I’ll comment on the comments in a future blog.

Divining Microsoft’s Responsibility

Rory was commenting on Kathleen Dollard’s Guest Editorial at Visual Studio Magazine entitled Save the Hobbyist Programmer (I think it regrettable that Kathleen choose the term “hobbyist programmer” rather than something like “occupational programmers” because the post’s comments seemed to attack more of what the term “hobbyist” implies than the actual concepts it seems Kathleen was trying to convey.) In his post, Rory starts out by saying:

Microsoft’s responsibility is not to hobbyist programmers. As someone who makes his living by working with Microsoft technologies, I would be rather ticked off if MS were catering to people who weren’t professional coders.

I found that quote most interesting because nowhere in his post did Rory reference Microsoft’s corporate by-laws, mission statement, or analyst presentation where thye indicated they had explicitly chosen to avoid meeting the needs of “non-professional coders.” As far as I know, Microsoft has issued no such statement of direction so I’m not sure why Rory would state Microsoft’s responsibility is not to hobbyist programmers. Has he been speaking to Gates or Balmer and just not told us?

She turned me into a Newt!… Well I got bettuh.

Continuing, Rory goes on to state:

I’m not so sure where the increased complexity is. I did quite a bit of VB6 programming before moving to .NET. I found the switch to be a bit of a shock, but when I was over the hump of getting accustomed to .NET, I found my job much easier.

Odd. If there were no increased complexity, what “hump” would there have been to get over?

Compare apples and oranges; they are both eaten

In his post Rory also implies an analogy comparing an older vs. newer car with the hobbyist programmer vs. the professional programmer:

Making changes to accommodate the tinkerers would be like rolling back advances in auto engineering. My car is held together by more electronics and gizmos than you’ll find at NASA Mission Control. I can’t change my own oil, and I sure as hell wouldn’t try to yank a spark plug out. Although I’ve been denied the chance to put my car on blocks and work on it over the weekend, I’ve been granted an automobile that is much more efficient, reliable, and powerful than I would have had if it had been built with accessibility to non-mechanics in mind.

I tried to understand this analogy, but I just could not get it to fit:

  • Changing oil and spark plugs is routine mechanical maintenance. Programs have no mechanical maintenance. Assuming programs are designed correctly then never “wear out.” There is simply no equivalent in software for the changing of oil or plugs.
  • Automobiles were generally designed to address a common use case: transportation. As designed, they meet the needs of most people who use them, although probably never perfectly but almost always good enough. Automobiles are far more analogous to applications like Word and Excel than to development tools which are designed to create software for new use cases.
  • It is simply not possible for one person with only intellectual resources to modify or create a new type of car to meet new use cases.
  • In the automotive field, the better analogy with development tools might be the tools required to fabricate new automobiles. Still, the physical requirements of creating an automobile to meet a new use case vs. the lack of such requirements for programming seem inexact analogy at best.

Maybe another analogy would be the professional drivers whose job it is to use cars (and trucks) to transport people or things from one location to another such as truckers, taxi drivers, package deliver drivers, and so. By comparison there are many non-professional drivers who also transport people or things by cars (and trucks.) We could possibly imagine a professional driver saying about General Motors:

General Motor’s responsibility is not to hobbyist drivers. As someone who makes his living by driving General Motor’s vehicles, I would be rather ticked off if GM were catering to people who weren’t professional drivers.

It would seem that might not make the most sense for GM as its market for drivers who transfer people or things from one location to another is larger if it does not ignore the “hobbyist” driver. I won’t further comment on this.

Mommy, where do “Professionals” come from?

Elsewhere in his post Rory states:

Gone was the horrible combination of procedural and OO programming styles. I no longer wrote code that made use of some mysterious global function that existed in god-knows-what library. My web applications are no longer monolithic pages of stand-alone code that’s about as reusable as a condom. Life is better.

Strange. By implication Rory states he is a professional programmer, but my understanding is that if one is a professional programmer one wouldn’t large monolithic modules of stand-alone code that are not reusable. But maybe that is naive on my part as technically the definition of “professional” means “they get paid to do it.” So maybe “professional” doesn’t mean one is actually reasonably skilled in their profession?

But maybe that too would be an unfair interpretation. Maybe when Rory used the term “professional programmer” he meant someone who has developed a level of skill and expertise in the area of programming, and someone who would be considered a “professional programmer” by others holding the same designation. That’s probably what he meant?

Assuming that definition, let’s revisit Rory’s last quoted statement above. Is it possible that Rory was not always a professional programmer but instead actually learned his skills over time? Maybe Rory is now a skilled professional programmer, but earlier he was not? That would seem logical as I don’t believe on the day of one’s birth, a person has ever left the mother’s womb carrying with them the designation of “professional programmer.” (please post comments and provide references if any readers know otherwise.)

Based on that postulate, wouldn’t logic dictate that the state of being a professional programmer would require a transition from being something less of a professional programmer? Further, it would seem logic would also dictate that is it not possible to instantaneously transition from being “not-a-professional” to being a professional if being a professional by definition requires expertise?

If my logic is all correct, that would then explain how Rory could be consider a professional programmer now yet at one time his code was previously “implemented using a horrible combination of procedural and OO programming” which is inconsistent with how a professional programmer would implement code. Clearly in the past he was not (as much of) a professional programmer as he is today?

The logic would also appear to reveal that there are not just two states, one of being a “professional programmer” and another being a “hobbyist programmer“, but instead an almost infinite series of states in between the two extremes. Given that, it would follow that it would be very difficult to determine just exactly to whom Microsoft has responsibility, assuming there was some way to determine, in this area, just to whom that specific responsibility would be.

Since any given state along the continuum between hobbyist and professional is infinitesimally small, how could Microsoft limit its target focus to one exact state along the continuum? Given the costs of creating and supporting development tools, would not Microsoft be required by the laws of economics to provide tools that could be used by a broader range of programmer’s along the continuum?

If so it creates the quandary of where to stop along the continuum as one targets professional and expands target toward hobbyist. Since all it is that appears to limit the hobbyist from the professional is skill and expertise, then would not catering to the hobbyist in turn generate more professionals since the hobbyist becomes like a professional each day programming? That would tend to support the earlier argument that a programmer transitions from being not-a-professional to a professional over time.

Divining Microsoft’s Responsibility, Redux

To finally bring this all to closure let’s consider the modern publicly-held corporation in a capitalist society. My understanding is that such a corporation’s primary responsibility is to its shareholders, and public company shareholders generally want, all other things being equal, for the share price to be increased. Since Microsoft is a modern publicly-held corporation in a capitalist society, it would seem Microsoft’s responsibility is to its shareholders and hence to increase the price of its shares.

In the past, ignoring government intervention, Microsoft has proven itself rather adept at increasing its share price (I personally am glad I bought Microsoft shares many years back, which I have since sold at a gain.) I think it can be argued Microsoft’s strategy’s for increasing its share price have generally been to increase the installed user base of Windows.

Further, I think it is reasonable agreed computer users generally purchase computers because they provide applications that provide the users with some level of value. Since developers create applications, it would seem empowering developers would help increase the number of applications available. Simple math would then imply that the more people developing applications for Windows, the more potential users would find applications for Windows they would value and hence be more likely to purchase Windows from Microsoft. Further it would seem logical that users would be more likely to value applications developed by programmers whose skill and expertise levels were greater because those programmers would be more likely to create programs of higher quality.

Given all of these postulates and theorems, it would seem Microsoft’s best strategy would be to focus on creating as broad a base of programmers as possible, and enable as many of them as possible to move from “hobbyist” to “professional.” Doing this would be most likely to increase the number of quality applications available for Windows, which would likely increase the number of people buying Windows, which would likely increase Microsoft’s share price. Would this not be the most logic strategy for Microsoft given the analysis?

How I see it

Assuming I have not made any logic errors in my prior analysis, it would then seem that, regarding Microsoft’s “responsibility“, the following could be said:

Microsoft’s responsibility is not only to professional programmers but also to hobbyist programmers, and all programmers in between. Anything less, as a modern publicly-held corporation in a capitalist society, would be a dereliction of their duties to their shareholders to whom they have ultimate fiduciary responsibility.

Anyway, that’s how I see it. :-)

Responding to Eric Lippert’s Blog Entry

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.

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."



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.

Development Tools Need Transitionality

This essay is really a prelude and prerequisite for my next planned essay, the essay which was one of the several catalysts to start me blogging in the first place.

What are Tools?

Let me start by defining some terms: "Tools" and "Transitionality." By "Tools" I don’t necessarily mean just 3rd party components like grids and menus, and 3rd party utilities like installers and help writers. Instead I refer to any software developers might use be it languages (C++/C#, VB/VBScript, Perl, Python, etc.), IDEs (Visual Studio, Eclipse), Installers, Database Query Apps, Source Code Control, and so.

Rewind to College Days

Let me define "transitionality" via anecdote. Around 1985 I took a course entitled "Human Factors in Software Development " from a professor by the name of Dr. Albert N. Badre. Dr. Badre was and is highly regarding in the software industry for his research in human factors. He consulted with Lotus on their 1-2-3 interface, and I took his course shortly after he published the papers entitled: "Designing Transitionality into the User-Computer Interface." (Ironically Lotus was suing Borland for using its user interface while I attended this course; clearly Lotus didn’t understand the market value of owning the user interface standard. But I digress.) Badre’s course had a lasting impression on me; more than almost any other course I took while at the North Avenue Trade School. In hindsight I was very lucky to have studied until Dr. Badre, even if for only one course.

Beginners vs. Experts

User-Interface Transitionality as defined (to the best I can remember) by Badre was the ability to morph user-interface so it was easy for a beginner and efficient for an expert. Further, though beginning users never make it to expert status, expert users were explicitly defined as being a beginning once. Although this latter point seems hardly worth stating, it was an important to optimizing user interface transitionality.

Trashing the Mac

I remember Badre praised the ease of use of a Macintosh, but abhorred its transitionality. This gave me great pleasure as I’ve never been a fan of the Mac, possibly for unconventional reasons (however, elaboration on subject is for another day.) Of course Badre also gave the Microsoft O/S of the day — DOS — failing marks its beginner user interface. But as I was a wet-behind-the-ears kid who foolishly considered himself a DOS expert, I really didn’t mind at the time.

Point-and-Click = Easy?

So, part of transitionality is the need to have both an interface for beginners and an interface for experts. In the day, a point-and-click GUI was enough to be a good beginner interface, and a command line was all that was needed for experts. Of course today software is more sophisticated and those distinctions aren’t sufficient, but the general concept is the same.

Feed Me, Seymour!

But just having both beginner and expert interfaces is not sufficient to provide great transitionality. Instead, having great transitionality requires that the path to becoming an expert is the ongoing use by one who starts as a beginner. For example, IntelliSense has a pretty good transitionality mechanism. The developer using a given set of objects for the first time is a beginner. Over time IntelliSense "tutors" the developer on the use of those objects until, possibly, the developer becomes an expert.

But the Tutor Could Improve…

As an aside I contend that IntelliSense could provide much better transitionality that it does currently. Instead of just providing the property/method syntax, it could also provide help with semantics including the ability to pre-select from standard multi-line patterns of use and the ability to sense which patterns are being used to offer up examples and suggestions. I know Whidbey is adding improvements in this direction, but I doubt to the extent I am envisioning. This proposed level of IntelliSense is much more advanced than current, and is probably several product generations of R&D away.

On the Other Hand

For counter example, Excel has a nice point-and-click interface for the beginner, and it has a VBA-based macro language for the expert. But other than its pitiful macro recorder (subject of a future blog) Excel has no way for the user to transition from beginner level to expert. The expert crown instead requires lots of initiative and hard work on the part of the user to obtain.

Just Say No to Dry Spells

One final important point: To embody transitionality a tool needs to eliminate big discontinuities in Time & Effort Invested vs. Productivity & Expertise Gained. More specifically, one should not have to invest hour and hours of study to accomplish the next simple task. Anyone with significant expertise in Visual Basic 6.0 but new to .NET who has tried to simply open and read from a text file in VB.NET or C# knows what I mean! Fortunately Whidbey addresses that specific issue.

To illustrate, here are few simple conceptual charts from our friend Mr. Excel:

Transitional Interface Non-Transitional Interface

Note that if investing one unit of time & effort gains you one unit of productivity & expertise, you’ve got pretty good transitionality. If you have to invest many, many units of time & effort to gain any additional productivity and expertise, transitionality is not good (can we say, C++?)

Another Blast from the Past

While in college I participated in the co-op program, going to school for a quarter and working in a industry for a quarter (Remember the quarter system? That infinitely logical scheduling structure that organized the school calendar into four essentially equal time periods? Ah, but that was before the college football lobby got its way and universities converted to the semester system en mass. Which make oh…so…much…sense. Yeah right. Score one for academics. Not!)

One of my co-op jobs was technical support at IBM Atlanta for the Personal Decision Series, or PDS. PDS was just like Microsoft Office except it was for DOS. And except it really wasn’t usable. And it except it didn’t even gain 0.9% let alone 90%+ market penetration. But then you already knew that last fact.

Anywho, among about 20 co-ops I was the geek that liked computers and software. Everyone else liked working for IBM. And being part of the IBM co-op social club. So I got all the technical assignments. Like three weeks in Menlo Park, California doing regression testing on PDS. But that’s another story.

I also got assigned a competitive analysis for PDS. They gave me copies of Ashton Tate’s Framework and Lotus’ Symphony (anyone remember them?), and another package from god- knows-who because I can’t remember called "The Smart Series " (maybe it was "Smart Software?" I dunno.)

Framework was really, really cool, but it was basically worthless. Symphony was cool but not quite as cool and only worth a nanometer more than Framework. Both were "integrated packages" by which I mean all functions were in the same program. Imagine writing letters and managing databases, all in Lotus 1-2-3. Not much difference.

The Smart Series actually blew away the competition, PDS included. It was a collection of separate apps that all integrated nicely. Well not as nicely as MS-Office apps do today, but remember, this was 1983 and DOS, okay? ANY integration back then was good integration.

But what really set The Smart Series apart was the fact it had a command line and everything that a user could do with a menu option or a keystroke sequence could be issued as a command. Not terribly revolutionary; kind of like Excel and VBA, right? EXCEPT! You see Smart Series would build commands for you in plain sight on its command line as you used menu and keyboard options. Basically it had beautiful transitionality, though, evidently, terrible marketing.

And the Smart Series transitionality feature is something that, to this day, MS-Office still has not matched.

Finally, Defined:

So it is time to return back to developer tools; I can now define transitionality for them:

Development Tools have transitionality if they allow a developer to be productive with a very small amount of learning, provide the developer the ability to gain expertise over time as they develop, and rarely if ever require investments of time & effort that far outweigh any expertise gained .

Real Programmers Don’t Need Transitionality!

I can hear it now: "Real Programmer’s don’t need transitionality! Real programmers can figure it out themselves! Real programmers put semi-colons at the end of the line."

My response? "Whatever! " [Oops, sorry about the semi-colon thang. :-)]

Of course Mort (the Line-Of-Business Developer) is a lot more in need of transitionality than is Elvis (the Professional Developer), but even Elvis can benefit.

And when the tool provider offers transitionality, the tool provider benefits even more because the sooner Mort and Elvis can be brought up to speed, the more likely lots of Morts and Elvis’ will soon be using their tool instead of the competitor’s.

The Winners…

Take a look at the Microsoft technologies. Which have taken off to high levels of usage and support? Which have fizzle or outright failed?

ASP for example, is a rather good example of transitionality. How hard is it to create an ASP page? Rename an HTML page! Of course the benefits of doing so are about equal to the effort involved, but remember the graph: little efforts offer little gains, but big efforts beget big gains.

Visual Basic v1.0 through v6.0 is another obvious winner in the transitionality wars. It could have been better, but…whose arguing with that installed user base?

And I’d say the SQL in Microsoft Access is another. I actually taught myself SQL over the years using Access’ query tool. At first I just couldn’t get my head around JOIN and GROUP BY/HAVING. But after trial and error using the query tool all while getting real work done, I’m now a heavy duty user of SQL Query Analyzer (definitely an expert level user tool), and I can do JOINs and GROUP BYs in my sleep. Well sort of. When I’ve having a bad night, that is.

Visual C++ doesn’t count. Lots of people cut their teeth on C/C++ in college and got over the hump long before the ever had to use Microsoft’s tool. Almost no one can afford that time investment on the job; that is what college is for.

…and the Losers

How about Exchange Agents? And programming for Office apps, especially Outlook? And what about BizTalk? (Well maybe part of the problem with BizTalk is their asinine pricing structure, but then that’s another blog…)

I don’t mean no one is using these technologies, just that they haven’t been widely popular like others from Microsoft. I hypothesize at least some of the blame for their lack of popularity has to do with the difficulty to become productive using these tools; when it takes Mort too long to get anything real accomplished, Mort give ups and never uses the tool. And all by exceptional Elvis’ do the same.

Including the Most Obvious Sore Thumb…

So what Microsoft development tool do you think has the most obvious transitionality problems, based on tons and tons of trade press articles recently? And I’m thinking of the tool whose transitionality causes the most problems, not the tool with the most transitionality problems (got that?)

I alluded to it earlier: VS.NET of course; especially VB.NET and ASP.NET. Though many people have complained Microsoft changed VB.NET too much in the transition from VB6, I am not one of those. I believe that "no pain, no gain" is truly applicable here.

No instead I mean that VS.NET does not manage its complexity as well as it should. It takes far too much learning to produce even a simple app. Many developers have made the transition, but only because of great persistence and intestinal fortitude. And they were rewarded with much greater productivity then they had in the past.

However many more developers have not made the transition. And since there is no way for Mort to gain any benefits from using VS.NET until after a tremendous time investment, which Mort cannot afford, there are very few if any Morts using VS.NET.

And that’s too bad, because many who are now an Elvis used to be a Mort.

I am Mort

As an aside, given that most of my day is spent running a business and not coding, I am unfortunately Mort most of the time. I am often stymied by a new technology that, but because of its lack of transitionality can’t become productive enough soon enough to implement. I could pass onto my staff, but they have the same problem if there is no transitionality; I can’t afford too much learning, I can only afford them doing (unfortunately; investors are, however, welcome to apply!)

For instance, we still have not moved to ASP.NET (and yet again, that is a blog for future day.) I do have the Whidbey bits from PDC, and Whidbey is a lot better. But Whidbey is still far from being good enough.

Microsoft should ensure all developer tools have transitionality

As an epilogue, I think Microsoft needs to put more resources towards ensuring transitionality in their developer tools. Of course I’m sure they try. I’m sure it is a resource issue; I certainly understand that here at Xtras.

But maybe, just maybe no one has recently framed it in this manner. If not, maybe several of the MS devs will read this post. And it they do, maybe we’ll have a mental model they might not have had that will allow them to incorporate more transitionality in their developer tools.

We can only hope. And if so, I’ve done my job.

And don’t think you get off easy…

And don’t think I’m just targeting Microsoft with this essay. I mean every one of you too. Especially 3rd party component and tools vendors; they are in general far worse than Microsoft on this issue. But I give them a lot more leeway here, because collectively, their revenues and hence resources are unfortunately still but a gnat on the behind of an elephant. That elephant being Microsoft.

And Finally

Well, that’s my first technical post. I needed to write it because it is prerequisite material for numerous planned future posts.

I’d love to hear your comments, good or bad. Post below, or blog about and link back from your place.