The Next Big Programming Idiom
Posted by Peter on May 6, 2006
Before I begin I would like to state, for the record, that I am not trying to incite a language flame war (at the moment). I’m not asking here which language will be the next popular language, but what programming style will be popular. Will functional programming make a comeback? Will OOP refuse to die? Or will it be something we haven’t seen before?
One thing I am sure it won’t be is natural language programming. Attempting to program using complete sentences is the opposite of what you want a programming language to be, namely concise and powerful. Have you ever heard someone tell you that the code is the documentation? This is because for the most complicated algorithms pseudo-code is a shorter and a more accurate description than words could ever be. As programmers we want our languages to be concise and precise, and natural language is neither.
The rise of a given programming style, historically, can be correlated with what kinds of problems were popular. For example when systems programming was the hot topic C (and the imperative style) became dominant. Functional programming had its heyday with AI researchers, because passing functions around makes algorithms in AI research much simpler. Most recently OOP has become popular with the rise of GUIs, because objects and messages are a natural fit for window controls.
So to predict what will be next we should look at the kinds of problems that programmers deal with most, and I think it is obvious that the “hot topic” in programming is distributed applications, specifically web services, AJAX applications, and collaboration software. From this list it seems likely that the next popular programming idiom will need to have concurrency, state, security, and errors as its strongest points. Concurrency means that the idiom needs a transparent way to deal with threads and synchronization. If you ever need to explicitly create a thread or lock a mutex then the idiom has not solved this problem. State means that the idiom must support the ability to maintain unique data for any number of clients in a natural way, and possibly the ability to unwind state when necessary (much like a continuation). Security means that stupid programmer mistakes, like passing the user name from a text field directly to an SQL query aren’t possible. Tainting is currently a way to “solve” this kind of problem, but I can’t say that it is a very good solution. Another way might be to do away with the ability to pass strings directly to library functions. Finally, errors mean that there must be a transparent way to deal with the unexpected, either by correcting the error in place or exiting from the part of the program that raised the exception. Once again, having an explicit try-catch construct is a sign that errors are a problem that hasn’t been solved as part of the idiom.
Web apps have been around for a while now, so you may be wondering why the next big thing hasn’t arrived already. I think the delay is because in this generation of problems we have several strengths required of new idiom that are at odds with each other, while in previous generations there was the real problems were closely related to each other, and thus easier to solve all at once. What I mean by all at once is that it can’t be simply be four solutions glued together, it needs to be one solution that solves all four problems, much like how OOP solved data encapsulation and message passing at the same time. And of course they must be transparent solutions, meaning that the best solutions with respect to these problems are also the easiest solutions, and require the least amount of programmer effort possible.
OOP enthusiasts will of course tell you how well OOP deals with these problems (try-catch, thread objects, synchronization objects, yadda yadda). These solutions are not transparent at all, and more tellingly the fact that you are expected to use a framework in many OO languages to create large scale web apps (java, ruby, ect) shows that the solutions provided by this idiom aren’t really up to solving all the problems. However, because its replacement hasn’t arrived on the scene yet programmers are stuck with OOP, resulting in buggy and insecure applications. Yes, you can make an OOP project thread safe, resistant to errors, and secure, but it is a radically different kind of task than throwing together a GUI, so why should programmers be using the same techniques? Unfortunately functional programming isn’t the solution either. Although functional programming handles concurrency well (assuming there are no side-effects), it suffers when you try to implement an error handling system, or synchronization when you absolutely must have side-effects.
A solution to the threading and state problems might be event based programming. In event based program the application is structured around a number of events, each of which is called asynchronously. Also each event is called in a “context” (local state). With respect to this context some events are exclusive, meaning that only one can be invoked at a time, while others can be running simultaneously with each other. Event based programming solves the state and concurrency problems, but not those of synchronization or error handling, meaning that it will not be the next idiom, since all of these problems must be solved in one fell swoop. I mention it simply to show that the idioms we currently work with aren’t the end of all language development.
The only conclusion I can provide unfortunately is that whatever the next idiom is that I haven’t seen it yet. If you think that you have feel free to leave a message here.