× 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.



On Thu, 2017-07-06 at 11:52 -0400, Jon Paris wrote:
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

I wonder if one of the reasons why OO is, or seems, less applicable to
the "400" is that like the OS, programs have always been "object based".
OO was a resolution to a problem that was not [as] applicable to the i's
environment in that while programs often accessed many disparate files
and did a large amount of validation (sometimes replicated across
multiple programs) the programs themselves were very self contained. An
order entry system had a program to maintain the order header, and a
program to maintain the order detail, which called a program to search
and select a stock item, which could also call a program to display the
stock item details.

I think one of the reasons why it was possible to write so many
programs, each one specific to a generalised task, was the speed at
which a program could be invoked in comparison to a "PC" program (even a
simple hello world). Although that said, when you're invoking a called
program 10's of thousands of times on the i even that speed of
invocation becomes limiting which is why externalised subprocedures are
just awesome, along with the increase in re-usable building/logic blocks
- its more of a granular improvement rather than a paradigm shift.
(Multiple modules in a service program, I feel, are more about code
organisation than the finalised implementation.)

PC programs however were getting bigger and bigger and having to handle
the gui, the input logic, and processing logic, and data logic, and file
logic... so OO seemed like a good way of introducing the fine grained
control that we, to some degree, take for granted on the i because its
second nature to break an "application" in to smaller isolated
"programs" (or objects) and we also had the advantage that the "ui"
processing was all handled by the system and was genuinely externalised
from the program (treated as a file) instead of being embedded, or
interwoven, with the validation processing logic.

Oh, and then there is the whole ecosystem that we take for granted.
Messaging as fundamental part of both the system and the application
programming languages (along with system wide message files), job logs
(as a kind of side affect of messaging), job queues that hide the
complexity of spawning "background" tasks or fiddling around with task
manager and the completion of the tasks being notified by the in built
messaging system... and so on; even down to the little panel on the
front that would give you chapter and verse (once you looked up the
codes) on why the thing had failed to power on - no silly beeps as the
only clue (heck even PC's now, finally, have got around to having a
little 2 digit SRC display on the motherboard years after the S36 had it
[my first experience with "midrange" kit after leaving school, which had
BBC micros and Comodor Pet's]).

And last, but by no means least, an integrated database with record
locking, concurrency, journaling, journal auditing (viewing/extraction),
commitment control...

Jon.


www.partner400.com
www.SystemiDeveloper.com

On Jul 4, 2017, at 7:02 PM, Richard Schoen <Richard.Schoen@xxxxxxxxxxxxxxx> 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

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

message: 2
date: Tue, 4 Jul 2017 01:37:25 +0000
from: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
subject: RE: RPG easier/harder to use than other languages?

I'm seeing a number of disgruntled former OO devs these days claim that OO is flawed in concept. Personally I haven't done enough to have my own opinion. I have seen some crazy designs where people try to force a strict "text book" OO solution over problems where that concept doesn't really seem to fit.


-----Original Message-----
From: Raul A Jager W [mailto:raul@xxxxxxxxxx]
Sent: Monday, July 03, 2017 5:32 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: RPG easier/harder to use than other languages?

Lots of business needs are better served by OLTP and relational database rather than OO. Sure, for the user interface OO is great, so use javascript in the browser and RPG in the server. Do not use 5250. Do not use "screen scrapers". Develop for web.

How do you classify a language as modern or not? The OO model is quite old. Java is showing its age to. Python is from the 80s.

Is OO the right tool for everything? Interpreted languages require very careful testing, and control over the input.

When there are lots of transactions, a compiled language like RPG or Cobol will enable the same processor to handle easily 20 times more transactions than the same code in PHP. Moore law does not work anymore, the speed has remained at 4 GH since the last 10 years or more. It is far more expensive to set up 20 servers rather than the difference of cost between developing in PHP or RPG.






--
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.