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.
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)?