J2EE & Learning Abstractions

This is the second in what has ended up being a series of posts where I develop this train of thought. Read the first post in this chain.

Since I first vented my frustration with technology tutorials, particularly official J2EE tutorials, my concept of “learning impedence” has continued to evolve. For background, I wrote about the difficulty of breaking into new realms of technical knowledge—something programmers have to do regularly—due to what I call an informational impedence barrier.

For me, the process can be summarized like this: I have a set of things I currently understand. I see an area of knowledge that I'd like to absorb into this body of knowledge. I hit Google up for a tutorial, and the first item on the list is the official tutorial written by the folks who created and/or sponsor the technology. I find that I cannot understand the tutorial at all, as if the new knowledge refuses to mix with my current knowledge.

Why? Here's the part of my thinking that has been evolving. The difficulty isn't learning new technology. The difficulty is learning new abstractions, which most programming concepts are built on. An abstraction is a system of logic that attempts to stay separate from—or independent of—other systems of logic. For example the URI is an abstraction that says, “this identifier represents this thing, never mind how the identifier gets resolved, or even whether a system exists to resolve it.”

Naturally, it takes a bit of mental discipline to teach yourself an abstraction. In order to use the abstraction, you can't worry about logic system Y while operating inside logic system X, even though you know that on some level everything operates in terms of logic system Y. This discipline is something programmers revel in. It's a mental charade that, besides being useful, is intellectually stimulating. Stimulating, that is, until somebody steps in and explains how logic system X is really just logic system Y and proceeds to not understand what all the fuss is about. Such outbursts are irritating and are discouraged by proponents of the abstraction.

The language and literature that grow up around an abstraction therefore tend to avoid going out of bounds of the charade. It's a form of informational hygiene. No mention is made of how logic system X is or is like logic system Y, because (it is felt) that would sully the intellectual value of the abstraction. In effect an informational barrier is erected around logic system X. This is the learning impedence barrier. When I want to learn logic system X, the only thing I have to draw from is other logic systems, but if there's no correlation to be found between what I already know and what I want to learn, then learning is difficult.

What disrupts the impedence barrier is when the charade falters and some connection to an outside logic system becomes evident. For example while I was learning JSP, I learned that JSPs are compiled into .java files that become servlets, and that ultimately JSP is just another way of arriving at servlets. It was at this point that the monstrosity that is JSP began to make sense to me, but does Sun's official JSP tutorial state up front that JSP is just another way to write a servlet? Hold on, let me check... No. Of course not. In fact they work pretty hard to hide this fact from beginners. Do I have a wrong understanding of JSP now? Or do I fail to recognize the abstraction? No way. I actually understand JSP really well because of it. I enjoy taking advantage of JSP's ability to abstract scriptlets out of the syntax by using custom tags. I am just not an intellectual slave to the charade, that's all.

Tutorials for software concepts that are based on abstractions should make an effort to explain the abstraction in terms of things the reader might already know. If I were writing the JSP tutorial for example, I'd intersperse factoids in the introductory sections that disrupt the impedence barrier:

Already Familiar with Servlets?
JSP pages are automatically converted to Servlets by the application server, which means that when you write a JSP, you're actually writing a Servlet! Why JSP then, you ask? JSP syntax was designed to be intuitive from an HTML writer's perspective, allowing easy creation of dynamic web pages without all the tedious formalism of coding Servlets.

And I would love to see this one in the official JSP tutorial:

Familiar with Java but not Beans?
What is a Bean anyway? In the JSP world you won't get very far without them, so here's a little secret that the other J2EE tutorials won't tell you: Beans are just classes whose methods conform to a naming convention. Yes, really. So when you write classes that you want to use in your JSPs, all you need to do is make some of your methods conform to JSP's Bean naming convention and you're off and running with Beans.

I had to grill my JSP professor for ten minutes before I extracted that little nugget of wisdom. He had a tough time stepping outside the bean-abstraction charade, even when pressed with questions such as “Yes, I know that beans are components etc., but what actually makes a bean a bean?”

Anyway, before I wrap this up I should make it clear that yes, a lot of technology areas have excellent manuals which do a good job of getting newcomers into the game with minimal fuss. PHP comes to mind. But PHP is also not so heavily abstracted as J2EE, unless you decide to delve into the world of PEAR, in which case may God have mercy on your doomed soul. So anyway, what is my point in all this, you ask? Basically, I think the intellectual atmosphere of programming—especially J2EE—could benefit from a general realization that the abstractions we use are just tools, and that it really is okay and even useful if we occasionally model our dialogue in ways that don't pay homage to the abstraction.