Making a Living in Languages (Redux) part 4: The Old Language-Centric Products Categories

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.

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.

Comments are closed.