Are Computer Languages Irrelevant?

By Kurt Cagle
November 24, 2008 | Comments: 13

[Editorial]

Every so often I entertain rather disturbing concepts as I look over the large and varied landscape of computer programming, and this particular question "Are computer languages irrelevant?" popped up one day as I was thinking about clouding computing, web services and the landscape of code that we all as programmers find ourselves deeply enmeshed.

Certainly the question "which is the best computer language" is likely, if thrown into a room full of programmers, to result in the emergence of only a couple of those same programmers, bloodied and battered, to leave the room alive, and then only so long as you don't get into different language versions. Yet increasingly I'm wondering if the particular languages themselves really matter all that much.

Consider this - I spend a significant amount of my working day staring at a web window pane within a browser. Now, that browser may be written in C++ (which would certainly have been the case even five years ago) but is increasingly likely to be written in JavaScript or Python of even Java, not necessarily because these languages are any faster (even with some of the most startling improvements in JavaScript, there's still an order of magnitude or two separating performance) but because these languages are generally easier to work with.

In other words, the advantages of using a language that provides detailed user control over memory management and garbage collection (and as such let developers move "closer to the metal") is outweighed by the simplicity of the other languages ... or put another way, the utility of using scripting languages is usually far higher in terms of productivity in the development and maintenance of applications than the inefficiencies of the code - the performance factor isn't in fact a factor.

Certainly there are plenty of counter-examples where performance is a factor, but over time, they're beginning to become rarer on the ground, compared to factors such as bandwidth and network latency. Most desktop applications written today have a direct pipeline to the web, either for updating state, storing entities, communicating with others via a server or insuring the validity of the user. Not a few of these "web-enabled" applications are being replaced, in fits and starts, with true "web-apps", written to run within a browser, albeit one with its own localized data store.

The history of computing is a history of abstraction and virtualization. Most contemporary programmers are probably unaware that the earliest programs were completely linear - the idea of procedural modules was initially an operation of convenience in order to minimize duplication of code, the association of a name (and from there a series of slots representing input and output parameters) with a given set of instructions.

Object oriented programming is often seen as the next stage of that process, but most people fail to appreciate that the real "next stage" was the deployment of discrete modular components that exposed specific properties and methods according to a common standard of integration. In its own way, Visual Basic was perhaps more important than C++, because it most clearly established the principle that if you build that common framework, you can drop in anyone's component, not just ones that you write or that come "out of the box". Thus, componentization of software can be seen as a layer of virtualization.

HTML helped to embody that concept perhaps better than anything else to date. There is nothing intrinsically magical about an HTML document - until such time as it is reified as a web page. It is a pure abstraction, and the mechanism that converts that abstraction into something of substance is some computer language running the browser.

Yet the wonder of that HTML page is that with usually with the exception of very minor discrepancies, that same document will render the page in more or less the same way, regardless of what language is used to implement the rendering and functionality. The reason that this is the case is of course the fact that the world has standardized upon the expectation of behavior for such documents, and as such the rendering language is largely irrelevant. The qualifications I'm giving here are only to reflect upon the fact that this seems to be a trend, and not all browsers conform to these standards yet (though most are giving it a good try).

This conformance is also being seen in the rise of AJAX components, built using a common JavaScript framework, that in turn host media "plugins". It's significant that the binary plugin architecture, common ten years ago for many kinds of applications, has dwindled down only to those pieces which absolutely cannot, as often as not for proprietary restrictions rather than efficiency reasons, be rendered any other way (e.g., video and audio components, and Flash). The next generation of AJAX will almost certainly challenge Flash's primacy in that space, and it is perhaps not surprising that many Flash oriented component frameworks (such as OpenLaszlo) are also now building AJAX frameworks to provide the same behaviour.

Virtualization of the operating system is also taking place. Most languages written this decade do not talk directly to the underlying system. Instead, the language is intended to run a virtual machine that in turn performs the execution at the lowest level. Web browsers are employing this strategy as well, to the extent that web browsers are becoming increasingly difficult to distinguish from operating systems in terms of their abstractions - they have to be in order to support their own abstractions across platforms.

Web services represents the other aspect of this virtualization, where the term describes network based componentization: localized client components embedded within applications that communicate with the server as a data abstraction. Mash-ups are of course a very visible embodiment of this principle, but the componentization also takes place via server components that are replacing the flat "scripts" of web development a decade ago with distinct components that as often as not are also represented by a declarative abstraction.

With both client and server, the componentization clearly demarcates a boundary between internal component code and glue code. As components proliferate (and the standards for integrating these components coalesce) the imperative glue code in turn disappears, in fits and starts, admittedly, but the direction is clearly there. With component standardization, the language that the component is written in becomes secondary to the expected behaviour of the component itself - the computer language becomes irrelevant.

This same process of virtualization is now taking place at the hardware level, and is fundamental to the principle of cloud computing. Create a hypervisor to manage each machine instance, and you can essentially create a virtual computer within minutes, each running its own distinct operating system with applications not only loaded but in many cases running.

The machine - the hardware - becomes irrelevant, an abstraction; you as a developer or IT manager are far more likely to be concerned with the virtualized machine, not the physical one. Already, standardization is taking place in the virtualization market, providing consistent standards that will make it possible for a given virtual computer to be created not just on company X's infrastructure, using their memory and processing systems, but on company Y's infrastructure as well utilizing the same web interfaces - in a manner that makes the transition from X to Y invisible to the end user.

If this model sounds familiar, it is - its basically the same model that public power utilities have used for handling load surpluses and draws with one another. This makes it possible to create system instances, and as demand picks or drops, underutilized computer farms can pick up the slack.

Yet the point to keep in mind with all of this is that throughout this decade and into the next, localized and specialized "one-off" instances in imperative language A vs. language B are also going to disappear in favor of standardized abstract declarative descriptions in which behaviour is standardized, not language.

This doesn't of course mean that the languages "go away". Declarative state diagrams are meaningless without having the ability to turn those diagrams into some formal (imperative) behaviour ... but the specific languages used to implement these behaviours are irrelevant to the overall discussion of the system.

This obviously has relevance to tech publishing (as well as to development, job seeking, college curricula and IT strategies) in the very near future. Componentization by its very nature means that you have a third party industry of component development at every level of abstraction along with a large floating pool of integrationists (a.k.a., mash-up artists).

Additionally, the more componentized the industry and the higher the degree of abstraction of the componentization layer, the more likely that these same integrationists will not necessarily need to be programmers at all, but instead will be "power users" who are also domain experts in their respective industry verticals.

They will need to know their domain specific languages - some XML representation, most likely - but even here they will likely not be exposed to the markup language of that aspect. Most XML component models tend to be composable, which in turn means that they can usually be rendered neatly via any number of "drag-and-drop" graphical UIs or forms/editor representation. Thus, while it is still necessary (indeed, far more necessary) that the user understand the specific domain model, their need to understand that model on a programmatic level is going to continue to decline.

The effect of this in the long term is to continue to grow the "designer" at the expense of the programmer, but you will also see the rise of ontologists (data modelers) who serve to model the respective domains in the first place. The closest analog to these roles in most existing IT shops is the application architect, but what are being architected are not code APIs but domain specific languages (though it can be argued that the one is essentially an early form of the other).

This is certainly an ongoing process. Are the differences between Ruby and Java important today? Yes. Are they as important as they were five years ago? No. Will they be less important five years from now? Almost certainly.

Distributed services, componentization and virtualization are the hallmarks of the emerging generation of programming. While cloud computing is certainly a part of this phenomenon, that "cloud" is not just the server layer, but is also the dynamic shifting sea of mobile devices, laptops and intelligent objects. In order for these to communicate with the cloud and one another, building around a specific computer language is not only irrelevant but potentially a barrier - the mechanism for communication is the standard protocol. This in turn informs the methodology of software development, and from there the business community that makes use of this technology.

Kurt Cagle is an Online Editor for O'Reilly Media.


You might also be interested in:

13 Comments

Well described! This article makes its point very well and with good examples.

The specification of the model and "interface" of any service independently from its "implementation" is indeed the key to the ability of a client to interact interchangeably with service instances whatever their technology of implementation. The use of a web browser to talk HTTP with a multitude of web servers is a well-known example of that. Assuming correct implementation, the language of implementation of the service is functionally irrelevant to the client ... under most normal usage.

However ... in some normal usage and most abnormal usage, this is not necessarily so.

Even under normal usage, if it is important that the service performs well (including execution speed and storage requirements) then the choices of technology (including language) and models (including data structures and algorithms) of the implementation have an important effect. As the article points out, this effect might be masked by i/o performance in many cases but, particularly as the system scales, this might not remain so.

Also, even if implementations in different technologies behave indistinguishably under normal circumstances, this might not be so under abnormal circumstances. The failure modes of different technologies differ radically from one another leading to completely different perceived behaviour unless extreme care has been taken in the specification of the interface and in the design of the implementation to protect the client from all such occurrences. For example: a C++ implementation might cause mayhem with a "dangling pointer", whereas such an occurrence is extremely unlikely in a Java implementation; on the other hand, a Java implementation might fail to find a "method" at run time, whereas this is unlikely in a C++ implementation which would probably have detected a fault at link-time. In general, whether abnormal usage arises due to accidents, faults, overloads or malicious acts, there is likely to be little similarity between the behaviour of implementations in different technologies.

These issues do not detract from the main point of the article and can even be used to extend it.

One of the key advantages of the hiding of implementations behind interfaces is not only that the client is unaware of the nature of the implementation, but also that the implementation can be changed without requiring modification of the clients. Over time, implementations can be improved including upgrading their design and changes in their choice of technology. This capability is an enabler of increased performance of systems over time, and allows the migration of implementations into completely different technologies when required. For example (and at risk of turning the language issue inside out) source code in standardized languages can be recompiled using new compilers for newer generations of hardware; in an even "closer to the metal" case, the introduction of hardware floating point units did not require code in high level languages to be rewritten. (After all, hardware can be considered to be crystallized software.)

This capability is also often used in a converse sense. Provided that the interface to a service is well specified for its clients' purposes, a "quick and dirty" implementation can be provided to allows its usage to be explored. As the importance of the service increases, the implementation can be improved and competing implementations can be interchanged without upsetting the clients.

Could it be that our current programming languages are not powerful enough to encapsulate our current abstractions? Maybe we need to find better programming languages; better than Java, Python, or even XML.

I consider HTML as the first commonly used declarative language. It is mainly a rendering language but XHTML+XForms is much more !

Declarative languages are top level languages while C++, Java, ... become intermediate languages, compiled or interpreted.

Of course, XML is very good for easily designing declarative languages.

Spore++.

People have been predicting the end of programming and the rise of easy, end user tools since Fortran has come out. What is often missed in this is that ease of use inevitably comes at the price of moving from the general to the specific.

The power of programming is that it creates something new that has never been seen before in the world. All the abstractions you can think of will be no use if you're creating something that's never been thought of before.

Programming will always matter and programming languages will matter as long as programming matters.

"Of course, XML is very good for easily designing declarative languages"

Ouch, this article is deeply wrong, or at least misleading, if it drives readers to such conclusions. God forbid us..

Xianhang Zhang,

I'm not predicting the end of programming any time soon, only that componentization and binding languages are effectively replacing application languages as the dominant meme. Componentization still requires at some level "deep code", but there is and continues to be a broad shift away from nearly all deep code languages as componentization becomes more dominant.

One point to consider here - what this is doing is turning power users and domain specialists into "shallow coders" - those who are more adept at working with glue code and componentization than at writing components. Can they write those components? In most cases probably not. Can they incorporate those components into their web pages/presentations/documents, etc.? Yes, absolutely - that incorporation and integration is what I'm talking about.

Juan,

I absolutely agree with you. Programming languages are in general an offshoot of the need to script a new environment in some manner. Very few people set out to build a new language solely as an intellectual exercise - far more often, they are wanting to control a new environment and need the tools to do that. This was true of languages like C, JavaScript, Python, Ruby and so forth, and secondarily true of Java (which originally emerged, ironically, as a language to better write web components), C# (which was an attempt to bind a Java-like language to the .NET world) and so on.

We're moving into an environment of large scale distributed applications run over the web, built increasingly along taxonomic lines and facing the twin complexities of asynchronization and latency. The resulting world is more semantic than it is functional, and I don't think that we've really even begun to scratch the surface for this next level of abstraction yet.

My 2 cents:

Are programming languages still relevant?
I think the answer should be sensitive to the context.
Programming languages are becoming less critical in composing elements into an architecture that provide end to end solution. The rise of more ( WS* ) and less (www) standards facilitate a composition of solutions from a variety of frameworks and languages.

However, programming languages will continue to be important in the context of enabling the implementation of more and better levels of abstractions (Hardware virtualization, utility computing, etc).

Will code go away and give up its place for a variation of a domain specific language expressed by XML? not entirely.

While DSL tools are only beginning to evolve and enable easier software authoring and better abstractions, XML and *ML languages were never good in expressing logic and behavior (IMHO).
I think these (*ML) languages are good at expressing structure (of data and state), but somewhat akward for defining flows and processes.

But hey, Syntax is irrelevant, right?

Yuval Goldstein,
End;

Ultimately android is an interesting platform. Now you still have to use Java to write native applications, but everything is pretty well standard and abstracted out, so it much easier to dig into than the iphone sdk unless you used to work for Next Computing and have been using objective c for 2 years.

I've been looking various Java code since 1996, so its very easy for me to start playing with android, compared to the iphone sdk which requires me to learn a while new c related platform. Java's not that much easier, but it passes the familiarity test.

Plus you're not dealing with all the variations of MIDP, its just one standard SDK and one standard platform.

But web apps still have the power of working about the same on iphone and gphone. However you can't write a 3D game with HTML, they tried that with VRML 2.0 and it never took, 3D has too much data to be readable even when its text.

Except that you can write a 3D game with VRML 2.0. Data size is not the problem. The interface out of non-real-time DOM applications into a non-DOM real-time scene graph is.

The problem is not VRML. It is programmers who have only learned the HTML declarative model. The VRMLers can build games with it. HTML programmers can't.

If HTML rendering had to compete with VRML rendering, HTML would not exist.

There are almost invariably costs to abstraction. I think VRML is a case in point - it is a declarative language, and while you can build games with VRML, the overhead cost of doing so efficiently so far is still high enough that you really gain comparatively benefit (and a lot of drawbacks) to writing in VRML.

However, I think that's changing. Assume that Moore's law continues to hold for a few more generations, even if its just overall computing performance rather than just processor speed, we reach a point where the advantages of abstraction significantly outweigh the performance bottlenecks.

At that stage, going with a declarative language actually makes more sense, because you can prevalidate such a document without instantiating, moving a significant amount of the error handling overhead out of the processor and into a preprocessor.

In my opinion, that error handling is probably the largest source of performance bottlenecks within a given application, and anything that can be done to more effectively move that out of the runtime cycle can only be a good thing.

Actually, VRML is a level of abstraction above the languages games are often written in, it having been an attempt to make it easy for people to write middling performant 3D graphics. Most gamers go a level lower to write games.

The choice of languages or platforms in that market space has little to do with languages abstractions these days. It is a market where each vendor is pursuing high performance. In the virtual worlds market vendors pursue lock in and domination while the open source and other disgruntleds stand on the side lines and cheer for them.

Real-time 3D is the proof that the so-called open communities in the main have feet of clay and the morals of a sixteen year old boy chasing a fifteen year old girl.

News Topics

Recommended for You

Got a Question?