“The Mythical Man Month” was published in the mid-70′s and most of it still rings true today: adding people to a late project makes it later, and there is no silver bullet.
It probably says something about software developers that they talk about a device or system for radically improving their professional lives in terms of a metaphor for killing vampires.
But code–while it is both soulless and immortal–doesn’t really resemble anything you’d want to slay very much.
That said, there have been a couple of silver bullets proposed in the past fifteen years, and it’s instructive to look at where they are today. The first is generic programming, which limps along under the somewhat more pretentious name of “template metaprogamming”, and the second is functional programming.
Generic programming got a big boost from the standard template library in C++, but despite considerable improvements over the years the system has never really caught on. C++ extensions like the “D” programming language remain academic, and while virtually any “good” language these days has some form of genericity–from Python’s duck typing to Java’s aptly named generics–they remain at the periphery of software development practice, and rightly so. While absolutely without peer in certain very limited but important areas, attempts to use generics for everything from matrix initialization to sliced bread have mostly fallen flat.
I’ve recently been playing with the boost::msm library, which is a good example of the failings of the “generics uber alles” approach to software development. While there may be a language out there that makes such concepts both powerful and easy to use, C++ is not that language and never will be. Nor do I think, for reasons that I won’t go into here, that are generics the appropriate way to provide software developers with the tools they are looking for to solve the problems generics take aim at.
So generics are not a silver bullet, but they are still damned useful in some very important but very limited scopes. I wouldn’t want to design without them, but I wouldn’t want to design with only them, either.
Functional programming is a much shinier silver bullet, having not yet had time to tarnish in the oxidizing atmosphere of actual software development teams for very long. Haskell and Erlang are the two most-talked about examples, with Haskell winning the prize for functional purity and Erlang the one for being pretty useful. There have been some significant applications written in Haskell–a provably correct Perl compiler is nothing to sneeze at–but its purity remains a significant barrier to entry. There’s nothing wrong with that, but Haskell has not to my limited knowledge ever made anyone say, “Wow, this would have been so much harder in language XYZ!”
Unlike Haskell, which was developed as a theoretical platform that should also be practical, Erlang was developed as a practical solution to a practical problem, and while it doesn’t get the hype that Haskell does it certainly seems like a tool that makes some things that would be otherwise very hard relatively easy: notably distributed concurrency. Outside of that, it’s not clear why one would use the language, although I’m certainly looking forward to doing so.
So like OO, functional and generic programming have their place, but they aren’t ever going to displace procedural programming as the core of the software developer’s workday.
It’s probable that functional extensions to general purpose languages will become relatively common in the next decade, much like OO extensions to procedural languages became common in the ’80′s. The purely functional languages are not going to kill any vampires, though, any more than Smalltalk took over the world when Reagan was president (although Ruby is giving it another go…)
The curious thing is that there are still people out there who believe that the next shiny bit of syntax layered on over the sequential execution architecture of the CPU is going to solve all our problems. Historically this is simply not a remotely plausible belief. This is not how the world of software development has ever progressed. There are no silver bullets because developers would rather stick to the tools and techniques they know, and adapt those tools to take on the best attributes of any candidate silver bullets shot in their general direction.
This is the same as the hardware world, more-or-less: the turnover of mature technology is incredibly slow. Hybrid automobiles are an example of how difficult it is to actually displace an established way of doing things. Burning fossil hydrocarbons is such a deeply optimized approach to the problem of transportation that it was easier to adapt it to a semi-electric vehicle than build an all-electric one. I think it likely we will still be using heat engines in cars a hundred years from now, and the computers in those cars will be running primarily procedural code.
