Re: Java is becoming the new Cobol

"LX-i" <lxi0007@xxxxxxxxxxxx> wrote:
Judson McClendon wrote:

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'll buy that - but I'm not sure that it's necessarily "very" inefficient in all incarnations of OO runtime. My OO PHP pages
actually seem to run faster than their "all in one script" counterparts, and the CPU usage looks the same.

Scripting is inherently inefficient too, possibly accounting for most of
the overhead in that situation.

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 don't know - it's really helped me. Maybe it's just something I "get" (or that OO helps me "get").

Perhaps so; you're not the only one to express that. We're all different.

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.

I'll agree with that last statement too. It took me several years to come close to understanding it, and several months of
actually coding it before I understood (and am now comfortable with my level of understanding).

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?

I think that some of it is hype, and some of it is the fact that the people developing it just didn't understand the paradigm. It
is very easy to write poorly-performing OO code. :)

(I know, that sounds like what you say below...)

When I protested these things here, I was always told "You just haven't
used OO enough; when you do, you'll see."

But it's not. :) What I'm saying is that the "easy" and "anyone can do it" parts are bull - it can be done, but it takes an
understanding that isn't easy to come by.

(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!)

heh heh heh... You know, those are ranked by the order they're most needed... ;)

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.

Are you dissatisfied with the code you're producing (from a performance, maintainability, or clarity standpoint)? Or, does it
just bother you that it's generating more machine instructions than you think it needs to? (I don't mean that last question to be
smart-alecky... I tried 5 different ways of wording it, and that was the best I could come up with.)

No, I'm pretty satisifed with the actual code I'm producing right now,
as to clarity and effectiveness. I've become pretty comfortable in OO,
as far as getting it done.

My biggest concern is that the overall people cost of learning and using
OO is far too great; the ROI is insufficient. OO effectively eliminates
the word "simple" from the process.

Believe me, I don't have a problem with complexity, when it's warranted.
I once wrote a series of reports that had a section so complex that, even
heavily commented, I put a heading over the code something to the effect
"Abandon all hope, ye who enter here." Several years later, a programmer
under a different IS manager decided to modify the code. Naturally, she
paid no attention to my warnings, broke the code and screamed "Help!"
The IS manager called to chew me out. But after I explained the system
requirements that his predecessor had given me, why I had done it that
way, and that I had provided and documented an easy and simple way to
accomplish such changes, he backed off and chewed out his programmer for
ignoring my warnings. I once wrote a compiler and P-code interpreter in
COBOL for a utility program I marketed, because COBOL was the only
compiler available to me across the target platforms. I also wrote a
graphics library in COBOL, from dot plot to line and character draw, and
graphics data compression algorithms, including an assembly language
printer driver on the receiving end so I could send 8 bit binary graphics
data from an EBCDIC mainframe across a 7 bit ASCII connection to an 8 bit
graphics laser printer to print ultrasound obstetrics charts. When I
tried to explain how that all worked to the client, his eyes glazed over.
My point is that I've often dealt with complexity, enjoy solving complex
problems, when the complexity is for very good reason. IMO, OO is not a
sufficient reason for this level of complexity.

Perhaps a more balanced approach than the "anything not an object is Bad"
approach would be better. Just because recursive logic can be wonderfully
simple, elegant and even beautiful for certain things, wo don't chuck
iterative out the window; because it's better for even more things. IOW,
don't throw the baby out with the bathwater.

Again and again, as I encounter new things in OO, once I research how to
approach it, I can't help but think how I would have done the same thing
using structured procedural techniques, and am stunned by how much more
complex the "everything OO or die" approach is. And this impression is
born out by the lack of good data to show that OO makes the process any
easier, quicker, or less expensive. Show me the definitive data, and I'll
admit my impressions are wrong. Since the data backs up my impressions,
I'll continue to believe I'm right. :-)
--
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: Java is becoming the new Cobol
    ... Believe me, I don't have a problem with complexity, when it's warranted. ... graphics data compression algorithms, including an assembly language ... The "data" doesn't back up your impressions at all. ... More than 90% of all the programmers in the world are using OO. ...
    (comp.lang.cobol)
  • Re: (and about tests) Re: Pedantic pickling error after reload?
    ... If there are things with nested classes etc, the programmer will have to ... Yes, I could have written that code on the fly, hitting F5 every few seconds/minutes to see if things work out - and once I'd be finished, I didn't have anything permanent that ensured the functionality over time. ... But we also use selenium to test JS-driven interfaces, as now the complexity of the interface rises, with all the bells & whistles of ajaxiness and whatnot. ...
    (comp.lang.python)
  • Re: Design Patterns and Functional programming
    ... Impurity is not required, as purely functional languages do exist, but it ... not the asymptotic complexity. ... this form of static checking requires the pattern matcher to be ... Then compiler leaves it up to the programmer. ...
    (comp.object)
  • Re: Java is becoming the new Cobol
    ... Believe me, I don't have a problem with complexity, when it's warranted. ... Several years later, a programmer ... graphics data compression algorithms, including an assembly language ... Since the data backs up my impressions, ...
    (comp.lang.cobol)
  • Re: Boxing and Unboxing ??
    ... It also increases language complexity, which can increase programmer ... adding one simple parameter qualifier and removing a complex qualifier. ...
    (microsoft.public.dotnet.languages.csharp)