Imagine a World
February 10th, 2008
I think that there’s a fairly serious problem with the programming languages that are in common use today. Most people seem to agree that object oriented languages such as Java, C++, Python, etc. are in some way better languages than early programming languages or assembly code.
A quick look at the wikipedia page on object-oriented programming gives some of these reasons:
Object oriented programming roots reach all the way back to the 1960s. As hardware and software became increasingly complex, researchers studied how software quality could be maintained. Object-oriented programming was deployed in part as an attempt to address this problem by strongly emphasizing discrete units of programming logic and re-usability in software.
Since it’s inception, object-oriented programming has proven to be an extremely useful way to think about programming. Through the use of an OO style, a programmer is able to encapsulate programming elements, abstract complex behaviour, inherit behaviour from other objects and control access to data and code. All of these features have made object oriented programming as popular and important as it is today. Even though OO code is a powerful and important tool, it is not without it’s flaws.
I would argue that a key concept in programming is the ability to encapsulate any logical construct so that it can be re-used in the future. Object oriented programming undoubtebly allows for some of this encapsulation. Whenever you write a method or a class, you are encapsulating functionality. The problem is that there are certain types of functionality that are either extremely difficult to encapsulate or impossible to encapsulate.
Design Patterns are widely celebrated and studied by advanced users of object oriented programming languages, and yet they seem to be an admission that there is something fundamentally wrong with the design of these languages.
There are a number of programming challenges which a developer encounters regularly in object-oriented design. There are also widely accepted solutions to these problems. The best known are the design patterns codified by Gamma et al, but in a broader sense the term “design patterns” can be used to refer to any general, repeatable solution to a commonly occurring problem in software design. Some of these commonly occurring problems have implications and solutions particular to object-oriented development.
If these patterns are repeatable and general, why is it that we haven’t put them into libraries in the same way that we have put file manipulation code into a library. I’ll try to motivate what I’m saying with a particular example.
One common and simple design pattern is the singleton pattern. The singleton pattern allows you to instantiate an object while forcing the object to have a single instance. Typically it takes 5-10 lines of code to convert a standard class into a singleton. You need to make the class’ constructor private and then add a method to get the singleton instance. While the amount of code involved in making a singleton is fairly small, it would be helpful to be able to encapsulate it.
Once you have defined what it means for a class to be singleton, it would be nice to be able to simply write:
singleton class ClassName
as opposed to the 5-10 lines of code it would normally take. Creating a construct as above is quite difficult in current object oriented languages. Something similar can be done using templates in C++ or generics in C#/VB.Net but it is likely not something worth doing due to the amount of work required, and does not provide quite the same results. The key ability that is missing in modern OO languages is the ability to define your own syntax . An object oriented programmer can only define certain types of syntax such as method calls or objects, but it becomes extremely difficult to define constructs in the vein of if statements or for loops.
I am currently doing research with Professor Gary Baumgartner at the University of Toronto to help remove some of these limitations from object oriented languages. It is interesting to note that there are already languages which allow this type of control. The macro systems in Lisp and various Lisp dialects allow for exactly these things. My next few blog posts will revolve around how existing languages provide this macro functionality while looking into how the control they offer can be wrapped around existing languages.