Re: Java is becoming the new Cobol



"Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote in message
news:0t5gj.59398$rc2.24476@xxxxxxxxxxxxxxxxxxxxxxxxx
"LX-i" <lxi0007@xxxxxxxxxxxx> wrote:

And yes, I'm programming using OO every day, have been doing so for over
a
year, and I have still yet to see anything I couldn't have done simpler
and
easier as procedural.

I've been doing it right at 10 months (so I guess I'm a little behind
you), but I'm of a completely different opinion. OO has saved me
*loads* of time. In fact, now when I hear a problem being described, my
mind automatically starts breaking it up into the objects that will be
affected, and the information they need to exchange to make it happen.

Just this past week, I had to write some code for a process that was
very similar to another one. What I did was look at what the old one
did, look at what I needed, *and* look at future known requirements, and
I was able to break the original object up into three objects, then
subclass the second to make mine. I didn't have to write *any* of that
code, because it had already been written. <snipped>

Had that code been already written procedural code, with comparably strict
definition and usage attributes, you would have been in the same
situation.
It appears to me, from your and Pete's comments, that you may be
unfamiliar
with very good modular structured techniques. I have done all of what you
describe above, many times, using well defined, modular procedural code.
And the underlying support system to get it done was far more streamlined
and efficient than the vastly bloated, inefficient OO tools we use now. I
have always worked toward modular, reusable code, with very good result.
IMO, it is using the principles of well designed modules, data hiding, and
other long ago defined structured principles that you are benefitting
from,
not OO per se. As I've said, I have yet to see one thing done in OO that
could not have been done as easily, or more easily, and far more
efficiently,
using good procedural techniques.

I don't know if you were around when I posted my "My First C#" post.
The feedback I got from it (in here) was really, really great. In fact,
I didn't realize the brilliance of some of that advice until I got to my
new job and started doing OO exclusively every day. The biggest thing
that helped me, I think, is the "one method, one responsibility"
concept. If the building blocks are small enough, you can put them
together quickly. If they're too big, you have to take the time to
either split them apart, or add "another" parameter to alter the
behavior under a certain condition. (And yes, it is valid OO to have a
method whose one responsibility is putting the pieces together - in
fact, that's probably the main method in the class.)

I agree. But all of those principles were already part of structured
design,
had people actually used it. I've been using them assiduously for decades;
perhaps that's why I see no real benefit to OO. When I look at OO, I see a
vastly overcomplicated technique that gives me nothing I haven't had for a
long time, and comes at a great price in complexity and inefficiency.

After all, OO is implemented procedurally at the
machine code level. OO is, functionally, just a wrapper, so it's false
to
say it couldn't be done procedurally, because it is procedural at the
bottom.

For me, it's been a mindset shift - and I have seen it benefit me.
Maybe I'm in a shop where it's done right. :) (Not implying anything
about yours, of course...)

Mental paradigms can be powerful. I remember a similar epiphany when the
principles of structured design and what it meant really "hit me". I'm
glad
the OO paradigm was helpful for you. But perhaps you just haven't been in
a
shop where structured procedural was "done right". :-)

Sigh. All of this is merely of academic interest, though, for the world
has
well and truly followed the Pied Piper of OO, for better or worse. It does
work, and I'm using it. I just grieve that this over-complex, inefficient
path has been chosen for us, when a better, simpler, much more efficient
one
was already in place, had it been used with wisdom and discipline.

Yeah, it really sucks to be a pebble in a landslide, doesn't it :-)?

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: Java is becoming the new Cobol
    ... with very good modular structured techniques. ... and efficient than the vastly bloated, inefficient OO tools we use now. ... other long ago defined structured principles that you are benefitting from, ... But all of those principles were already part of structured design, ...
    (comp.lang.cobol)
  • Re: OO Design induces an existential crisis
    ... >> are roughly about 10 times more written on systems software in OO ... easier to move the management of those variations into the database ... > property in the _finished_ design for any single iteration. ... > Implementing a design requires an understanding of all of the principles. ...
    (comp.object)
  • Re: OO Design induces an existential crisis
    ... > examining a set of principles, in detail, and challenging one of them (while ... > I ask you to find the single OO principle that you disagree with. ... > that is pretty good for meeting the principles of both OO design and SOA ... >> more code rework in the device driver examples. ...
    (comp.object)
  • Re: My First C# (warning - long post)
    ... and all hold onto the **Single Responsibility Principle. ... Of all the principles of object oriented design, ... People tend to use inheritance for code reuse instead of modelling ...
    (comp.lang.cobol)
  • Re: Total skiing: ski the whole ski
    ... The Tao of skiing is to study the principles of skiing, ... principles to develop techniques; as the techniques are developed from ... Based on what you've put on the web, "flatboarding" is simply ...
    (rec.skiing.alpine)