Agreed. Some definitions are really bad. I guess the cause is noble but it is executed very poorly. ( The definition of functional is also used nowhere in the d

Agreed. Some definitions are really bad. I guess the cause is noble but it is executed very poorly. ( The definition of functional is also used nowhere in the document - Although it is mentioned. ) Another oddity: "Object oriented" programs are defined as functions {0,...,n} -> O where O is "a set of objects". Yet: A program is defined to be an endo-relation S<->S. Accordingly, we have O = {0,...,n}. I don't see how this definition gives any insight on the nature of object oriented programming. Now for the strangest thing: The definitions of "object oriented" and "procedural" involve differentiating between possible condidates for S. Yet the only property a set without any context really has is its cardinality. So we can rephrase the definitions of "object oriented" as follows: An "object oriented" program is a set S together with a total function S -> S with S finite. ([total function] AND [S finite]) Negating, we arrive at the definition of "procedural program": A "procedural" program is either a relation S <-> S that is not a total function (no restrictions on the cardinality of S) OR any relation S<->S but S must be infinite. ([not a total function] OR [not S finite]) I don't see how this definition captures the notions of object oriented programming and procedural programming in any meaningful way. But maybe the author will appear here and to clarify his ideas.