On Thu, 4 Aug 2016 12:10:17 -1000
Joel Roth <joelz@???> wrote:


> What do you mean by "imperative" that contrasts with
> something that smalltalk has/does?
>
> ISTC the original traits paper is in reference to SmallTalk.
>
> I can't speak to C++ or Java. So when I talk about OO, I'm
> speaking through the lens of mainly perl where I commonly
> use OO.
> To subclass seems so easy and natural way to deal
> with situations that would otherwise require
> conditionals.

The kinds of things that eliminate conditionals can also be done by C
structs, Perl hashs, Python dicts, etc. You could, if you wanted to,
even pin function references to a struct, hash or dict to avoid OOP. I
don't usually do that: I use OOP in when different functions are used
for different situations, but you could.

>
> Something like $this_track->bus->dump or $this_track.bus.dump
> seems clearer idiom than bus_dump(bus_of($this_track)).

Maybe. The difference is kind of syntactic sugar and isn't HUGELY
important though.

> That and subclassing really make it for me.
>
> Anyway, my hat is off to you if you can get by with other
> ways of working.

I sometimes go OOP, and sometimes not. And some of my programs are
basically structured programming with some objects thrown in. I think
one would need to be nuts not to represent a data store as an object.
Having an application as part of a window object --- not a fan.

We're not that far apart here. What I originally said was:

===============================================================
Then there's OOP. My opinion: OOP didn't achieve our expectations for
it, it's often misused, it's vastly misunderstood.
===============================================================

Expectations: 1990 - 2005 OOP was expected to be the savior. It would
cure all our coding ills. Coding factories. Less errors. Useable by
less skilled programmers. For the most part, that never happened.

Expectations (again): They said OOP must be all or nothing. Smalltalk
good, Perl bad. No fair using structured code where it works best, and
objects where they work best. Nope, if you're not 100% OOP, you're just
a hack. LOL, Java required the main routine to be in a class: I'm
forever seeing main classes that obviously are kludges for (disallowed)
structured code.

Often misused: How many hundreds of times have you seen somebody
willy-nilly substitute a "has-a" relationship for an "is-a"
relationship, and vice versa. How often have you seen completely
unrelated things thrown into a class because "it seemed like a good
idea at the time"? How many times have you seen code tracing turn into
a volleyball game, where logic bounces repeatedly between three or four
objects? How many classes have you seen whose sole purpose was to take
data from one object to another? Dbus, anyone?

Misunderstood: In 1990-2005, ask ten experts what OOP is, and you got
ten different answers. NOBODY understood it, but they all thought they
did. Structured programming, which immediately preceded OOP, had an
agreed on definition and came with an iron-clad program building
methodology: functional decomposition. As far as I know, no program
building methodology for OOP ever emerged from the cauldron of DIY,
one-offs, and expert book author pablum.

Hey, I use OOP. Anything in my programs that resembles an entity becomes
an object. If objects contain objects like a classroom contains
students, I have no problem putting objects in other objects. If I have
several objects that are almost the same but have differences, I have no
problem using inheritance.

I'm just saying some people endorse it as the only valid paradigm, and
when they try to use it as their only paradigm, their code sucks.

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
Brand new, second edition
http://www.troubleshooters.com/mgr