The Soapbox - The Trashing of OOP: Legacy vs ABC

by Russ Eggen

Published 1999-02-01    Printer-friendly version

I normally do not subscribe to the newsgroup, Comp.Lang.Clarion. I forget why I discontinued accessing it a long time ago. However, I subscribed to it again to see what was going on in this world. I quickly remembered why I unsubscribed.

Although I did focus on a few threads, they were quite active in debate. About how bad ABC is, difficult to learn, poor docs, etc. Seems there are still folks who hold onto the idea that ABC is not what it was promised to be. While this notion may be true at this particular point in time for them, conceptually, nothing could be further from the truth.

I will not deny that ABC requires some study to get an acceptable product (working code that can be easily maintained). One cannot deny that legacy took quite a bit of study too. I will also state that using legacy may produce working code, the maintenance part is open to interpretation. I will postulate here and now, that legacy requires more energy to maintain. For those still using legacy because of ABC learning problems, no insult is intended. However, let me spell it out a bit so you understand my viewpoint.

Anyone going to an OOP model for the first time will find that it looks as foreign as an alien lifeform. Doesn’t matter if it is Clarion or any other language. First impressions of OOP are that it is strange looking. I came from the same school of top-down programming, code everything linear, no forward references, etc. However, as I started to study what was going on, several things started becoming apparent.

We have been using "OOP-like" concepts in our code anyway! How about multiple calls to the same routine? (Re-using code). How about *? and ? as parameters? (unknown parameter types). Both since the DOS days! How about this little goodie: Strings. What about Strings? Strings are arrays of one-byte strings. The debugger can prove this very quickly. We do not think about CUS:Name as "an array of 30 one-byte strings put end to end". We think of it as simply a "string". Now why is that even OOP-like? Because it is an object. We literally think of it as an object that we can do something with. It is an object whether one was conscious of it or not!

OK, so what is the point? The point is that you are closer to using OOP than you may realize. So I have to ask, why is there such a fuss on Comp.Lang.Clarion? Let’s toss aside those folks that take great pride in being stubborn and refusing to learn. I cannot help them. Neither can anyone else. They need to change their attitude and viewpoint before help will take hold. This is for the folks who are trying, but struggling.

Whenever I see comments like, "TopSpeed is making a huge mistake in going to OOP", or "OOP is just a fad", or "It writes spaghetti code, one cannot possibly follow the logic" does not understand OOP. These are actual comments, some from coders whose work I respect. So they are capable. There are many more such comments. Comments such as these mean only one thing: They do not understand this topic, so they condemn it. I used to be one of them!

Pretty brutal statement and certainly not very PR like. However, it is true. Now, before anyone runs out and chips in for tar and feathers, I will also state that once OOP is understood, even just conceptually, the criticisms start dropping off. Coders start seeing how to cut their workload while maintaining functional applications. Ideas start entering into the picture.

Before anyone condemns OOP (or the ABC implementation), understand what OOP is first. No one who understands these concepts condemns them. It is the "not understood" and/or "misunderstood" words that are tripping you up. Remember what benefits an OOP dialect brings to the table:

• Code re-use. You use the same code, not copies or clones of this code with different labels. This simplifies your code and makes it far less prone to break. If it works, then it works and you have only one spot to maintain it, not 80. Cuts down on spaghetti, too.
• Flexibility. If a bit of code does not do what you need, you simply code only the bits that you do need. Use of embed points drops and, even when used, less code is needed to get the job done.
• Buggy code. You are less prone to this. But lets assume the worst and there is a nasty bug in one of the ABC classes. Some folks have been changing ABC classes. No, no, no, no, NO! Never do this. It is not needed! Simply derive your own object and override the buggy bits. Later, the nasty bug is fixed. Guess what? Your code still works! You can back out your "patch" and see what happens, and it will still work. When using OOP correctly, there is a natural "no man's land" that no one should cross. This is something that legacy cannot do.

Suppose you write a bit of code that retrieves a record. In Clarion this does not take a lot of code to accomplish. I think we all know one or two ways to do this. Now lets suppose that working bit of code can be used on any file, queue or view we wish. We know the Clarion statements to do this, and we can easily prove it works. However, the code is written so the only thing needed is the data label. All we really need to do in our application is point it at the data object we want to get a record from. Remember, the code works. Only the label of the data is "dynamic".

We call this bit of code anytime anytime we need a record, regardless of application. How can one possibly write this procedurally? In the same amount of code?

I have deliberatly not included any code in this article. For those doubters, I merely wanted to discuss this on a high level. Nothing here is mystical or magical (although it may appear that way). I will also state that I hardly know ABC. Surprised? This is another great benefit. You do not need to know all the internals of ABC like you did with legacy. You will get familiar with some of the code, but you certainly do not need to get intimate with it to produce a functioning application.

Lets talk about embeds. Guess what? There is no difference in how you use Event embeds. This is about 80% of your embeds. You certaintly do not need to know OOP to use those. I give this advice to all my students when I teach embeds - "If you feel you need to write an embed, sit on your hands". Mildly humorous, but there is a very strong point being made here. ABC is far more code complete that legacy. This does not mean that legacy was poorly written. It means that legacy could go only so far. Nothing really wrong about that, as that is what we have come to expect from templates. ABC is certainly no different. It takes you only so far too. However, they go further, out of the box. Thus, the reasons why you use embeds in legacy no longer apply! One should come to a conclusion that less effort is truly needed to use ABC. You would be correct.

Sounds like a pretty good deal to me - less work, more functionality. I am painting a rosy picture here, and not because I am a good cheerleader. It is because it is true!

Try this exercise. You still do not believe me. You have 2 weeks to give a presentation to your customer, boss, or your R&D crew that you need to switch to ABC. You also need to convince them of this fact. You need to back it up with code and ensure they understand why you are making a stance. How do you educate them on the merits when you yourself know next to nothing about it?

Remember that there have been some good coders in the past that have criticized OOP and they now live by it. Have you wondered what changed their minds?

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942