Gee... I've been in the IT field long enough that I remember hearing "C is dead".. "C++ is dead" "COBOL is dead", "BASIC is dead" and on it goes.

It wouild seem to me that C and C++ are just as alive today as they were in the late 1980s when there were those that thought they were dead. In fact the company I work for has been using C++ for our core products to this day.

BASIC hasn't gone away either. It may have morphed into other things such as the dialect of BASIC used with the Stamp and Stamp II micro-controllers.

Perl is not going away soon in my humble opinion. As evidence I offer up the last contract job I took on with a major financial institution who had such an investment in locally developed Perl modules it would take them at least 20 years in my thinking to replace all that functionality.

As for JAVA. I program in Java and I find myself frustrated with the language on numerous occasions finding it rather difficult to do things in the language using 20 lines of code where I could do the same darn thing in 5 lines of Perl. As a web language under such web containers such as Tomcat, JBoss, Weblogic and others you are constantly dealing with memory issues.

PHP is another of those languages that I try and avoid writing code in it. Seems to me it takes a lot to get simple stuff done.

Ruby is a relatively new language to me and the jury is still out. I get interested in Ruby because of my interest in Puppet which is a system configuration management tool. Puppet is written in Ruby and can be extended with new types and providers by writing Ruby code. Ruby on one hand reminds me of Perl in some respects and is cryptic as all get out on the other.

Python... I don't do snakes.

Getting back to Perl. I spent some time as an adjunct professor teaching Perl to the masses. The majority of my students were Visual Basic (another form of BASIC!) or Java programmers. Once I got them over the fact that they'd actually have to use some sort of text editor to write code instead of a neat GUI or IDE with on the fly syntax checking I was surprised to see how quickly I could take a class of students from

#!/usr/bin/perl -w 
use strict;

my $w1 = "Hello";
my $w2 = "World";

printf "%s %s!!\n",$w1,$w2;

exit(0);
[download]

I guess one of the "take aways" here is that the actual language you program in doesn't really matter. It is the mindset of the programmer doing the work, their ability to organize the steps of the solution to a problem, and when things go bad their ability to debug/troubleshoot the code.

I've seen (and been responsible for) some really ugly code in a wide range of languages from my beginnings in 1972 with Dartmouth BASIC and Fortran IV, to COBOL in 1974 and up to the present day with C/C++/Java/JavaScript and of course my favorite language, Perl. I've also seen very elegant code (including some of my own) written in the same languages.

Another "take away" I can offer as well I have a workshop at home with tools ranging from simple screw drivers to a small lathe. I have electronic instruments ranging from VOMs to Oscilloscopes. If I need to hang a picture on my living room wall I am not going to drag the lathe up from the basement to bang the nail in. As absurd as that sounds that is what some folks try and do in the programming world. Anymonk remember the TCL/TK web browser plugin? </p.

If I need to do AJAX on a webpage I need to use JavaScript. As far as I can tell there is no way around that if I want to be browser neutral. Having brought up browsers I can tell you that writing JavaScript that runs on every possible web browser out there can be a challenge at times. Try using the DOJO framework and see what happens when you compare the results between Firefox and IE5. Not pretty.

The backend to AJAX doesn't matter. I can write that in Java withing a web container, I can write that as a RESTfull service in Perl. I can even write a web service in Ruby on Rails to get the job done. What is going to drive my decision as to which I'm going to use is going to depend on the application itself, the environment it is running in and what is already running on the target web server. If there's no CGI support on the web server but they are running a web container, guess what? I'm going to end up writing the back end in Java.

No one language has all the answers.

I will now fall off my soapbox.