07 January 2005

1. Less choice leads to better results.
2. Higher level languages and frameworks restrict choice.
3. Thus, higher level languages and frameworks should lead to better results.

<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /> 

The “less choice” statement flows from this article entitled

Choice Cuts. Ignore the politics and focus on the research beneath the statement. That’s what is valuable in this context.

  It is obvious that higher level languages and frameworks restrict choice, so I’m not going to cite a bunch of references for that. While many of these languages and frameworks provide a way to drop out to a lower level, in and of themselves they restrict choice. Just look at Visual Basic versions 1-6. Very productive, but often restrictive.   Whether the conclusion that higher level languages and frameworks will lead to better results is true or not is unknown.   Certainly there are examples where better results have been gained. This train of thought is lurking somewhere behind the software factories movement, and does seem quite compelling. Certainly many people using

CSLA .NET with code generators have found radically increased productivity – and the combination of the two does restrict choice.

  Yet there are countless examples (especially from the era of CASE tools) where the results were totally counter-productive. Where restriction of choice forced intricate workarounds that decreased productivity and made things worse.   Charles Simonyi

contributed to an article on The Edge, essentially noting that there still is a software crisis and that low-level languages aren’t solving the problem. He argues in fact, that low-level languages like C#, VB and Java are a dead-end. That we must move to higher-level language concepts in order to adequately represent the real world through software.

  This is the view of the software factories people and the domain-specific language movement. And it is rather hard to argue the point. There are many days when I feel like I’m writing the same code I wrote 15 years ago – except now its in a GUI instead of on a VT100 terminal. But the business code just hasn’t changed all that terribly much…   To look at it a different way, a software architect’s job is to restrict choice. Our job in this role is to look at the wide array of choices and narrow them down to a specific set that our organization can use. Why? Because having each developer or project lead do all that filtering would seriously cut into productivity.   Companies employ architects specifically to limit choice. To set standards and policies that narrow the technology focus to a limited set of options. The rest of the organization then lives within those artificial boundaries. There are many reasons for this, including licensing costs, training and so forth. I doubt that many people have considered the direct (presumably positive) impact of the reduction of choice however.   I’ve been working on an idea I’ve dubbed an Entity Description Language (EDL). My original motivation was to reduce the amount of plumbing code we write. Look at a typical Java, C# or VB class and you’ll find that less than 4% of the actual lines in the class perform tangible business functions. Most of the lines are just language syntax or pure plumbing activities like opening a database connection.   In working on EDL though, I’ve discovered that it is virtually impossible – and perhaps undesirable – to replicate the capabilities of C# or VB in their entirety. There are reasons why these languages use such a verbose syntax. They require verbosity in order to provide flexibility, or choice. Virtually unlimited choice.   If we now consider that limited choice is better, then perhaps the fact that something like EDL restricts choice is only good…