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



I think in a lot of ways we're agreeing , but with a few semantic differences. I'll point out a couple, and maybe one or two places where we can just agree to disagree.

I would say the prime selling point of any paradigm is how well it
models the problems you are trying to solve. Some problems happen to
conceptually fit very nicely into an object-based model. For me, GUIs
seem to be quite naturally object-oriented. Back-end business logic
is often not a good fit for OO (though it conceivably could be, for
some businesses and for some programmers).

Agreed. GUI is a natural fit for OO, business logic not so much, although there are lots of places where OO components may certainly make sense (e.g., encapsulation).


I disagree. I think whether something is hard or easy to change is
mostly in the design. A *truly major* change is going to be hard in
any system.

Here we have to agree to disagree. In my experience, the real world throws changes that can't possibly be foreseen. You write a system that does exactly what you want. And then the company merges with another company and one of your fundamental design assumptions goes out the window (maybe you are thrust into multi-currency, or you have to deal with coproducts when you didn't before - the possibilities are endless). Sometimes new government regulations kill you - my favorite was when the payroll tax was split; that kicked the crap out of lots of payroll systems.

Highly OO systems - especially systems with lots of data hiding - are often harder to modify in this situation. That's because most business objects are inter-related, and almost without fail you end up with a calculation that needs more data than it did originally. You either have to include that data in some object that didn't need it before, or you have to add it to a global session object, or you have to change the signature of a function. And after a few changes like this, you realize that your hierarchy is out of whack, and it's time to refactor it. And that's when major changes are very hard.

With procedural code it's very easy. Adding a field to a data structure is easy, adding a CHAIN to another file is simple, even adding a parameter to a call is not particularly difficult; all of it is usually very easy because you're not as locked into the rigidity of what is passed between layers. Now, this is my own personal experience, and as you note, composition rather than subclassing mitigates this problem to some degree, but it's still easier to modify a procedural program than a highly segmented object hierarchy.


And a relatively minor change is going to be hard in a
system that isn't designed to accommodate it. (I would like to say
"any change is hard in a poorly designed system" but it depends on the
ways in which the system was poorly designed. A poorly designed
system might nonetheless be easy to add duct tape to, for example.)

Future proofing is part science, part art and frankly part luck. But systemic changes of the nature I've mentioned have in my experience always been much easier to do in procedural environments rather than OO.

I think well-designed OO systems are just as easy to make major
changes to as well-designed procedural systems, perhaps easier. Not
all OO systems are based on a "class hierarchy".

Well, this is technically not true. All OO systems require classes. The objects must be parts of a hierarchy. Certainly your runtime has lots of classes, and lots of those classes subclass others. Now, you may be able to design applications where every class is a root class and has no superclass (in Java, all would subclass Object) and your entire design is composition. I've never tried it and I have seen very few non-trivial systems that didn't have some degree of subclassing; it's the fundamental technique to implement code reuse.

At least for me,
that is not what OO is about. And as I mentioned earlier, I find GUIs
a natural fit for OO, and this is a highly dynamic problem, both in
terms of the event-driven nature of user input, and in the fact that
the specs and requirements for a GUI can change approximately as often
as the business rules behind it.

Here's where we just have a semantic difference. You say that GUI is a dynamic problem, and I consider GUIs to be one of the most static problem sets we program. For example, there is only one way to program an HTML tag: it has a bracket, a keyword, and an optional set of attributes. It can have data that is then closed by a closing tag of the same kind, or it can be a self-closing tag. This is a perfect problem set for OO - you can easily define a class called HTML tag, and that class can be used for any type of tag. You can also build on that class either through composition or inheritance to create more complex and more specific tags. But the reason I consider the problem set static is that once written those classes don't change. Which tags you actually place on the screen to address a specific business problem certainly changes, but populating the data is something I would write in a procedural language, because how you get the data may change depending on the business situation.

And I'm not the only one who thinks procedural languages have
their uses, Java may be the number one language, but C is
number 2, and there ain't no objects in C.
Ah, but who would use C for their business logic either? C is not
meant for things that RPG is meant for. That is not why C is still so
popular. C's popularity is not an argument for "procedural language"
popularity (or relevance or importance or what have you). C provides
no coattails for RPG to hang onto in a discussion comparing languages.

Why certainly it does. If OO was the perfect solution for everything, then you would program everything in C++ not C. C++ would have long overtaken C much the same way that C# has eclipsed VB, but it has not. There is an entire significant problem realm in which OO is not the tool of choice. My point is that in business programming, the same is true. There are problem sets which OO is good for, and others where it is not and for most of the latter RPG is the best fit.

If your only point is that OO is no silver bullet, fine. But I don't
think anyone is arguing (seriously) that *everything* should be done
with OO languages, or even in an object-oriented way (regardless of
language).

Hmm. Then you don't read the "Java will replace RPG" comments that are everywhere. A related argument is the "SQL must replace native I/O" discussion. I just have a problem with any argument that says one technique or language is intrinsically better than another. In context, each tool has its strengths and weaknesses. And in my opinion, the ability to respond to major external stimuli is a strength for procedural languages.

Further, so-called OO languages are really just languages that happen
to provide explicit support for some set of OO mechanisms; these
languages do not define what OO is, and using such languages is not
the same thing as (nor is it even required for) OO programming.

At the same time, if you use an OO language and don't use its OO constructs, then you aren't really using the language. For example, using Java purely for procedural programming isn't really using Java. But that's a different topic entirely.

Joe


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.