The most popular object oriented languages

The most popular object oriented languages today have one thing in common. They provide compilers that enforce your data typing. In Java, C# and VB .NET, the compiler makes sure that you have declared every variable to be an explicit type, and that every call you make to a subroutine that provides or returns a variable is appropriately accessed by variables who’s types have been specified.

This “strong typing” is supposed to help us by making it possible for the compiler to catch our mistakes.

It is true that strong typing catches mistakes in calls to routines, but it comes with an added cost as well. Whether you make a mistake or not, every variable must be declared as a specific type. These declarations can, at times double the amount of code required. There are languages available today that don’t require you to type your variables.

Smalltalk, Python, and Ruby are popular languages today that allow you to write code in far less time. Since these languages are interpretive, they run slower, but this is not a problem for many of the applications today. The hardware in use today is very fast and many applications don’t require maximum speeds capable on today’s computers.

What I have found is that strong typing hinders productivity. I rarely have the need for the compiler to validate my variable typing. Since I write test code before I write my programs, I already have a method of checking my programs that is stronger than the compiler. To make matters worse, writing my tests for a compiler that enforces typing makes it even harder to write code the way I do.

When you write tests for a piece of code, you often need to isolate the code by faking some of the objects that it uses. We call these “fakes” “test-doubles”. Some of the objects that need test-doubles are objects that consume physical resources, or depend on a special object that only exists at run-time like a web service or a web server. In order to test the code, a fake web server object or database object must be provided.

Faking some of these objects can be time consuming if the compiler forces you to provide an object of the specific type. In some cases, it is actually impossible. On the .NET framework for instance, the FileInfo object is “sealed” which means that you cannot inherit it. It also provides no interface that you can use to implement on an object that you wish to provide as a test-double to your test. Without the ability to make a test-double or the ability to inherit the class to provide one, you must create a delegate that implements an interface that you make up.

This is expensive and has been a problem for Test-Driven Developers for years. The beautiful thing about dynamically typed languages is that the overcome these problems with great ease, by allowing you to send in an object that has an entirely different type. It only needs to implement methods that have the correct names and the necessary parameters that you plan to test. No questions asked.

You just can’t do this with VB .NET, C# or Java. I have found that the amount of code required to do the testing can easily be more than three times more than with a dynamically typed language. So, then, what language do I recommend?

I recommend the one language that probably is better known than any other in the world today: JavaScript.

JavaScript is found for free in just about every system today. This is because it is implemented in almost every browser. Not only that, JavaScript is about to be upgraded. Right now the standards body is working to release ECMA Script 4. Can JavaScript be used to make engineered applications? My answer is: Why not?

Google and Microsoft are both using a great deal of JavaScript for their web presences today. The real issue behind the lack of JavaScript with good engineering behind it is the lack of discipline in the process of development, not the lack of capability of the language, and this is something we, as programmers, have to resolve. If so, I think we will be a great deal more productive.