Last week's discussions of Java suggested to me that most of the response people have to programming language choices is driven first by the lack of real choices and secondly by issues of scale and perception.
Setting aside embedded uses of Java, I get the clear impression that if the stuff you do is what I'd consider fairly mickey mouse than you're likely to like Java because in that context it's fairly simple, somewhat safer, and far more politically acceptable than C or C++. If, however, you work with large scale business systems the Java you see is quite different: a horrendous mashup of this that and the other two things with little consistency, many, many dark corners, and roughly the efficiency of using a highway tractor trailer combination for your daily commute.
The reason for that is, I think, simple: when downloadable Java failed and people moved the code back to the servers, they extended its use into business application development when they should have abandoned it. Then, because it really is the wrong tool for that job, they tried to extend the object idea to avoid having to re-invent the wheel for each new deployment - specifically by building frameworks, libraries, and methodologies on or through which the business applications were to be constructed and run.
It almost makes sense: given Java, given object re-use, given the Windows IDE idea - but in practice what it produced was applications that require multiple generations of Sun's J2EE stuff on the same server, require multiple configuration files on idiosyncratic paths, and make debugging such a nightmare that you'll dream of doing simple things - like picking bits of smashed eggs out an anthill without disturbing the ants.
In a real sense this isn't Java: it's a compilation built on Java that masquerades as Java -but if working with it is a consequence of trying to force a Windows client run-time onto Unix, then what's the better alternative?
It isn't C/C++ - that's the right toolset for building Solaris, Apache, and the gnutools but it's absurdly wrong for something like a distributed customer support system.
So, .net? that's just BASIC with the Microsoft's proprietary version of Java's encrustation thrown in, so you might as well use Java and avoid both the risk of brain damage and the Microsoft lock-in.
COBOL? Somebody suggested that - and I hope he was joking: COBOL was an absurd codification of tabulating machine practice when it evolved in the late 40s and early 50s and hasn't gotten any more relevant to the digital age since.
So what's the alternative? I think frequent contributor fr0thy2's comment headline last week hits the nail on the head: C is fast, Ruby is beautiful, and Erlang is WTF? - and the last part of that goes for lots of unpopular choices because popularity has a lot to do with acceptability at the corporate level.
And that's the practical bottom line: there aren't many choices that are both acceptable and any good. Frequent contributor Mark Miller mentions, for example, a web development framework called Seaside - and on quick review it looks interesting enough to warrant exploration, but products like these are just too immature and too little known for enterprise scale use. Basically the problem is that no matter how well it works, the average IT manager won't buy it until its blessed by massive publicity and/or supported by IBM.
So what's left? Progress is pretty good - it's cheaper, easier to use, and both more portable and more scalable than .net - but it's still just BASIC in drag. The other 4Gls are either gone or on lifesupport -my own long time favorite: Unify Accell/Vision is barely alive and Oracle Forms, although nominally supported, is nearly unrecognizable - and new stuff is either very cool but useless at scale (like Access) or WTF - like trying to sell the TcL/Tk/Perl combination today.
So what other options exist? I think PHP sucks - but works for "risk contained" browser based applications. So, while I've never done a payroll or any other traditional business application that way, I think it could be done - and probably quite well too. More importantly, I think that the SAMP/LAMP toolset is getting better all the time -so if I were forced to bet on something right now, that's probably what I'd bet on.
And that's just awful.