Thursday, January 25, 2007

What to Hide?

In the world of computer programming, a lot of thought goes into deciding "what to hide" - in particular, what to hide from the computer programmer.

For example, at some point in history people wrote applications in machine language. Today machine language is hidden from the developer and we see something more human-friendly, like C or Java. The stuff that gets hidden is usually closer to the way machines communicate. The stuff that remains visible is closer to the way humans communicate. At least that's the idea.

The terms high-level and low-level are used to convey this concept. Low-level technologies are more machine-ish and ripe for hiding. High-level technologies are more human-friendly. The high-level technologies are often referred to as abstractions that encapsulate or hide the low-level technologies. Today's high-level technology often becomes tomorrow's low-level technology.

Char and Array

Two language constructs that I once used daily are the char and the array. Today, I use them only indirectly, preferring higher-level constructs like String and Collection. In other words, the char and the array are going the way of machine language: mostly hidden.


Sometimes it's not alway clear what should be hidden and what shouldn't. For example, many years ago a high-level language called SQL was invented for working with data. SQL is an abstraction designed for humans. SQL is, in no way, a reflection of how machines or hardware work. It was designed for humans. Yet still, SQL is gradually crossing over to the world of the hidden, joining the ranks of machine language, chars and arrays. If you have ever used JDO, EJB Entity Beans or Hibernate, then you know what I'm talking about.


The blogs are filled with developers singing the praises of dynamic languages (formerly known as scripting languages). The two most popular dynamic languages that I use are JavaScript and Ruby. Dynamic languages are often more terse, flexible and feature-rich than static languages. Static languages, like Java, do have their advantages though. They are typically more IDE'able and optimizable. The thing to note here is that both Java and JavaScript are pure abstractions. Both were invented to be human-friendly ways of programming computers. But if I had to pick one as being "lower-level", it would be Java.

So which is the preferred abstraction? Java or JavaScript? Not everyone agrees. But if you look at frameworks like the Google Web Toolkit (GWT) or ICEfaces you will see that JavaScript may be crossing over into the land of the hidden. With GWT, the human codes in Java, then the GWT compiler translates your Java into JavaScript. No human ever sees the JavaScript. Only the machine sees it. In this case the machine is the JavaScript enabled web browser.

Hiding Gone Wrong

The key point here is to choose your abstractions wisely. The stuff that's not hidden ultimately becomes a dependency. The goal is to encapsulate things that are complicated or volatile behind abstractions that are simple and stable. Here are a few examples where, in my opinion, the choice of "what to hide" is sometimes wrong:

Web Service Toolkits
XML is simple and stable. HTTP is simple and stable. Web service toolkits (like Axis) that hide the XML are not simple or stable. They add unnecessary layers and complexity. For most developers that need to produce or consume web services, it makes more sense to work directly with XML. Tools like Axis have their place, but in my opinion, that place is a fairly small niche*.

O/R Mappers (like Hibernate)
SQL is simple, stable and extremely versatile. I can teach anyone SQL in a half day. Hibernate is not so simple. Contrary to what anyone tells you, it's a very sophisticated tool. If you don't know what your doing, it can easily cause more trouble than it saves you. Again, Hibernate does have its niche*. In fact, I love Hibernate. But do keep in mind that with Hibernate (and O/R mappers in general) you are encapsulating something really simple with something really complicated. So be sure you are clear on the benefits and drawbacks before moving forward.

* Note: if you take our Hibernate or Web Services workshop, we do cover these decision making criteria. That is: when does it make since to forgo Hibernate or Axis and work directly with the underlying technology (like SQL or XML)?