I keep reading blog posts where people equate Java with Cobol, that it's a dying language not suited for work today, and that people who use Java are generally less intelligent about programming in general. Given that dinosaurs ruled the earth another 50 million years or so after the Triassic period, I'd say Java still has a long useful lifespan.

Not that it's perfect at all, but I've been using Java for almost 10 years now, and compared to my years of C and C++ I am fairly glad I moved on. I've worked for years starting with Basic, then Fortran, Pascal, Assembly, C, C++, Objective-C and finally to Java; I've seen a steady improvement in my ability to be productive with my language and its entourage (frameworks, libraries and communities). Like the dinosaur, every language eventually falls out of favor as new "mammals" appear but rarely does a language die out completely. Like most animals and plants, they survive and even thrive in different environments way beyond the general evolutionary landscape that might otherwise kill them off. How else can you explain Object Cobol?

For me I find I can do almost anything in Java, provided a reasonable set of choices for the environment I am writing code in. I dislike most of J2EE but there are so many better ways that have sprung up to write Java applications unless you are forced to use the worst of breed "standards". It's not the language that kills so much as the accompanying baggage you have to drag around with you. Java may not be a perfect language design (if such as thing can even be agreed on) but it gets my job done.

Not that I intend to sit on my butt and become dinosaur fodder. Scala, Erlang and Haskell are languages I find fascinating to study, although Scala being JVM based makes it more likely to be useful to me. I think of Groovy as a more laid-back Java, and relatively easy to pick up as well for us Triassic Java coders.

Give me any decent language, and I can write any decent program. The difference is always in how long will it take, how reliable will it be, and how well can it be maintained. That is the mark of a good programmer no matter what they use to write with. Of course the choice of language does make a difference, but choosing the right tools for the job is also a mark of a good programmer. Often you have no choice (other than seek alternative employment or become an advocate for change) and you have to work with what you have. There is real skill in writing good code, and real skill in understanding the strengths and weaknesses of your chosen (or forced upon) toolset.

Often a language which requires a great deal of experience and understanding to master leads the average programmer to fail miserably. I'm sorry, writing complex C++ programs is not for a beginner. Even Java can be difficult (such as at my newest job where a whole set of mainframe programmers face the difficulty of learning a new language or having to leave) if you are not familiar with the concepts of OO programming. Is there a market for people who need a simpler language? Of course there is; but never assume mastery of a simple language or toolset means automatically that you can move on to more complex projects, or even assume your basic language choice can itself handle tougher problems. The world is littered with way too many VB/Access apps on an enterprise scale, for example.

So is there something wrong with learning Java, or using Java, or even improving Java? No there isn't, unless you take the approach that you will stop using Java when they pry it from your cold dead hands. It isn't the final stop on the programming roadway but it's a powerful, useful language with an enormous open source community, great tools, and works for a variety of uses.

Face it, there isn't any one solution to writing code, any more than there was when I started in 1981 writing Fortran. No matter what your favorite new language is, someday it will suck and people will laugh at you. So the trick is to work with the best choices available to you, and keep your eyes open for the new mammals on the block.

If I'm still coding in 50 million years I'll probably not be using Java.

My Tags: java essay languages

Scala is an interesting hybrid OO and functional language I am reading about. It runs on the JVM and integrates with Java frameworks, but still has a varied and interesting feature set.

A basic intro is Scala Intro:http://www.scala-lang.org/docu/files/ScalaTutorial.pdf (pdf).

So far I like it. The plugin for Scala for IntelliJ is not all there yet so playing with it won't be as easy as it could be for me.

The home page is at Scala Home.

My Tags: languages

In reading an article about Haskell I came across a reference to another functional language: Clean.

Although it appears to be yet another language designed by academia, there are some cool features.

A Functional Programming Language like Clean is based on the concept of mathematical functions. Clean is a pure functional language, there is not such a thing as an assignment. This has a big advantage: a function cannot have a side-effect. A Clean function is referential transparent: the result of a function only depends on the value of the function arguments and on nothing else.

