Quantcast
Viewing latest article 1
Browse Latest Browse All 11

Making A Living With Languages

When it comes to programming languages, my tastes are pretty eclectic. I've been using Object Oriented languages for years, primarily Java, and in the last few years I've tried several functional languages, such as Erlang, Haskell and Clojure. I've played around with Google Go (a REALLY difficult language to search the web for ... c'mon guys, try using something other than a common verb as a name), CoffeeScript, Dart and just recently took a look at the new Microsoft language, TypeScript.

One of the benefits I get from looking at these different languages is that they help me think differently about problems. Using Java, and only Java, for a long time can make you think in Java. Your mind effectively becomes limited to the same programming model expressed in the language, and so is limited to solutions which can be expressed in that language. Trying out different programming languages helps keep your "programming model" open and flexible, often solving problems using the required target language but in new and innovative ways. Some of this bleeds over into usable frameworks - for example, the Akka Java/Scala framework is based on the idea of actors and message passing seen in functional languages like Erlang.

However, experimenting with all these different languages can also be a little depressing, because at the end of the day I need to make a living, and the real world is sometimes not shiny and new.

Where I live and work (Calgary, Alberta), there are two job opportunity sets: Java & .NET. OK, there is a smattering of work done in C/C++ and I've even seen some Erlang. Web development means more JavaScript has surfaced over the last few years, and mobile development has added Objective-C and Android-Java to the mix, but the take-up of mobile apps in the corporate space is still limited. For the most part the languages, frameworks and techniques used in enterprise applications are pretty straightforward and staid. Really, as they should be when software development is not your business but just a tool. Sadly, that leaves little room for "fun" at work: playing with new languages, tools & frameworks is something I do in my own time and, while it often has a beneficial effect on my work it's something that doesn't happen very often at work.

I've spent the last umpty-ump years coding in Java - from the 1.0 days - and probably will until I retire. Don't get me wrong, I like Java and I think it's fair to say that if you're a Java programmer you're not going to be unemployable any time soon (although you may have to be flexible on your rate). But, the "safe" Java route  of JEE, and even Spring-based, applications can get a bit boring after a while. Chances to use new languages & frameworks doesn't often come along, so when they do, I seize them. But ...

Again, the real world is where I work, so I have to be sure that when I recommend or use something new & shiny it is in the best interests of my client to do so and not just because of the shiny. That means considering other factors such as who will maintain the code after I have gone - does the skill set exist in the Calgary area (or at least can it be easily learned)? What is support for the technology like? Is support commercially available or just community-based? These factors often limit choices to a manageable, mainstream set of technologies. Balancing the potential commercial advantages of a particular technology against it's technical "risks" can be an interesting challenge at times.

Viewing latest article 1
Browse Latest Browse All 11

Trending Articles