October 21, 2006

Software development seems to have changed and it now tends to focus on the creation of methodologies that make better use of already existing languages. Some methodologies can be used with almost any kind of programming languages, but they don’t change the languages to which they are applied.

Another aspect is the creation of class libraries and APIs (Application Programming Interfaces) to cope with the limitations of some languages. For instance, Java has developed sets of APIs for Web TVs, speech recognition and smart cards.

It is worth noting that many of the most used languages today have just gone beyond their procedural infancy. PHP is an obvious example. Other languages were already born as object-oriented languages, but didn’t introduce any new concept in their syntax and/or semantic domains.

C# and Java are typical examples. That means many languages are just repeating history, trapped in an old evolutionary cycle.

Another concept that has gained wide currency in recent years involves dynamic typing. Many modern languages have opted for dynamic typing to improve productivity and to reduce errors.

It’s curious that Java and C#, languages created with market considerations in mind, use static typing and are forced to provide resources to “violate” that concept because of its failings. Boxing is one of such violations which tries to remedy the gap between value and reference types in those languages.

By looking at history and the current status of software development, it’s easy to say that we are moving from general purpose languages to domain specific languages. There is no single best way for people to communicate with a computer and hence no single solution. Thus, there will be no single language that’s used universally.

Following are the main categories of programming languages.

Futuristic languages

Today the programmers’ efforts are mostly confined to identifying the steps in which (s)he should write the solution of the underlying problem so that the computer understands it rather than actually figuring out the solution of the problem. (S)he is still being forced to think in terms of the computer rather than the computer thinking like him or her.

One way to design a language is to just write down the program you’d like to be able to write, regardless of whether or not there is a compiler that can translate it or a hardware that may run it. When you do this you can assume unlimited resources.

No modern language should worry you with its nitty-gritty. Moreover, the current concepts of programming like Object-Oriented Programming will also refine to incorporate dynamic needs of future. Some of them are mentioned below.

Where will OOP be?

Somehow, the idea of reusability got attached to object-oriented programming in the 1980s and no amount of evidence to the contrary seems to shake it free. But although some object-oriented software are reusable, what makes it reusable is its “bottom-up-ness”, not “object-oriented-ness”.

Consider libraries: they are reusable because they’re language whether or not they are written in an object-oriented style. OOP does not offer much good to programmers, except in certain specialised domains where it is irresistible for large organisations.

Object-oriented programming offers a sustainable way to write spaghetti code. It allows accretion of programs as a series of patches. Large organisations always tend to develop software this way and this is expected to be as true 100 years from now as it is today.

Prototype-based programming

Another emerging technology is called Prototype-Based Programming. With prototype-based programming you create objects only. If you want more of that type of object you “clone” it. If you want to add or change functionality of an object you “clone” the object and change what you want in it.

In pointer-based languages, you save memory. Instead of having a class definition take up memory, and every instance take up memory, clones of objects generally take up a small amount of memory, to almost none at all. Every object just points to another object. Thus, the fewer changes you make to the clone of an object, the lesser amount of new data needed to be stored.

User interfaces would benefit from the use of prototype-based languages. User interfaces contain a small amount of objects. Objects tend to be created in interfaces for very specific purposes. Instead of creating many classes for different purposes, or creating a few large classes, each with many methods for implementation, cloning objects may be an easier solution.

Prototype-based programming will not replace other current practices in object-oriented programming. It doesn’t benefit the nature of repetitive types of data, such as those used in databases.

In fact, prototype-based programming would decrease efficiency for these types of systems. Class-based programming would still be the recommended solution for these kinds of problems.

Merger of OOP with lists

In the gaming industry, it is likely that some composition of C++ and LISP will be available in near future because game engines are system level programming and need some imperative language. The dynamics of the game requires objects to be simultaneously loaded and linked in the memory that is supported by LISP.

Moreover, in the game industry a handful of companies write engines in C or C++ and then either use them internally or license them out. The vast majority of game companies do not write new game engines for every product they produce. Most of the new code that gets written is in a scripting language to be processed by the engine.

It also looks as if the future for true power programming is meta-languages, where they can take upon some aspects of a specially designed language. ML does this, as do most variants of Lisp, but you also have to consider fully standards compliant C++, with operator overloading, templates, etc. to be a language like that.

It’s interesting to see C# changing to offer many of the same sorts of features that C++ has had all along. And it’s doubly interesting to see the C++ gurus, most notably the Boost folks, writing good implementations of all of the big parts of Lisp that aren’t in C++ already (because, as we all know, every large-scale programming project not in lisp contains an ad hoc implementation of at least half of the Common Lisp standard).