I'd like to stress the point about wrapper types, which can even be usefully employed in C. Note that - in C - this is not typedef (which is mostly cosmetic), but rather wrapping primitives in otherwise empty structs. This has no runtime cost and has the tremendous benefit that you won't mix up the arguments to place_order(price_t, quantity_t) where you might to place_order(int price, int quantity).

I think what this planet needs is a comprehensive study of how different typing techniques and schools of thought would solve different classes of problems, because what I notice is that

1) definitions are hard, and don't mean much

2) there are many equivalences, and some idioms are conceptually very similar across different type systems, and are just not implemented the same way. For example, a it's a common hobby among FP weenies to show how most of the GoF design patterns are one-liners in their languages of choice.

3) the scope of many typing disciplines is not the same; for example, unityped languages work great for tasks of limited scope with lots of user interface components, functional is historically used to write nice algorithms, and OOP is an attempt at giving a distinct shape to software of very large scope (and it happens to be a pain in the ass when the scope isn't that large)

    def compare(a: Int, b: Int): Int

    This one has not only 232 possible results, but an incalculable (232)264 possible implementations. Even if we are generous and only allow the inputs to be 0 or 1, we still have 2128 implementations. If the only meaningful return values are -1, 0 and 1, indicating “less than”, “equal” or “greater than”, then why would we embed them like specks of dust in a big desert of undefined behaviour?

I don't agree with this. This is not a "big desert of undefined behaviour". The behaviour is defined along the entire spectrum of Integer values. "Less than" maps to all values <= -1, "equal" maps to 0, and "greater than" maps to all values >= 1. There's no undefined behaviour here.

Implicitness as a source of error (in general) seems to raise its ugly head over and over again.

This entire post seems to conflate "weak typing" with "dynamic typing". Both are terms that seem to have a lot of common definitions, but they're nevertheless distinct.

Weak typing usually implies a system where types get coerced easily:

    php -r "echo '4' + 4;"
    8

Dynamic typing, though, generally means that the type is associated with runtime values. It doesn't mean that the typing is necessarily weak:

    ruby -e "'4' + 4"
    -e:1:in `+': no implicit conversion of Fixnum into String (TypeError)
	from -e:1:in `<main>'

It's a well written version of, "our software design was sloppy and our programmers took shortcuts. Therefore language feature X is to blame."

  def findAddress(userId: String): String
  What does it do? Are you sure?

  Now lets look at another:

  def blah(foo: UserId): Address

What about

  def find_address_of_user( UserID )

or even better

  class User(Model):
     …
     address = our_models.AddressModel( … )

So you can use 'x = user.address' with no need to explicitly map between users and addresses because the mapping is part of your data structure?

In some scenarios, Hungarian notation might make sense:

  def user_address(user):

In Hungarian notation you explicitly state what kind of data is expected, so that you can easily determine if mistakes are being made in the code:

  billing_vcard = contact_vcard(customer.billing_contact)

as opposed to:

  display_vcard = contact_email(customer.billing_contact)

Of course, cue the irrational knee-jerk reaction to "Hungarian notation" by people who don't understand what it actually is.

  OO lore has it that pattern matching is evil, and that subtype-polymorphism is the answer to all questions.

Not the OOD that I've been taught. Polymorphism is a tool, and it is as much the answer to all questions as a screwdriver is the answer to all construction projects.

That the author of this piece has found various languages educational in presenting new ways of solving problems (with code smells, data model smells, or sloppy architecture) is the biggest take-home message for me: don't be a "Perl programmer" or a "Scala programmer". Be a software engineer, and make sure you are aware of all the available architecture rules, modelling guides and design patterns that have been developed over the years to make your job easier.

Perhaps I'm missing something due to having read through the article too quickly. Please educate me.

News flash!! Strong typing has benefits!

> Perhaps I'm missing something due to having read through the article too quickly. Please educate me.

The point I got out of this fine article is that we are under/misusing types.

Types encode logical propositions. The compiler, besides producing binary code, is also a proof checker. We should let it help us reason about the program instead of trying to do everything informally in our heads.

Hi Manicdee! The point is that with any unityped representation you can come up with, the name tells you nothing certain; any conclusions you think you can draw from it are pixie-dust and moonshine. Even with nonsense names, the argument and return types give you solid proof not only about what the method does, but importantly what it _doesn't_ do.

There's no criticism implied of my colleagues at all -- I'm as culpable as anyone. The point is though, we can make big improvements with types, without paying a big cost.

You must have had good OOD teachers: http://c2.com/cgi/wiki?CaseStatementsConsideredHarmful http://c2.com/cgi/wiki?SwitchStatementsSmell

Cheers

  def position_sprite( top_left: point, sprite: sprite)

It is not as much feature X, but lack of feature X that's the problem in the article. Statical typing is a tool you should be using if it is suitable to your problems. The problem described is verifying there is no garbage in garbage out situation for your functions. Proposed solution is making compiler do the check instead of manually checking the codebase, writing more code known as TDD, enforcing conventions that are easily confusing... Common theme in these alternatives are necessity of extra tools and all associated effort. Compiler can be a perfectly servicable point of enforcement if types are used properly with possibly no extra cost.

My completely subjective opinion:

OOP is a valid way to write strongly typed code, but there are many useful and common situations that can be solved by some primitive feature found in any good functional language, where the OOP solution is verbose and counter-intuitive.

And that partly explains why so many people bypass the properly designed, strongly typed, object-oriented solution and write shitty code instead.