My job requires me to figure out road maps for software technologies. One of the key heuristics I use in figuring out where a software technology is likely to go is mapping out that technologies transition from a procedural to a declarative design environment. This technique is proving a big help for my work on utility computing.
In their beginnings most software technologies start off procedural.
Think of the web, the first dynamic web pages usually started off life as Perl or C code that outputted a bunch of HTML to some function that handled sending them as a response in a HTTP stack. The benefit of this approach is flexibility. Anything the programmer can provide instructions for can be achieved using a procedural approach. The downsides to a procedural approach are speed of development and code fragility.
Speed is an issue because it takes time to think of each and every step and make sure they are all designed exactly right. Code fragility is a problem because procedural code describes what a system is supposed to do but it doesn't specify the actual goal the instructions are supposed to achieve. So for example, if a programmer wanted to change the navigation path between Perl or C based dynamic web pages, the programmer has to manually go through all of the code and find all the print statements that contained URLs and change those URLs to follow the new flow pattern. This process is error prone and therefore likely to cause undesired results or even break the code all together, hence the term "code fragility".
Over time, as more experience is gained with a new technology, best practices are understood and common use cases are documented, the development tools will start to switch from a procedural to a declarative basis.
Going back to the web example, modern dynamic web pages designers use technologies like page flows that allow them to use a canvas to drag and drop page icons and then draw links between icons to define navigation paths. If the programmer wants to change the navigation paths they just change the links. No grubbing through code trying to find all the href print statements.
In a declarative system the programmer specifies their goal, i.e. what they want to accomplish and leave the task of actually figuring out how to achieve that goal to the development tools themselves. The strengths and weaknesses of declarative solutions are the inverse of procedural ones.
Declarative solutions tend to enable rapid code development because the developer can focus on their goals rather than detailed sets of instructions. Declarative solutions also tend to be more robust because reviewers only have to check if the programmer has expressed their goals correctly. In a procedural system the reviewers both have to check the programmer's goal statements (which are usually in a natural language) and then make sure that the potentially thousands of individual instructions will result in those goals being achieved. In addition when the code is changed it is the development tools and not the programmer who figure out what the consequences of the change are and make all the appropriate adjustments. The end result is that even large changes can be made with a much smaller probability of code breakage.
On the other hand declarative solutions tend to be much less flexible than procedural solutions. In a declarative environment the programmer can only accomplish goals that the underlying tool has been programmed to support. The developer can't achieve goals that the tools don't understand.
In practice the distinction between procedural and declarative solutions is not as stark as presented above. It is common for procedural solutions to include declarative capabilities (just look at the source code annotations craze) and similarly all good declarative systems have procedural "escape hatches" to allow programmers to do something unexpected.
Understanding the transition from procedural to declarative development helps me figure out where technologies are likely to go. For example, right now I'm working on utility computing, specifically the issue of compound application management. Although management technologies do make use of declarative tools most of the real work is being handled procedurally either through script files or through manual set up and configuration of machines and hosting environments by administrators. Recognizing that management technologies seem stuck in procedural techniques I am now much better placed to start building a road map to get them to a more declarative (and thus faster, easier and most crucially, cheaper) future.