Coming down the pike
So there I was, surfing reddit and DZone for some Helltime material, when I found the 5Whys blog on technical leadership. I found a post about a possible job description for a tech lead:
… Here’s what you need to do:
Remember what it was like to be a junior programmer
Teach others to avoid the mistakes you made so they don’t stay junior for long
Know about the next generation of technology coming down the pike …
Ah yes, the fabled advice to know what the next big thing will be and not be left behind. I have written before at a somewhat high level about the future, and I have also expressed my own concerns that I try to stay up on the latest and greatest. That is partly the reason behind the Code H’yungs my severely-delayed re-implementation of The Project.
I haven’t gotten specific, though. What are the specific languages, tools, and ideas that are up and coming right now? Let me share my findings, categorized of course.
Languages
I think the programming languages of the future will be multi-paradigm languages, and I’m talking about languages that are both object-oriented and functional. I also see functional languages themselves coming of age. I think this is due to the increasing need for parallelism, thanks to the rise of multi-core processors (via the limits we have reached on single-core units) and the death of the thread model.
Most of the languages also seem to be dynamically-typed, and I think the rise of continuous integration, automated unit tests, and better hardware are all contributing factors to this trait. Statically-typed languages are still in the mix too, though.
This list is my general impression of what I read in various blogs and articles around teh interweb.
- Python: object-oriented, functional, imperative, dynamic
- Ruby: object-oriented, functional, imperative, dynamic
- Groovy: object-oriented, dynamic
- Scala: object-oriented, functional, imperative, static
- Clojure: functional, dynamic
- Haskell: functional, static
- Erlang: functional, dynamic
- Delphi: object-oriented, functional, static and dynamic
- Jython: object-oriented, functional, imperative, dynamic
- JRuby: object-oriented, functional, imperative, dynamic
- Objective-C: object-oriented, static and dynamic (mainly because of the iPhone)
- Prolog: logic, looks dynamic
- Perl: object-oriented, functional, imperative, dynamic
Buzz-worthy:
- Self: object-oriented, dynamic
- Factor: object-oriented, functional, dynamic
The Tiobe index is another good compliment to my daily blog surfing to find out what languages are on the rise.
User Interface
This section will be short since it isn’t my strong point. Clearly, Web 2.0 is the norm. Websites by and large are behaving more like desktop applications running on the operating system that is the internet. Asynchronous features using Ajax are prevalent. jQuery complements by allowing developers to quickly script web pages.
Web development frameworks that figure to be big soon (or are starting to be big now) are Rails, Grails, Spring MVC, and Django.
Architecture
Oh yes, let’s get very hand-wavey now. First, you have to say that The Cloud is probably the architecture of the future. It is abstraction at its highest point yet. Every actor in The Cloud is shielded from the implementation details of those upon which it depends. Everything is a service: software as a service, infrastructure as a service, platform as a service.
More generally, systems are already becoming more distributed and will be in the future, specifically N-tier architecture. Also, don’t discount the effect that virtualization can have on an architecture. Requirements like availability and resiliency can be met when operating systems are de-coupled from their hosting hardware platform. From there, it isn’t a far leap to desktop as a service, the ultimate thin client.
Coming hand-in-hand with the scalable nature of cloud architecture is the concept of distributed databases. The same old benefits of scalability and performance are the main motivators.
At a lower level, the Spring Framework seems to be the big player that is starting to dominate the Java application development framework arena. I searched far and wide for competitors for Spring and I wasn’t able to find anything that covered as many avenues that Spring covers. The closest thing I could find was the Google Web Toolkit.
Good reads on the next stage of software architecture are the 10 must-know architecture topics for 2009 and InfoQ’s architecture trends for 2009.
Data Storage
Relational databases are so ubiquitous nowadays that you might take them for granted as the default data storage mechanism. I’m in the game to avoid complacency at all costs, and it is perhaps the most dangerous where you least expect it.
The first wave of non-relational storage has come in the form of XML. XPath and XQuery are query languages that exist to fill the need for easy access and manipulation of XML.
Beyond that, there is a movement out there called NoSQL, which advocates the abandonment of SQL from databases. This almost always implies a move away from the relational data model as well. Examples include CouchDB, written in Erlang, which apparently retains query capability.
The big gain of the NoSQL movement is avoiding the object-relational impedance mismatch. Further reading on databases: Sybase blog: database trends. Hank Williams: The Death of the Relational Database.
Data Access
This brings us to our final category: Data Access. Next to the data storage category, this category required the most research because there seems to be a lack of direction.
The big thing right now is object-relational mapping. I’m sure you’ve all heard of Hibernate for Java, NHibernate and the Entity Framework for .NET, and so on. ORM is big.
If you’ve paid attention to reddit or DZone lately, you might start to re-think ORM, either partially or totally. The rise of the aforementioned functional languages have led some to advocate abandoning ORMs for lightweight solutions based on closures.
There is also a good deal of detractors from ORMs, and from domain-driven design in general, who insist that using an ActiveRecord approach is the best way to go. This throwback might also be in the future of data access.
Although I have yet to find any examples, another step in the evolution of data access would be to completely de-couple your data access code from changes in your schema. Then again, I’m led to believe that good, old-fashioned stored procedures provide exactly this capability. Typically, when your stored procedure changes, it is because you need to add more or less data, and at that point, your code will have already changed anyway. Perhaps going back to such an implementation is also in the future of data access technology. I know I’m an advocate of this approach.
So?
So you can’t stop learning. Writing this post was depressing because it reminded me of how little I know. And I especially don’t understand people who spend nearly a decade working with one technology or language and wonder why they can’t pick up Java in a few weeks. I mean, it’s Java.
 |
Announcer: You’re reading the EIP web-ring. |