Another great feature is that there are few runtime errors. The syntax takes a bit getting used to, as it is with most functional languages when approached by someone with a procedural background. In some ways it reminds me of APL, where a lot of power can be expressed in very little syntax.

I hope to spend a little time playing with Clean. It supports most of the major operating systems.

My Tags: languages

After seeing this Programming Languages Chart again, I thought about all the programming languages that I have learned and actually written code in:

• Dartmouth Basic
• Fortran II
• APL
• Applesoft Basic
• 6502 assembly
• Z80 assembly
• Fortran 66
• IBM JCL
• Fortran 77
• Jovial J73
• Mil Std 1750a assembly
• Z8000 assembly
• Turbo Pascal
• 8088 assembly
• C
• 680X0 assembly
• Forth
• C with object extensions
• Postscript
• Think C
• C++
• PowerPC assembly
• Java
• SQL
• Objective-C
• Perl
• Javascript

Of course I have played with many others, especially lately, but these represent real use.

The coolest language that I ever used was APL. So much power in so few lines of code; but the next day you had no idea what it did.

In 1988 I read about OO for the first time but had no language available to me so I wrote my own object extensions on C. It was pretty oddball, but it worked, and still lives on today (as far as I know, a scary thought) in the Deltagraph source code.

My Tags: languages

The future of computing is going to go belong to the nimble mammels that are dynamic, interpreted, virtual machine-based instead of the dinosaurs that are compiled, linked and mostly static.

With the current generation of multi-core, high performance CPU's, there is so much processor speed available that the whole idea of statically-optimized native executables seems like yesterday's solution. C and C++, along with assembler (which has already been mostly abandoned for quite a while) have been popular for more than a generation (I used C for the first time in 1984 and C++ around 1990). Languages compiled to optimized native code were necessary as the generations of processors were barely keeping ahead of the demand for performance.

The earliest VM (virutal machine) language implementations were convenient but hardly good performers, as the overhead of running the virtual machine was significant on the processors of the day. My earliest exposure to these was the UCSD P-system, which allowed you to run Pascal on a variety of systems. I believe at one time Microsoft wrote applications under a p-code interpreter. When you think of VM based languages, the most common would be Java, which debuted in the mid-1990's, and C#, which debuted more recently.

Early versions of Java were slow and hardly any competition to native languages. Over the years since it was released, the improvements in the runtime (which basically compiles the virtual bytecode to native code on the fly) and the better performance in the processors have allowed the language runtime to meet, and even surpass in many instances, that of statically-optimized native code. In 2002 some former co-workers of mine built an F-22 simulator for Lockheed that ran on commodity linux (dual cpu) hardware and supported a functional cockpit mockup along with most of the onboard systems written entirely in Java.

One of the benefits of a language compiled/interpreted to an intermediate code (instead of directly to native) is that the runtime sustem can watch the application at runtime and choose to optimize the final conversion to native code based on what is actually happening. Static native languages are generally optimized at compile time based on an analysis of the code. Optimizations that may be broader in scope that a narrow view of functions or lines are difficult to do as the actual usage of the application code is unknown to the optmizer. If there is sufficient performance available at runtime, the dynamic optimizer can use some bandwidth to observe usage and directly change the execution to optimize for time.

Of course running a virtual machine that hides the underlying native environment is only one step to the future. Optimizing the intermediate code to native code conversion is still a low-level event, mostly out of the view of the programmer. Higher level abstractions that benefit the programmer directly optimize the coding-time performance of actually writing an application. In the long run, the cost of writting an application lies mostly in the people who design, code and test.

Dynamic languages, where the runtime behavior of the application can be manipulated by the programmer, and interpreted languages, where the runtime executes the source code of the program directly, both allow the programmer more tools to express the requirements of the application as well as make development easier. Dynamicism and interpretation can be used together, and along with runtime virtual machines are a potent combination for the future.

In the following articles I intend to discuss in more detail examples of several languages that fall in one or more of the categories.

My Tags: programming programming languages