oo fun

Long live procedural!?

You read the article I see. ;-) (Not).

Of course these links are provided to stir the pot.

As the famous Edsger Dijkstra said:  "I am still convinced that in computing, elegance is not a dispensable luxury but a quality that decides between success and failure; in this connection I gratefully quote from The Concise Oxford Dictionary a definition of "elegant", viz. "ingeniously simple and effective". Amen. (For those who have wondered: I don't think object-oriented programming is a structuring paradigm that meets my standards of elegance.)" (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html) 

could be worth to consider and think / research a bit further - or try at least - than the measure of your noses instead of easily and blindly following the trends progress software company aligns for you, as a trendfollowing company. ;-)

see c2.com/.../wiki for an extensive list, and a link to benefits of oo also.

Regards, Stefan.

Agent,

You've been on this soap box for quite some time and if memory serves me correctly, in multiple threads in the Community.  I'm curious, sir, what is the driving factor behind your hard line anti-OOP stance?  More importantly, are recent releases of OpenEdge keeping you from continuing to develop software adhering to the procedural development paradigm that you clearly favor?

Where did you read that I favor the procedural paradigm? You got it totally wrong in any case. I post these links just to consider the arguments offered therein and it is not a soap box in spite of the title I gave to the thread.

I inferred as much from your multiple threads with anti-oop themes, and more recently, from this very thread;

"could be worth to consider and think / research a bit further - or try at least - than the measure of your noses instead of easily and blindly following the trends progress software company aligns for you, as a trendfollowing company.  ;-)"

Clearly I did not put enough weight into the winking emoticon at the end of that statement.  Sarcasm, perhaps?  Either way, I misread your intent.  Pardon my ignorance and thank you for clarifying your position.

I see my position as unimportant in these matters. But I really hate to be put in a position, and that is what you notice (the sarcasm and so). This thread is just to provide some links to texts questioning the oo paradigm, inasfar as oo is identifyable as a paradigm. Maybe that is my scientific education ( ahem). Say that I look for falsifications of the paradigms I work with, to get knowledge of their boundaries / problems. Google for popper paradigm kuhn falsification. F.e. en.wikipedia.org/.../Falsifiability is a result.  

> On Aug 27, 2015, at 11:06 AM, agent_008_nl wrote:
> Where did you read that I favor the procedural paradigm? You got it totally wrong in any case.
> I post these links just to consider the arguments offered therein and it is not a soap box in
> spite of the title I gave to the thread.


I, on the other hand, do favor procedural code for the simple reason that no one has demonstrated (to me) that object programming is any better. To be sure, it has a certain appeal. I was once enamored of Smalltalk and Dylan but it was only temporary, even though I worked hard at it to learn to use Smalltalk.

Good to hear a voice of an experienced programmer that is not following the crowd. I for myself did not give the matter enough thought to have a strong preference I think.

There is an H.S. Lahman quote to the effect that the thing about  OO programming is that it has never been tried.

[quote user="gus"]> On Aug 27, 2015, at 11:06 AM, agent_008_nl wrote:
I, on the other hand, do favor procedural code for the simple reason that no one has demonstrated (to me) that object programming is any better. To be sure, it has a certain appeal. [/quote]

OO certainly presents a challenge for a procedural developer to get their head around - particularly when it comes to mapping the problem space to an OO model, and dealing with the DA layer.

Where I really like with OO is I can directly map the problem-space behavior of an identified entity directly to an object and then use that functionality all over the place, pass it around as a parameter, etc. - which is something I couldn't easily do with procedural code. 

Tim, that reminds me of the transition from CHUI to GUI when v7 came out. It was a real struggle for lots of people. OO certainly has a higher level of overhead not only in learning but with planning.

Tim, I often agree silently but now you produce an incomprehensible text. At least for me. I do not think my understanding fails because I'm dutch. Plus I'm programming for a couple of years in oo progress now, besides doing other things, that should't be the problem either. It shouldn't be that hard to defend oo progress in simple terms. I understand, no need, almost everybody is convinced, the voice pro is massive. And vox populi must be the truth, mustn't it. You have courts with juries don't you. The truth is a democratic and lucrative thing.

  But oo/procedural/functional programming do not to offer the same possibilities in different languages.  (Hope I added someting intelligent? :-). Progress is not the only language on earth (ditto, for Christ sake!). We are all caged! There must be links - to be found with google - to learn how to overcome positive thinking. Help! :-)

Stephan - I'm not sure what I wrote that's "incomprehensible" - my basic point is that the conceptual / thinking process is different between procedural and OO programming, and that's the main challenge for anyone making a transition between the two.

Research I've done on the topic suggests that it takes 6-18 months for a procedural developer to get to the "aha! So that's how it works!" stage, and ~3 years under the guidance of an OO expert for a developer to become sufficiently proficient to teach others.

