But now it seems there’s a wee paradigm shift – back in the direction of languages we once rolled our eyes at…
Why is this shift ocurring now?
Imperative programming, with its military overtones of control and strict hierarchy, has been in vogue for a long time. There’s always been something simple and straightforward about telling a machine exactly how to do its job, laying out the boolean master plan with infinite and painstaking precision.
But then our apps got smarter, moved onto the web, got even smarter still, and developed a hunger for data that we’ve never seen before.
You can’t do anything intelligent without data. Want statefulness? Data. Want to know and remember users/customers preferences? Data. Want e-commerce transactions? Data. Want to manage content? Data. Want to enable interactivity and discussion? Want to track events? Data.
Some applications are evolving to the point where the actual functionality (as a percentage of the overall application) is just the flimsiest of skins stretched over a humongous network of data entities in the form of a modern-day RDBMS. Application maintenance is becoming synonymous with data backups and data replication strategies. Application enhancements are becoming synonymous with extra SQL queries against the backend.
Data, the most underestimated, un-planned for, un-cared for element in most systems development life cycles… data has a new old friend, and its name is declarative programming.
Simply put, we are starting to return to those programming and scripting languages that are most adept at manipulating data. Because when data becomes your chief focus, it’s nice to be able to stop caring how the machine gets its answers. It’s nice to just be able to give it a few words of advice about how things are related, hand over some initial conditions and then walk away.
Languages like Ruby, Python and Haskell have hit the big-time in the last few years because of elements of functional programming. (Functional programming is a subset of declarative programming, and this is just as well. We still enjoy being abstracted from the the complete mindf*** that is pure declarative syntaxes).
The other reason that data will push this issue further is this: the sort of algorithms that drive collective intelligence and datamining tasks are better written declaratively.
The sheer expressive power of available functional programming languages doesn’t just alter the way you think about problems, but I believe it helps you to think about, and solve, data manipulation problems. It’s not just that complex filtering and correlations can be done in a few terse lines of code, but that if you were to reverse engineer the logic and try to do it imperatively, you would end up doing it a different (less efficient) way.
Imagine being abstracted from telling the machine that it first needs to find an array of items and loop through it. And not having to tell the machine how to pick out, in particular, just the ‘blah’ items, and then do something with them. We shouldn’t care how it does this. We should only care that at a certain point in the application we need to ‘do something’ to all the ‘blahs’.
Anyway. The shift is one to keep an eye on…