Object-Oriented Programming (OOP) has been heralded as having the same impact upon computing software as the industrial revolution had upon manufacture. The "cobbler", "tailor" and other craftsmen will be made obsolete by the ability to mass manufacture software from reusable parts (objects). Great houses can be assembled quickly & easily from screws, nails, drywall, 2X4s, etc, when these parts need not be fabricated from scratch.

The demand for software applications of ever-increasing size & complexity has called into question the ability of top-down functional decomposition, centralized program control and massive databases to cope with these problems. Typically, these large systems become too complex for a single mind to master -- and they necessarily become untouchable when it becomes too difficult to make alterations without unpredictable & undesired side effects.

Using Object-Oriented design, problems are modeled not on the basis of data & functions (nouns & verbs), but as collaborating objects possessing both knowledge (data) and functionality. OO technology is focused on the products, rather than the tools, of production. Objects needing data or functionality can request these from other objects (a client/server relationship) by sending "messages". A complex system can be built from complex objects possessing simple interfaces.

A PC, for example, may connect to a mouse, keyboard, monitor, modem and printer. There are many means to implement these complex objects, but as long as there are simple & standardized interfaces, the complexity of the objects can be hidden (encapsulated). We interact with many objects in our lives (automobiles, elevators, televisions, washing machines, etc.) through simple interfaces -- often knowing little or nothing of the internals. Hiding data & functionality inside objects is called encapsulation, a key Object-Oriented concept. This form of modularity has great promise as an alternative to the functional modularity of procedural programming languages. Individual objects can be repaired, replaced or upgraded without compromising the rest of the system. Re-use is promoted.

The classic Object-Oriented Programming language is Smalltalk. Like APL, Smalltalk is interpreted rather than compiled -- and its interactive development environment is greatly appreciated. Like APL, Smalltalk has automatic memory management and minimal data-typing. Its pre-existing classes for creating dialog boxes, buttons and other such objects can make GUI programming easy & fun. Almost everything in Smalltalk is treated as an object, including what are data types in other languages. Integer & Float are subclasses of the Number class, which is (in turn) a subclass of the Magnitude class (along with Character and Date). File handling is done by objects instantiated in the Stream class. Methods (functions/operators) like "<" and "max" defined in the class Magnitude can be inherited by Character, Date and Float subclasses. The Smalltalk class structure seems almost as ambitious an attempt to classify knowledge as Roget's Thesaurus or the Dewey Decimal System. Rather than having to remember what utility libraries are available, you can inherit methods that are applicable to the objects you are using.

C++, by contrast, is a "hybrid" language, an attempt to add Object-Oriented capability to the procedural language "C". In fact, C++ was originally called "C with classes". Language-wars are not unheard-of in the OO community, and many a Smalltalk programmer will disparage C++ as being a "grotesque hybrid" that encourages "bad habits" (non-OO coding & design). C++ does not come with a pre-existing hierarchy of classes -- and such features as constructors & destructors (which automatically initialize & destroy objects) can make the building of such a hierarchy unwieldy.

The C++ use of pointers for memory management, declaration of strong data-types (float, double, long int, etc.), and erosion of encapsulation by public & "friend" class members undermines the OO focus on the problem domain rather than the machine domain. Pointers, by providing covert access to all of memory, can potentially compromise the integrity of encapsulation. Nonetheless, Smalltalk & APL programmers who deride C++ compilation, declaration and memory management have no grounds to complain about the slower execution speed of their interpreters. You can't have it both ways.

Smalltalk programmers often deride C++ because C++ provides OO features rather than enforces OO. Pascal enforces structured programming, but good programmers who understand structured programming principles do not use "GOTO" statements to write spaghetti code. Good APL programmers make limited use of branching -- there is no need to prohibit branching.

Although C++ makes it far too easy to violate OO principles, a determined & skilled programmer can use C++ to take advantage of many OO features. C++ advocates staunchly defend the freedom & power of their language, despite the bugs, housekeeping chores and potential abuse of OO principles that can go with that freedom & power. For projects where the problem domain corresponds to the machine domain, C++ has proven to be an excellent tool. 150 IBM developers worked as a team to develop a RISC version of AS/400 in C++.

