[myArray insertObject:myObj atIndex:myIndex]

…where the message “insertObj:atIndex:” is sent with “myObj” and “myIndex” as its arguments to myArray.

I want to be able to say: Okay, Strings are this class, and this object is an instance of String, but whenever *THIS* bit of code is dealing with strings, I want you to offer the string through this filter. The filter is free to do just about anything. It could, for example, add an rtrim() method. It could also offer deprecated functionality that the canonical (newer) version no longer has. There are quite a few things you can do with such a feature:

– put however much lipstick on whatever pig you have to work with until you find it palatable (such as adding rtrim as a method, but only for your code unit e.g. package, module, source file, whatever is suitable).

– aggressively update APIs without any concern for backwards compatibility – then write a filter that is automatically offered to all other bits of code that declare that they were expecting v(old). You now not only have 2 separate code bases that represent the same thing (String v1 and String v2), but strings from one version are 100% interchangible and compatible with the other. They’re really the same object, each code base simply sees a different set of operations on them.

– aggressively modularize and personalize the entire language. If *I* am a folding fanatic and I want /: to mean fold left, that’s fine, and I can adopt this in my view. But, if you take this notion to the extreme, a tool can analyse my call to /: on an iterable, and figure out that the ‘foldLeft’ call in a different view of the same type means the same thing, and translate. If I pass this code off to another developer who has set up his programming environment to translate things to his particular view if at all possible, he will see .foldLeft, and if he saves this and sends it back to me, I will see /: again. In actual fact, the canonical method is located somewhere outside of the Iterable type altogether (lets say in an IterablesUtils class, or some such – analogous to your C# StringUtils) – but nobody involved here even needs to know this. Even better: If that other guy finds the code unbearably long-winded and complicated, he can look through a specific ‘view’ definition I’ve set up that makes this code much clearer to me (think DSL), and selectively start enabling each transformation described in it as he groks them, which instantly translates all the code of that project to incorporate these transformations. He can also elect to start off with my view, and anytime he sees gibberish he doesn’t understand, just mouse-over or do some other quick HID operation to temporarily see how the given code snippet would have looked like if I programmed it according to my view definitions.

Anyway, I think one point is that this fine article lost a bit track.

You started with “OO has contributed many big and important innovations to programming.”
but then changed to Haskell quickly… which left me confused. What has Haskell to do with OO?

Haskell itself is evil already, I dont know why syntax changes make Haskell code anymore evil – it is as close as Satan codes.

God may use Lisp, ancient as he may be if he would exist – but Satan uses Haskell.

It is as evil as programming can be.