OOF – A New Programming Metaphor


The “OOF” or “Object-Oriented Fail” family of languages is intended to deliver reliable, deterministic, 100% failure rates to public institutions seeking to implement social programs to increase nationwide stress, eliminate all disposable income of and decrease the average quality-of-life for all members of the middle class.


In the past, OO languages have been forced to choose between single- and multiple-inheritance models. OOF languages, however, dispense with this model by introducing the concept of “half inheritance”: derived classes will inherit precisely half of the properties of their base classes, selected by a pseudorandom number generator at runtime. This ensures that no defined class can be represented as a directed acyclic graph or UML model. By choosing the revolutionary half-inheritance model, all “design-up-front” development methodologies will be rendered instantly obsolete.


Instead of employing memory management, OOF languages must, in the initialization routine of the garbage injector, use operating system calls to allocate and pre-initialize the largest block of free heap available. Access to objects and variables must be aligned on “n”-byte boundaries, where “n” represents the current day of the month. This will provide consistency in the number of available variables and/or objects in a given program on a given day. Programmers should take care to design their usage of variables and objects with the lowest day-number of any given month in mind. All access to heap memory is through pointers in the code segment, which are to be managed by the garbage injector.


The garbage injector’s prime responsibility is to modify the addresses of all such aforementioned pointers using the same runtime pseudorandom number generator as used by the half-inheritance system. Data pointed to will be copied from its original location to its new location in ascending order. No mechanism is provided to examine the usage of the new location prior to overwriting its data with the result of the pending copy operation. This mandatory operation will run during idle CPU cycles, and result in a consistently inconsistent execution environment for all system and user programs.


The garbage collector will address the inconsistencies of the OOF program’s execution environment, as ensured by the garbage injector. Its operation is simple: any access to variables or objects will trigger a call into system BIOS routines which will reboot the entire computer, thus eliminating any inconsistencies in the program’s state, and indeed, the program’s ability to store and retrieve state at all.


We recommend that the runtime library for any OOF language be web-enabled in such a manner as to crash or otherwise disable the end user’s web user agent when any request is made for an OOF program or subroutine. Ideally, this disabling mechanism should also initiate a low-level format of the user’s fixed storage devices. It is recommended that any government implementation of an OOF system be paired with extensive subsidies for large computer repair establishments, such as The Geek Squad. This will provide ┬ámaximal economic benefit to all.

Tried Solutions are not Tired Solutions

This article provides a great argument to why a tried-and-tested database like the one provided in GT.M is a better solution than the trendy, buzzword-compliant, Johnny-come-lately industry darling of the day. If a social networking package finds MongoDB’s consistency problems unacceptable, imagine the disaster lurking for its use in the kinds of apps currently being supported with MUMPS databases! Also, the problems inherent in querying these kinds of databases for any but the most simple set of predicates is barely even covered.

While one could argue that MUMPS suffers from a lack of sex appeal that keeps it a little-known and oft-ridiculed language, let’s remember that the resilience of our flagship VistA–in spite of its mother agency’s constant and concerted efforts to kill it–is in large part due to the small and dedicated community that has built up around supporting and improving it. Perhaps we should entertain the idea that a smaller, more focused community of good people is better for our language and its applications than a large and well-known group, which would invariably be fated to follow the unstable and expensive path dictated by the wiles of a fickle and short-sighted industry.

Long story short, we should focus on improving the existing MUMPS language and database, and be extremely careful to avoid being distracted by the lure of bright, shiny objects. There are no silver bullets, and anything that sounds too good to be true probably is.