When Developers Seek to Speak

 
 
By Peter Coffee  |  Posted 2005-06-20 Email Print this article Print
 
 
 
 
 
 
 

Opinion: Language choice may matter less when smarter objects can see -- not say -- what they need.

Software developers used to be famous for their readiness to launch into language wars: protracted, passionate or even vicious debates on the power and elegance of various notations. The move toward service-oriented architecture should take the angry energy out of those arguments.

I suspect that language wars used to start for reasons described by storyteller Garrison Keillor in his 1985 book "Lake Wobegon Days," in which he told of the frustration of immigrants to the U.S. who found themselves surrounded by people who dont speak the same native language. "You become a yokel ... an idiot," Keillor wrote, no matter how smart and insightful you might have been when you could speak in the language you know best.

Programming languages are even more varied than everyday languages in their ways of framing basic concepts, let alone their nuances of vocabulary and style. How much greater, then, is the frustration of the programmer who feels as if the language available to solve a problem is either unfamiliar or simply incapable of saying what needs to be said? And how great is the delight that comes with the discovery of a language that might make it possible "to speak intelligently and with feeling," as Keillor put it, "about anything under the sun"? -- or at least, about the problem thats currently at hand?

I found myself thinking along these lines when I saw last weeks bulletin from the National Institute of Standards and Technology concerning an emerging process specification language called ISO 18629 -- if it has a more euphonious name, I havent uncovered it yet -- which purportedly "uses artificial intelligence (AI) and mathematical logic to represent computer commands." Oh, my aching head. Imagine: a language that doesnt just let you demonstrate how smart you are, but that adds its own intelligence to yours.

A few deep breaths later, Im willing to be persuaded that ISO 18629 is a good idea burdened by an over-hyped description. Theres nothing wrong, in principle, with a language thats designed to work with a sophisticated run-time environment -- one thats capable, for example, of inferring specifics of ideas like duration and sequence from the context of whats going on. In fact, this seems like a pretty natural extension of the polymorphism that weve seen in object-oriented languages for years.

Telling an object to print itself, for example, can result in any number of different behaviors depending on whether its a piece of text or a color graphic -- or even a turtle-graphics script that drives a robot around on a piece of paper on a classroom floor. I can likewise imagine telling one process to begin "after" another process, relying on metadata of the latter process to tell the former whether that means "after Im up and running in a stable mode" or "after Ive run to completion without errors."

Is that an example of artificial intelligence? No, but its a style of programming that makes it natural to think about systems as if they were built from individually intelligent elements, instead of trying to put all the intelligence in top-level executive code while dealing with all of the lower-level modules as if they were mindless idiots.

When applications run in environments that are populated by rich -- if not actually "intelligent" -- objects, consisting of readily discovered services and easily repurposed data, the language thats used ought to become less important. If I put a Norwegian, a Spaniard, a Russian and a Thai around a conference table and tell them to develop a plan to build a house, I can expect some problems due to incompatible languages. If I put the same team on a job site, with tools and materials at hand, Ill probably get a serviceable house much more quickly. If a person can see and recognize a hammer, a nail and two pieces of wood, he doesnt have to know what another person calls those things if he can point at them and indicate a wish to use them.

The same dynamic, it seems to me, is the promise of not merely writing code in the form of services -- but of deploying services in an environment designed to let them find each other and work together.

Tell me what language makes you feel smartest at peter_coffee@ziffdavis.com.
 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel