Indeed, OO hatred is usually a sign of an inexperienced functional programmer.

Smalltalk was a great start, though, that should not have been the benchmark for implementing object oriented languages. There are some valid concerns about oo that were imo missing in mainstream languages such as Java/C++: uniform access principle (scala provides for that, but scala is a different type system) pre-conditions/postconditions as part of core language rather than annotated comments. weaker/stronger pre-conditions/postconditions in derived classes : this makes the use of methods quite obvious and what features are being inherited from the parent class. selective exports of features (this is a less known feature but can save a developer many a times). Repeated inheritance/multiple inheritance implemented right (so diamond hierarchies should be handled without having to resort to any ambiguities). Genericity (templates that understood hierarchy: this was missed in C++ at least in 2001. I havent programmed in C++ since then) Covariance (this was a direct side effect of method inheritance and I found it to be useful).

Without these features and many other features (I borrow this list from Bertrand Meyer's OOSC, 2nd edition), language compilers tend to shift the burden from the compiler to the programmer to manage types etc. It is probably too late to go back to Eiffel, though, I still think that it even today is far ahead of most oo languages, so if folks feel strongly against oo, I can understand that to some extent.

I recall a small exercise,where I was modeling Matrix using integers to do some basic addition and multiplication in Eiffel. It worked the code compiled, tested, assertions validated etc. All good. But how about determinants (I forgot the exact computation that needed that). I was still programming in java at my work and had that sinking feeling of change code at few places to make things Float and (read them as objects instead of primitives etc..you know the drill). It turned out, that the Number hierarchy in Eiffel was quite refined, I changed the declaration at one place and everything worked as expected. This was a small exercise, though it clearly outlined the power of the language.

As an aside, there was another feature that ensured that floating point numbers weren't being allocated on a heap: it was a keyword : Expanded: implying no references are created for the expanded objects. This feature alone can save a ton when decoding objects from a network etc, without me, the developer, having to worry about boxing/unboxing and the subsequent performance implications.

So, yes, OO was/is a great paradigm, though it is the details of implementation that matter. When I used to attend job interviews and was faced with one of the canned questions: which is better Java or C++, I started to take the "fifth" because I could not in all honesty compare truly bad implementations of the oo paradigm. The only reason I started to briefly look up scala was because Martin Odersky used Eiffel as one of his references : Uniform Access Principle to implementing the Scala type system. But that is as far as I could go, because, after looking at OCAML, it hit me that oo and functional can't safely mix.

I used to work at BT with a (very good) DBA who's first boss was Dijkstra

Integer overflow?