Stefan is the name, no ph. I understand nothing of the whole of your text and I'm an experienced oo developer. Dependency injection, IoC container, patterns, GoF, you name it. For more than three years. But never mind, maybe others can bake a chocolate pie of your text.

it was the shift from spaghetti code to confetti code that gave people such a hard time.

> Research I've done on the topic suggests that it takes 6-18 months for a procedural developer to get to the "aha! So that's how it works!" stage, and ~3 years under the guidance of an OO expert for a developer to become sufficiently proficient to teach others.
>

Yes, I've heard that a few times. But: once you have made the transition, are you any better off? or just different and desirous of infestation ?

I definitely think "better off" as it enables me to 

1. do a better job of compartmentalize things,
2. write better code / data structures,
3. secure data members as "read-only" if I need to (no more side effects due to changing values that shouldn't be changed!),
4. get much stronger typing checks,
5. write code against generic _behavior_ instead of accepting data as parameters and then writing a multitude of case statements to decipher what it means before handling it,
6. create naming structures that more closely match what I'm modelling,
7. swap out entire subsystems for something different,
8. use the same API name w/different parameter structures to communicate context, 
9. etc. 

And with Progress's ABL - I can be as "OO" or 'procedural' as I want to be depending on what the situation calls for. :)

TIM: And with Progress's ABL - I can be as "OO" or 'procedural' as I want to be depending on what the situation calls for.

Exactly. I'm not an OO developer, I'm not a procedural developer, I'm an ABL developer. I choose the solution to fit the problem, and my toolset is both wide and deep.

> my toolset is both wide and deep

Without a trace of  self-mockery! How different is this from the utterings of someone like prof. dr. Edsger W. Dijkstra.

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague."

I'm traveling, so not able to follow this exchange in real time, but  as I catch up, I am quite amused ... by a number of aspects.  But, I think one of the problems is that people are not really talking about the same things.   The point of the Lahman quote is that the vast bulk of the programming done in OO languages is not a good example of OO and yet it is those examples which people often look at when they are deciding whether or not they like OO as a concept.  This is rather like trying to decide how one likes ABL based on the examples in the manuals. The essence of OO is not in the implementation details, but in the separation and interaction of the parts.  The principles are not very different than what made for good programming in ABL *before* we had an OO option.  Implementation details are, just that, implementation details.  These vary by language.  ABL, being ABL, we have some language features available to us that oo3GLs don't have.  This doesn't mean that the system as a whole has a different design overall which is independent of the language.

Reminds me of the great Canadian piano player Glenn Gould (en.wikipedia.org/.../Glenn_Gould). He told about Chopin that he considered it a composer who had ' fallen into his instrument' (typical for a swooner ;-) - he only had the piano with it's specific possibilities in mind while composing. What he meant is comparable to what is seen and loved as oo and - opposed to oftenly - procedural/functional by the composers here: what the abl offers / makes possible.

 Let's realize that limited size of our skull. We will never be free. :-) Amen.

Dogma is a hell of a drug :-)

Every tool has pros and cons. OO has quite a few benefits for a variety of application functions but procedural has a lower barrier to entry, especially if you have an existing procedural code base.

Just like people misuse inheritance... people abuse include files and supposedly reused procedures. You can write well structured, functional code in either procedural or OO. To be honest there aren't too many examples of either in most vendor packages (not just OpenEdge based).

Blaming poor OO design/code on OO itself is like blaming the ABL for some of the horrors we have all witnessed over the years... like include files nested 7 layers deep or finding 10 different "standard" versions of a function.

The preceding question could be: "can OO on itself be blamed".

Quite not the dumbest answer "yes". For example the interviewed man here www.stlport.org/.../StepanovUSA.html :

"I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI [....]   I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work."

Maybe interesting also to read: http://jalf.dk/blog/2010/11/good-design-oop/

And socially about OO I can find truth in the following (of course hardly anyone drinking the oo abl koolaid here wants to hear these obvious but inconvenient things, what the hell when you can earn money with it + never counterspeak your good old 'friends'   ;-):

"What went wrong? People rushed to use the complex stuff (see: inheritance, especially multiple) when it wasn’t necessary, and often with a poor understanding of the fundamentals. Bureaucratic entropy and requirement creep (it is rare that requirements are subtracted, even if the original stakeholders lose interest) became codified in ill-conceived software systems. Worst of all, over-complex systems became a great way for careerist engineers (and architects!) to gain “production experience” with the latest buzzwords and “design patterns”. With all the C++/Java corner-cases and OO nightmares that come up in interview questions, it’s actually quite reasonable that a number of less-skilled developers would get the idea that they need to start doing some of that stuff (so they can answer those questions!) to advance into the big leagues."

In biological anthropology we have a long established phenomenon in which a certain type of researcher will find a new specimen, seize on some element of uniqueness of that specimen, and proudly announce that it is a new species and deeply changes our understanding of human evolution.  Of course, this is silly from the outset because given a small sample size and wide variation in space and time, one actually expects to find some unique element in any new specimen.

