Re: Java is becoming the new Cobol

"LX-i" <lxi0007@xxxxxxxxxxxx> wrote:
Judson McClendon wrote:
"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.

I've seen places where the type of programming I'm doing now would fit nicely into the system I used to work on. Of course,
getting permission to do it would be the tough part. It's hard to pitch a perceived benefit most directly visible to the
developers. (The "increased reliability for the users concept" is hard to quantify. "So, Jim, how many problems didn't we have
this week?")

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.

What tools seem bloated and inefficient to you? (I'm not saying they aren't - I'm just curious as to what you're referring.)

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.

Sometimes, though, you have to do the best you can in the environment you've been given. In the Unisys 2200 environment using
their Network Database Server (DMS), you get a schema work area depending on how you invoke the schema. Your choices are
working-storage, linkage, or common-storage. (Common storage is a Unisys thing - all linked modules have access to this area of
memory.) However, it not only copies the schema area into the program, but the "DMCA" (Database Management Communication Area -
basically, the block of information that holds your connection state) is copied in too.

The problem is, you can't realistically bring it into linkage, because the 200+ 01-level record definitions would get copied in.
So, you're left with working-storage, which makes it visible to your program only, or common-storage, which makes it visible to
programs linked in. Either way, the design of it natually lends itself to a tight coupling with the database. Unless subroutines
are coded with the schema defined the exact same way, they don't have access to it (even though the thread has been established).

Now, that being said (the perfect set-up for the "but I just can't do it" excuse), it COULD be done. However, without a complete
database abstraction layer, these limitations are still going to be there. So, you get these monolithic programs with two or
three screenful's worth of copy statements. The data's wide open, because it has to be to work.

I would absolutely love to create a data abstraction layer for that system. :) But, getting all the program changed to use it,
getting them tested, then getting them out the door make it not feasible.

<reminiscing>
There was one program that I broke up into nested subprograms. It was our batch routine validator, and it did column-by-column
verification of inputs, ostensibly to catch errors without having the overhead of starting a batch run. I modified it to have a
nested subprogram for each transaction code, then within these, I copied in the screen working-storage (which had meaningful
names), and changed the validation to use the names. However, because of the whole schema thing, I had to keep paragraphs in the
main program to be able to do data validation against the database. :( The structure change benefitted no one but me (well, and
the other folks who got to maintain it), and if I hadn't been quick on some other code, I would not have had time to do it.

Ideally, though, each of those would have been its own separate module.
</reminiscing>

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.

I really don't see the excessive overhead. That's why I asked you what environment you're working in. But hey, we've got to have
*something* for all these cores in our modern computers to do! ;)

Been a while since I've seen an actual 'core'. :-)

Wow, where do I begin? When you are casually instantiating and disposing
of objects, have you ever stopped to think what is actually going on to make
that happen? How about inheritance, overloading, etc? A truly vast amount
of code is being executed to do it. The OO paradigm is highly abstracted
from how current CPUs actually function, and implementing this high level
of abstraction takes a lot of work, both to develop the OO development
system, and to execute it. The process is, by definition, "very inefficient"
from a hardware perspective.

I'm actually using .NET (Visual Studio 2005). As for "efficiency" in .NET,
the CLR adds a whole new level of inefficiency on top of what I described
above, because it's interpreted code. But I'm experienced and objective
enough not to blame OO for the CLR inefficiencies. :-)

As bone-headed as many of the design decisions were in .NET, I have to be
truly impressed at the massive accomplishment. As it is, there are big gaps
and booboos in .NET. Just write a program using .NET to meticulously set
fairly narrow margins on a printed page and make it look right across
different printers and print preview. Whoever designed that set of classes
was absolutely clueless, and clearly had no concept about how they should
have been implemented.

Understand, I'm not arguing against abstraction. Abstraction can be very
powerful and useful. All HLL compilers are abstractions. Even labels and
macros in assembly are abstractions. But when you create an enormously
complex and expensive abstraction, you need to get a very good return on
the investment, not only in development, but in learning and using it. As
has been pointed out by others in these threads, there just is not good
data to show that OO is worth the enormous price the industry has paid
for it, compared to other, simpler, alternatives. The reverse is closer
to reality. I can already hear the screams of indignation from the OO
proponents. :-) Let's take a look at an earlier "paradigm revolution".

In the 1970s I spearheaded implementing the relatively new structured
methodologies at my shop. Within a year I had solid hard data to prove,
beyond any question, that the structured methodologies were giving big
paybacks in shorter development time, less bugs, easier maintenance, etc.
The data was in no way ambiguous, it was as clearly definitive as one
could want. Not one person involved, even those who had been dead set
against it, failed to be absolutely convinced. The programmers I had had
drag, kicking and screaming, into structured programming, were beyond
enthusiastic to ecstatic. I have seen nothing remotely comparable from OO.
It's clear that the learning curve for OO development is much steeper than
for structured. At the same time, I have seen project after project using
OO go belly up, or vastly over budget and time, at all my clients. Why,
if OO is so much better?

When I protested these things here, I was always told "You just haven't
used OO enough; when you do, you'll see." Well, I've been immersed in
OO for over a year, and I'm now comfortable developing with it. I love
many of the design tools, like Visual Studio's IntelliSense. I can now do
whatever I want using OO without much difficulty. The prime "difficulty"
being finding the specific functions I want among the vast set of .NET
classes. Improved documentation and search would mitigate this a lot.
(Note to Microsoft: when someone searches for "xxx", *first* give them
the definition and usage of "xxx", *followed* by the 4,000 bug reports
and other articles on "xxx", not vice-versa. Duh!)

I would be delighted to discover that OO is, indeed, the way we needed
to go. It's obvious we're all going there, good or bad, like it or not.
Better to be 'good' and 'like' than not. But I'm still unimpressed and
unconvinced.
--
Judson McClendon judmc@xxxxxxxxxxxxx (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


.

Relevant Pages

  • Re: Abstract public member variales?
    ... client (the problem solution) is indifferent to the details. ... at the level of abstraction where you define how the game works. ... I describe the workings of the game at many levels of abstraction, depending on who I am talking to. ... At the other is the level of abstraction that I use when summarizing my design in a paragraph for usenet. ...
    (comp.object)
  • Re: Ease of product development (was Re: Nanotech arms race worries:all smoke and no fire?)
    ... but design problems as well. ... > Levels of abstraction is an extremely powerful design tool. ... > there'll be no more molecular engineering needed. ... I, however, am a hardware developer. ...
    (sci.nanotech)
  • Re: LSP and subtype
    ... Do you seriously classify UML as a language? ... > for resolving functional requirements during design so the 3GLs are ... > abstraction in 4GLs. ... >> But that just means that you don't reuse anything. ...
    (comp.object)
  • Re: OT: concrete and clay WAS: Re: I need a new compiler...
    ... oriented *design* over object oriented programming. ... I was using "abstraction" in the sense of the word in English and not as the ... He has become an accomplished pilot on the simulator and I was very ... We need abstraction layers to keep us sane. ...
    (comp.lang.cobol)
  • Re: what is better - one field or eight - mysql bit testing
    ... table a better option, especially since it saves a hell of a lot of work, ... This is the design of maximum efficiency, ... Abstraction does require a lot more work. ... and not just throw generalities and hypothetical ideals at me. ...
    (comp.lang.php)