Future Trends

Relatively speaking, I guess that Christopher Diggins is a more prominent blogger than I - but from where I’m sitting his recent post on The Future of Programming Languages is almost laughable.

Making predictions that are ten years out is pretty difficult, but I’d suggest that you shouldn’t start by listing trends and ideas that have already happened.

I’m not sure what Christopher has experience with - the Dr Dobbs Code Talk site is a walled garden and I can’t see his profile - but I’d strongly suggest that he should start by coming up to speed with version 3.0 of the C# language, where many of his far-future predictions are mainstream, today.

For what it’s worth (and I’m pretty sure I’ll look back on this post in the future and cringe), here are some of my own predictions on the near future of programming and development:

Source Code will still be text. Despite predictions to the contrary over the last couple of decades, we are still writing the majority of our applications in plain old text files (I don’t consider the transition from ASCII to Unicode significant). The reason for this is simple - flexibility. Text base source files are easily manipulated (generated, compared, compressed, parsed, compiled and more). No binary file format will ever be as flexible. Moreover, I don’t believe that any language designer truly knows what the language will be used to achieve.

Functional programming will become dominant. In many ways, the functional paradigm has already hit the mainstream - lift the hood on LINQ for example, and you gaze on a functional heart. This approach is going to become dominant, as it provides one of the cleanest ways to achieve extreme levels of parallel operation without requiring too many contortions on the part of the developer. When the computer on your desk has ten thousand cores, the current paradigms for splitting processing across five or ten or twenty cores are going to be inadequate. Pure (side effect free) functional programming opens the door for the compiler to provide the parallelism through optimisation, rather than relying on Joe developer. In many ways this is similar to the way that low level (assembly) coding has become fully automated, with our compilers producing results superior to the work of all but a few genius coders.

Business Users will write more of their own systems. As the toolkits and products become ever more powerful, the business value that can be delivered by technically minded business users will go up dramatically. This is a continuation of an existing trend - consider what can be done today by untrained business users with products like FileMaker Pro and (ergh!) Microsoft Access, and contrast this to the mid-1980’s where trained professionals used products like dbase III and Clipper to deliver less.

Developers will still be necessary. No matter how productive the toolkits, one truth will remain - business users are experts in their business, not in software. As the reliance placed on a system grows, the importance of more formal controls becomes greater. There will be a high demand for developers who are able to take on the systems grown by business users and nurture them into highly reliable, scalable and dependable systems.

Each of these predictions could be turned into a blog post of it’s own - perhaps I’ll do that. For now, though, I’d love to hear your thoughts.