On Practical Elegance
April 6, 2005
"Understanding the problem well is the first — and probably the most important — step in programming." —Paul Hudak in The Haskell School of Expression
Paul Hudak's excellent book begins: "Programming, in its broadest sense, is problem solving." Would that we all lived by such a sensible guideline. Thanks to human nature, the big picture easily drifts out into the mists, especially in certain kinds of discussions. Perhaps this is a contributing factor to so-called permathreads.
No doubt, part of this falls out naturally from more experienced, or maybe more jaded, programmers who already understand the big picture. What's left are the interesting bits that can hold a geek's interest — real-world problems with lots of sharp edges. In this issue, we'll examine a few of them to see what bigger-picture patterns emerge.
A Look at XML Templating
In contemporary application servers, templating plays a huge role. The design of the HTML language, forms in particular, makes up a surprisingly rich problem-space. Originally on www-html, but later on xml-dev as well, Robert Koberg wonders why he needs a clumsy template to set a radio button to either the checked or unchecked state. Why does he have to do this:
Actual template code
#if ($isChecked)
<input type="checkbox" value="true" name="something"
checked="checked"/>
#else
<input type="checkbox" value="true" name="something"/>
#end
Rather than:
Wished-for template code
<input type="checkbox" value="true" name="something"
checked="${isChecked}"/>
As the thread goes on to explain, the reason boils down to a SGML feature where attribute names could be omitted, leaving only the value in the markup — a feature that didn't transfer over to XML — resulting in something that, from the point of view of templating software designers, looks like a wart.
Robert's message is a good example of a common virtue in programmers: the desire to generalize, to smooth out rough edges, to simplify. The more legacy a system has, though, the more difficult it gets to refactor the system in this way, at least for real-world situations.
HTML forms won't get off the hook so easily. Other design choices that can't be entirely blamed on SGML make life more difficult for template systems:
1. To place text in an entry field, one needs to either set an attribute value,
or set element content for a textarea.
2. To work with a checkbox or radio group, one needs to scan many different
locations in the document, creating a checked attribute where needed.
3. To indicate a selection in a list, the required processing differs between a set of radio buttons, as above, or a select element withoptionchildren, at least one of which needs aselectedattribute.
The real world gets in the way. As a result, things like templating systems are a continual source of development cycles by accretion, complexity, and ultimate refactoring. The Apache Cocoon project, where I was honored to work recently, is a central hub of state-of-the-art XML templating engines. Even so, a frequent topic on the mailing list revolved around refactoring or rewriting how templates work. Such problems are tricky, but effective solutions yield a large payoff.
Clearly, tension exists among groups that work on XML templating. Can this be usefully characterized? Can it be generalized out to bigger problem spaces?
Certain personality types fare better at coming up with clean designs whereby problems can be solved (or sometimes partially solved) in a simple, elegant way, and take measures to avoid perceived blemishes in a beautiful design. For this discussion, we'll call these folks elegantists.
Certain personality types take delight in prickly problems, sorting through the myriad requirements, and crafting a complete functional solution — maybe not as pure, but definitely working. For this discussion, we'll call these folks practicalists.
Both of these are generalizations, and in fact a few rare folks are able to fit both
profiles simultaneously. Still, the distinction remains useful. Elegantists tend to
get
upset about special-cases like selected="selected" and would prefer to change
(X)HTML to make it more uniform. Practicalists, on the other hand, enjoy a challenge
and go
forth to produce a rich template language that includes all of the complicated moving
parts
needed for the real world. These two dispositions come in different strengths as well.
A
high-ranking elegantist can work wonders, finding common factors that can resolve
even the
most prickly problem into a smooth and shiny design.
From this arises a trajectory for many kinds of technical projects. The initial version is a straightforward expression of an idea that falters in the face of real world requirements. Shortly it gets extended numerous times by practicalists that need to get their jobs done. The result gradually gets more and more complex. Eventually, with the benefit of experience, elegantists move in to refactor or rewrite the project on a much more elegant foundation. The process may repeat at this point.
Next, let's try this analysis on another area.
Analyzing the Web Services Permathread
A permathread re-ignited when Len Bullard asked: "Can someone point me to a list of the capabilities that one gets using SOAP/WS* that one won't get using REST?" Aha! At first glance, it seems like we have the same tension, here between REST elegantists and Web Service practicalists. The REST folks bristle at all the ugly WS-machinery, while the SOAP folks come up with reasons why the sum of all those parts are necessary to solve their problems. Dare Obasanjo summarized the topic with his usual pith: "SOAP vs. REST is rich vs. reach."
|
|
|
Also in XML-Deviant |
|
Mike Champion responded that the extra pieces needed are "usually something like confidentiality, reliability, and protocol neutrality". Rich Salz goes on to elaborate on the reliability issue, which applies to cases where even TCP-level reliability isn't sufficient, and later also talks about multi-hop scenarios where SSL isn't sufficient for security. In this round of discussions, no one came up with a plausible defense for the third feature Champion mentioned, "protocol neutrality".
It's up to readers to look at the additional features offered by the Web Services stack to determine whether they need them, or whether they can stick with a more elegant REST solution. The elegantist/practicalist distinction holds up well, albeit with some differences from the template discussion. For one, the core of the REST philosophy is already well-developed and influenced by implementation experience. If the trajectory discussed earlier holds, I predict we will see the elegantists eventually figure out ways to include additional use cases in RESTful systems for the handful of real world problems that currently aren't covered well.
Conclusion
Looking at it another way, the elegantist vs. practicalist distinction sheds some new light on two long-running permathreads. Might other permathreads be analyzed in light of elegantist vs. practicalist tensions? Relax NG vs. XML Schema, XSLT vs. XQuery, XML vs. Binary XML, RDF syntax choices, XForms and web forms, linking in general, and others come to mind. The XML-Deviant research department is hard at work on this subject. For now, awareness of this distinction can help keep us all more aware of the larger issues, including problem solving.
Births, Deaths, and Marriages
Schedule and Session descriptions are available.
Details on the web site.
New release improves support for converting XSL-FO, SVG, and XHTML.
Documents and Data
More REST vs. SOAP: Point. Counterpoint. Counter-counterpoint.
Survey says 52% of a non-representative, non-random group of XML developers already use XML Query.
Thankfully, JavaScript is not evil, just twisted.