Language Workbenches

Martin Fowler's latest article is on "language workbenches", which is a term he defines as tools for doing "language oriented programming", which he defines as programming using domain specific "little languages" (DSLs).

He makes the distinction between "external" DSLs that are written in a separate language, and "internal" DSLs that use the main language itself to write the DSL.

I found this pretty interesting because one of my goals with Suneido was to support internal DSLs, although I didn't call them that. For example, rather than use external XML files for plugins like Eclipse, Suneido uses internal object literals. Similarly, GUI layouts in Suneido are also written as nested object literals.

I've thought about taking this a step further and allowing custom editors for internal DSLs. For example, a visual editor for GUI layouts that would simply be another way to edit the code. This is the kind of thing the article describes as part of a "language workbench".

Now if only I had unlimited time to work on this stuff ...

New Articles

Here are a couple of new interesting articles from Martin Fowler's web-site although not written by him.

Before Clarity - Michael Feathers

I think what he's saying here is that testability has first priority, sometimes even ahead of clarity. I think I'd agree. I'm coming to believe that the only way to have high quality software is to have tests. What good is clarity if the code isn't correct?

Fail Fast - Jim Shore

This article argues that it's better for software to fail right away if there is an error in the code, rather than trying to be "error tolerant" and hiding the error. I'd agree. I have this debate with my programmers. I'll say "we should put an assert here", and they'll say, "but we don't want the user to get an error". But they're missing the point - the purpose of the assert is to catch any errors before they get to the user. And if an error does slip through to the user, it's still better to know about it sooner rather than later.

This article also prompted me to change our user error message from "A program error has occured" to "An unexpected problem has occured". My support staff has wanted this changed for some time - they think that "program error" sounds like it's our fault. Of course, it usually is, but I guess there's no point making that too obvious!

Dependency Injection

It started with an article listed in the IBM developerWorks technology newsletter - Secrets of lightweight development success, Part 2: How to lighten up your containers
which was interesting enough, but at the end there was a link to Martin Fowler's article on dependency injection. I always like Fowler's writing so I followed the link and printed the article to read later. I read it last night and, as usual, he does a great job of explaining the topic, including alternatives.

I'd read about dependency injection in Spring in Better, Faster, Lighter Java, but I don't think it sank in until reading Fowler's article. I also found an article in Ruby Garden about it. It talks about HiveMind which is one of the Java dependency injection packages (Pico is another).

Dependency injection also ties in with breaking dependencies for testing as explained so well in Working Effectively with Legacy Code by Michael Feathers.

I'm not sure how I can apply dependency injection in Suneido, but I'm going to keep it in mind. It would be easy enough to implement - it's more a question of where it would be useful.

2005-6-11 Another good article - Dependency Injection in Ruby

There has to be a Better Way!

Recently, I've been listening to some tapes of our training sessions and there has to be a better way! I don't blame the trainers - it's hard to see the forest when you're thrashing through the bushes.

My company trains our customers' staff how to use our software. We don't do this to be nice. Our sales depend a lot on word of mouth and referals so we need happy users. And, so far, the best way we've found to get happy users is to train them. (Even that doesn't always work, but it seems to help!)

The big question is: what is the best way to train people to use a complex software package. Actually, that's not the whole problem. Sometimes it's a matter of trying to train them to operate their business, which shouldn't be our problem, but it tends to get in the way of our goal of happy users.

I've got to think about this some more, but some initial thoughts are:

• don't waste time on a lot of details that the user couldn't care less about
• don't just lecture - they won't remember so it's a waste of time
• focus on what they need to know to start using the software
• treat it more like "consulting" rather than "teaching"

I'm always suspicious of technical "solutions" to people problems, but I wonder if "screencasts" that covered small parts of the software would be a good addition to our documentation and to the training process. I've been impressed by Jon Udell's screencasts so I bought a copy of Camtasia to see what we can do with it. I also want to try it for Suneido.

Cutting With the Grain

Cutting with the Grain is an interesting article by Kent Beck, Joseph Leddy, and William Wake.

I could definitely relate to what it was talking about, both from personal experience and from feedback on the Suneido forum.

A couple of other programmers in my company are currently working on a feature that seems to be a neverending source of complications. Definitely going against the grain. But do you abandon it or push ahead? If you push ahead, are you going to end up with something ugly? (It wouldn't be the first time.)

Suneido can make certain projects wonderfully simple. But sometimes people seem determined to make it do something it was never designed to do. Not surprisingly, it's very difficult and I can't help them much. Sometimes they persevere and Suneido gains new abilities. Other times they give up and disappear, no doubt with a negative opinion of Suneido. I try to lead them onto the path of least resistance, into "cutting with the grain", but it doesn't always work.