Java is an OO language incorporating the best features of C++ and Smalltalk, and adding quite a few more. Although it is written in C++, Java eliminates pointer declaration and manual memory management, while incorporating a hierarchy of classes for GUIs & networking (especially Internet WEB networking). Java is multi-threaded, meaning that execution is modular and could occur on parallel processors. Built-in Java primitives handle thread synchronization.

Java code is compiled into a RISC 1-byte instruction code designed to run on a Virtual Machine interpreter that can be implemented on the most common hardware and operating systems -- an ideal situation for a Network Programming Language. The Virtual Machine even has the smarts to compile at run-time, rather than interpret, sections of code that run more efficiently when compiled. The major vendors have now agreed to include the Java Virtual Machine in their operating systems, so it will no longer be necessary to install the interpreter in local machines.

Bytecode Java programs (called applets) are compact, optimized and secured (with public key encryption), making them ideal as dynamically loadable objects on the Internet. A word-processor can download a spell-checker applet on the fly, without risk of a virus or a worm. OO gurus predict that the World Wide Web will establish Java as the predominant programming language in the coming decade.

Object-Oriented technology is most suited for large "systems" projects implemented by teams of programmers. But Smalltalk, C++ and Java are lousy as Array-Processing Languages. If your objective is to build systems (especially computer systems) or GUI applications, then an Array Processing Language is probably not the best choice.

Robert Brown is working to implement an Object-Oriented APL patterned after C++ and Eiffel. Like C++, his OO-APL would be a "hybrid": APL2 with added OO functionality. C++ has been heartily denounced for its complexity & difficulty of mastery -- and denounced as a language that makes it too easy to mix procedural & OO programming. I can only imagine that an OO-APL would amplify these problems an order of magnitude. APL is not nearly as standardized as C, has only recently begun using control structures and offers the programmer a multiplicity of means for achieving the same ends. Functional arrays may provide a tool for simulating OO programming, for example, but there would be no true instantiation, classes or inheritance. APL has never been a language of choice for teams of programmers, and it is unlikely that OO-APL will change this.

As an example justifying the use of OO-APL, one could define a class of object called BOND. Objects, unlike data-types, have functionality (methods in OO terminology) as well as data. Subclasses of BOND could be Spanish Bonds, Italian Bonds, etc., each one having its own unique features & pricing methods. A vector of BOND objects could be placed in a variable called "BUNCHOFBONDS". A new APL primitive "_@" can be created that joins methods with objects. "BUNCHOFBONDS_@MATURITY" would tell all the BONDs in the vector to send their maturity date.

"MATURITY" isn't really a function (or method), it is the name of a function or method sent as a "message" to each of the BOND objects. The message corresponds to the method, which may be different for each BOND object, but which nonetheless results in the maturity date being returned in a uniform format. Messages can also be sent with arguments, and a single method name may actually correspond to a number of different methods. The method used will depend entirely on the number of arguments and the data-type of those arguments -- a key OO feature known as overloading.

The "PRICE" message could be sent in the form "+_/BUNCHOFBONDS@PRICE" which causes all of the bonds to price themselves by their own price methods, and these prices are then plus-reduced. Functional programmers, by contrast, would have to resort to a huge function (or a control function) which priced the different subclasses of BONDS by some kind of case mechanism. Such a function would likely be complicated and error-prone, less modular than objects which can handle their own functionality. New BOND subclasses can be added, deleted and modified with no impact on other BOND subclasses.

APL is a language of individualists (craftsmen!) who do not readily become cogs in a huge team "machine". OO-APL may not succeed in bringing APL into the "mainstream", but it does offer great potential for talented APL programmers. If powerful objects written in APL can interact with objects written in other languages through simple interfaces, the encapsulation of the language & functional internals of those objects may be of little concern to others. The objects would be judged by their utility, not by the language they were written-in.

Why APL?

APL Resources

HOME PAGE