Consistency

I've been thinking a good deal about consistency lately. It's one of those things that's easy to dismiss. In the past, I think I've tended to side with the poet, Ralph Waldo Emerson, who once wrote, "Consistency is the hobgoblin of small minds." That sounds so expansive! A friend of mine likes to talk about the "big ideas" of programming as being much more important than "mere implementation". And hey, who wants to be trapped with those small-minded people worried about consistency when the world of "big ideas" awaits us?

Well, I guess I do. I've come to value consistency a great deal recently and it's related to two recent events. First, I wrote a book, Discovering CFCs (www.techspedition.com), that explores the use of CFCs in ColdFusion programming. Macromedia has touted CFCs as a giant step on the road to object-oriented programming. I have a strong background in OO (Smalltalk) and welcomed this news greatly.

So, I began to write. There's not much documentation on CFCs and so I had to put on my scientist's smock and do some first-hand investigation. I knew that Macromedia was holding up Java as the gold standard of languages and, indeed, much of the terminology they use comes from the Java world. At first, all went well but as I tried applying OO principles to CFCs, problems appeared and those problems were based on inconsistency: a method marked "private" was not restricted to the CFC itself, but could be called by any subcomponents; an instance variable in the only private scope available could not have the same name as a method's arguments, etc. If you're new to CFCs, those examples might not mean much to you, so let me use one from a pre-MX version:

<cfset x = ArrayAppend(myArray, 10)>
<cfset y = ListAppend(myList, 10)>

In the first case, x represents a boolean value, true. The variable, y, though, is not a boolean value, but is the newly appended list itself. No, it's not a major problem, but it's inconsistent, a violation of that virtue that until recently I took too much for granted.

Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors

I've been beating the drum recently to alert ColdFusion developers to the idea that we belong to a rapidly shrinking group of people: procedural programmers. While the rest of the world has moved to object-oriented programming, CF has been a bastion of procedural code. But that was supposed to change with CFCs. That was going to be a move to OO. And it is-sort of. The problem is that there are too many inconsistencies with CFCs. Another friend of mine without an OO background regularly calls me in exasperation. He's trying to learn both OO and the CFC implementation of OO. For him, the inconsistencies aren't just irritations. When something doesn't work as advertised, he's unsure where the problem is. Is it him? Is it the language? "I feel like I'm walking on ice and all around me I can hear the sound of cracks developing", he tells me. "I know they're there, but I don't know exactly where they are and just how bad they might be."

He has a point, there. Long ago, I learned that the secret to debugging was investigating the problem knowing with near-certainty that the problem was me and not the compiler/interpreter/language. When doubt is introduced, debugging goes from difficult to maddening.

I said at the top that there were two recent events that cause me to change my mind regarding consistency. One was seeing the effects inconsistency can have on my friend who's bravely struggling to piece individual parts together to form a coherent whole. The other event was the Java class I recently taught.

I've spoken with quite a few CFers who don't like Java. They don't like the look of it, the syntax of it, and they really don't like what they perceive to be the excessive fussiness of it. This same friend of mine who's trying to learn OO and is struggling with CFCs went to my Java class, having had several weeks of working with CFCs immediately prior to the class. "Yes, Java is more fussy," he says. "But I'm willing to accept the fussiness because Java is so consistent. I had no idea how important that was."

Hmmm…I don't think I did either, but again, he's right. The value of consistency rises-seemingly exponentially-with the complexity of an application. One of the reasons for adopting OO is its greater ability to build and manage complex applications-the kind we often run into in the real world. But that ability to build is undermined if we're worried about the foundation we're building on.

Now, let me correct any misimpressions I may have given. First, I'm definitely not saying either that CFCs are bad or that we shouldn't use them. In fact, I think just the opposite: I strongly encourage CF developers to use CFCs. The hard part of moving to OO (which I'm strongly encouraging all CFers to plan for) is not the syntax of a new language, but working with those "big ideas" my friend speaks of. CFCs offer support for the three tenets of object orientation-polymorphism, inheritance, and encapsulation-using a language we're already familiar with. I think this move makes sense for all of us. Plus, the more of us using CFCs, the more Macromedia will be motivated to fix the inconsistencies.

The second possible misimpression I want to correct is any assertion that Java is inherently superior to ColdFusion. Java is better-at certain things. And ColdFusion is better-at other things. Like so many things in life, there's no simple, easy answer and anyone who promises that there is an easy answer is selling something.

Oh-and that quote from Emerson? I grew up hearing that quote but, significantly, only found out recently that the actual quote is this: "A foolish consistency is the hobgoblin of small minds." What a difference a word makes.

If you have the time, interest, budget, etc. for a class in Java geared specifically for ColdFusion programmers with no previous OO experience, I invite you to join me in Las Vegas for just such a class. Our first one really was fantastic.

The first part of the class focuses on syntax-all those fussy things about Java such as data types, casting, operators, etc. The second part goes into object orientation as applied to Java. How is inheritance different from aggregation-and how is each used? Why are interfaces so crucial to developing strong object models for Java?

Then, the last section of the class involves taking some fuzzy requirements (just like the real world!) and coming up with an object model that you then write Java code to implement. Once this Java back end is done, you'll learn to hook it up to a ColdFusion front end-letting each language work at its optimum.

If you'd like to ask me about it, please feel free to email me at: hal.helms I hope I'll see you in Vegas!