OOP The Easy Way

I purchased a digital book in three formats with the cash left over on my forex card.

It made me feel good, and gave the promise of a worthy pursuit to me who was wallowing in indulgence, guilt and post-operative invalidity.

Why OOP ? I used to read articles titled "OOP is a horrible disaster that must end " and nod my head all along and wait for civilisation to come crashing down due to OOP so that I could say "ah ! I told you so".

The hour is late and the time is nigh and the industry has consumed OOP with great delight and absolutely no sign of letting up and mostly, all the jobs paying my salary has been on this.
So maybe I am turning into the skid.
Or maybe I am digging my grave a foot deeper .
Time will tell.

Who is Tim Rentsch ?

https://www.academia.edu/34882629/We_need_to_Small_talk_object-oriented_programming_with_graphical_code_browsers

https://dl.acm.org/doi/10.1145/947955.947961

OOP was meant to be easy enough for children

Part 1 of the book is deconstruction of OOP

Objects receive messages and locate methods corresponding to those messages and invoke them.
Flip this and you get Objects decide what to do with messages.
The CMU Mach system . No tight coupling - send messages over a port.
Compare with opening para of the ZeroMQ book (written by the creator)

Micro-services sounds like OOP. A micro-service is an independent entity communication over stateless wire formats with other parts of the system. = object.

Brad Cox founded Objective C and built a company to exploit it .

"... so that OOP becomes an “alternative” to functional programming, in which the big problem is decomposed according to the operations used in its solution. "

More stuff to read ,this time on functions/functional

https://dl.acm.org/doi/10.1145/3193776

Haskell is a functional language with facility for handling state (oh no , monads !!)

------------------

In his textbook “A Touch of Class” from 2009, in Section 2.3 “What is an object?”, Bertrand Meyer uses the following definition:

An object is a software machine allowing programs to access and modify a collection of data.

This is in exact opposition to the usual goals of "encapsulation" or "data hiding" that we have heard about, in which we try to forbid programs from accessing and modifying our data!
------------------


very much a huh ? moment there .. doesn't an object encapsulating data and providing methods for their manipulation satisfy both ?



ooh ooh ooh - a paper by the biggies ! also note, they refer to Tom DeMarco in the, well, references !!!


Kent Beck and Ward Cunningham published a paper on UI patterns before the GoF got theirs out.
http://c2.com/doc/oopsla87.html
The paper has 5 UI patterns


Kent Beck is one my favourite software heroes - the c2 wiki is apparently made from 4 or 5 lines of code.
Similar to the PHP founder's comments


Patterns failed, why should we care ?
https://www.deconstructconf.com/2017/brian-marick-patterns-failed-why-should-we-care


All GoF patterns are implementation patterns, unlike Christopher Alexander


Larry Wall's TimToady = TIMTOWTDI = there is more than one way to do it




---- building objects
smalltalk ideas of bytecode, live editor, image etc
- the image is both personal and universal !
is gnu smalltalk a smalltalk ?
no building step .
live objects !



" The worldview that lends us words like “toolchain” or “pipeline” is one of sequential activities, where a program may end up “in production” but certainly doesn’t start there. People using the programs happens at the end, when the fun is over. "

We feels deeply about this. And I agree. The fun is tinkering and seeing magic happen. In todays world they don't care about this, they care about you shipping magic regularly, in a horrible clanking setup and no fun.

The point that the using and making of software should go hand in hand is a doctrine that lies unadopted ,but is probably the only way to have fun in creating software.

I am close to ending part -one - the antithesis
OOP is independent agents interacting through messages. There. What I do at work in Java is not OOP.

What I do with micro-services at work is, somewhat OOP.

Another telling line ( supporting  my stance in the first para of this post)

"....  OOP seems to have failed, but it may not even have been attempted. " 

one problem with random object structures coming over the wire is that JSON de-marshalling creates piles of doo-doo like lists and maps containing lists and maps , even for simple objects.

This causes nightmares


------

I might have mis-bought this book. I might have confused the book with a blog post which takes apart Uncle Bob's OOP vs FP  example. That was an interesting piece of code refactoring involving klingons and guns.