Oo Lacks Math Argument

The argument that object-oriented programming lacks a mathematical foundation. This is often contrasted with relational database theory, which has a solid theoretical foundation in the RelationalAlgebra of SetTheory.

While it's true that OO arose out of pragmatic rather than theoretical concerns, several formalisms have since arisen. Here are some Wiki pages that deal with the subject:

The following series appeared in the Journal of Object Technology, and describes a mathematical formalism based on type introduction rules: Also, it's well-known that ClosuresAndObjectsAreEquivalent. [note- no, it's neither well-known nor agreed upon] And closures have a solid basis in the lambda calculus, that can then be translated to object terms.

A better name for this page might be OoLacksUsefulMath?. After all, there might be a "goto math" (there is: DenotationalSemantics using ContinuationPassingStyle), but that does not necessarily mean gotos are easier to work with. For example, I don't see math bringing more consistency to OO design. Relational "math" is actually used in practice by most practitioners. None of the above is actually commonly used in practice. The above also seems to depend on heavy belief in subtyping as a useful modeling technique. In theory one can define things as subtypes, however, in practice it can be messy. See ThereAreNoTypes. Perhaps some of the above should be moved there.

> None of the above is actually commonly used in practice. That is not a fault of the maths but of those who choose not to use it. Why computing is the only engineering discipline that actively resists basic maths and theory is beyond me.

{{In any case, this math is used in the design of (some) programming languages.}}

Yes, but not by the application developer. They are just stringing objects/classes together like a map-based mobile with no known/constistent pattern or rules. Relational tables are a higher-level, larger-scale concept than maps (ObjectsAreDictionaries) and must follow certain rules of structure and access. At best OO has developer-specific conventions. There is no accepted "map math" that OO users must adhere too. The fancy underpinnings of such a language are not providing rules for the developer to follow, at least not without being a subset of OO. But a subset would probably be called something besides "OO" anyhow.

Math based on OO being about "types" (if you subscribe to such definitions) perhaps should be moved to DefinitionsOfTypesInPublications or ThereAreNoTypes.

Note that this topic used to be a very long, heated discussion. However, it was removed for whatever reason. Feel free to search the archives if you are interested. [insert link to archives when found]

This whole debate, of course, is a MisuseOfMath. TopMind has engaged in quite a bit of argument about how the mathematical foundations of TypeTheory are little more than a UsefulLie (as many RealWorld problems don't map to it well), therefore its applications to programming are questionable (numerous languages out there exist that seemingly pay scant attention to it). Of course, much of the same thing can be said to claims that the RelationalModel is superior to OO on the grounds that the RM has an agreed-upon mathematical formalization. What's sauce for the goose is sauce for the gander, after all.

I have since recanted my "OO lacks math" claim, as explained in MisuseOfMath. Further, this is about OO, not type-theory. The two have not been connected yet because dynamic OO languages such as SmallTalk have not been shown covered by it.

For example, in a dynamic OO language two different classes/objects may have "x" and "y" attributes, among others. They can both serve as a 2D "coordinate" type (a "coordinate" Interface perhaps in Java), and the other attributes perhaps be used for other purposes or "types" also. However, there is nothing in the language itself that enforces or cares about coordinates. It is purely a programmer convention. It is too ad-hoc to be connected to any formal type theory unless you can find a way to accurately model people's heads. Remember, MostHolyWarsTiedToPsychology.

-- top

The referenced papers almost appear as if somebody is defining an OOP/type "engine" using set theory. It is thus not much different than RunTimeEngineSchema. I am just doing it using computer terms instead of math notation. Otherwise, sets is sets. Just because you can define a type engine via sets does not necessarily mean it is "good". See MisuseOfMath. -- top

See also: CriteriaForGoodMathOrCompactNotation, OoLacksConsistencyDiscussion, IsProgrammingMath, ProgrammingIsMath, SqlFlaws.

EditText of this page (last edited November 22, 2014) or FindPage with title or text search