Smalltalk, C++, and OO COBOL: The Good, the Bad, and the Ugly

Reader Comments - feel free to add some of your own

The ANSI X3H7 Object Information Management Technical Committee has been evaluating the relative merits of object models since its inception in 1991. After working on object database systems built in C++ from 1986-93, I now work for a Smalltalk company supporting development of MIS business applications. The relative merits of Smalltalk versus C++ are being brought into stark relief as my Enfin Smalltalk development team launches a new products for design, assembly, and reuse of business objects.

Recently, Micro Focus announced an object-oriented COBOL product for release in mid-1994. We need to integrate Smalltalk with both C++ and COBOL applications, so I recently took a close look at OO COBOL. The ANSI X3H7 Technical Committee maintains a liaison with X3J4, the OO COBOL Technical Committee and Micro Focus has been a driving force on building consensus for the emerging OO COBOL standard. It is interesting to compare the anticipated merits of OO COBOL with Smalltalk and C++.

Memory Management Can Impact Programmer Productivity

Although the emerging ANSI standards for both OO COBOL and Smalltalk support garbage collection, the first release of Micro Focus OO COBOL will not include it. Support of garbage collection is a major difference between higher level object-oriented languages and C++. It is one of several reasons commercial MIS developers have had limited success with C++:

· Without garbage collection the application programmer has to ensure unused object are deleted or the system can run out of memory and crash. This is like handing a COBOL programmer a loaded gun with the safety off.

· COBOL programmers have never heard of memory leaks, a related issue. This occurs when parts of memory are no longer used by the program but the program does not know how to reclaim the memory space. Its like giving a COBOL programmer a water bucket with holes in it.

· C++ was designed to be a better C. Those of us who have been around long enough to remember when C was born know that C was designed to replace assembly language. C++ is object-oriented assembly language and is good for building systems code, but too low level for application programmers to be as productive as Smalltalk or OO COBOL.

· C++ is significantly more complex than C and C was already hard for COBOL programmers to learn. Take a COBOL programmer who is being retrained in C++ out to lunch and you will get an earful about this. Experience with Smalltalk suggests an easier learning curve and the OO COBOL standard has a lot of similarities to Smalltalk. Their learning curves will be about the same for a new programmer.

Performance Differences Between Languages

Bjarne Stroustrup designed C++ to be able to perform as well as C. As a result, many people assume that this performance is easily attainable. A recent article in C++ Report pointed out that the average C++ program written by new C++ programmer runs only about half as fast as the same C program. It takes optimization skill to get it to run 80% as fast and see and only real C++ experts can achieve 95% of C performance. In addition, performance is gained at the expense of introducing complexity into the code, the kind of complexity that should be avoided by application programmers.

A good Smalltalk programmer will produce an object-oriented program that will run as fast as the average C++ program. We occassionally use C++ to optimize pieces of a few Smalltalk programs, but we've learned that the average C++ programmer can't do it efficiently. It takes a C++ expert to tune Smalltalk to get any significant performance benefit.

· To get the performance of C, C++ requires the programmer to understand the use of pointers. This means a programmer can control the allocation and use of memory anywhere in the machine. This includes the ability to overwrite data that is already in use causing the system to unexpectedly crash, an undesirable feature to provide an application programmer.

· COBOL already runs slower than C and the first release of Micro Focus OO COBOL will run significantly slower than regular COBOL because, like Smalltalk, all binding is dynamic. Early implementations of OO COBOL compilers will probably not produce code as efficient as Smalltalk because Smalltalk environments have been repeatedly optimized for more than 20 years. ANSI OO COBOL will support both static and dynamic binding like C++.

Dynamic Binding is Better for Application Programs

Smalltalk is pure object-oriented environment with dynamic binding. This is one of the elements that makes Smalltalk a very rapid development environment, much faster than C++. Smalltalk is also both an interpretive and compiled language, whereas OO COBOL is a compiled language. The flexibility of Smalltalk makes it an ideal language for business applications that are subject to repeated change as the enterprise re-engineers itself. OO COBOL will be more flexible than C++, but less flexible than Smalltalk.

