Last time: “Hidden Special Purpose Languages,” in which we said that cool languages can be a secret sauce embedded within useful products.
Now: What about having each product share a common language?
[This is an excerpt from a Lisp conference talk I gave in 2002.]
One way of looking at general purpose language products is by categorizing them into three areas:
Language engine: This may be a compiler, byte-code engine, garbage collectors, etc.
Runtime Libraries: for general utilities, graphics and windowing, etc.
Developer’s tools: source code editor, codeless “designer environments”, documentation, class browsers, profilers, debuggers, source code control systems, etc.
Vendors of specialty languages tend to produce all three. A basic price gets you a basic developer setup, with volume runtime-engine/runtime-library licenses below, and “enterprise” or “professional” developer tools above. A premium is often charged for libraries that are “must haves for certain applications: persistence, network or interlanguage communications, and User Interfaces. Examples in this category are specialty languages such as Powerbuilder, Smalltalk, and Common Lisp. The idea is that a relatively small group of people have determined that they “must” work in this chosen language, and vendors meet this need with a whole product solution, oriented towards the details of that particular language. There are several categories of users with different pain/price points, so the vendors provide several tiers of options to survive within this relatively small market.
I haven’t been reading comp.lang.lisp in the last two years, but as I recall, most of the discussion was based on how to convince the world that the Lisp was the best language for this three-legged, language-centric product model.
Unfortunately, this doesn’t tend to promote embedded usage, because of runtime licensing fears. Nor does it promote expansion of the developer community. Few companies can afford to try a small pilot project in a strange language, with unfamiliar tools, at a non-zero price-per-seat.
For the C language family, including Java, the language engine and many libraries are becoming commodities, with ever lower or non-existent profit margins. Some companies specialize instead on providing just one part of the whole application development experience. Examples are tools vendors (such as Rational and Interwoven) and specialized library producers (such as for graphics). The idea here is that vendors can target their specialized products at a definite, identifiable market segment. The most successful of these companies produce product families that cross languages. That is, they are specializing their market segment based on functional role, rather than on language. What would happen if we generalized this approach?
next: Platforms – The New Application-Centric Product Positioning.
Start of nine part series.
