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?
next: The Old Language-Centric Products Categories.
Start of nine part series.
Related Posts:
- by Harold March 15, 2022 It isn't the sultry Regency drama of Bridgerton, the action psycho-drama of Moon Knight, or even the, um, whatever the heck Human Resources is. But…
- by Harold August 29, 2023 In July, the Media and Democracy Project filed a Petition to Deny the license renewal of Fox29 (WTFX-TV) in Philadelphia. The Petition rests on a…
- by Harold July 24, 2023 Back at the end of June, Canada passed C-18, aka "The Online News Act," a law designed to make Google and Facebook negotiate with news…
- by Harold November 8, 2021 5G has been accused a lot of ridiculous things -- causing Covid, causing cancer, causing autism. This article provides a list of 9 separate conspiracy…
- by Harold July 1, 2022 For most people, the Supreme Court’s decision in West Virginia v. Environmental Protection Agency was about environmental policy and what the Environmental Protection Agency can…
- by Harold June 9, 2021 Yesterday, the Ohio Attorney General filed a lawsuit asking an Ohio state court to declare Google a common carrier and/or public utility under the laws…
About Stearns
Howard Stearns works at High Fidelity, Inc., creating the metaverse.
Mr. Stearns has a quarter century experience in systems engineering, applications consulting, and management of advanced software technologies. He was the technical lead of University of Wisconsin's Croquet project, an ambitious project convened by computing pioneer Alan Kay to transform collaboration through 3D graphics and real-time, persistent shared spaces. The CAD integration products Mr. Stearns created for expert system pioneer ICAD set the market standard through IPO and acquisition by Oracle. The embedded systems he wrote helped transform the industrial diamond market. In the early 2000s, Mr. Stearns was named Technology Strategist for Curl, the only startup founded by WWW pioneer Tim Berners-Lee. An expert on programming languages and operating systems, Mr. Stearns created the Eclipse commercial Common Lisp programming implementation.
Mr. Stearns has two degrees from M.I.T., and has directed family businesses in early childhood education and publishing.
OpenLaszlo — which provides my paycheck, so I’m biased, naturally– is an XMLian system. LZX, the OpenLaszlo language, is an XML language and LZX apps consume data in XML format.
Origninally we compiled to run in the Flash Player. There are two modes of running, either standalone or connected to the OpenLaszlo server. When proxied through the OpenLaszlo server, the apps relied on the Laszlo xml parser. When running standalone, they relied on the Flash Player’s XML parser.
With OpenLaszlo 4.0 you have the option or compiling to native browser JavaScript (aka DHTML or Ajax). Which means that you will be relying on the IE or Mozilla or Opera or whatever XML engine to process datasets.
Meanhile in the “Orbit” project, Sun Microsystems is creating a compiler to turn LZX source in to Java bytecode. Those apps will rely on the Java VM’s XML engine.
As you might expect, some of these XML engines are better than others, especially when it comes to raw horsepower.
Thank goodness, in any event, that the XML standard seems to have “stuck”. The age old problem of innummerable marginally different but incompatible variants (see: “Unix Wars”,; see “embrace and extend”, etc), has (knock wood) been avoided by XML. It’s almost miraculous, if you think about it.
Naturally I hope that OpenLaszlo will become the dominant “paradigm” for doing web applications. Whatever happens, it will be interesting to see the relative proportions of apps compiled to Flash, Ajax, and Java.
More on this at some future point, if I can figure out what I want to say about it. Meanwhile I’m enjoying this series.
Of course, with Laszlo, there’s a real language (i.e., semantics) that underlies the applications. XML is just a syntax for serializing content, which is but a tiny portion of the problems a developer must face. While Microsoft has continued with XML for it’s purpose, it also has a long history of DDE, COM, OLE, OLE2, ActiveX, Common Runtime, etc. for modeling the interaction between active parts of a program. By contrast, Lazlo jumped right to that current state-of-the-industry level of semantics. (The failings of those semantics is a subject for another time.)
But in any case, yeah: there’s a lot of languages to get all geeky about in there. Lots of ways that developers and salesmen can impress folks with nice diagrams and plenty of work for technologists to make it all work. And it does work. All of which is the point of the last posting.
The point of this posting is that, to the great extent which the semantics of the Laszlo language provides a unification of all that noise, people using Laszlo can produce some pretty darn cool stuff. It’s their secret weapon over those just cobbling together stuff without powertools.
The next posting is about the traditional (circa 2002) ways of selling a powertool like Lazslo. The different ways you describe for delivering Lazslo applications make a nice example.