Loose Typing Sinks Ships

The recent release of IronPython .NET, and Microsoft's subsequent hiring of its creator, got me thinking about typing. There's a really interesting, albeit old, post on the dubious benefit of strong typing at Bruce Eckel's blog. Which reminds me how much I hate constantly casting objects via CType() and DirectCast(). It's a waste of my time-- a productivity tax. You can disregard my opinion, sure, but Eckel is the author of Thinking in Java. And he's not the only one that feels this way:

I also realized that the flexibility of dynamically typed langauges makes writing code significantly easier. Modules are easier to write, and easier to change. There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler. Now I am back programming in Java because the projects I'm working on call for it. But I can't deny that I feel the tug of the dynamically typed languages. I wish I was programming in Ruby or Python, or even Smalltalk.
That's from Robert Martin, author of Designing Object Oriented C++ Applications Using The Booch Method, among other books.

So why do we do it? Why define a class like this, with all the overhead of inheritance:

// Speaking pets in Java:
interface Pet {
void speak();
}
class Cat implements Pet {
public void speak() { System.out.println("meow!"); }
}
class Dog implements Pet {
public void speak() { System.out.println("woof!"); }
}
public class PetSpeak {
static void command(Pet p) { p.speak(); }
public static void main(String[] args) {
Pet[] pets = { new Cat(), new Dog() };
for(int i = 0; i < pets.length; i++)
command(pets[i]);
}
}

Now compare that to the Python version:

Python and similar "weak" or "latently" typed languages are very lazy about type checking. Instead of putting the strongest possible constraints upon the type of objects, as early as possible (as C++ and Java do), languages like Ruby, Smalltalk and Python put the loosest possible constraints on types, and evaluate types only if they have to. That is, you can send any message to any object, and the language only cares that the object can accept the message - - it doesn't require that the object be a particular type, as Java and C++ do.

# Speaking pets in Python, but without base classes:
class Cat:
def speak(self):
print "meow!"
class Dog:
def speak(self):
print "woof!"
class Bob:
def bow(self):
print "thank you, thank you!"
def speak(self):
print "hello, welcome to the neighborhood!"
def drive(self):
print "beep, beep!"
def command(pet):
pet.speak()
pets = [ Cat(), Dog(), Bob() ]
for pet in pets:
command(pet)

In other words, you call methods on objects without the unnecessary complexity of inheritance, and most of all without the mind-numbing cast-a-thon that strong typing requires. So the question is, do you want to be correct and pure, or do you want to be productive? However good you are, three Indian programmers can churn out mechanical code blocks a lot faster than you can-- and for the same price. Choose carefully.

Read more

Stay Gold, America

We are at an unprecedented point in American history, and I'm concerned we may lose sight of the American Dream.

By Jeff Atwood · · Comments

The Great Filter Comes For Us All

With a 13 billion year head start on evolution, why haven't any other forms of life in the universe contacted us by now? (Arrival is a fantastic movie. Watch it, but don't stop there - read the Story of Your Life novella it was based on

By Jeff Atwood · · Comments

I Fight For The Users

If you haven't been able to keep up with my blistering pace of one blog post per year, I don't blame you. There's a lot going on right now. It's a busy time. But let's pause and take a moment

By Jeff Atwood · · Comments

The 2030 Self-Driving Car Bet

It's my honor to announce that John Carmack and I have initiated a friendly bet of $10,000* to the 501(c)(3) charity of the winner’s choice: By January 1st, 2030, completely autonomous self-driving cars meeting SAE J3016 level 5 will be commercially available for passenger

By Jeff Atwood · · Comments