I was inspired to write this by the following youtube videos:
It is not enough for a developer to only know one programming language these days. Our industry has evolved to the point where we are expected to do everything from frontend web development, backend business application development, mobile development, cloud computing, etc … Unfortunately, no single programming language is going to be able to do all of these things; so, it fall on us to increase our breadth.
From what I can see of where the industry is moving, in order to stay relevant (and in-demand) as a developer, you should know at least 5 of these languages..
1. One object oriented programming language (C++, JAVA, C#)
Business is very invested in these languages; so, they are going to have to maintain these systems for a very long time (probably longer than they should, too). If you know at least one of these languages then you are guaranteed employment for the rest of your life.
The downside is that doing maintenance programming is incredibly boring. However, it’s one thing not to like your job; it’s another thing not to have a job.
I personally enjoy not being poor.
2. One web scripting language (Ruby, Python, PHP)
The web is ubiquitous. However, programming a web application with a general purpose programming language is extremely painful. I’ve had the misfortune of having had to build very complicated web applications using JAVA and C#; so, I know from experience how torturous that kind of development is.
Web scripting languages like Ruby, Python, and PHP are amazing at building web apps. For example, I use VI to develop in PHP and run unit tests on the command line. That’s how powerful PHP is for the web.
The only reason JAVA and C# are even viable options for web development is because of the extremely powerful IDE’s and enterprise frameworks built to support it. In my opinion, if your language has to rely on a boatload of extra stuff to work then maybe your language isn’t up to the challenge.
Any experienced web developer will know that web scripting languages provide the easiest and most straightforward way for you to build a website. The solution may not necccessarily be as elegant as something built with ASP.NET or JAVA Spring, but it will get the job done.
You might be tempted to respond with something like “but .NET is beautiful” or “PHP is so ugly”. That kind of thinking is the result of programmers constantly being told that “what we are doing is art”.
NO! NO! NO! NO!
The person paying you to build him a website, isn’t paying you to be an artist. He is paying you to build him a website. Period. Choose the simplest most cost effective way to do that.
Software architecture as art will promote aesthetics over utility. I’ve worked with too many web frameworks built with super elaborate class diagrams that you had to memorize in order to do the most basic thing.
I have a suspicion that the people who create these frameworks are not actually using them. Instead, they are appreciating the beauty of their class diagrams.
Sure, some of the web scripting frameworks might not be the best, but you are still better off using one of them than something like Spring or .NET MVC.
3. One functional programming language (Erlang, F#, Scala, Clojure, Haskell)
Programming languages have a tendency of coming and going in waves. Functional programming is the next wave. To understand why, you have to understand where we were before, where we are now, and where we are going next.
The 1970’s introduced the imperative programming wave because it freed developers from having to write low-level assembly language. C, COBOL, Fortran, and BASIC were able to create applications that were independent of a computer’s architecture, which at the time was a big deal.
The 1990’s introduced the object oriented programming wave. As applications became more and more sophisticated the need to simplify very complex conditional logic drove the industry toward polymorphism. There were other styles of polymorphism but class based polymorphism ended up being the implementation of choice.
The 2000’s (primarily the later half) was all about web scripting languages. The web 2.0 revolution meant that you had to build a website fast and iterate fast. For better or worse, scripting languages allowed you to hack together a website pretty quickly.
These transitions were made possible by Moore’s law. Moore’s law states that processor speeds would essentially double every 18 months. It is this phenomenon that allowed developers to move from one wave to the next: we had to wait for the computer engineers to build the hardware that could power a certain type of development.
For example, scripting languages are horrendously inefficient compared to compiled languages. However, with a fast enough machine, that doesn’t really matter. What matters is how fast you can get a working product out.
At some point, Moore’s law began to fail (we’ve been stuck with 3.0 Ghz processors for at the last 10 years). To compensate for hitting that wall, the computer engineers began to add multiple cores to a CPU.
For example, my current laptop has 8 cores inside of it running at 2.5 Ghz, but in order to take advantage of those 8 cores, my software has to be explicitly written to spread the execution across all those cores.
Concurrent programming is extremely painful; so, developers simply don’t do it.
However, technology stops for no-one, and the CPU arms race will continue to double the amount of cores available in a computer. It’s very likely that 18 months from now we will have 16 core machines, and 18 months after that we will have 32 core machines.
Your days of programming for a single machines and a single thread are over. The systems of the future are going to be highly distributed and multi-cored, and the way that we currently build software doesn’t deal with that.
Are you up for the challenge of building systems that can take advantage of 32, 64 or 128 cores? My guess is that you are not; so, you had better start learning how to do that, now. Employers will not like the fact that they are buying hardware that you can not take full advantage of.
If you think that you will be writing concurrent applications in C++ and JAVA then you are either the best programmer in the entire world or simply crazy. The traditional shared memory model is too error prone and unpredictable.
The shared memory model introduces problems like deadlock, livelock, and starvation. While we have methods to deal with them, they are not easy. For example, it is not uncommon to spend months chasing a multi-threaded bug. Imagine how painful it will be when we have 32, 64, or 128 cores.
Functional programming languages removes the shared memory model by operating on immutable data types and working with side effect free functions. Once you remove the shared memory model, you also remove all the complexity associated with them.
Further, functions in functional languages behave very similar to mathematical functions; so, it’s much easier to reason about program correctness with them.
These properties makes concurrent programming more predictable and manageable in functional languages. That is a huge competitive advantage over procedural or object oriented languages. The caveat is that it introduces a completely new way of thinking.
Do you like getting paid? Well, you had better start picking up a functional programming language.
OK. That is technically 3 different programming languages, but it is pretty much impossible to building anything useful with one of them in isolation.
We no longer need JVM or CLR technology in order to get cross-platform applications. Thanks to the universal adoption of HTML5 every HTML5 application can easily be deployed to any OS or device
At least, that is the promise of HTML5. We are still building the technology to support the HTML5 infrastructure, but the future definitely looks promising.
I’m particularly impressed with Phonegap. I haven’t created a native android or ios app in a year because now I can just deploy an HTML5 app to those devices.
Unless you really enjoy writing multiple applications to support multiple platforms then I would suggest you start learning how to write SPAs. There are plenty of options: Durandal.js, Angular.js, Ember.js, and Sencha Ext JS are just a few from the top of my head.
The relational model that SQL is built on top of is incredibly powerful. 40+ years of research has gone into developing it. It has been studied from top to bottom and left to right. The use of normal forms for OLTP, and data marts for OLAP are incredible tools. There simply is no equivalent to them. Although, there is some attempt to try and create one (see: http://queue.acm.org/detail.cfm?id=1961297).
Ultimately, it is the way of thinking about your data that SQL requires you to do that is important.
Some of you reading this might be thinking “What about ORMs?” or “What about NoSQL?”. Well, let me address your concerns.
The fact that ORMs exist are not an excuse to ignore SQL and the relational model. ORMs are a convenience. They are not meant to serve as a drop in replacement for database knowledge (or at least they should not be).
It is a shame that people have invested so much time and effort into thinking of strategies to prevent software developers from actually having to learn database theory. I’m amazed that entire frameworks have been invented so that programmer would never have to understand the details of how a database works (i.e. hibernate).
These frameworks have essentially given developers the license to be stupid. It’s never a good idea to let developers be stupid.
NoSQL was driven mostly by non-functional requirements: scalability and partition tolerance. In order to achieve that goal, most NoSQL implementations had to relax certain properties in order to achieve that end. That isn’t necessarily a bad thing, but it points to the fact that NoSQL isn’t trying to do the exact same thing as SQL. Simply because something else exists doesn’t give you license not to understand something else.
Of course, this is all just my own opinion. Your goals may be very different from mine.
If you really love JAVA and don’t want to do anything other than JAVA then by all means do so. However, I seriously doubt that 10 – 20 years from now, you want to be the legacy JAVA programmer that the new young developers make fun of. If you think that that can’t happen then consider that 20 years ago we still had a lot of COBOL programmers.
Our industry moves really fast: faster than any industry, probably. If you are not constantly updating your skillsets or mastering fundamentals then your are in serious jeopardy of being left behind.