From C++ to Java to C# to (what some people believe to be the best of the YACLLs) D, these languages have toyed with syntax and tinkered with object orientation; some have compiled to native code and others to bytecode. They’ve made changes and they’ve made ‘improvements’. But on the whole their differences have been pragmatic - mundane, even - rather than visionary or revolutionary. Their goal has to get the job done rather than to change the nature of the job itself. In the long history of programming they will, ultimately, all be seen as ‘more or less the same thing’ doing ‘more or less the same job’.

Recently the fashion has been for ‘scripting languages’ - a whole slew of them. Some of them are broadly YACLL (Perl, PHP), while others (Ruby, Python, Lua), go more sparingly on the curly brackets. These are all, in their way, useful languages. But they are devoid of Big Ideas.

Back To The Future

So when were the last Big Ideas in programming? In my view, there have been only two - or anyway, only two that have made any lasting impression - within the last four decades: namely, logic programming (epitomised by Prolog) and Object Orientation (epitomised by Smalltalk). Sadly, neither of these Big Ideas has (yet) lived up to its early promise. These days, hardly anyone does logic programming. And while Smalltalk may have spawned countless OOP languages, the version of Object Orientation adopted by most ‘mainstream’ languages is bastardized almost beyond recognition.

“The best way to predict the future is to invent it” - Alan Kay

But before rambling down the OOP road, let me say a few words about the Big Idea of Prolog.

I ‘discovered’ Prolog in the mid ‘80s, though the language was created over ten years before that. I have to say that when I first used Prolog, I was pretty much overwhelmed by its expressive power. When using other (‘procedural’) programming languages, you had to find solutions to all your programming problems at the development stage and then hard-code those solutions into your program. With Prolog, on the other hand, you could ask your program questions at runtime and let it look for one or more possible solutions. Heady stuff. This was like ‘talking’ to your programs, Captain Kirk-style. This (I thought) must surely be the way that all programs will be written one day.

Prolog - The Logical Choice?

Prolog programs are written as a series of facts and rules. For example, you could assert that Smalltalk and Ruby are OOP languages by declaring the following ‘facts’:

To find a list of all known (to the program) OOP languages you would just enter this query:

oop(L).

In Prolog, when an identifier begins with capital letter, this indicates an ‘unbound’ variable which Prolog will try to match with known data. In this case, Prolog replies:

Now you can go on to define some rules. For example, let’s says that you want to write the rule that Reba only likes Languages that are OOP as long as Dolly does not like those languages. This is the Prolog rule:

Assuming the program also has this rule...

likes( dolly, ruby ).

...when you enter this:

likes( reba, L ).

The only language returned will be:

L = smalltalk;

This is just the tip of the iceberg with Prolog. The language gets really interesting once you start defining enormously complex sets of rules, each of which depends on other rules. The essential idea is that each rule should define some logical proposition. When you write a rule you can concentrate on a tiny fragment of what might eventually become an amazingly complex set of interdependent propositions. But the programmer (in principle) doesn’t have to worry about the ultimate complexity. Instead, as long as each tiny individual rule works, then you can rely on the fact that the vast logical network of which they will ultimately form a part will also work. Making sense of that complexity is Prolog’s problem, not the programmer’s.

In principle, Prolog seemed to offer the potential to do ‘real’ AI (programming) of great sophistication. Some people even believed that Prolog would provide the natural path to creating a truly ‘thinking machine’.

Well, years went by and Prolog failed to live up to its promise. Part of the problem was that, while it was great at finding numerous solutions to a problem, it wasn’t so good at finding just one. A nasty little thing called the ‘cut’ (shown as a ! in Prolog) was used to stop Prolog searching when once a solution had been found. But the cut, in effect, breaks the logic and scars the beauty (and simplicity) of Prolog. Another problem was that Prolog was, relatively speaking, slow. Prolog compilers were created to get around this and Visual Prolog even introduced strict typing (which is not a part of standard Prolog) - but in order to gain efficiency, the compiler sacrifices the metaprogramming (self modifying) capabilities which many people consider fundamental to the language.

