Just Say No to XML - Software Development Times On The Web

Just Say No to XML
By Allen Holub

September 1, 2006 — XML is perhaps the worst programming language ever conceived. I’m not talking about XML as a data-description language, which was its original design. I’m talking about perverting XML for programming applications. It’s inappropriate to use XML as a scripting language (e.g., ANT), a test-description language (e.g., TestNG), an object-relational mapping language (e.g., Hibernate, JDO), a control-flow language (e.g., JSF), and so forth. These sorts of XML “programs” are unreadable, unmaintainable, an order of magnitude larger than necessary, and audaciously inefficient at runtime.

So, why would anybody use XML in this bizarre way? As far as I can tell, it’s because many so-called programmers just don’t know how to build a compiler. I really don’t have much patience for this sort of thing. To my mind, there is a minimum set of topics with which you have to be conversant to call yourself a professional programmer. If you don’t know these things, you’re a dilettante. This list includes a deep understanding of data structures and key algorithms, a little math (set theory, logic, a little statistics), mastery of analysis-and-design techniques, both process (e.g., RUP or XP) and structure (e.g., design patterns), and database structure and use (e.g., SQL). You also need to know how the hardware works.

You need this stuff even if you’re not actually using it in your work, because no matter what you’re doing, knowing this material will make your work better. How could you possibly decide which of Java’s Collection classes to use in a particular situation if you don’t know how those classes work under the covers, for example?

Knowing how to build a compiler is certainly one of the skills on this need-to-know list. Compilers are fundamental to what we do every day as a programmer. Knowing how the compiler works will let you make intelligent decisions about program structure, decisions that have real impact on the quality of our programs. More to the point, most programs have to parse input (either from a human being or from a machine) and make sense of it. To do that, you have to build a small compiler. Corrupting XML for this purpose, simply because you happen to have an XML parser lying around, is inappropriate at best.

Basically, you’re selfishly making your life easier at an enormous cost to everyone else. For every hour you save, you’re subjecting every one of your users to many hours of needless grappling with overly complex, hard-to-learn, hard-to-maintain, impossible-to-read, XML-based garbage. This is no way to make friends and influence people.

Learning how to build compilers is, unfortunately, too difficult. The most widely used textbook, Aho, Sethi and Ullman’s “Compilers, Principles, Techniques and Tools,” is a classic example of everything that’s wrong with academic writing. Its thorough, but impenetrable, coverage of the subject offers virtually no practical information. The academicians love it, but I’d recommend avoiding the book unless you have a strong mathematical background and are interested more in the underlying math than practical application.

By contrast, Watt and Brown’s “Programming Language Processors in Java: Compilers and Interpreters” is a great practical introduction to the subject. The authors take a learn-by-doing approach, presenting the complete sources for a compiler and interpreter in Java. Though this book is probably the best introduction to compilers for Java programmers, the Java itself is not particularly well done. It’s very procedural (using lots of public fields, for example), doesn’t use polymorphism particularly well, uses way too many impenetrable single-character variable names, and other bad things. As long as you mentally separate the compiler topics from the Java ones and don’t take the Java as a model of good programming practice, then the book is fine.

Kaplan’s “Constructing Language Processors for Little Languages” is another good introductory text with plenty of (unfortunately C++) code in it.

By the way, my own “Compiler Design in C” also has vast amounts of code in it, but it’s obviously all C, not Java. My book shows you not only how to build a compiler, but also how to build the tools that you need to build compilers. (I provide full lex and yacc implementations.) When you’re done learning and moving on to doing, there are a bunch of tools available to help you build compilers, most of them free.

“The Catalog of Compiler-Construction Tools” ( catalog.compilertools.net) is a great compendium of every tool that I know of. There’s not much point in looking at this site unless you’ve read a book on the subject first, but once you have, it’s a great resource.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE COLUMNS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/1/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

SHARE 2008
8/10/2008 to 8/15/2008
San Jose
SHARE

ACM SIGGRAPH
8/11/2008 to 8/15/2008
Los Angeles
ACM SIGGRAPH

Intel Developer Forum
8/19/2008 to 8/21/2008
San Francisco
Intel

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA