Computer programming is an activity that lies at the\nintersection of epistemology and engineering. \nThe process of reducing a desired set of actions by a computer to the\nrigid set of instructions that can be directly executed by physical hardware\nrequires a clarity of expression that can only be attained in a properly\nstructured, logical language. The\nhistory of programming languages has consisted largely of the advancement of\nthese methods of expression toward an accurate model of human epistemology,\nwith only a handful of tributary paths leading to apparent dead ends when they\nstrayed too far from how human beings actually think. However, in the latest round of language\ndevelopment, I believe we are seeing the entry of an alternative philosophy of\nthought that can only lead to a weakening of a programmer\u2019s ability to attain a\nclear vision of what they are trying to create.<\/p>\n\n\n\n
The earliest programming languages \u2013 COBOL, FORTRAN, BASIC, C,\nand many others \u2013 were capable of expressing the four fundamental operations of\ninformation flow: assignment of data to named memory locations (variables),\niteration (loops), conditional branching (if\u2026then\u2026else), and, in their more\nadvanced forms, function definitions (named subsequences of instructions). In these primitive languages, each statement\nwas a representation of concrete knowledge, with the only level of abstraction\nconsisting of parameterized subsequences, or functions. In a very loose sense, this might be\nanalogous to a representation of an animal\u2019s epistemology. This isn\u2019t to say these languages were not an\nadvancement of technology \u2013 to the contrary, they brought the capability of\ntranslating internal states of the electronic computer into a language that\ncould be read and manipulated by humans, allowing a dramatic improvement in\nprogramming efficiency.<\/p>\n\n\n\n
However, as the desired capabilities of software systems\nincreased, the inherent inefficiency of concrete-bound languages often led\ndevelopers into increasingly complex code structures. Without rigidly following self-imposed\ndevelopment guidelines, the resulting code could easily become nearly\nimpossible to understand, even to the original author of the software. Although such a situation can arise in any\nprogramming language without proper design discipline, documentation, and\ncareful planning, the inability to express a proper level of abstraction in the\nconcrete-bound programming languages made any approach to controlling the\ndevelopment of large-scale projects extremely difficult to maintain.<\/p>\n\n\n\n
Starting in the 1980s a fundamentally new approach to\nlarge-scale software engineering emerged, object-oriented programming. When used properly, the object-oriented\nframework for expressing the organization of information, its internal\nstructures, interrelationships, and mechanisms of flow, can very accurately\nrepresent a model of human organization of thought. Human thought is fundamentally based upon the\nidentification and manipulation of concepts. \nIn object-oriented programming, concepts are represented by classes, which\ncombine the abstract definition of data contained in a group of similar\nconcrete objects, or instances of the class, with the operations the software\ncan perform on these data members of the class. \n<\/p>\n\n\n\n
This closely parallels an epistemological model of human\nthought in which concrete objects are represented as instances of\nconcepts. Concrete objects in this sense\nmean any form of existent or potentially existent object, which includes not\nonly physical objects, but things which are abstractions in themselves as well. A concept contains all of the essential\nattributes shared by a set of concrete objects, with the values, or\nmeasurements, of these attributes removed. \nAn instance of the concept is then considered in the human mind with the\nvalues set to match those of the object being recalled. The use of conceptual reasoning dramatically\nreduces the complexity of our mental interaction with the world by avoiding the\nneed to retain all of the specific attributes of each object encountered and\ntreat each of them as unrelated to all other similar objects. We are thereby enabled to consider the\ninterrelationships between concepts as a whole, instead of working directly\nwith interrelationships of all of the objects these concepts represent. Simply\nreplacing the word \u201cconcept\u201d with \u201cclass\u201d in the above description accurately\ndescribes the base structure of an object-oriented programming methodology, and\nindicates the power of expression possible in such a language. <\/p>\n\n\n\n
Two specific forms of relationship between concepts are\ndirectly represented in the object-oriented languages. The attributes of a class can themselves be\nobjects of other classes \u2013 hence the concept wheel is an attribute of the\nconcept car, as a car has wheels, and a wheel itself is a bundle of additional\nattributes \u2013 radius, width, hub, tire and so on. In the object-oriented terminology, this is\nreferred to as a \u201chas-a\u201d relationship (a car has a wheel). <\/p>\n\n\n\n
A more powerful form of relationship is the abstraction of\ngroups of concepts and classes into even more general concepts in parent-child\nstructures. Thus cars, trucks, and\nbusses are all ground vehicles, and ground vehicles can be considered as their\nparent concept. Separately, airplanes\nand helicopters are children of the aircraft concept, and supertankers and\nyachts children of the boat concept. \nIndividual attributes that are common among the child concepts \u2013 such as\nwheel in the case of ground vehicles \u2013 exist in the parent concept and are\ninherited into the child concepts. Going\nfurther with our example, ground vehicles, aircraft and boats are all children\nof the transportation vehicle concept. \nThese are \u201cis-a\u201d relationships in the terminology of object-oriented\nsoftware design \u2013 a car is a ground vehicle, which is a transportation vehicle.<\/p>\n\n\n\n
A final key component in the object-oriented approach to\nmodeling knowledge is control over access to the defining aspects of\nclasses. Access to attributes of a class\ncan be open to all other classes, available only to child classes of a class,\nor completely hidden and manipulated only through the use of various functions\ndefined in the class. This again is a\ngood representation of how information may be exchanged between conceptually\nseparable elements of the real world, where the internal state of an object may\nonly be ascertained through specific interfaces or appearances.<\/p>\n\n\n\n
Despite the great success of fully object-oriented\nlanguages, they do require a certain discipline to be followed in order to be\nproperly expressive and best match human epistemology. Unfortunately, the most recently developed\nlanguages have begun to turn away from these disciplined principles, doing so\nin the name of freedom of expression, and ease of learning the language. I believe reducing the structured discipline\nmay allow short term gains, but can only result in an illusion of simplicity\nthat will lead to a disastrous increase in complexity, and return us to systems\nof software that cannot be understood by either other developers, or the\noriginal authors.<\/p>\n\n\n\n
The Python language is now the dominant language in use in\nacademia and most scientific research endeavors. Although it is nominally an object-oriented\nlanguage, it includes some major simplifications, the most serious of which is\nthe \u201cfreedom\u201d from needing to declare the class of variables that are used\nbefore using them, and instead inferring their type from the assignments made\nto them. Declaration of the class of an\nobject before assigning to it is not even an option in Python. Furthermore, a single variable can be reused\nin the same section of code to represent objects of different classes, as long\nas when the variable is used in a function call or assignment statement it is\nof the expected class at the time the statement is made. Further eroding the object-oriented formalism,\neven the attributes of a class are not defined when the class is defined, but can\nbe created at any time by code either inside or outside of the class.<\/p>\n\n\n\n
Although Python is depicted as an object-oriented language,\nand allows the use of classes and inheritance to organize its structure, a\nclose look at how this is done in the Python language reveals that the\nobject-oriented framework is only an illusion in this language. When working inside a class, the class\nattributes cannot be directly accessed, but rather must be designated by\nstating \u201cthis\u201d as the object containing the attribute to be accessed. Stranger still, each function defined in the\nclass must have a first parameter called \u201cthis\u201d with which to pass the object\nitself to the function, even though when the function is actually called, that\nparameter need not be explicitly listed. \nThese oddities strongly suggest that the language is only \u201cfaking\u201d its\nobject-oriented expression and is, at its base, a completely unstructured\nmorass of data storage and instruction sequences.<\/p>\n\n\n\n
Each of these simplifications or freedoms severely\nundermines the relationship between knowledge expression in the programming\nlanguage and the proper functioning of human epistemology. That nothing needs definition before its use,\nor equivalently, that its use completely defines its meaning, is an empiricist,\nand ultimately existentialist viewpoint of knowledge. Existentialism in philosophy leads to a\nconclusion that the world cannot be understood because there is no meaning to\nbe found. This is the source of the\n\u201cnausea\u201d of Sartre accurately names as he attempts to face the world through\nthis interpretation. Is this really how\nwe want to be designing software?<\/p>\n","protected":false},"excerpt":{"rendered":"
Computer programming is an activity that lies at the intersection of epistemology and engineering. The process of reducing a desired set of actions by a computer to the rigid set of instructions that can be directly executed by physical hardware requires a clarity of expression<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-227","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/posts\/227","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/comments?post=227"}],"version-history":[{"count":1,"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/posts\/227\/revisions"}],"predecessor-version":[{"id":228,"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/posts\/227\/revisions\/228"}],"wp:attachment":[{"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/media?parent=227"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/categories?post=227"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/nutmegfamilies.com\/aaronnturner\/index.php\/wp-json\/wp\/v2\/tags?post=227"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}