In brief, it’s probably fair to say that Prolog’s greatest enthusiasts were simply unrealistic about what the language might achieve. For the time being, Prolog seems to be an interesting diversion in programming history which has not (so far) delivered upon its early promise.

That said, one currently fashionable language, Erlang, uses a syntax which is based on Prolog. I have not used Erlang myself so I can’t make any detailed comparison between the two languages. From what I read, however, I gather that Erlang has jettisoned much of what makes Prolog so interesting (including ‘in depth’ searching of rules through ‘backtracking’). The raison d’être of Erlang is to implement a safe form of concurrent programming. Once again, this strikes me as a pragmatic language rather than one with Big Ideas. But if I am wrong in this assumption (as I rather hope I may be), I’d be glad if someone would explain what I am missing...

Smalltalk - Beauty and The Beasts

There is no need to labour over an explanation of the significance of Smalltalk. Suffice to say that without Smalltalk there would have been no Mac and no Windows. In all probability you would not now have a mouse attached to your computer, networking might have come around eventually but not as quickly as it, in fact, did - and object orientation might never have made it to the mainstream.

Then again, maybe object orientation never did make it to the mainstream. Well, not the sort of beautiful, simple, elegant object orientation at the heart of Smalltalk, anyhow...

C++ was the first (YACLL ah, there’s no getting away from them!) to take OOP into the mainstream - and most languages that followed appear to have built on the foundations laid by C++ rather than by Smalltalk.

Let me not labour the point again. I’ve written plenty about OOP on previous occasions. Let me just say that C++, Java, C# and Delphi’s OOP are not the same things as Smalltalk’s OOP (the often-quoted remark by Alan Kay - the ‘founding father’ of Smalltalk - bears repetition: “I invented the term ’object-oriented’, and I can tell you I did not have C++ in mind").

Most OOPified languages take some bits of Smalltalk (such as classes and methods), miss out other bits (true data-hiding encapsulation, a class-browsing IDE, image-saving, the ‘message passing’ paradigm) and add on a few things of their own - such as C++’s multiple inheritance or Delphi’s ability to mix and match OOP Pascal with procedural Pascal. The end result is that all of the above languages are less simple, consistent and coherent than Smalltalk.

Moreover, to get back to the theme of this article: none of them - not C++, nor C#, nor Java nor Delphi - have the Big Ideas of Smalltalk. They all combine a mishmash of existing ideas - a bit of OOP, a bit of procedural - optimize it for a certain class library, platform or multiple platforms, stir it all together and bake until done.

Why OOP Anyhow?

Most mainstream languages these days use OOP more as a way of dividing up code libraries into scoped ‘units’ rather than as deeply descendent, thoroughly encapsulated class hierarchies. In other words, whereas Smalltalk’s classes are ‘small closed boxes’ with many generations of ancestor classes, C# and Delphi classes are more like ‘big open boxes’ often with only one (or, if the programmer feels adventurous) two ancestral generations.

An argument could be made that modules of the type used in Pascal’s successor, Modula-2, would have been a far better choice than classes for many of the languages used today. Modules enforce encapsulation (‘modularity’) much more thoroughly than C#, Delphi and Java (and, in my view, modularity is always a good thing) but they don’t have lines of descent (which is an OOP feature which many programmers largely ignore anyway).

What Is The Next Big Thing?

If there are to be Big Ideas in the future, what are the problems they need to address?

I think the main ‘problems’ that programmers face today are the same ones they’ve always faced: Complexity and Maintainability.

Curious, then, that when I read programming forums on the Internet, the main feature which is praised by enthusiastic programmers of whatever language happens to be under discussion is something different - namely: the speed with which they can write programs.

The more time I spend programming, the more I become convinced that the way in which we do the task today cannot be the best way. I suspect (indeed, I fervently hope) that in years to come people will look back upon the programming languages of the late 20th/early 21st Century with the same sense of bewilderment that we might look back upon the Penny-farthing bicycle. “It’s amazing,” they will say, “That people could ever use the darn’ thing let alone get from A to B on it.”

Programming needs to be simpler.