· Smalltalk will select methods to fire at run time based on object type. This dynamic binding enables polymorphism, or the ability to send different objects the same message and let the objects figure out how best to handle it. OO COBOL supports dynamic binding.

· By default, C++ has only static binding. Declaring virtual functions in C++ provides partial support for dynamic binding with a performance penalty. Furthermore, the ability to specify method parameter types at runtime requires using C++ templates. "... Templates are a step beyond the current linker and environmental tools technology," causing problems for the C++ expert that are quite beyond the capabilities of the average application programmer.

Upward Compatibility Can Be a Negative as Well as a Positive

A major feature of OO COBOL is that it is compatible with old COBOL programs.

· Any conventional COBOL program will run in an OO COBOL environment. This will make OO COBOL easy to adopt by COBOL programmers because they don't have to learn anything new or do anything different. Some say this shortens the learning curve. Others say it prevents programmers from learning how to build good object-oriented programs, thus lengthening the learning curve and not allowing them to achieve the real benefits of object technology.

· C++ is compatible with C programs and 80% of the C++ code now being written is really C in disguise. Reusability of C code is only 15% on the average. This means most of the gains in productivity achievable by object technology are not seen in most of the C++ code being written. The situation could be even worse with OO COBOL programmers.

· OO COBOL and C++ are hybrid languages that make acceptance of the language easier at the cost of losing over 80% of the benefits of object technology.

Multiple Inheritance is a Red Herring

There are several other issues of importance to object-oriented developers. One of the red herrings in the object technology community is multiple inheritance. This is supported by C++ and OO COBOL, but not by Smalltalk. The primary benefit of multiple inheritance is to allow an object to inherit attribute and methods from multiple parent objects.

Business applications need more than multiple inheritance. They need objects to be able to change type dynamically without having to make copies of the object. None of the object-oriented languages support this. The flexibility of the Smalltalk environment supports implementation of roles. Roles allow an object to have multiple types and to change type dynamically in the runtime environment. Since the flexibility of Smalltalk more than compensates for the lack of multiple inheritance, I don't view this feature as a differentiator between these languages for MIS applications.

Availability of Class Schemas at Runtime Provides Flexibility

The ability of Smalltalk to support dynamic type changes at runtime is a benefit that will be supported in OO COBOL. This is a major deficit of C++, which loses all knowledge of class definitions at compile time. The feature is essential for modifying classes by changing attributes during normal processing.

Portability is Important

Smalltalk is considerably more portable than C++ because C++ has some nasty hidden features that inhibit portability. For example, a single change of a private data member in a C++ operating system can cause every application using the operating system to have to be recompiled. OO COBOL portability will probably be less than Smalltalk but better than C++.

Class Libraries Are Not Part of the OO COBOL or C++ Standards

Smalltalk does a much better job of supporting class libraries. In fact it consists of a large class library. The ANSI C++ standard does not support any class libraries. Neither does ANSI OO COBOL.

Class libraries impact portability. A Borland C++ application using Borland's OWL classes cannot be ported into a Microsoft C++ Foundation Class environment without major rework. To get portability across C++ compiler environments will require standardizing class libraries. The ANSI X3J20 Smalltalk committee is standardizing Smalltalk class libraries so that Smalltalk applications can be portable across ANSI compliant Smalltalk environments.

The Bottom Line

So what is the bottom line on C++ versus OO COBOL versus Smalltalk for MIS applications development? The tables below shows my ratings. One is good, three is bad, and two is ugly. Remember these numbers are for MIS applications, not for systems level programming.

                                                 C++      OO COBOL   Smalltalk 

Flexibility         Dynamic Binding                2             2           1 

                    Dynamic Classes                3             1           1 

                    Multiple inheritance           2             2           3 

                    Support Roles                  3             3           2 



Ease of use         Class libraries                3             3           1 

                    Learning Curve                 2             1           1 

                    Speed of development           3             2           1 

                    Portability                    3             3           1 



Support             Tools                          1             3           1 

                    Multiple vendors               1             3           2 



Performance         Performance                   1*             3           2 



                    Garbage collection             3           1**           1 

Minimizing Risk     No memory leaks                3             1           1 

                    No overwriting memory          3             1           1