yost@esquire.UUCP (David A. Yost) (10/28/89)
Consider the case of a large existing C program that is
being maintained and extended. Now one gets the idea
to migrate the program incrementally to an OO language.
Here are some alternatives:
I. Languages-by-C-extension, such as C++ or Objective-C:
No muss, no fuss. Simply switch to the new
compiler, start using the OO features here and
there among the existing code, and before you know
it, presto! You have an OO program!
(Seductive. But will you respect yourself in the
morning? You've bought into a language that put
compatibility above all, that held on to all the
complexities of a low-level language and
compounded them with the complexity of OO features
struggling to coexist. I think it's high time for
a clean, please-make-it-incompatible, higher level
language. At some point you have to let go of the
details to move up. Remember when we migrated
from assembler to C? Remember all the low level
control we gave up? Just as we let go of register
allocation, so must we now let go of memory
allocation (for example). I love to ponder our
fate if instead of C, Bell Labs had given us a
language called, say, "incr_asm". Then imagine
extending that language to be OO. Wow, full
control! It's like a CEO trying to do all the
jobs in a big corporation all the time.)
II. Non-C-derived languages such as Eiffel:
Link the existing C code with external code in
the new language.
A. Using vanilla C:
Using external objects is notationally ugly,
and you have to live without some or all of
the benefits of type checking, exception
handling, garbage collection, etc.
B. Using a compatibly extended C:
I am suggesting here a preprocessor for an
ANSI C superset language that would have
enough extensions to manipulate objects
maintained in Eiffel (as a client, not a
parent or heir) and would possibly also
transparently insert code for example, to
support exception handling in the Eiffel code.
In effect, you would be extending C to make
available more powerful types, (which can be
garbage-collected, can handle exceptions,
etc.) but you would leave to Eiffel the
implementation of those types. The Eiffel
environment could even keep track of the
external type declarations without the need
for header files in the C code, much as Eiffel
now works within its own code.
I like the idea of this last approach because it could
allow you to migrate a large program slowly to a new
language without the need for that language to also
serve as C or for C to try to be a full-blown OO
language. To convert, one might slowly change the C
program by a mix of these strategies:
* using library objects from the OO side
* moving large blocks of functionality from the C
side to the OO side
Now we raise the question: is it really a good idea
to try to migrate an existing program to OO or is it
better (quicker, more maintainable) in the long run
to redesign from scratch in the new language using OO
design? (If the latter is true, then it is all the
more clear that there is no contest between a cleanly-
designed higher-level OO language and a compatible C
extension.)
It is an attractive notion (though short-sighted) to
simply switch a program to C++ or Objective-C and start
getting the benefits of OO right away, but does it work
so smoothly in practice?
Would some experienced hands out there tell us the
good, the bad, and the ugly about real experiences
migrating existing code to OO?
--dave yostpsrc@pegasus.ATT.COM (Paul S. R. Chisholm) (10/30/89)
In article <1530@esquire.UUCP>, yost@esquire.UUCP (David A. Yost) writes: > Now we raise the question: is it really a good idea to try to > migrate an existing program to OO or is it better (quicker, more > maintainable) in the long run to redesign from scratch in the new > language using OO design? (If the latter is true, then it is all > the more clear that there is no contest between a cleanly- designed > higher-level OO language and a compatible C extension.) Hmmm. This is one of my warm buttons (I'm too jaded to have *hot* buttons, okay?-) First of all, it seems like no one's ever proud of the code they maintain, not even if they wrote it. I'm maintaining fifteen to twenty thousand statements of C code that I didn't write. A friend of mine is responsible for a (very roughly) similar amount of software that he was called in to write two or three years ago. Each of has looked at what we've got, and what we're being asked to do, and has been overcome by the feeling that we could do a better job if we tossed it all and started fresh. I got over this urge by talking with one of the quality folks here. He related the story of how one program (in an organization with lots of time pressure) had been written by one person, and passed on to four successive maintainers. *Each* of the four had rewritten the code from scratch. Now, either at most one of the five was a competent programmer, or this "fresh start" business is maybe more egotism than real promise. (This is purely anecdotal evidence; I ought to ask the quality guy to study this more carefully, if possible.) Second, how far back are you going to go? My instinct would be to reverse engineer the (non-object-oriented) design from the code (you'll be able to re-assemble a lot of the low level stuff in your OO design), then reverse engineer the requirements from the design, and only then start doing a new design. But will you end up re-evaluating your requirements? Yeah, sure, that's a good thing to do, make the customers happier with the final product. But will you still be in that business (will your firm still be in business at all) when your perfect product finally ships? > --dave yost Paul S. R. Chisholm, AT&T Bell Laboratories att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
jwd@cbnewsc.ATT.COM (joseph.w.davison) (10/31/89)
In article <1530@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: >Consider the case of a large existing C program that is >being maintained and extended. Now one gets the idea >to migrate the program incrementally to an OO language. > >Here are some alternatives: > >I. Languages-by-C-extension, such as C++ or Objective-C: > > No muss, no fuss. Simply switch to the new > compiler, start using the OO features here and > there among the existing code, and before you know > it, presto! You have an OO program! > > (Seductive. But will you respect yourself in the > morning? You've bought into a language that put ... >II. Non-C-derived languages such as Eiffel: > > Link the existing C code with external code in > the new language. ... > B. Using a compatibly extended C: Why not use C++ or Objective C in THIS manner? They're already extended enough to define the classes you need. So, build a class EiffelObject and tie it to Eiffel... > >Now we raise the question: is it really a good idea >to try to migrate an existing program to OO or is it >better (quicker, more maintainable) in the long run >to redesign from scratch in the new language using OO >design? Well, It depends on how rich you are, and how long your customers are willing to wait. If the "Legacy" (the system that has been handed down and needs to be migrated) took 5000 Staffyears to get to where it is now, even if the answer to the question is obviously YES, it IS better, and it IS more maintainable. And even if your productivity enhancement in switching to GOODS (the Great OO Development System) is at least 10, the task may still be 500 StaffYears. OK, you're going to do even better -- take another factor of 10. Can you and your customer affort 50 Staffyears? (How about for systems 10X larger? 100X? ) I suspect that for LARGE systems one wants a hybrid approach, where one can identify subsystems that have not been changing much in recent times, and they can be left largely intact, using approach I where necessary. Other subsystems will have been changing much more rapidly. Those I would consider doing a full redesign, and use approach II to connect to the old system. If one considers the issue from an Analysis of Algorithms viewpoint, I think you will find that, just as in sorting, the optimal way to solve the problem depends on the size of the problem. > >It is an attractive notion (though short-sighted) to >simply switch a program to C++ or Objective-C and start >getting the benefits of OO right away, but does it work >so smoothly in practice? > Somehow, changing compilers doesn't seem like it's going to make major improvements... -- Joe Davison jwd@ihlts.att.com