...which is easier said than done. Just how do you go about making a programming language simpler? The trivial answer is, I suppose, to make the syntax simpler. As a general principle, this is something of which I strongly approve - which is why I favour Pascal, Modula-2 and Ruby over APL or C++. But syntax is really quite a minor problem. Any half-way decent programmer will rapidly overcome an aesthetic aversion to an ugly syntax. Prolog took a more revolutionary approach to simplification - it worked on the basis that finding solutions would be left to the program, not to the programmer. While Prolog didn’t fully live up to this ideal, it seems to me that we still need people with that certain spark of genius to explore equally unusual and surprising approaches to the whole process of programming.

And what about maintainability? Ah, this is something to which, currently, I see barely even a glimmer of a real solution. At one time, maintainability was at the heart of programming design. That’s why Smalltalk worked with inheritance (re-using existing features) and encapsulation. And that’s why Modula-2 implemented data-hiding inside hermetically sealed modules. Where are Modula’s modules now? Watered down almost beyond recognition in the form of .NET namespaces and Delphi units, perhaps?

Life After Hacking...

A new generation of programmers, who have grown up with scripting languages such as PHP, Python and Ruby, often don’t seem to have any conception of the need for maintainability. There is now a whole culture of ‘contributing hacks’ to projects. This actively encourages the avoidance of personal responsibility for your code. For many people, it’s enough to write a clever code fragment, contribute it to some existing codebase and then just move on to some other project.

I know that’s not true of all programmers in these languages. There are some excellent Ruby, PHP and Python applications written by first-rate programmers. That doesn’t change the fact that the culture of ‘programming by hacks’ is fundamentally at odds with the traditions of programming for maintainability.

Often developers are obliged to rely upon tools as a means of maintaining their code rather than relying upon the inherent features of the language itself. So if a language has poor modularity/encapsulation, type checking and range checking - well, you can worry about that later when you run your test suites, difference checkers, versioning tools and so forth - many of which are aimed at picking up problems after they’ve already happened. This is the programming equivalent of investing in towing trucks to reclaim the wreckage rather than in better maintained roads and safer cars.

Where Next?

I’m not suggesting that there are no new ideas in programming these days - just no Big Ideas. It seems to me that most of today’s ideas are variations on established themes. For example, the current fashion for MVC (Model View and Controller) applications in which an application is compartmentalised into the data manipulation (Model), user interface (View) and programming logic (Controller) is no more than an attempt at good old-fashioned modularity. Then there are the functional languages - such as Haskell, Erlang and Microsoft’s F# - in which the evaluation of functions is the central principle. New? Hardly. Track down a white-haired LISP programmer and he’ll no doubt tell you he was doing this sort of thing half a century ago.

Then there is aspect orientation. A close relative of object orientation, this attempts to solve problems associated with shared behaviour (‘cross cutting’) in various parts of a single application. Aspect orientation provides a way of separate out shared behaviours and modularizing them - a wholly admirable objective, in my view. But a truly Big Idea? I have yet to be convinced...

And then there’s Groovy. This is the latest thing in trendy dynamic languages. Could this be the language I’m yearning for? According to its official site, Groovy has ”power features inspired by languages like Python, Ruby and Smalltalk”. OK, well, why not, I guess? The next question is, what innovating new syntax does it use? Wait a moment - are those curly brackets which I see before me? Yup, you guessed it, the newest exciting language on the block is yet another Yet-Another-C-Like-Language.

Aaaarrrrgggghhh.... I’ve seen the future - and it’s YACLL!

More From Bitwise The following articles expand of some of the points above...

 First Steps In Prolog
 Free Prologs
 Programming Milestones: Smalltalk
 Beginners’ Guide To Smalltalk
 Introduction To Ruby
 S# - Smalltalk :: The Next Generation
 The D Programming Language
 Interview with Walter Bright, creator of D
 Where Did Object Orientation Go Wrong...?
 The Great OOP Debate
 Stone-Age Programming and the Death of the IDE

Also (on the SapphireSteel Software site):
 Ruby The Smalltalk Way