We dont need no Ooooo-Orientation – 3

In my earlier posts Ive discussed some context around why OO has been one of the more dismal failures in the history of IT/CS.
Here I talk of the error in thinking 'inheritance'.
And this gives the philosophical separation between those drawn to OOP and those not.

Before I come to the meat of the matter – why OO sucks – it would be good in all fairness, to deal with the

Very few successes of OOP

In fact, if we could simply and without caveats say OOP has been an unmitigated disaster, we could cut our losses and move on.  Unfortunately, OOP has had its small share of successes. ['Unfortunate' because the general costs of OOP have far outweighed the benefits and the OO-aficionados use those occasional successes to justify the general costs]

1. Simula – Simulation

OO started with Simula-67 which set out to give a framework for doing simulation.

I believe that even today simulation is likely to be one of the area where OO succeeds.

Now what does simulation really mean? It usually means we know the rules of the game at a micro-level but have less clue about how they pan out at the macro level and would like the machine to aid us in this micro-to-macro path.

To the extent that this is not so ie to the extent that we know analytically/mathematically the big picture, OO stops being useful

2. GUI – Smalltalk

The next (and last) major success of OO was with Smalltalk-80 wherein the inheritance-structure of widgets worked very well with the development environment.

To this day the echoes of this success remain in modern OSes like WIndows wherein the file-associations give a kind of (half-baked) OO-ness – the OS knows what is 'the right thing' to do when you (right)click on an arbitrary object (usually file).  Those who like this consider it an improvement against traditional (process-oriented) OSes like *nix.  [And those who dont can find cases wherein it botches badly]

3. Introspection ­– Python

One of the nice things about python is that we can start up the interpreter, take some random entity in hand, say the string "Hello" which I want to upcase and start of a conversation with python on this:

$ python3.2
Python 3.2.3 (default, Feb 20 2013, 17:02:41) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s="Hello"
>>> dir(s)
[ 

   __dunder__ elements snipped

  'capitalize', 'center', 'count', 'encode', 'endswith', 'expandtabs', 'find', 
  'format', 'format_map', 'index', 'isalnum', 'isalpha', 'isdecimal', 'isdigit',
  'isidentifier', 'islower', 'isnumeric', 'isprintable', 'isspace', 'istitle', 'isupper',
  'join', 'ljust', 'lower', 'lstrip', 'maketrans', 'partition', 'replace', 'rfind', 'rindex',
  'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith', 'strip',
  'swapcase', 'title', 'translate', 'upper', 'zfill']

>>>

Hmm… There seems to be something called upper. Lets poke a bit more…

>>> help(s.upper)
Help on built-in function upper:

upper(...)
    S.upper() -> str
    
    Return a copy of S converted to uppercase.

Aha! Is that what we want??

>>> s.upper()
'HELLO'
>>>

Note that in this respect python is better-endowed than its less object-oriented neighbors like Erlang, Haskell etc.

One last example where

4. Inheritance actually works

The exception hierarchy of python is one (of the very few cases) where inheritance is actually an aid to the programmer.

5. And that's it folks

For the most part beyond  a few exceptions like the above inheritance creates more mess than it solves

In the next post I deal with the cardinal reason why OO is nonsense