This article is an introduction to metaphor-oriented programming (MOP), the latest and possibly the most significant paradigmatic abstraction in software engineering.
We begin with an overview of MOP and MOPED (metaphor-oriented program engineering and design), move onto an example and end with thoughts on its use in higher education.
Along the way, we argue for a "metaphors-first" approach to teaching programming, while noting that this appears to require very little change in most HE courses.
What is MOP?
Without exception, advances in programming seek to simplify the process of creating working software. In almost all cases, this is achieved by abstraction, moving away from the real and concrete world of electronics and into spaces closer to human understanding. A "dumbing-down", if you like. Think about these examples:
- High-level languages in general, through abstraction, simplify the task of programming by reducing the number of operations that a programmer needs to learn, lumping together the extremely flexible operations that the processor is capable of executing into gross instructions that the programmer is more capable of understanding
- Functions make the job of programming more simple by creating even coarser lumps of functionality. Again, the trade-off is flexibility. Before the invention of functions, programmers would write custom code to perform every task, every time. This meant a great amount of effort, but also programs that didn't all feel "samey". Today, most software has a similar look and feel, betraying the laziness of its programmers.
Two different applications from two different desktops, GTK (left) and KDE (right). Note the similarities.
- Objects and object-oriented programming (OOP) move us even further along this path by accepting the fact that modern programmers not only need to be able to partition their software into many smaller pieces of software, but also that they needed help to think about these pieces. Each "object" is a cogent lump of data and functionality that can be created and analysed separately. By lumping things into objects, the programmer can use the mental machinery usually reserved for interacting with the physical world to help with the task - "pass that object", "construct an instance", "getting jiggy with the SOAP", and so on.
A class, similar to those designed by many new programmers.
More recent paradigms have simplified things even further by breaking down the clear separation of concerns engendered by OOP. Aspect-oriented programming, for example, allows programmers to be less conscientious and skillful. The potential impact on training budgets is obvious.
Metaphor-oriented programming takes this one step further, by allowing the programmer to lapse into the kind of vagaries that fill "real-life" specifications.
For example, when talking to a subordinate about the likely outcome if he is found sleeping at work again, we rarely say "I will invoke my reprimand method, with you as the first and only parameter!", but it is often heard (where I work, anyway) "I'll come down on you like a tonne of bricks." If you're thinking "that's a simile, not a metaphor", you aren't relaxed enough for MOP, yet.
Aspect-oriented programming is important because allows us to be less strict about partitioning. In the same way, MOP allows us to be less strict about specifying interaction.
In the next section, we look more closely at MOP and the methodology surrounding it by giving a high-level description
MOPED and a high-level MOP example
Metaphor-oriented program engineering and design (MOPED), is as user-friendly as MOP. That is, we are allowed to be less concrete than with OO.
As an example, we will design a "right-leg" class and associated metaphors. This example has been chosen to be representative of the level of reality and sense found in the average programming course.
First, we have the usual hierarchy of classes. So far, there is no difference between OOP and MOP.
Now we list the metaphors suitable for interacting with the right leg. Some of these would be common and part of a library of metaphors. Others would be application-specific.
Here is our list:
These metaphors would have standard operations that the class definition maps to operations. In some cases, more than one metaphoric operation would map to a single method. "Slice" and "cut", when applied to the left leg as a "knife", would map to "swingInArc", or possibly to another metaphoric operation that ultimately maps to a method, such as "swinging" (as a pendulum).
The key point is that the class deals with these mappings and, once written, allows a programmer to interact with them in any number of vague, half-baked and uncertain ways.
In the teaching of programming, MOP will be revolutionary. Currently, the single biggest hurdle faced by students learning to program is the change from programs representing sailing boats, naive bank accounts, people and furniture to creating classes dealing with abstract data types, hardware abstractions and GUI peculiarities (MouseActionListenerAdapterSocket, for example).
With MOP, this change need never happen. Instead, we reduce "real world" problems into the vague metaphors that the students are used to.
Example: Memory is like a row of pigeon-holes, as the classroom metaphor goes. So why not create metaphoric mappings such as "post" and "peek"? Going further, we could add lockable doors to protect regions of memory (goodbye segfaults!) and stickers to mark regions' purpose (addSticker("pikachu")).
University staff are constantly being put under pressure to produce results, employers are constantly seeking ways to reduce training costs, programmers are always looking for the easy option. As long as we're careful about how we mix our metaphors, MOP could be the answer to many people's prayers.