My thoughts around my first JavaOne conference centered around, "What is the next big thing going to be?" in the sense of "what do I need to learn to stay current?" I definitely came back with a short list of very promising, but currently underdog technologies:
- JUnit (or unit testing in general) is easy and important enough to be part of every project. I even wonder if good unit tests are easier and more beneficial than type-safety in your programming language!
- Scala (successor to Java)
- Git (successor to Subversion)
- Maven (successor to Ant)
- Functional Programming (it's finally ready for prime-time)
- Algorithms (more than Data Structures)
These thoughts motivated me to make some tool changes and to take Martin Odersky's "Functional Programming Principals in Scala" (which was mind-blowing).
I've seen the rise of Data Structures, then Object Oriented Programming, and now Functional Programming and Algorithms. Functional Programming was really a dark horse from my perspective because Lisp is the second-oldest programming language, yet FP failed to become mainstream until very recently.
My functional experience before Scala was confined to e-lisp and XSLT, neither of which make a particularly good general-purpose programming language. The recent death of Moore's Law and the triumph of concurrent processing in cloud services like AWS have given Functional programming better performance and code-comprehension characteristics than imperative programming. I definitely didn't see that coming.
Sometimes the Don Quixote principal makes bad popular ideas successful - if enough people believe in something it becomes true. I wondered about that and Functional Programming. "Computer Science" has lived in the Math department of most universities. If you get enough math geeks doing programming, of course they will start to favor a style that looks and behaves like functions from the field of math. So what, I thought, if Functional Programming was based on Lambda Calculus - is it practical for solving business problems?
But this was not the right question. The people asking, "What can a program possibly do" and "What is the best way to do X?" are the ones creating the technological innovations that ultimately drive the rest of the industry. The limitations of what programs can do (and how efficiently those tasks can be accomplished) constitute a good part of the study of algorithms and the inspiration for new languages. Sure, you can do most things in most general-purpose languages, but as James Roper said and Havoc Pennington quoted in his recent talk (slides available here), just because you can do something in a language doesn't mean that you will. Some things are just too difficult in some languages. This is why knowing both Imperative and Functional styles is very helpful in addition to studying Algorithms.
The easy problems may continue to be solved in imperative languages without much thinking about algorithms at all: transform one kind of text to another, deliver the right data for a given request, or generate a report from a database. But the hard problems are increasingly going to require concurrent processing with the most effective algorithms. Sure, it's easier to do some things in a functional language, but a great algorithm in a limited language beats a crummy algorithm in a concise and beautiful language any day.
Java is a great language, but it is showing its age:
- Primitives and API classes (like List and Map) are all designed to be mutable. Concurrent programming with this inherent unsafety is a real bear. Even without concurrency, it's just easier to reason about things that don't change. Just using Java collections properly requires immutability!
- Collections are managed through iteration which puts the burden of concurrent programming on the user of those collections. This will be fixed by Lambdas in Java 8.
Scala is the language most similar to Java that overcomes these limitations, so you may find more of that and less Java going forward. In any case, my search for "The Language After Java" has led me instead to a short list of really promising tools, and a rapidly growing interest in Functional Programming and Algorithms. I only wish I had hit on these ideas earlier in my career. Thank you JavaOne - and thank you John for getting me to go there!