OOPC
Through clever use of macros and function calls, OOPC provides C programmers with a highly flexible, fully dynamic, object-oriented development system. OOPC’s object-oriented features read like a wish list. As a development toolkit, OOPC is a full-bodied powerhouse. ~ American programmer Mark Gerl
In 1992, a tiny company called Electron Mining (1991–1994) released OOPC: a revolutionary product that failed to spark a revolution. OOPC was a cross-platform software development kit that greatly accelerated application development by dint of the language in which the framework was written.
The initial release of OOPC was for the Macintosh. Development for a Windows version began, but the company went under and the Windows version was never released.
OOPC was an object-oriented extension to the C language inspired by CLOS. CLOS – the Common Lisp Object System – was the object-oriented extension to Lisp.
Lisp was specified in 1958 as a practical mathematical notation for computer programs. As a high-level language, only Fortran is older (1957).
Lisp isn’t a language; it’s a building material. ~ Alan Kay
Lisp quickly became the favored language for artificial intelligence (AI) research, and pioneered many ideas, including tree structures, automatic storage management, and recursion (the ability of a behavior to repeatedly call itself).
Lisp has jokingly been called “the most intelligent way to misuse a computer.” I think that description is a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts. ~ Edsger Dijkstra
Common Lisp got its start in 1981. A syntax extension to Lisp, CLOS offered great flexibility with data structures and manipulation. Behaviors could be treated as objects.
OOPC was CLOS in C clothing, without the dross of C++. Further, with its inherent simplicity, OOPC offered elasticity without the syntactic complexity of Lisp.
OOPC began in 1987 as a language suited for AI programming. Those inclinations were accommodated by its open-ended nature. The distinction between classes and objects was largely arbitrary, as classes might have their own data, and objects could have their own behaviors.
Further, OOPC offered a dynamic flexibility unheard-of in other C-based OOP languages. The behaviors of classes or objects could be changed as a program ran.
Multiple inheritance is the concept of a class or object inheriting methods from multiple superclasses. Multiple inheritance was accommodated in OOPC by simply listing sequentially the priority order of inheritance. In contrast, C++ made multiple inheritance an invitation to confusion, giving this extremely helpful ability a bad reputation.
Overriding a superclass behavior in C++ meant that the subclass method lost the functionality that the superclass offered. This badly complicated code reuse.
With OOPC, simply setting a flag let a subclass behavior override, precede, or follow superclass functionality: hence subclasses could judiciously specialize or augment behaviors.
By employing a strict polymorphism, OOPC allowed the full benefit of inheritance without the disadvantages inherent in C++. For example, any object could be drawn within a window via draw(object). This greatly simplified the API. To display any object, all a programmer had to do was write draw(object). But even that was unnecessary, as the built-in OOPC library provided for a functioning document-based application in only 2 simple lines of code.
That economy freed up a program developer’s effort to focus solely on the features needed for the specific application. It was easy to create robust programs in OOPC because defenses were built-in to preclude bugs (software defects).
A common error in software to this day is reading an awry location in memory by looking in an array at an index that is not legitimate. Worse is corrupting memory by writing to such an out-of-bounds location.
C and C++ programs can easily read/write memory out of bounds. Using an OOPC array object (or any object that inherited array functionality), that error was impossible.
Another ubiquitous software problem involves memory leaks: using memory temporarily, but never releasing it so that the memory can be reused. Microsoft Windows and its Office suite of applications have historically been sieves of memory leaks – a problem that has only lessened somewhat, not been eliminated, in Microsoft software.
OOPC had automatic garbage collection that precluded memory leaks. Further, OOPC’s memory management worked many orders of magnitude faster than either the Macintosh or Windows OS ever have, as the programmers at those companies never bothered to develop an efficient algorithm for object-oriented memory management, which invariably involves a multitude of memory allocations in small chunks.
Apple Computer learned of OOPC at a developer trade show of theirs in 1992. Rather than express interest in the technology, which was far superior to their own, the company simply banned Electron Mining from having a booth at future Apple developer conferences. Apple offered an ersatz competing product in Pascal called MacApp.
Electron Mining knew it was in trouble when a matter-of-fact article describing OOPC in MacTech, the Macintosh developers’ magazine, was met by readers with disbelief that such programming capability was even possible.
Microsoft was given a presentation of OOPC technology in 1993, to a room of uncomprehending engineers. These muddled men were unable to grasp the elegance of OOPC because they had been brainwashed by C++ constructs, the language which Microsoft had already adopted as its standard. (Even now, most of the problems with Microsoft’s Windows OS can be attributed to it being coded in C++, as well as the skill of the programmers involved.)
In the 1st decade of the 21st century, OOPC’s developer advanced the technology under the name of Silon. Silon solved many of the problems associated with software today, including providing a robust OS, impervious to malware; a consistent GUI among all applications; rapid application development through effortless code reuse; and an end to spam email. These are desired goals which no operating system vendor – Microsoft, Apple, and Google, most notably – has even come close to solving.
Microsoft, Apple, IBM, Google, Amazon, and Sony, among other companies, were offered Silon technology. But none of these arrogant corporations had the good sense to take an interest. Belying their commercial success, the corporate cream of the software crop lack core competency at the technical level.
