TL;DR - Technically no, but practically yes.

I'll start by examining why Java is not a monoculture.

Java is interesting, in that it is both a programming language and a runtime environment. When Java first burst upon the scene, it was promoted as a general-purpose cross-platform programming language. It was not the first language to make such a claim, but it was the first to live up to most of its hype. I was a very early adopter of Java and remember the joy of writing code on a Windows PC and then having my tester run that exact same code on their Apple Mac. I'd used scripting languages that could do that, but never anything that needed compiling. I was hooked.

Java achieves this cross-platform behavior by using a runtime environment that is compiled for each target environment. This is known as the Java Virtual Machine, or JVM to its friends. Any operating system that has a JVM can run Java code unchanged. Java wasn't the first language to use this approach. Other languages were intended to be able to be easily ported. C is perhaps the canonical example of this, being intended to allow the Unix operating system to be ported to other different architectures. The Pascal language compiled to p-code which was then run by the Pascal runner. But, for all of this, there had never been any emphasis on taking this to the next level and making languages runnable cross-platform.

Updated the link to point to its new blog home

Robert "Uncle Bob" Martin is a programmer's programmer. He's been called a Master Craftsman. And he likely deserves even more respect and admiration than that.

Here is a great quote from an entry titled First on his blog:

Well designed tests are small isolated snippets of code that call into the system being tested, expecting certain results. A programmer can read the tests to understand what the tested code is supposed to do. So the tests are documents. They are written in a language you understand. They are utterly unambiguous. They are so formal that they execute. And they cannot get out of sync with the application.

My favorite Ron Jeffries quote, from the NeverIsNeverNever page on the C2 wiki:

I know that if you agree NEVER to let the unit tests drop below 100%, you'll only do it that one time when you just couldn't figure out an incremental way to change all the deductions from negative to positive. If you agree NEVER to keep a task open for two weeks, you have a better chance of finding the way to do it incrementally, and that one time you'll make sure you've sucked every idea out of the universe before giving in.

When I say something should never be done, it should mean that you'll never do it unless you really have to.

And if you really have to, you'll ask everyone you know first so you still won't have to.

And if you still have to, you'll be looking over your shoulder scared to death that I'm going to materialize there and say "why didn't you just ..." and be RIGHT, and EVERYONE will know you're an idiot.

When you're sure that you'll be able to say "because X" and I'll quietly lower my eyes and say "oh" and de-rez back to wherever I come from ... then break the rule.

Then do one more thing. When it's over, and you've suffered - as you will - for breaking the rule, think back and figure out what you could have done, and learn the deeper meaning of NEVER.

(One from the archives. Not sure when I wrote this. I think it still stands.)

These days, with the rise in programmer testing (also known as unit testing to its friends) much testing effort is put into ensuring that program logic is correct. This is good and to be encouraged at all times. A program that does the right thing is always more likely to be correct than one that does not. Interestingly, with all of this new-found enthusiasm for testing, there seems to be a few gaps in our approach. The one I'd like to discuss here is the principle of "Always Valid".

This principle is easy to arrive at from first principles. You see, programs do stuff. Every programmer knows this. We know it because we're the ones that tell them how to do it. But pause a moment and consider what this "stuff" is most of the time. The vast majority of the time we're processing data; and it's the data that is the star of the show. Our programs are just descriptions of what we want to do to that data. The data is the important thing.

Given that we care deeply about the data, we should be careful to ensure its quality at all times. We need to not only care about it when we're processing it, but both before and after. At any time that data is in the gentle "hands" of one of our programs, we need to treat it with the respect that it deserves.

When learning a new programming language, and I've done this more than once, there are certain steps that I typically take in the process. I like to poke around the language web site and then read the getting started tutorials. If I like what I see and it fits my definition of an esoteric programming language, I'll install it and try my hand at some examples from the tutorials and the classic hello, world program.

These steps seem to be fairly normal for geeks like me and certainly the writing of a hello, world program is enshrined in programming lore and tradition. What is less clear is the recommended path to take after that. Some people complete tutorials, others buy books and work through them and then some dive in and work on a project so they can learn as they go. None of these are bad approaches, but I think that there needs to be something between working through tutorials or books and the big project for learning.

To this end, may I suggest the concept of Learning Projects? This involves writing a series of programs of increasing complexity that incrementally explore the capabilities of the language. I'm looking at replicating a select number of the traditional Unix tools, starting with the simpler ones and expanding from there.

In some ways this is an expanded view of the concept of Learning Tests. Learning tests are tests written by a programmer learning a specific language to help them understand the language they are learning. (I don't know who first coined the term, but I first heard it from Mike Clark.) There is nothing wrong with learning tests, but when approaching a wide number of languages, not all will have testing frameworks available and, most importantly in my view, the end result is not anything you can use or recycle components of after the learning effort.