Moreover, once the dust settles, there isn't really any change in our understanding except that the finder's versions of the human phylogenetic tree will have a branch on them corresponding to the finder's fossil. Meanwhile, there is another type of researcher who is busy looking at the whole, looking for unifying patterns instead of unique spurs.  To him or her the new specimen is mostly expected and, at most, provides a slight jiggle to what was known all along.  

One often speaks of splitters vs lumpers, although the "my fossil is unique" is a special narcissistic form of splitting. The splitters win in the contemporary press because new, unique, change are words which drive news.  The lumpers win in the end because that is all that is actually supported by the evidence.

There is a similar phenomenon in CS in which some seek to come out against something to provide a unique or at least a controversial or newsworthy stance while others are looking for underlying patterns or unity.  It seems to me to be a variation of the same contrast.  To me, an extreme lumper, what all these anti-OOP proclamations are often based on is railing against some detail, often a detail which may not even been good OOP to a core lumper.  Moreover, their offered alternatives seem frequently to be expressions of core good OOP.

> railing against some detail, often a detail which may not even been good OOP to a core lumper.  Moreover, their

> offered alternatives seem frequently to be expressions of core good OOP

That Stepanov does not rail against details, quite the contrary. Moreover he knows what he is talking about. As far as I understood.  

"saying that everything is an object is saying nothing at all"  - Stepanov

It is good to know that we can blame the procedural model for all of the horrible code out there and not the actual developers :-)

We can blame the bad code out  there on the developers, no matter what paradigm it was developed under.  For a lot of legacy ABL, the paradigm is probably best described as unimaginative cowboy, i.e., imitate what is there unless you feel like doing something else.  For OOP languages, one can naively expect that the code would at least be a reflection of OOP principles, but that is rarely true.  But, to blame the idea of OO on the travesties committed in its name is missing the point.

Stefan, I am glad you have found inspiration in Stepanov.   I didn't.  To me, it was details.  E.g., the specifics of how and why around generics and templates to me are religious wars which get wrapped up in implementation while people forget what was underlying.

>  For a lot of legacy ABL, the paradigm is probably best described as unimaginative cowboy, i.e., imitate what is there unless you feel like doing something else.

agreed

> blame the idea of OO on the travesties committed in its name is missing the point.

That is not what Stepanov, Edsger Dijkstra etc. did, nor what I do.

> the specifics of how and why around generics and templates to me are religious wars

Demasking the oo abl hype, that's what I'm interested in, you could have concluded that by now from what I mailed. That's totally different from a religious war.

"OOABL" hype?  Seems to me that OOABL has been crawling its way out of the muck rather than being hyped.  It seems to me that, it is only in the last year or two that I see it being used with any kind of frequency and even a great deal of that is a limited use in the context of a procedural envelope.  People advocating the use of OO form (note, for some of the concrete OO pluses like compile time type checking) are often mapping that form on to familiar procedural constructs, which might ease the transition for the new to OO programmer, but hardly results in good OO practice.  Serious, rigorous OO is a rarity  ... and often mocked.

We have different ideas of what OO means.

> We have different ideas of what OO means.

Who are "we"? You cannot have an idea of what I think oo means in any case.

Could be an interesting book of this Stepanov: "Elements of programming"

www.amazon.com/.../032163537X

Think I'm going to buy this one (well, take a look at some more excerpts first).

Commercial: “The book contains some of the most beautiful code I have ever seen.

   —Bjarne Stroustrup, Designer of C++"

Got to have a book of EDW also.

All a matter of taste, I suppose ... I certainly have never seen any C++ that I thought was beautiful.   Now, TOOL, that was beautiful.

Then put aside your prejudices (pardon me, but you show tons of them in your reactions) and study that book. ;-) Doubtless there are more. You can improve your programming capabilities by studying books with examples in other languages. C++ has possibilities that progress does not have of course, in any case it's good to have knowlegde of those possibilities then. I learned some refactoring from Martin Fowler's Refactoring: Improving the Design of Existing Code. Examples in java. You won't find books on the art of programming with beautiful abl code.

  Some discussion about how C++ moved on:

http://stackoverflow.com/questions/1039853/why-is-the-c-stl-is-so-heavily-based-on-templates-and-not-on-interfaces

I stopped counting languages I have developed in when I got to 50 ... that was in the early 90s ... so I am well aware of the potential for cross fertilization. It is hard enough to find beautiful ABL code, much less books on it.

You won't find books on the art of programming with beautiful abl code.

So sue me. I've gotten lazy in my old age. 

Don't worry, your book would hardly sell. Moreover the most interesting developments in languages don't take place at psc as it is a (slow) trendfollower.

Friendships are discovered rather than made.
~Harriet Beecher Stowe

pompiedom where is the deletebuttom

Ah, watch this one: Civilizing the Barbarians Lecture 1: Introduction  www.youtube.com/watch

By that same C++ Stepanov.

 Must watch for some here.