Last time: “Every Application Architecture Has Plenty of Languages,” in which we said that IT was full of enough languages to keep any language lawyer busy.
Now: Well clearly there’s room for languages work, but where are the language products hiding?
[This is an excerpt from a Lisp conference talk I gave in 2002.]
One technique that language developers have been using successfully is to bury the language in an application, where it is not immediately seen.
Many software products use small, purpose-built Lisp or Scheme engines internally. This includes Emacs, Autocad, PTC, Interleaf (Broadvision), Viewlogic (Mentor Graphics). Whole Common Lisp systems are tucked away within ICAD (Oracle and KTI), Gensym, and Viaweb (Yahoo). All these companies put into practice what Phil Greenspun said in his 10th law of programming:
“Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.”
One current crop of embedded language systems is based on XML engines. Few Internet-oriented products are created today without at least an XML parser/generator, and many include engines for the various W3C programming languages such as XSLT or the DOM API. New companies are forming to produce procedural languages embedded in XML, intended for customization and for making Web services available. Water is one Lisp-like example. Microsoft is the biggest example. It as though their product development strategy could be summarized as:
“Any sufficiently complicated business or personal application contains a crappy XML engine.”
The dirty little secret here is that most of these products tack XML engines on as an afterthought instead of using them natively.
Anyway, the combination of individual products and embedded languages can generate a lot of languages to learn. That list of languages for N-tier projects is so long, in part, because each product involved has its own language embedded. What about having each product share a common language?