Most absurd premise for an article that immediately goes back to the beginning of computing history, rockets to the present and makes an absurd unsubstantiated claim. Firstly there’s a false dichotomy, and then a reductionist view on TDD and types in general. This article’s most interesting point is the history lesson which the author claims is abbreviated (highly) and apocryphal.

And so, Java, and it’s bastard cousin C# became the languages of the internet; and held sway for two decades. But there was a lot going on behind the scenes.

That’s not…it doesn’t even…goddamnit Uncle Bob.

EDIT: For folks playing the home game, the answer here would’ve been Perl/PHP/Javascript.

You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?”

That was not my experience. Rather, I often thought: “why am I wasting my time writing tests for this, which could be avoided if the language had better type constraints?”

And that’s exactly what happened in second half of the first decade of the current millennium. Tons of Java programmers jumped ship and became dedicated dynamic typers, and TDDers.

This seems unsubstantiated, IMO. Bob implies, IMO, that all these Java developers “left” Java for dynamic languages, in order to become TDD developers which seems to me just a teensy bit absurd.

How will this all end?

My own prediction is that TDD is the deciding factor.

IMNSHO that is Uncle Bob’s prediction because Uncle Bob’s income relies on harping on about TDD like a broken record. Often nonsensically—like in this post.

You don’t need static type checking if you have 100% unit test coverage.

This is just plain false. Making sure your function has 100% unit test coverage does nothing to help you if someone calls your function with unexpectedly typed data. Say your function expects two integers, but are called with a dictionary and a list. Or another function. Sure, you can add type checks to your function, and more unit tests to verify that those type checks catch the unexpected types, but that’s a lot of boiler plate to add everywhere.

“Oh, but my function is not useful enough to be included in a library used by others, and I do have 100% coverage of my app, so I assert that it is not called with unexpected types.” Right. Does your app get data from anywhere? Input from a form? Environment variables that people can set before running your app? Are you sure that the input to the function does not come from inadequately sanitised data? If you were using Perl you could activate taint mode, but it looks like the equivalent in Python was rejected in 2009. I don’t know if Ruby has anything equivalent. And even if you are using Perl, there’s a lot of ways your function can fail that taint mode won’t help you catch.

Learning swift has been an interesting experience. The language is very opinionated about type safety. Indeed, I don’t remember using a language that was quite so assiduous about types.

It is weird for the author to state up front that he doesn’t really have any experience in the subject at hand, and then make a bold prediction like “dynamic typing will win”

You don’t need static type checking if you have 100% unit test coverage.

So much years behind him, yet he seems to have learned very little about type systems. For example, a good type system allows a programmer to design structures that make illegal states unrepresentable; taking advantage of this capability is better than tests because the compiler ensures that the invariants are held everywhere in the program and that you haven’t missed one in a weird control path of an obscure module.

I laughed so hard when I read this line.

“The language is very opinionated about type safety. Indeed, I don’t remember using a language that was quite so assiduous about types.” This was about optional types.

Huh! Funny, considering he thought himself an expert enough to write THIS article 2 years ago: http://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html

How the hell does he think he’s smart enough to know about the benefits of FP with static types when he hasn’t used any variations of the statically typed functional language ML, which has dominated this space since the 70s (practically 50 years!!!). This is such astounding proof to me that Uncle Bob is a hypocrite and a charlatan, and you should almost never trust anyone who says they have the right answers.

This post is pure applesauce.

The language is very opinionated about type safety. Indeed, I don’t remember using a language that was quite so assiduous about types.

I dislike the usage of “opinionated” here. How is having a particular model for types more opinionated than one that has no model for types? Opinions are just views or judgments, a type system is a mathematical model. It’s like saying addition is opinionated because it is only defined for numbers.

The extreme nature of the type system in swift got me thinking about the “Type Wars” that our industry has been fighting for the last six decades. And that got me to thinking that I should blog about the history of those wars, and then predict the future outcome.

If Swift is the most typed language Robert Martin has worked in, then I am not convinced he knows enough to have a history of type systems.

WARNING: This history has many omissions and contains much that is apocryphal, or at least wildly inaccurate.

That’s an understatement. Why even write this post then? Usually Martin doesn’t have anything of value to say, and this time he actually admits it before the content.

Apparently many programmers agreed with me because C won that language war; and won it decisively.

C did win, although there are several other possibilities for why it won than because people had the same view of Pascal as Martin did. My guess is it won because of UNIX.

The late ‘80s and early '90s were a kind of “cold-war” between the static type-checking of C++ and the dynamic type checking of Smalltalk. Other languages rose and fell during this time; but those two broad typing categories pretty well defined them.

Oh? That’s a pretty narrow view. SML and Haskell were both created in the 90’s. A huge amount of research went into statically typed languages in the 90’s. Not to mention StrongTalk, the statically typed Smalltalk that became Java. And let’s not forget Perl, which had a hugely successful 90’s (at least the second half).

And so, Java, and it’s bastard cousin C# became the languages of the internet; and held sway for two decades. But there was a lot going on behind the scenes.

What? Java has a front-end language (applets) lasted only a few years as a serious option, replaced by a dynamically typed language called JavaScript. Now Java does hold a lot in the backend of the internet, though. But C#? Certainly places are using C# for backend, but “the language of the internet” is nonsense.

You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?” Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python.

In my experience, they ask themselves “Why do I need TDD if I can have the compiler do it for me?” IME, many companies are moving towards Go or Java, away from Ruby or Python. This paragraph is really just Martin either trying to sell snack-oil or evidence of how out of how out of touch with reality he is.

Tons of Java programmers jumped ship and became dedicated dynamic typers, and TDDers. That ship-jumping continues to this day, spurred on by the fact that salaries tend to be higher for programmers of the dynamic languages.

This needs to be substantiated, based on what I’ve seen at every company I’ve worked at, this is fantasy.

Oh, and I should tell you about one special unit of Smalltalk programmers who stayed at IBM planned their revenge against Sun. They executed that revenge by creating … Eclipse.

I’m not sure if this is meant to be satire or not. Eclipse did what, exactly, to Sun? Made a popular, free, IDE for Java allowing adoption? Or was Eclipse revenge on me, the hapless programmer, for using Java?

And so here we are. The pendulum is quickly swinging towards dynamic typing. Programmers are leaving the statically typed languages like C++, Java, and C# in favor of the dynamically typed languages like Ruby and Python.

Perhaps if this blog post was written 10 years ago this would be true. But I’d also be surprised if people who were using C# were leaving it for either of those options.

My own prediction is that TDD is the deciding factor. You don’t need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What’s more, the benefits of that achievement are enormous.

And I don’t need 100% test coverage if I have static type checking. And 100% test coverage doesn’t tell you as much as you’d like to think. What about external inputs? As @tedu pointed out, gets will work well for some input and not for others, but it’ll still look like 100% test coverage to your program.

Therefore, I predict, that as TDD becomes ever more accepted as a necessary professional discipline, dynamic languages will become the preferred languages. The Smalltalkers will, eventually, win.

A pyrrhic victory, if the prediction does hold up, at best.

Apologies in advance for the meta-question: given how playful and refreshingly simple the language is, I would expect Smalltalk advocates to be cheerful, happy people. But my experience online has been quite the opposite: lots of grandiose promises and barely concealed hostility. I wonder why that is?