Tuesday, March 25, 2008
The Language Question
My first job was working with Cold Fusion for a year. For the next two years I worked primarily with Javascript and a proprietary language. Next was a brief stretch with PHP and ASP, followed by about 3 years of .net. Finally, for the past 2 years I've been doing Ruby. I do not consider myself a Ruby developer. I prefer to just be a developer.
I don't expect that Ruby will be the last language I ever work with. In fact, I expect I'll probably be doing something new in the near future. The question is what language should I work with next? Should I go for a classic like Lisp or Smalltalk? Should I give Scala or Erlang a shot and ride the concurrency wave?
The problem is, I'm asking the wrong question. Rarely when discussing languages do the languages themselves dominate the conversation. I can't remember ever being in a conversation where someone won a language debate with things like closures, metaprogramming or static typing. Instead, the primary focus of language debates are usually around frameworks, performance, IDE support, developer availability, what OS does it run on, and any number of other factors that are only related to the language.
The question extends even beyond factors related to the language.
Two years ago I started looking at Ruby because several of my colleagues were giving it a look. I preferred Rake to NAnt, and starting using it on my .net projects. Before long, someone asked me to be part of a Ruby project, because of my limited exposure to Rake.
I got introduced to Ruby by coworkers who were interested. I got involved with Ruby because I prefer build files that do not require XML programming. I stuck with Ruby because we had a steady stream of Ruby projects that needed experienced developers, I got plenty of blog content, I liked the composition of the Ruby teams I got to work with, and I liked working with clients who are comfortable with early adoption.
Notice, none of the reasons I use Ruby have anything to do with the Ruby language itself.
I'm interested in doing something new because I feel like I've been doing the same thing for about a year now. I'm also interested in traveling to other ThoughtWorks offices and getting some fresh ideas for innovation.
Again, none of my desires have anything to do with language.
I'm not giving you the tired "no silver bullet" or the hand waving "the right tool for the right job". I'm asserting that people use those phrases to justify their language choice, but you'd be better off asking what the real motivations for choosing a language are. What other factors does the language introduce that make it their choice.
It's also helpful to have this understanding when considering criticizing someone's language choice. My friends aren't using Java because they like Java, they are using it because they like IntelliJ, high performance on a few boxes, simple deployment, Hibernate, String Template, Spring, and a hundred other factors. Therefore, criticizing Java as a language doesn't really do anyone any good. Even if I convinced them that Lisp is a better language than Java, I still wouldn't have convinced them to use Lisp on their next project.
I don't expect that Ruby will be the last language I ever work with. In fact, I expect I'll probably be doing something new in the near future. The question is what language should I work with next? Should I go for a classic like Lisp or Smalltalk? Should I give Scala or Erlang a shot and ride the concurrency wave?
The problem is, I'm asking the wrong question. Rarely when discussing languages do the languages themselves dominate the conversation. I can't remember ever being in a conversation where someone won a language debate with things like closures, metaprogramming or static typing. Instead, the primary focus of language debates are usually around frameworks, performance, IDE support, developer availability, what OS does it run on, and any number of other factors that are only related to the language.
The question extends even beyond factors related to the language.
At Google I’ll work with C++ rather than (for example) Ruby but I do get to be part of changing the world. -- Jon TirsenJon gave up a job using his language of choice to work with another language he likes far less, but for a cause he's very interested in. I have another friend who recently starting working with an investment company because he was interested in the domain.
Two years ago I started looking at Ruby because several of my colleagues were giving it a look. I preferred Rake to NAnt, and starting using it on my .net projects. Before long, someone asked me to be part of a Ruby project, because of my limited exposure to Rake.
I got introduced to Ruby by coworkers who were interested. I got involved with Ruby because I prefer build files that do not require XML programming. I stuck with Ruby because we had a steady stream of Ruby projects that needed experienced developers, I got plenty of blog content, I liked the composition of the Ruby teams I got to work with, and I liked working with clients who are comfortable with early adoption.
Notice, none of the reasons I use Ruby have anything to do with the Ruby language itself.
I'm interested in doing something new because I feel like I've been doing the same thing for about a year now. I'm also interested in traveling to other ThoughtWorks offices and getting some fresh ideas for innovation.
Again, none of my desires have anything to do with language.
I'm not giving you the tired "no silver bullet" or the hand waving "the right tool for the right job". I'm asserting that people use those phrases to justify their language choice, but you'd be better off asking what the real motivations for choosing a language are. What other factors does the language introduce that make it their choice.
It's also helpful to have this understanding when considering criticizing someone's language choice. My friends aren't using Java because they like Java, they are using it because they like IntelliJ, high performance on a few boxes, simple deployment, Hibernate, String Template, Spring, and a hundred other factors. Therefore, criticizing Java as a language doesn't really do anyone any good. Even if I convinced them that Lisp is a better language than Java, I still wouldn't have convinced them to use Lisp on their next project.
Labels: languages
Wednesday, October 31, 2007
Erlang Interest
Why do the Alpha Geeks care about Erlang? The obvious conclusion points to processor speeds remaining static, and multi-core computers becoming mainstream. As of October 31st 2007 it is quite complex to create a well designed desktop application that takes advantage of multi-core processors using Java, C#, Ruby, etc. Alpha Geeks like to have several tools at their disposal. Having several tools available can ease solving a complex problem if the tool is designed with that problem in mind. Therefore, looking to see if Erlang provides a better solution for concurrent programming is an easy choice.
Why do CIOs care about Erlang? CIOs know that computing power is going in the direction of more cores, not faster processors. Knowing that Erlang is a language designed to take advantage of multi-cores is enough to drive interest. Other questions that I would expect from CIOs are: Reliability? Nine nines uptime[1]. Maturity? It's been around for 20 years. Who else is using it? Ericsson, Nortel, T-Mobile. The argument sounds compelling.
Why do I care about Erlang? I quite like the idea of running an entire test suite in parallel. Additionally, Procedural languages were mainstream years ago and several best practices emerged. These days, OO languages are mainstream and more lessons have been leared; however, the masses have never exploited the power of functional languages. I believe that if programmers start writing applications in Erlang to address the concurrency issues the best practices from the functional community will be given more attention. I hope that everyone can benefit from the diversified experience.
[1] The AXD301 has achieved a NINE nines reliability (yes, you read that right, 99.9999999%). Let’s put this in context: 5 nines is reckoned to be good (5.2 minutes of downtime/year). 7 nines almost unachievable ... but we did 9. (http://www.pragmaticprogrammer.com/articles/erlang.html)
Why do CIOs care about Erlang? CIOs know that computing power is going in the direction of more cores, not faster processors. Knowing that Erlang is a language designed to take advantage of multi-cores is enough to drive interest. Other questions that I would expect from CIOs are: Reliability? Nine nines uptime[1]. Maturity? It's been around for 20 years. Who else is using it? Ericsson, Nortel, T-Mobile. The argument sounds compelling.
Why do I care about Erlang? I quite like the idea of running an entire test suite in parallel. Additionally, Procedural languages were mainstream years ago and several best practices emerged. These days, OO languages are mainstream and more lessons have been leared; however, the masses have never exploited the power of functional languages. I believe that if programmers start writing applications in Erlang to address the concurrency issues the best practices from the functional community will be given more attention. I hope that everyone can benefit from the diversified experience.
[1] The AXD301 has achieved a NINE nines reliability (yes, you read that right, 99.9999999%). Let’s put this in context: 5 nines is reckoned to be good (5.2 minutes of downtime/year). 7 nines almost unachievable ... but we did 9. (http://www.pragmaticprogrammer.com/articles/erlang.html)
Wednesday, June 27, 2007
The next big language
I believe the large success that Ruby has enjoyed has made programmers eager to find the next big language (NBL). The NBL holds a lot of promise for the aspiring software developer. Become an expert in the NBL and you'll be able to command a premium while riding the next wave. If your lucky you may also design the testing or build framework that will ensure stardom in the NBL community.
So, how can you be ahead of the curve? How can you be one of the first to master the NBL? Tim O'Reilly already told us how to start: watch the Alpha Geeks.
The NBL might be a language that already exists. Dave Thomas recently blogged a bit about Erlang. Avi Bryant continues to invest his time in Smalltalk. And, it would be foolish to ignore Paul Graham and the Lisp community.
Then again, the next big language might be Ruby with YARV, Rubinius, JRuby, XRuby, or IronRuby. It could also be a language that exists but has a small community such as IO or Boo. Or, it could be a new language with more or less rope.
I think part of the problem with guessing what the next big language will be is that the question assumes there will be one language that can satisfy all your needs. The truth is, differing systems have very different needs. How many web applications have you worked on that actually needed an object oriented language? Because of the request/response nature of the Internet, most web applications could easily be built using a procedural language. There's tons of PHP sites that work just fine without objects. Sure, some sites are complicated and need a bit more than PHP4. For example, building Yahoo Store must require an Object Oriented language, right? While Yahoo Store was probably a bit complicated for PHP4, Paul Graham lists Lisp as their secret weapon of success. I'm not implying that OO languages are better than Lisp or vice versa. I'm simply pointing out that a language choice is probably not something worth making at an Enterprise level. The same is true when looking for the NBL, you aren't likely to find one that is perfect for solving all possible problems.
So then the question becomes, of the various NBLs of the future, which one is designed to address the problems you are interested in? If multi-processors and concurrency interest you, Erlang might be the ticket. If you love building web applications, Ruby/Rails isn't likely to go away any time soon. Or, if you want to build on years of experience with the same language, Smalltalk and Lisp have plenty of lessons for you to learn.
In my opinion it doesn't matter what NBL is. Most languages have unique solutions that allow you see problems in an entirely new way. That's why the Pragmatic Programmers suggest that you learn a new language every year. So instead of looking for the NBL, learn a language with a paradigm that differs from the one you use at your day job. For example, if you are currently using an OO language, learn a functional language. The established languages of today have plenty of lessons for you to learn. Knowledge of Ruby, Smalltalk, C#, Java, Lisp, Erlang, PHP, Perl, etc will ensure that you will quickly become proficient in any language you adopt in the future.
If you still insist on trying to predict the future, here's something to consider. As an industry we spent many years learning the lessons of procedural languages. Next, the majority learned the lessons of statically typed object oriented languages. Now, more than ever, we are learning the lessons of dynamically typed object oriented languages. If I had to guess, I think sooner or later the masses are going to figure out that functional languages also have power to offer.
So, how can you be ahead of the curve? How can you be one of the first to master the NBL? Tim O'Reilly already told us how to start: watch the Alpha Geeks.
The NBL might be a language that already exists. Dave Thomas recently blogged a bit about Erlang. Avi Bryant continues to invest his time in Smalltalk. And, it would be foolish to ignore Paul Graham and the Lisp community.
Then again, the next big language might be Ruby with YARV, Rubinius, JRuby, XRuby, or IronRuby. It could also be a language that exists but has a small community such as IO or Boo. Or, it could be a new language with more or less rope.
I think part of the problem with guessing what the next big language will be is that the question assumes there will be one language that can satisfy all your needs. The truth is, differing systems have very different needs. How many web applications have you worked on that actually needed an object oriented language? Because of the request/response nature of the Internet, most web applications could easily be built using a procedural language. There's tons of PHP sites that work just fine without objects. Sure, some sites are complicated and need a bit more than PHP4. For example, building Yahoo Store must require an Object Oriented language, right? While Yahoo Store was probably a bit complicated for PHP4, Paul Graham lists Lisp as their secret weapon of success. I'm not implying that OO languages are better than Lisp or vice versa. I'm simply pointing out that a language choice is probably not something worth making at an Enterprise level. The same is true when looking for the NBL, you aren't likely to find one that is perfect for solving all possible problems.
So then the question becomes, of the various NBLs of the future, which one is designed to address the problems you are interested in? If multi-processors and concurrency interest you, Erlang might be the ticket. If you love building web applications, Ruby/Rails isn't likely to go away any time soon. Or, if you want to build on years of experience with the same language, Smalltalk and Lisp have plenty of lessons for you to learn.
In my opinion it doesn't matter what NBL is. Most languages have unique solutions that allow you see problems in an entirely new way. That's why the Pragmatic Programmers suggest that you learn a new language every year. So instead of looking for the NBL, learn a language with a paradigm that differs from the one you use at your day job. For example, if you are currently using an OO language, learn a functional language. The established languages of today have plenty of lessons for you to learn. Knowledge of Ruby, Smalltalk, C#, Java, Lisp, Erlang, PHP, Perl, etc will ensure that you will quickly become proficient in any language you adopt in the future.
If you still insist on trying to predict the future, here's something to consider. As an industry we spent many years learning the lessons of procedural languages. Next, the majority learned the lessons of statically typed object oriented languages. Now, more than ever, we are learning the lessons of dynamically typed object oriented languages. If I had to guess, I think sooner or later the masses are going to figure out that functional languages also have power to offer.
Labels: languages
