News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
Most Read Latest News Blog Resources

Just Say No to XML




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.


Share this link: http://www.sdtimes.com/link/29508
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading