[catnaroek]

> Funny, but that's exactly what we Smalltalkers had in Smalltalk

Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”. In other words, there's no separation of concerns.

> and almost all of it in our heads

What you realistically can't produce entirely in your head is a proof that your program is correct, unless the language is explicitly designed to lift part of this proof obligation. That's exactly the role of parametricity: to help you separate concerns, allowing you to prove one small thing at a time.

[stcredzero]

Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”.

In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds. You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.

[catnaroek]

> In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds.

This doesn't scale to either large programs or programs not entirely written by yourself.

In ML, there's no need to search anything: the only admissible operations on a value are those sanctioned by its type.

> You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.

As a library author, you can't search code written by users of your library.

In ML, I can prove things not only about my own code, but also about how others may use it.

[stcredzero]

This doesn't scale to either large programs or programs not entirely written by yourself.

My industry experience clearly shows that you're just flat wrong -- with multiple large systems written by other people over the span of over a decade.

As a library author, you can't search code written by users of your library.

What kind of nonsense is this? The library author doesn't need to do such a search! The library users in Smalltalk would do such searches. Access to source was the norm. Decompilation in Smalltalk is trivially perfect, excluding local variable names, so closed source was fairly pointless.

[catnaroek]

> My industry experience clearly shows that you're just flat wrong

Please tell me how a code search performed by library author Foo will ensure that library user Bar won't break invariants Foo intended to enforce.

> What kind of nonsense is this?

In ML, I can prove that users my library can't use my library wrong. Maybe they won't be able to use my library at all - they type checker will reject every attempt. But it guarantees that, if they can use my library, they will use it right, in the sense that every invariant I enforce won't (and can't possibly) be broken by users.

For example, there may be multiple ways to realize the same ordered set as a red-black tree (balanced differently), but I can arrange things so that the difference can't be observed by users of the ordered set abstraction.

> The library users in Smalltalk would do such searches.

Library users shouldn't be in the business of enforcing invariants that are only relevant to the library's author. See? This is what I mean by “Smalltalk can't separate concerns”.

I'm not saying all of this to be mean. It's been known for quite a while that parametricity is the mathematics of abstraction and separation of concerns [0]. If you need to insulate users of your code from your design choices, you absolutely need parametricity. (Or “social conventions”, but those don't work in the long run.)

[0] http://www.cse.chalmers.se/edu/year/2010/course/DAT140_Types...