× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Jon

If you remember IBM's "San Francisco project" it failed not only because of
lack of performance but also because of OOP driven to the degree of
perversion by developers that didn't had a clue of what debit or credit
was. The same thing did actually nearly happen with node.js where
everything suddenly had to be asynchronous that is a nice thing if you
happens to have to put a man on the moon but really overcomplicates code if
you just have to read a row, do a simple calculation and update it and ends
op with code where 99% of the code just is handling the wait for the event
that the previous statement finished.

On Thu, Jul 6, 2017 at 9:31 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

I think we are in in agreement on this Richard.

It has always seemed to me that OO was a terrific fir for something like
graphical programming (browser or desktop) where inheritance of things like
buttons, entry fields, etc. has real advantages. But all too often the
purists rammed the paradigm down our throats as the solution for
everything. In theory using OO principals also works OK with (say) types of
bank account. In practice it only seems to work if the IT group can
constrain the kind of non-sensicle "customizations" that are demanded by
the marketing folks. All too often there are so many exceptions that it
would have been easier and more maintainable to just write a few custom
pieces and build the different account types from those rather than
attempting to inherit the behaviours.

Java is often referred to as the "new COBOL" in this sense as it has
become every bit as hard to maintain and update business apps as it was
before. In the Windows/Browser/etc. world the order of the day seems to be
more towards simply rewriting and to hell with backward compatibility.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jul 6, 2017, at 12:56 PM, Richard Schoen <Richard.Schoen@helpsystems.
com> wrote:

Now there's some meat.

Thanks for those Jon. Made me laugh.

Reading that I thought it felt kind of like the purist view of database
design and trying to get to 5th Normal Form in a database design.

Fine in thoery, but in practice, you maybe get to 2nd, 3rd or 4th normal
form.

In terms of re-usable objects I typically think of RPG service programs,
Java JAR files, PHP classes, .Net assemblies and web services which are all
the concept of having similar code callable via an API which may contain
objects internally but makes a developers life easier by bottling re-usable
processes. And hopefully it's documented 😊

Possibly some inheritence, but generally implementing some specific
functionality that can be used across programs saving a programmer lots of
time.

Only thing that really matters is testing the re-usable code,
documenting the code and its usage and making sure a developer knows how to
apply the re-usable code in a production app.

That applies to any language.

My three cents.

Regards,


Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
------------------------------

message: 3
date: Thu, 6 Jul 2017 11:52:01 -0400
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: RPG easier/harder to use than other languages?

This is quite an enjoyable and informative read
https://medium.com/@cscalfani/goodbye-object-oriented-
programming-a59cda4c0e53 <https://medium.com/@cscalfani/goodbye-object-
oriented-programming-a59cda4c0e53>

And this https://content.pivotal.io/blog/all-evidence-points-to-
oop-being-bullshit <https://content.pivotal.io/
blog/all-evidence-points-to-oop-being-bullshit>


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jul 4, 2017, at 7:02 PM, Richard Schoen <Richard.Schoen@helpsystems.
com> wrote:

Do you have some examples of how these former disgrunted OO devs have
found OO programming to be flawed ?

Just curious since your statement seems pretty generic.

Regards,

Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.