Friday, November 2, 2018

Arotars in Cyberspace

The basic problem of software engineering is the creation of a computer system which solves some human problem. But the satisfaction of a human problem cannot be reduced in a straightforward way but instead forces a designer to solve many problems in parallel which ofter are in contradiction or interaction with each other. This is a design challenge and has not yet given us a linear way to perform software engineering that at once ensures logical perfection (is functionally correct) while also satisfying what are called emergent properties. This essay begins to layout the structure by which I am approaching this engineering challenge to make it tractable through a series of essays that I hope will coalesce into a book which puts a human face on the role of software engineering in human society.

The Role of Functional Engineering
We have not yet achieved technical perfection in the realm of functional engineering but we have made huge strides in the past few decades in engineering and the education of software engineers. A banking system ensures balanced books and accurate balances for the customers. A hydro-electric plant operating system will ensure safe and efficient operation of the many complex components of the system. But as computer software is the manipulation of abstractions of the real world which only later are transduced into reality, the primary task is one of model building.

The marvel of the modern computer is that of the blazing fast logic circuits that reduce even complex computation into tractable solutions. The process of programming is the reduction of the physical problems into abstract mathematical models, which after all are nothing but logical models of the real world. If the model represents a useful homomorphism to the real world, the manipulation of those abstractions through logical operations will give us control over the physical universe that solves the human problem. In the vocabulary of object oriented programming and design, we create objects for computation that model the real world. We are creating cyber models for the real world.

Software Qualities


The Linguistics of Computer Communication


The Differences Between Human Processes and Machine Processes



Merriam-Webster define avatar as the incarnation of a Hindu deity in human form. This basic definition is extended to mean any concept embodied in human form such as the avatar of charity and concern for the poor, for example. The cyber models we construct are similar to yet the inverse of this definition of avatar since those avatars are physical manifestations of abstract beings. The word seems to have no prior and accepted antonym.

Word origin and history: 1784, "descent of a Hindu deity," from Sanskrit avatarana "descent" (of a deity to the earth in incarnate form), from ava-"down" + base of tarati "(he) crosses over," from PIE root *tere- "to cross over" (see through). In computer use, it seems to trace to the novel "Snowcrash" (1992) by Neal Stephenson. If my understanding of Sanscrit is correct, the opposite of ava- would be aro-. So I backform a noun, arotar to be something from the physical world lifted into the otherworld, in this case cyberspace.

I suggest that the process of software engineering is the construction of these arotars and the success or failure of the complete computer system depends upon the accuracy of this transduction between the real and cyber world.

I want to also suggest that there is reason to go back to a philosophical debate raised by Descartes in his conception of dualism. For sometime we have comfortably accepted the mind as a physical device no different from any other device in our physical universe. Yet the dominance of social constructs in our lives gives us as many objects of an abstract nature as we have in the physical universe, allowing for the abstractions we subject our universe to in making it comprehensible. After all, by the very nature of our brain we cannot comprehend all the grains of sand but subject them to collective nouns which are abstractions of the multitude of individual grains. These social constructs result in some avatars which inhabit our physical universe such as currency which is an avatar for money. But in computer systems these objects are mere informational objects whose representation is almost infinitely mutable so long as we have an agreement about that translation from one form to another. Just as we can exchange currency, we can pour cyber objects from one object into another.

The way we build software models is with the use of specialized languages which we hope are unambiguous and useful for the task of building these models. They must allow us to build structures (nouns) and processes (verbs) and then weave these together into ensembles that will collectively solve a problem in cyberspace that hopefully maintains its correspondence to the human problem in the real world. This parallel operation has such a strong similarity to the substance of mind that Descartes spoke of I question whether we must completely reject dualism as a practical matter and instead admit of a cyberspace that is a stand in for what Descartes may have meant were he familiar with modernity. So I use this as a starting point to explore an alternate way of conceptualizing the software engineering process, if only as a thought experiment. Let's make a leap and think of cyberspace as some alternative universe that is in parallel with our own and intersects through a collection of avatars and arotars that come into existence, cross over that barrier and cease to exist. Does this buy us anything in our understanding of the place and use of computer technology as it is experienced by human beings?

You can take most any major corporation today that does business with customers and you see arotars. They interact with us not as individuals but as cyber entities. It is not our actual attributes they see but the attributes that have been set in those cyber objects in their databases. Anyone who has had problems with identify theft fully understands the implications this has in our lives. It is not the reality of our lives that controls their interaction with us but their belief about us that is formed by their databases. Once those databases have been corrupted, the responsibility falls to us to struggle to bring correspondence back between the arotar and our reality, often at great expense to ourselves. For the corporation, the arotar IS the human being.

This concept has been fairly well explored in science fiction as was suggested by the definition above which used avatar to represent the "embodiment" of the real in the cyber. This was also repeated in the movie of that name. But I am choosing to make a distinction between the physical brought into the cyberspace, what I am calling arotar, with the more traditional understanding of avatar which would be the physical embodiment of some abstract cyber object into our physical and social lives. But with that small adjustment in language the science fiction works have nicely explored the way the mind grapples with this interaction between the physical and cyber worlds.

Human Society, Its Construction and Maintenance
memetics

The Creation and Maintenance of the Social Meme Structure
speech act theory
The construction of a social reality that uses abstractions that are not directly found in nature long precedes cyberspace. Those who study linguistic pragmatics recognize that humans use language for that very purpose. We construct new concepts and then use language to communicate those concepts to others. Some of those concepts construct, constrain and mould our society. Human relations, hierarchies , and organizations are formed using these words and people have a predisposition to accept many social conventions without thought. Richard Dawkins offers a compelling argument that these concepts are in fact an evolutionary step for social creatures to break the shackles of our genetic adaptation and instead have bundles of information that are passed from one generation to another which gives the society some evolutionary advantage over other societies in the competition for scarce resources. Whether or not you accept Dawkins memetic argument may not be important to my thesis but it at least offers one way in which we discuss abstract concepts which are communicated with language and have profound influence over a society and its members. This is not possible without language.

The specific ways in which language gave primitive societies an advantage is a subject of speculation. We can assume it enabled more complex forms of coordination among the hunters and gatherers. But even the earliest recorded inferences we make about language suggests it was used for means other than mere survival. There was an oral tradition of stories that served some purpose in their societies. One use was in the telling of stories. Some of these stories purported to be retellings of history. But the standards of accuracy were not strict by modern standards and the telling of an entertaining yarn were as important as staying true to historical facts, even if the memory was accurate. In time this gave way to stories that were complete fabrications and fiction was born.


The Counterfactual, Fiction and the Communal Construction of the Intended World
Even linguists stumble when discussing fiction. When someone is acting a role in a play they do not become the character despite their best attempts. And no audience member believes the player becomes the character, no matter how convincing the performance. There is an odd social transaction that the player(s) and the audience enter into a mode of suspension of belief so as to inhabit this constructed universe of the playwright. The playwright has license to create an alternate universe and populate it with anything that can be conceived by the human mind. I do not think it is too much of a stretch to suggest that from its earliest manifestations that these alternative universes were an early cyberspace.

Of course from story telling and plays passed through an oral tradition humans found a way to fix their language using physical devices like clay tablets and other forms of writing. This innovation in fixing a story helped to constrain story telling making a distinction between that which was meant to be historical from that which was allowed to be fanciful. A written history would belie the fable teller's altered version but still allowed for embellishment where the written account was silent.

While the volume of alternative universes has grown at an every increasing pace, things did not change in any fundamental way until the creation of new technologies for the capturing of visual images. Photography, cinema, sound recording, television and radio have increased the amount of information that can either be recorded or fabricated to inform and entertain. These new media extended the evocative power of story telling to allow an even greater suspension of disbelief and engagement in the alternative universe.

The realization that language and all media can be reduced to flows of information with the most minimal and effervescent of physical trace allows for the convergence that has been long anticipated. Cinema can become virtualized with constructed actors and scenes. Music need never involve physical instruments that manipulate air. While composers may be able to construct music without the realization of the sound, most people can appreciate the realization but not the idea alone. One is the design, the other the construction and implementation of that design.


Software As Memes Trying to Live
Software is in the realm of ideas that at best are realized statically as text or binary files on a disk. However they are mutated into something else once transcribed or translated into the memory of a physical machine. Once there and once given agency, they command the machine to do its will.  The machine is in the realm of the atoms while the software reaches through the machine to create an interaction between the world of ideas and the world of atoms.

One aspect of software engineer that departs significantly from computer science is the realization of the idea using physical machines. Unlike idealized logic machines, a computing device may not behave as predicted. For example all modern machines have the operating system as an intermediary. Various conditions may result in unexpected and illogical results, such as a read failure from storage because of a software failure in the OS. To the application program this cannot be anticipated and makes no sense yet it is a condition that must be programmed for and handled. The contingency of many software instructions must similarly be allowed for and has created a great deal of art. Unless and until we have physical machines that achieve their logical perfection, we must program contingently and always include a fair dose of risk management in those systems.


Software Engineering Through the Lens of Dualism
I believe it is time to revisit and old philosophical position, Cartesian dualism. No modern is willing to suggest that the abstract thoughts of humans is metaphysically separate from the physical universe of atoms. But there can be little doubt that abstract thoughts pass from human to human using language and have little or no physical presence other than their representations in human minds and the various representations they take in the physical universe such as spoken word, written symbols or the various representations they take in computer systems. By themselves they do not interact with the universe of atoms unless mediated by human beings and the effect those utterances have on us.

These abstract ideas can  of course of profound consequence on the world of atoms. One only need consider the choices societies have made since the invention of agriculture. We are now seeing the effect of anthropomorphic climate change based on the behaviors of civilizations over eons of using fossil fuels. This change only happened because of human behavior. And that human behavior was shaped by the accumulated knowledge of how to exploit the natural resources to propagate the species.

One cannot place humans in some category that is completely different from any other animal. There are after all many species which can create profound changes to their environment as well. Populations may grow beyond the limits of their ecosystem and starve. Changes in weather patterns or meteor strikes may present challenges that a species may not survive. But humans are different in their adaptability and their ability to grow in number beyond most any other species. It is this unique ability of humans that must be examined to understand how software engineering plays a pivotal role in our society today. And this requires an examination of the work of Richard Dawkins who coined the word memetics.

Computers as Machines to Propagate Memes
Unlike other animals, humans are far less bound by their genetic destiny than most any other animal. The adaptation of civilizations to the various environments in which humans moved conferred a benefit that could not be possible without some genetic pre-determinism. And that benefit is clearly bound to the ability of humans to form civilizations and work cooperatively. But many other species are social. What makes humans different?

Insect are simple creatures. It is possible to completely decipher their DNA and given time we can create models of their behavior and mimic the relatively simple behavior they exhibit given the stimuli of their environment. Yet despite their simplicity they can become a formidable species. Such is the power of social behavior. Mammalian behavior, especially the ability for complex speech, dramatically improved the ability to communicate and coordinate. Even more important is the ability to transmit information from one generation to the next. Now adaptive behavior discovered by one generation could be passed forward to the next. Now one generation could benefit from the mistakes of the past. How to grow, hunt, build, organize society, etc, was not lost. Civilizations grew and became more powerful. Dawkins called this transmitted information memetics borrowing the analog of the gene to suggest that somehow there are bits of information that the human mind could receive from parents and elders yet carry forward and pass on to their progeny. While the science of memetics is perhaps still a bit controversial and ill-formed, the basic premise that information in a society influences that society and has a remarkable ability to resist change seems hard to refute.

The Dance between the Static and the Dynamic

Communications Protocols through Linguistic Eyes














Sunday, October 28, 2018

Engineering and the Mind's Eye: an annotated bibliography



Engineering and the Mind's Eye by Eugene S Ferguson (1972, MIT Press) is a discussion of a view on engineering that differs from the mainline education of contemporary engineers in most disciplines. It emphasizes the history of engineering in design and the inherent way in which engineering uses visual or even artistic representation to communicate and develop solutions for patrons. While focused on the physical engineering disciplines, I believe it informs an approach to software engineering that is not taught today and which is poorly understood or appreciated.

"The Secret of Design
The design of Italian fortresses illustrates a fundamental tenet of engineering--one so right and proper, so self-evident (once it has been pointed out) and now so ingrained that it has become axiomatic: Whatever an engineer may be called upon to design, he know that in order for the plans to be effective the system being planned must be predictable and controllable. The designer first defines the boundaries of the system (often involving highly arbitrary judgements), just as the fortress designer set his boundaries at the limits of cannon range. Then the permissible inputs to the system and the permissible outputs from the system are carefully determined. Nothing may cross the boundaries unobserved or unaccounted for. There is no place an ideal engineering system for unpredictable actions, either by machines or by people. Thus the assumptions and essential procedures of the fortress designer--the fortress mentality--fit naturally the needs of the modern engineering design."  p 70

This passage is pregnant with implications for application in software engineering and is just one of many passages which discuss civil engineering or other physical engineering traditions but can be mined to gain insight into how software engineering is done by contrast with how we do not follow in this tradition.

The first obvious point is how systems engineering is about the identification of system boundaries with focus on that which crosses the boundaries. This is always taught to one degree or another in a standard CS curriculum but often given only an hour, at most, in the classroom. Yet there is a great deal of subtlety in where these lines get drawn and the very central issue of figure and ground that is assumed. In the 90s a popular mantra in systems consulting was the risk/reward ratio of scoping a re-engineering effort. A large percentage of system's projects are not greenfield development but instead a re-engineering of existing function. There is benefit to the patron in the re-engineering but that benefit is tied to the scope of that effort. A small scope can have only a small benefit while a larger scope may have a larger benefit. If the relationship of cost/benefit and the risk is linear, this is an easy decision to make. But it is rarely linear and it takes a measure of educated judgement to scope the project to maximize the benefit to the final cost.

This kind of management decision crosses the boundary between the technical engineering and the project management and the organization culture and upper management.

Another insightful comment has to do with the predictability of the system. Earlier in the book the point was made that much of modern engineering has to do with the manipulation of mathematical models of the system under design. The ability to accurately model a complex physical system with math varies depending upon the system. And the arc of engineering in any discipline has been the refinement of those models, often with the insight of prior failures. Engineers have always depended upon the knowledge gained from building the scale models or even complete project based on novel ideas and then refining based on experience over time. (Tacoma Narrows is only one example). Complex physical systems are often not completely modeled by the mathematical models. Insofar as we have a solid logical model of a computer system, this would not be a problem. But at some point every computer system will interface with a human being. And our understanding of HCI is in no way modeled using a mathematical model. We simply don't have the tools to do that nor do we even know whether that would be possible.

***

We have become so accustomed to this subordination of technology to science that it is difficult to realize that the Renaissance engineer, trained as an artist and retaining the artist's use of intuition and nonverbal thought, had significant counterparts in the United States as recently as the nineteenth century. For example, Robert Fulton of steamboat fame and Samuel Morse, inventor of the American telegraph, wee both artists before they turned to careers in technology.   (p 155)

***

The Crisis in Design
In the late 1950s, the declining ability of engineering graduates to carry ut design projects was becoming painfully evident to employers and to older teachers and administrators in engineering schools.

In 1961, Pay Chenea, head of the mechanical engineering department at Purdue, observed that while the engineering sciences had developed rapidly, design had "slipped back." Perhaps that was because the "faculty of several institutions have concluded that this may be an area of knowledge that cannot be successfully taught and hence have taken steps to eliminate an experience in design from the students' program." Perhaps a better explanation of the slipping back was that given by B. R. Teare, Jr.,m dean of engineering at Carnegie-Melon University:  "Design must compete with the engineering sciences for a place in the curriculum and for academic respectability and prestige."

A 1961 report issued by a faculty committee at MIT fully justified the fears of those who saw a crisis in design. Recent graduates were criticized for "unwillingness an inability" to consider a complete design problem and for preferring to tack only the fully specified problems that could be solved by analytical methods. This tendency was more marked at the M.S and Ph. D. levels, where young engineers "feel at home in solving problems which have numerical answers--the kind of problems used in school for teaching analytical techniques." Also, these "young engineers tend to consider problems which do not involve mathematics at least at the level of the calculus as beneath their dignity--something to be turned over to a technician who [is] without the benefit of a higher education."  (pp 161-162)

***


Wednesday, October 24, 2018

Semiology of Graphics by Jacques Bertin: An Annotated Bibliography

Semiology of Graphics: Diagrams, Networks, Maps
Jacques Bertin
Translated by William J Berg
Esri Press, Redlands, California, 2011
from the library of Carollina Song

Originally published in English by the Univ Wisconsin Press
1983

Originally published in French as Sémiologie grahique by Jacques Bertin copyright 1967 Editions Gauthier-Villars, Paris

LOC QA90.B47513 2010

monosemic system: the meaning of each sign is known prior to use
polysemic system: the meaning of the individual signs follows and is deduced from consideration of the collection of signs. "Signification becomes subjective and thus debatable."
"...and perception consists of decoding the image. The reading operaton takes place between the sign and its meaning. The abstract painting represents an extreme form of polysemy. In its attempt to signify "everything" it no longer signifies anything precise and so becomes "pansemic"."
p 2

"On the other hand, in graphics...each element is defined beforehand.", "The reading operation takes place among the given meanings."

"But graphics and mathematics differ in the perceptual structure which characterizes each of them. It would take at least 20,000 successive instants of perception to compare to tables of 100 by 100. If the data are transcribed graphically, comparison becomes easy; it can even be instantaneous."

"Monosemy is the fundamental condition of logic, but it also defines its limits. In effect, monosemy can only exist within a finite domain of objects and relationships. Logical reasoning, therefore, can only be a moment of reflection, since there is an infinite number of finite domains, however large they may be. Logic appears, then, as a sequence of rational moments immersed in the infinite continuum of the irrational." (footnote, p 3)

"Thought can only be expressed within a system of signs." verbal and written language are codings as are digital representations. "Any transcription leads necessarily to a separation of content from form. The 'content,' those elements of the thought which can remain constant, regardless of the sign-system into which they are translated, must be distinguished from the 'container.' that is the means available in a given system and the laws which govern their use. These elements are constant, whatever the thought to be transcribed." (p 4)





Wednesday, August 15, 2018

Software Art Thou: A summary of the lecture by Glenn Vanderburg from Real Software Engineering

Software Art Thou: Real Software Engineering
A summary of the lecture by Glenn Vanderburg currently VP Engineering at First.io

https://youtu.be/RhdlBHHimeM

Zendesk published a Youtube in January 2018 in which Glenn Vanderburg talks about the nature of Software Engineering and offers some insightful comments. Since many of his points are important to the research I am doing I am creating a summary of this Youtube to assist in citation. Parenthetic remarks are time m

Where SE went wrong and how to fix.
(0:27) Programmers: Stop Calling Yourselves Engineers, The Atlantic. Are SEs engineers?
Software Engineering: An Idea Whose Time Has Come and Gone?, Tom DeMarco, Computer Magazine, ACM? IEEE?
"Calling what we do 'engineering' doesn't make us engineers. It makes us liars, Dave (Pragmatic) Thomas, Extreme Programming mailing list at 2003
(2:04) Arguments against SE as engineering reduce to charge that it is fundamentally different from other engineering or that it is more artistic than engineering which essentially is the same argument.

The term Software Engineering can be traced to a NATO publication from a conference in Garmisch Germany in Oct 1968. And then Rome 1969.

He calls the 1969 the launch of Academic Software Engineering and was analytical, formal and aspirational toward engineering.

All academic software engineering (ASE) modeled process models of large scale engineering projects. Requ

Allister Colbert, was proj successful? how strictly to chosen process? PM differed from coders. Would you use this process again? (mostly no)

good people who cared were motivated to subvert process

in mid 90s, attempt to find new process, Agile
less iterative, experimental, less formal, correctness by testing, rapid adoption.
Now two views: software development should be more like engineering and software development is NOT like engineering.

Both ignore what engineering process really is.

Herbert Simon, The Sciences of the Artificial,
A Rational Model of Software , Parnass

(12:50) Glenn's view:
Software development already is engineering
it always was
the rational model (Parnass) is a caricature of engineering since no engineering is really done that ways and some look nothing like that
We don't need to become engineers but refine the software engineering process which does not have to adhere to the academic software engineering processes that were first suggested.

Remainder of talk:
the errors of ASE, what is engineering?, what is SE?, what's next?

(15:00)
The Errors of Analy\tical software engineering
Brian Randell, newcastle ed 1968
history of software engieering conference 1996
At that history of SE cibnference, he said:
"Unlike the first conference, at which it was fully accepted that the term softare engineering expressed a need rather than a reality, in Rome there was already a slighgt tendency to talk as if the subject already existed. And it became clear during the conference that the organizers had a hidden agenda, namely that of persuading NATO to fund the setting up of an Internal Software Engineering Institute. However things did not go according to their plan. The discussion sessions which were meant to provide evidence of strong and extensive supooret for this proposal were instead marked by considerable scepticism, and led one of the participants, Tom Simpson of IBM, to write a splendid short satire on 'Masterpiece Engineering'. IOt was little surprise to any of the participants in the Rome conference that no attempt was made to continue the NATO conference series, but the software engineering bandwagon began to roll as many people started to use the term to describe their work, to my mind often with very little justification. ... I made a particular point for many years of res\fusing to use the term or be associated with any even that used it."   Brian Randell

Early dissents

Alan Perliss. in 1968
A softwae system can best be designed if the testing is interlaced with the designing instead of being used after the design. (TDD)
A simulation which matches the reqrements contains the cotrol which organizes the design of the system.
Througb successive repetititons of this process of interlaced testing and design the model ultimately becaomes the software system itself. ... in effect the testing and the replacement of simulations with modules that are deeper and more detailed goes on with the simulatin model cotrolling, as it were, the place and order in which these things are done.

Fred Brooks, The Design of Design

Winston Royce agreed that waterfall seems like it should make sense but then went on to criticize it in the same paper. (Managing the Development of Large Software Systems http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf)

"John H. Van Vleck, Nobel-laureate physicist was Dean of Harvard's Division of Engineer and Applied Science when I was a graduate student there, in Aiken's lab. Van Vleck was very concerned that the practice of engineering e put on a firmer scientific basis. He led a vigorous shift of American engineering education away from design toward applied science. The pendulum swung too far; reaction set in; and the teaching of design has been contentious every since. I am grateful that three of my Harvard teachers never lost sight of the importance of design and taught it: Philippe E Le Corbeiller,  Hary R Mimno, and Howard H Aiken, my adviser."
Preface to The Design of Design by Fred Brooks

(19:47)
Devalued the role of code.
What is needed is not classical mathematics, but mathematics. Systems should be built at levels and modules, which form a mathematical structure." Friedrich Bauer

[...] our basic tools are mathematical in nature. -Edsger Dijkstra

David Parnas 2007 oopsla, "In engineering...people design through documentation,", "Code cannot fill that role."

Academic software engineering emphasized correctness over cost.

(23:27)
graph of cost of error correction versus phase of project where error is found. But, Glenn says, emphasis on careful review of all artifacts at all stages increases costs throughout since more reviews, more quality control is needed. "The cure is worse than the disease." Low cost, high impact. Cost of long feedback loops.

(25:00) What is engineering anyway?
"Unlike the extensive analysis of the scientific method, little significant research to date has sought the philosophical foundations of engineering. Library shelves groan under the weight of books by the most scholarly, most respected people analyzing the human activity called science. No equivalent body of research treats the engineering method." -Billy Vaughn Koen

8 good books on engineering process

The sciences of the Artifiicial, Herbert A Simon
The Design of Design, Gordon L Glegg
Definition of the Engineering Method, Billy Vaughn Koen
To Engineer is Human, Henry Petroski
What Engineers Know and How They Know It, Walter G Vincenti
Engineering and the Minds's Eye, Eugene S Ferguson
The Existential Pleasures of Engineer , Samuel C Florman
The Design of Design, Fred Brooks


[Programming] is not some kind of engineering where all we have to do is put something in one end and turn the crank." -Bruce Eckel

(or paraphrased, it is not algorithmic, nor can it be)

Engineering process is inherently creative, exploratory, and will always have false starts, dead ends, and learning processes.

"The Engineering Method is the use of heuristics to cause the best change in a poorly understood or uncertain situation within the available resources." -Billy Vaughn Koen

Different engineering disciplines are different. Process Control Model, defined at one end, empirical at the other.

"The defined process control model requires that every piece of work be completely understood. A defined process can be started and allowed to run until completion, with the same results every time. The empirical process control model provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs." -Ken Schwaber and mike Beedle, SCRUM

Engineering which has expensive construction requires are defined.

"The conversion of an idea to an artifact, which engages both the designer and the maker, is a complex and subtle process that will always be far closer to art than to science." -Eugene S Ferguson

(31:18)
"At first sight the idea of any rules or principles being superimposed on the creative mind seems more likely to hinder than to help, but this is really quite untrue in practice. Disciplined thinking focuses inspiration rather than blinkers it." -Gordon Glegg

(38:00)
Deflection theory for suspension bridges. Tacoma Narrows bridge. Deck so thin that it had aerodynamic properties that exciting resonant frequency.

Engineers adopted formal methods to save money. Predicting failure point makes it possible to reduce safety factor.

Structural analyses (indeed any engineering calculations) must be employed with caution and judgement, because mathematical models are always less complex than actual structures, processes, or machines." -Eugene S Ferguson

Engineering driven by practitioners but refined by academics.

Robert Hook, 1671
(45:51)
Sagrada Familia

(49:00)What is Software Engineering?
Structural engineering is the science and art of designing and making, with economy and elegance, ... structures so that they can safely resist the forces to which they may be subjected.
-Structural Engineers Association


In structural engineering the engineers create diagrams and specifications which are given to builders. Historically we map this onto SE by thinking of the designers as creating specifications for the coders. But this hasn't worked well. Are coders really builders?

The source code is not the solution. It is a design document. It is what the compiler that constructs the system that actually provides the solution.

For structural engineering the most expensive phase was construction. But for SE the compiling is the cheapest. With continuous integration this phase is effectively free.

Jack Reeves, what is software design? (http://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf)

Dave Thomas said XP processes tightly coupled.

Kent Beck wrote first XP book

If you look at the 13 processes, they can be arranged along a continuum of the amount of feedback they give and the scale at which it is given. From the processes that provide the most immediate feedback with the smallest scope is pair programming. At the other end we have practices that give valuable feedback but at a large scale of time and effort in short releases.

pair programming
unit testing
system metaphor
continuous integration
on-site customer
collective ownership
acceptance testing
planning game
short releases.

One suggestion: don't use languages that enable mutable state! (ha)

platform/application divide.

Glenn: stop using unsafe languages for applications.

formal methods to prove validity and security of small micro-kernels. formal methods now practical for well restricted domain.

Glenn Vanderburg, First.io, glenn@vanderburg.org or @glv






Friday, August 10, 2018

What Does Software Look Like?

I am reading the book, Engineering in the Mind's Eye by Eugene S Ferguson. The book is an in-depth discussion of the design process as found in many areas of engineering. And the focus appears to be on how those forms come to exist. He frequently cites the many paper models of the project to be created. And he stresses the visual component of how the designer tries to document what the finished product and its components look like. But how do I apply that to software engineering? If I am going to specify a system, what images help? What does software look like?

The difference between the surface appeal of a product and the inner workings is not unique to software of course. Something like a motor presents the user with a largely inscrutable object which turns an armature. But we all know that the inner workings of such an engine, or pump, or even an auto are complex. At the extreme we have the computer which has a relatively trivial surface appearance with a screen and a keyboard. But we all know the enormous complexity that exist under the cover. By analogy it is not much different than having a modest cottage that has all the inner workings of a large modern skyscraper. The appearance belies the complexity.

It is not as if the surface appearance does not matter. Quite the contrary. Working out the human-computer interface is a very important part of the design process. Not even as much because of the importance of that interface for the successful operation of the product, but because it is the way that most users can most easily explain the expected behavior, and the complex inner state transitions that are expected.

Some software product however have no human-interface design at all. Embedded systems have an interface of course. But that interface has no user perceived behavior. It becomes a piece of the infrastructure like the plumbing that we never want to deal with. And as long as it works, we don't need to.

Yet these are all important applications of software technology. And we must find a way to understand how to specify the software we need and communicate that to those who can build that for us. And much is the design literature leads us to believe that this division of designer and implementor is something artificial even while scale may require some specialization by skill.

So in this book I am hoping to find the start of some answers about what software looks like. When I engage in creating a blueprint for a software system, what should that look like? What should be visual? Are UML diagrams the right way to communicate intentions? What must be tabular? or do we need new extensions to computer languages to capture the information that right now seems to imperfectly flow from designer to builder in the processes we use today?

Monday, August 6, 2018

Software Engineering and Society


The Atlantic ran a provocative article a few years ago and I take strong exception to the points it makes. Titled Programmers: Stop Calling Yourselves Engineers (https://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/) I can agree with the point that much software engineering fails to live up to the aspirational goal of being like structural engineering. But by painting with such broad strokes the article does more to set that aspirational progress back than it does to propel it forward.

First let's consider the basic metaphysics of what a software engineer must do. Advances in steel are small and incremental. Yet changes in hardware design are still following Moore's law many decades after it was first recognized. In addition operating systems have grown in size, complexity and function just as fast as the underlying hardware. How is it possible to imagine the kind of well defined processes we find in structural engineering we see today if those engineers had such dramatic changes in their raw materials? Or if the scale of the structures they built kept pace with the growth of software systems? We would not have the dependability we see today. To suggest that software engineering is failing because it is not on par with structural engineering is a destructive false equivalence.

Next the author talks about how society has regulated some engineering disciplines. Yes, some engineering areas are subject to laws, have well defined apprenticeship tracks and continuing education requirements. But to assume that the mere adoption of those superficial forms would somehow achieve the desired effect of creating fewer software engineering failures is naive at best. Those professions themselves evolved those norms after decades, or even centuries, of practice. Software engineering today bears very little resemblance to the practice of even 30 years ago. We continue to experiment with the processes by which products are created. And the needs of the clients are so disparate that it is obvious the methods we use to created embedded systems for high safety applications bears only the vaguest similarity to the free social media apps the author cites.

Another false equivalence in the article is the criticism of the data breaches that are now getting so much criticism. The way in which we are using computer systems today is far more radical than the way we are using bridges. If society and its institutions continue to use software in novel ways we must expect that we will uncover new problems. Few thinkers in 1968 could have anticipated the kind of cyber espionage and warfare we must prepare ourselves for today. To place the blame for these failures at the feet of the software engineers who were as trusting as the people who commissioned them is hardly fair.

The author's charge of "engineerwash" is not fairly placed against engineers. Like all attempts to manipulate public trust this needs to be assessed against the organizations that profit from the work of those engineers. Engineers are rarely granted the opportunity to design the products they will build without significant input from their clients. Budget, time frames and quality are almost entirely set by the client and not the engineer. As long as we have a capitalist economy, there will be tension between engineers who may be inclined to over-engineer the product and the entrepreneurs who have incentive to under-engineer them. A great deal of legislation was introduced to affect this balance and check the worst impulses of decision makers who profit from the moral hazard.

The author does do a service to the community by pointing out the most obvious way in which engineering software systems is fundamentally different than a discipline of physical rather than information forms. Yes, changes to software alone are almost trivially made compared to structures of steel. And a great deal of rapid advance was enabled by recognizing this in our processes. If we had continued with the kind of waterfall processes that dominated most other engineering processes, many of the largest corporations on the planet today would not yet have been profitable and probably would never have been built. There is clearly a tension in practice between the need to do some level of high level design and yet embrace evolutionary design.

But process is not one-size fits all. The author glibly flits from low risk products such as social media platforms through large enterprise wide systems like airline reservation systems to individual products like spreadsheets to embedded systems with human life and safety concerns. No single process is appropriate for all of these products. The most safety critical benefit from reusing proven designs on stable platforms that have been exhaustively tested. But a great deal of wealth has been created by relaxing those constraints to explore new product categories and experimental systems. The matching of the process to the product goals is something an engineer can influence but is hardly the sole decider. And this leads into some of the most disingenuous parts of this article.

Software engineers are not unique in having clients who wish to employ them to achieve their organizational goals. A necessary feature of all engineering, as opposed to pure science, is the reality of economic constraints. These constraints are mediated by the client and are subject to limited negotiation by the engineer. We have already seen some engineering failures that were predicted to some degree of certainty by engineers such as the Saturn O-ring disaster. Engineering decisions are not made solely by engineers. To blame them for all failures is bordering on scurrilous.

Let's face facts here, Facebook is nothing like the Golden Gate Bridge. A complete failure of that platform would not end lives are throw a region into chaos. To suggest that the same standard of care should be exercised equally over both is polemic and unfair. Perhaps the notion of "move fast and break things" was in retrospect a bit naive. But the entire history of innovation is really no different. If one cannot take chances with a novel and uncritical application like a social network, then when are risks worth taking? As long as the publics health and safety is not placed at risk, the suggestion that heavy handed approach to regulating the software engineering profession betrays an officious attitude toward business.

The author also charges that software engineering has become hermetically insulated from the world. As if rocket science is not?

By page 7, the author has come back to the issue of professional licensure. I am old enough to remember these attempts. But I already pointed out how quickly the professional has changed. I looked at these early attempts with scorn at the superficiality of the certifications. Even green hiring managers could more accurately divine the capability of a potential engineer than these pseudo certifications.

I'll offer one aside on this issue. It is traditional that engineers have a four year degree. But there is scant evidence that the degree, by itself, is a reliable predictor of the engineers innate ability. While it is common that corporations will impose that restriction on hiring, it is usually out of expediency in filtering resumes more than empirical evidence that they make better engineers 4 years after hire. And given the cultural filtering of who can achieve a four years degree, it becomes more of a social filter than a technical one. This argues for the prejudice that Google and Thiel promote and which the author sneers at.

I feel I have addressed the most superficial faults of this article. But there is much more we can learn from some issues raised. One is the lure of entrepreneurship. He is absolutely correct that the ability to create a prototype system by a small group of entrepreneurial software engineers and make a great deal of money by selling this promise changes the very nature of what it means to be a software engineer. These engineers have merged the role of developer and business risk taker just as many scientists have done the same when developing their contributions to basic science. But no, this avenue is NOT turning computing into a type of speculative finance simply because the number of engineers inclined, or in a position, to take those risks is a minority. But he glosses over why this avenue is so attractive. He blithely says that engineering has always been a well-paid profession. Perhaps to a journalist.

Given the explosive growth in the technology, there has always been a severe shortage of talent compared to the appetite of the market. But like so many other labor markets in the US, this market mismatch does not explain the compensation. Consider the different economic outlooks of a hedge fund manager who can act as angel investor compared to the economic outlook of the engineer who creates the product. One can consistently outperform the other by a factor of at least 10, often far more. The basic capitalistic system encourages the use, some can say exploitation, of the engineer to remain in a risk free, but limit compensation role. How is it any wonder that young and talented developers are more inclined to explore being entrepreneurs rather than engineers?

Add to this structural bias toward risk taking the fact that powerful corporations can use selective manipulation of immigration laws to grant themselves economic relief. By keeping salaries low in the US for software engineers, they control the flow of students who choose it for a profession, When the inevitable skill shortage affects them, they claim an exception to immigration laws to allow for more software engineers to enter the US. If this were done fairly by giving them green cards I would accept it as part of the inevitable globalization of labor. But that is not what is done, these corporations go along with restrictions of these foreign workers that limit their ability to respond rationally to the US labor market and go where they can be paid the market rate for their skills. The author misses a great opportunity to make an important point about the power of the engineer in society by ignoring this.

The author cites the difference between many other professional engineers and software engineers and I made some comments about the false equivalence. However I will end by saying that I think the author does touch on something that is actually a valid criticism although I doubt they understand how valid a criticism it is. ABET is the standard by which most university programs are judged. A dirty little secret is that the computer science curriculum has fundamentally changed very little since 1968. And for prestige universities computer science is the program an aspiring software engineer must navigate to have the best chance of securing a position after graduation. Yet as the knowledge in the industry has exploded, the education system has not kept up. Once someone who wanted to study computer science got a math or physics degree. We are long past the time when meaningful distinctions can be made between computer science and software engineering. Why haven't we? Why has the gulf between academia and practice grown? Why are the first two years of a software engineer spent learning things not taught in school? And by this criticism I am not talking about skills training which by necessity is the responsibility of the employer. But instead a more mature approach to the entire software lifecycle than a very superficial mastery of basic coding, if even that.

The author accurately says that software engineering titles are aspirational more than an accurate description of what goes on in the industry or taught by the schools. But on the whole the article comes across as an uninformed hit piece that is designed to get attention by offering half truths about the role of the software engineer today. It missed a great opportunity to make some very valid criticisms of the role of software and the role of software creators in today's world.

Thursday, August 2, 2018

Speech Act Theory and It's Role in Software Engineering

John Searle was a disciple of J L Austin who has first defined what we now call Speech Act Theory. Searle's lectures for both the Philosophy of Language and Philosophy of Mind at UC Berkeley were both recorded and are available on Youtube. I want to make a few points about how I believe this linguistic theory informs software engineering and complex software systems.

A key point in speech act theory (SAT) is that some human realities are created with some utterances. When a person has the formal authority to marry or judge, a simple utterance can make a person guilty or married. I extend this concept (or perhaps am anticipating what others have already said) to surmise that language is not only a means of communication among people but is actually a tool by which we construct and maintain social reality. And I see no reason why this would not apply equally to how we use language and software artifacts as language to construct other realities. Here I am trying to work out what that can mean.

What is a computer program? What is software? I take a piece of code to be a blueprint for a machine. When combined with hardware and given agency it transforms that machine in which it is loaded into a realization of that intended machine. The message, utterance if you will, to run the program creates a kind of intentionality that has a world to mind direction of fit, we desire to have that machine be real and make it so with our utterance. This can be a command issued at a command line or the click of a button.

Programming can become arbitrarily complex and progressively more agency can be invested in the machines. Instead of pressing a button, we can invest a machine with the authority to press the button in response to some external stimulus (a mind to world direction of fit in reference to the agent) or on some schedule, which is after all a stimulus of passing time. As we progress with giving more agency to these machines I believe it makes sense to use a theory of mind to talk about the agents and not just humans.

There are two distinct threads in machines today, computation communications. Computation often steals the focus today with the dramatic advances in artificial intelligence and the prevalence of algorithms in social media. But the advances in communications are no less impressive as we progress toward a single pervasive and omnipresent communications network that is used for internet of things as well as for human communications. The growth of computer to computer communications is no less impressive than the ability of any person to be able to converse with any other person on the globe at will. But this intra-computer agent communication must become visible to us at our will as well, especially when it does not serve our needs and we need to understand or change it.

Does it not make sense to look at all network communications as utterances on par with human communications? Do we not preside over a cybernetic realm that is now an extension of our human and physical realm? Do we not have utterances by agents that change our social world as thoroughly as a chaplain or judge? When a municipal system issues a warrant for our arrest, even when done in error, it is a real warrant and will have real world consequences. I want to take this as a starting point and begin to review computer systems through this lens.

***

The origin story for this line of thinking came from a more modest question of how programmers document their code. It is rather obvious that a programmer is creating a unique language that becomes a kind of private language between them and compiler. If the intentionalities of the coder are to be preserved, care must be taken in the naming of the nouns and verbs. For they invariably have some connection, usually indirect, with things in the real world. And in the complexity of the design, this intended relationship is often lost. Even worse is the complexity of the mechanisms by which the surrogates of the real world are manipulated by the algorithms. Anyone trying to pick up the pieces behind a coder must enter into a unique world as envisioned by that coder with the private language they had constructed to communicate their intensions to the compiler.

The connection to speech act came about because of some earlier work I once did on trying to relate communications between a client and a lawyer and codify the conditions of satisfaction that would underlie commitments that were made. But once one understands this linguistic theory, it begins to open new ways of looking at computer languages beyond the standard syntax and semantics that are used.

The Role of Design in Engineering and Software Engineering Education.

A continuing issue I have in the teaching of computer science at university is that I believe it is either delusion or fraud. What the computer science program is used for by students is to prepare them for a job in software engineering yet few schools seem inclined to embrace that label and instead cling to the more traditional notion of computer science. I don't see how we can progress as educators if we do not look honestly at what is going on and how that is not serving the needs of the students. 

Computer science, when it was first acknowledged as a separate academic department apart from applied mathematics, was either organized with mathematics, as a branch of applied math, or in the engineering college, to align with the hardware engineering. According to a an ACM article, the first PhD in computer science was awarded to Richard Wexelblat in 1965 and the second was awarded to Andy van Dam both at the University of Pennsylvania in 1965/1966. (https://cacm.acm.org/blogs/blog-cacm/159591-who-earned-first-computer-science-ph-d/fulltext). The general trend has been to organize the department into the college of engineering but I happen to believe that is wrong and implicitly acknowledges that what is really taught as computer science is truly software engineering under the false label of computer science.

This was easily justified in decades past since there was really not sufficient material to make a distinction. But the amount of material that can be taught, and should be taught, to a budding software engineer has grown and university programs find themselves constantly squeezed to satisfy current market needs by teaching many current techniques while also unwilling to stick to the traditional programs that stressed the more abstract computer science in favor of heavy emphasis on programming. 


There is one particular failing that results from this trend to cling to the science as opposed to the engineering and that is the place of design in the curriculum. And this failure is not limited to only the computer science department but can be seen throughout the college of engineering. For engineering differs from science in one crucial respect, it is inherently tied to economy and to the satisfaction of a client. So why do I believe this is so in today's universities? I believe it is a combination of a few aspects of the culture and history of engineering in the US.
Engineers are invariably quantitatively oriented. And for software engineering in particular, the formal mathematical foundation of the discipline does not admit for much qualitative or humanistic ambiguity. The first uses of computers were for intense calculation and that did not require any design, at least as that concept was understood outside of an engineering discipline where design only meant the choices one made between some relatively well known approaches. Design, and humanities in general, were kept external to the discipline and while that works for most engineering disciplines, it is no longer tenable in software engineering. 


All engineering requires a degree of creativity although the practice is more dominated by the reuse of a few well known designs that are scaled or altered by the application. But even the most routine of engineering disciplines allows for novel design and innovation. Software engineering is exceptional in the growth and innovation that it has experienced. And its high-touch applications in human-computer interaction with its use of visual communications, it has benefited from graphic artists and others outside of the engineering college. 


The other way in which humanities was admitted to the study of software engineering was from the liberal admission of metaphors to architecture. Today major software systems are complex and enormous ensembles that dwarf any physical structures we build today. Yet the way we understood the construction of a software system was heavily influenced by the construction of buildings and other large scale physical artifacts like airplanes or rockets. This had enormous impact on both practice and education as I'll explain below. But for now the point i wish to make is that all of engineering wanted to distance themselves from a discipline that was aligned with the art department, art and architecture. 


A lecture that gives voice to many of the beliefs I hold about software engineering can be found on Youtube and was given by Glenn Vanderburg under the title, Software Art Thou. (https://youtu.be/RhdlBHHimeM)  
This was easily justified in decades past since there was really not sufficient material to make a distinction. But the amount of material that can be taught, and should be taught, to a budding software engineer has grown and university programs find themselves constantly squeezed to satisfy current market needs by teaching many current techniques while also unwilling to stick to the traditional programs that stressed the more abstract computer science in favor of heavy emphasis on programming. 


There is one particular failing that results from this trend to cling to the science as opposed to the engineering and that is the place of design in the curriculum. And this failure is not limited to only the computer science department but can be seen throughout the college of engineering. For engineering differs from science in one crucial respect, it is inherently tied to economy and to the satisfaction of a client. So why do I believe this is so in today's universities? I believe it is a combination of a few aspects of the culture and history of engineering in the US.


Engineers are invariably quantitatively oriented. And for software engineering in particular, the formal mathematical foundation of the discipline does not admit for much qualitative or humanistic ambiguity. The first uses of computers were for intense calculation and that did not require any design, at least as that concept was understood outside of an engineering discipline where design only meant the choices one made between some relatively well known approaches. Design, and humanities in general, were kept external to the discipline and while that works for most engineering disciplines, it is no longer tenable in software engineering. 


All engineering requires a degree of creativity although the practice is more dominated by the reuse of a few well known designs that are scaled or altered by the application. But even the most routine of engineering disciplines allows for novel design and innovation. Software engineering is exceptional in the growth and innovation that it has experienced. And its high-touch applications in human-computer interaction with its use of visual communications, it has benefited from graphic artists and others outside of the engineering college. 


The other way in which humanities was admitted to the study of software engineering was from the liberal admission of metaphors to architecture. Today major software systems are complex and enormous ensembles that dwarf any physical structures we build today. Yet the way we understood the construction of a software system was heavily influenced by the construction of buildings and other large scale physical artifacts like airplanes or rockets. This had enormous impact on both practice and education as I'll explain below. But for now the point i wish to make is that all of engineering wanted to distance themselves from a discipline that was aligned with the art department, art and architecture. 


A lecture that gives voice to many of the beliefs I hold about software engineering can be found on Youtube and was given by Glenn Vanderburg under the title, Software Art Thou. (https://youtu.be/RhdlBHHimeM)  A key item he reports is ideas held by the dean of the Harvard engineering school from 1951 to 1957, Doctor Van Vleck. He desired to place engineering on a more scientific basis. It should be noted that Doctor Van Vleck was a Nobel Prize winning physicist. In the talk Brooks is quoted as having said:

The Vanderburg video rails against the embrace of the waterfall model for earlier academics. There was always a belief that this was the dominant process model for all engineering. 



"Van Vleck was very concerned the the practice of engineering be put on a firm scientific basis. He led a vigorous shift of American engineering education away from design toward applied science. The pendulum swung too far; reactions set in; and the teaching of design has been contentious ever since."
I agree with Brook's comment and I see as a consequence that the heightened need to teach design principles now affects all engineering disciplines but is most visible in the failure of computer science professors to teach even rudimentary design concepts. And it has also shaped the expectations of these students to what the academy believes is the correct process that should be followed in industry.
The needs of students, the needs of future employers and even the material itself all argues for a fundamental rethinking of how students who wish to become software engineers are taught at university today. We must look at the distinction between engineering versus science and also redress the avoidance of good design in their education. It is our job to do the best we can and I believe we are failing to do so.

Wednesday, June 13, 2018

Counterfactuals in Programming and Language

A counterfactual is something that is discussed as if it exists but does not. I can talk about the bald king of france and people will follow my flight of fancy knowing there is no such person. In one sentence i have conjured up a world different from our own. Many talk about the multiple world hypothesis and attribute this some more tangible meaning than i think it is due. Just because we can discuss an alternative reality does not mean that one can, or should, exist "out there." These counterfacturals hinge on a capacity of human minds to imagine that which is not.

If Speech Act Theory does one thing well, it explains how the very real abstract objects of social life are created. Property, money, and justice all depend upon these human created objects which would have no existence in our universe without people. These are human constructs but real and important to us even without any corporeal presence.

Programs too conjure things into existence. The objects instantiated by a program are mere potential or real energy captured as information on some substrate. Through multiple layers of representation we come to attribute meaning or social reality to these strings of bits. Is it accurate to look at these ontologically? to suggest that we are recognizing a new metaphysics? I am beginning to believe we should.

The human mind continually engages in imaging alternatives to the world we perceive. We can see improvements in our mind's eye. We wreck havoc on our enemies to satisfy an urge we must not act on. And we spin tales, fiction that generates many billions of dollars of US revenue by making more real something that is not.

When writers invite us into a fictional universe, they do so with conventions. A book is understood to be fictional before the first page is read. A movie, already something understood to be at minimum a dramatic retelling of some historical truth, may tip into magical realism with sone scene that defies the rules of physics. We willingly enter into the consensual hallucination of the story and are entertained by it. But when Searle talks about fiction and its speech acts, it all becomes hopelessly muddled. It seems that recognizing this alternative reality more directly makes the whole enterprise much easier as a theory.

While the multiverse may be entertained by some as a form of cosmology, it is undeniable that we can imagine a multi-verse whether or not one exists. Why not allow this human capacity to exist in multiple realities into the theory of language? By casting myself as an author and speaking as the author of this reality, I am relieved of the usual burden of truth. I am free to populated by universe with whatever rules and objects I like. I take on God-like powers there and can create heroes and demons at will. And these objects become real in the minds of the readers, the audience at a play or movie and in the players of games. The consumer of these products willingly pushes the one reality we cannot deny into the background enough to allow this alternative reality to consume their attention.

In this way creating computer systems is very much like taking some small bit of physical space and spinning an alternative universe for some purpose. Prosaically we build formal models of the social realities we want. We create accounting systems to reflect the economic systems we have, land registries, policy and procedure manuals and they record the various roles individuals play in the myriad organizations we create. These systems do more than make tangible the concepts we have. In important ways they become that reality. If the bank shows a balance, that is my money and there is no point in arguing one way or the other at that point of time. There have been many interesting cases of bank errors that enriched an individual and sometimes the money cannot be clawed back by the bank due to some accounting error on their part. Their accounting error created a reality and it is only in the most obvious cases where that windfall is understood to be theft when acted upon.

As our world become more determined by these cybernetic realities, it is important to heighten our philosophical notions to match this encroaching reality where cyber objects become as real, or even more real, than the older forms of social reality that preceded them. I suppose one hopes that it is still only human speech acts that create the cyber reality that transcends the older one. But like the Buttle/Tuttle mixup of the movie Brazil, that veil is thin. I want to dwell on this metaphysic for a time and come to my own understanding of the relationship between human language and the socio technical systems we create.

Saturday, June 9, 2018

The Ontology of a Java Program

To someone who cannot let go of the physical world, ontology is an odd subject. It is the philosophical study within the branch of metaphysics that deals with the nature of being. Or as Wikipedia says, "Ontology is the philosophical study of the nature of being, becoming, existence, or reality, as well as the basic categories of being and their relations." But for my purposes I will go no further than to talk about objects and their existence.

For anyone immersed in the objects relations school of computer programming objects is a weighted term. And it is exactly that overtone I wish to look at. But let me take one step back for a moment and observe that until one has successfully strung together a file of symbols that will pass a Java compiler, there is not yet a software module. The moment the compiler first accepts that text file and generates a byte code file, a new module is brought into existence in that file namespace. It has been summoned into existence.

The object-relations school of thought looks at a software module as an object that possesses attributes and behaviors. The byte code object can be copied, moved, executed and deleted (destroyed). Yet does the byte code file have any behaviors? Does any purely descriptive object be said to exhibit any behavior? I am going to say no. But of course the purpose of a byte code file is not to merely exist like some artifact lost in the desert of a file system. It is the essence that imparts some special magic into the machine with a Java Virtual Machine (JVM) running on it which will take that descriptive text and use it to create objects within the memory of that computer. And the original intent of the creator was that this object in the machines memory takes over the capabilities of this machine in a virus like way and bends it to the hidden will of the creator. It transmits the design of a virtual machine to this physical machine and then

 Computer Science is no more about computer than Astrophysics is about telescopes (E.W. Dijkstra)

Ontology is one of the prime areas of metaphysics. How did I end up reading about metaphysics when I intended to understand what makes programs readable? I am here because while we blithely talk about instantiating objects in a Java program, I am taking it in a more literal sense and finding that the language of ontology and then the later issues of sense and reference applicable to these. It cannot be mere coincidence that the two fields overlap in this way.

I am not alone of course. There is this post which directly asks the same question and gives a rather good answer. I found in in June 2018. 
http://www.mathema.com/philosophy/metafisica/is-metaphysics-relevant-to-computer-science/

But let me race on to the thought that sparked this entry, the famous sentence in philosophy about the bald king of France. Is this true or false?

in Java terms, we have two predicates. One would answer the question of whether x is the King of France. The other would answer the question of being bald. The first predicate could never be answered, could never be true, since there is no such person. This gives a null referent for the second predicate. And null referents defy the precondition of any predicate giving an indeterminate response. So in programming terms we exactly see the philosophical notion of the presumed referent.

When listening to the lectures on the philosophy of language and specifically the discussions of fiction that I came to what I think may be a metaphysics different from Searle's. I need to read more about this to see if it is a distinct metaphysics and if so, learn to describe it. 


References:
Ontologies: Principles Methods and Application, Mike Uschold Michael Gruninge, 1996,  The University of Edinburgh
http://www.aiai.ed.ac.uk/publications/documents/1996/96-ker-intro-ontologies.pdf 

https://www.springer.com/cda/content/document/cda_downloaddocument/9780387370194-c1.pdf?SGWID=0-0-45-495101-p173670217

https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-871-knowledge-based-applications-systems-spring-2005/lecture-notes/lect22_ontolog.pdf

https://plato.stanford.edu/entries/computer-science/



Friday, June 1, 2018

Charles Sanders Peirce - philosopher, logician, mathematician

For anyone who has studied formal logic, Peirce (pronounced like "purse"), is remembered for his binary operator, the Peirce arrow which, as it turns out, is functionally sufficient to derive all the other logical operators. This math fact gives us the ability to construct entire computers using only a single logic gate.

Charles Sanders Peirce (/pɜːrs/,[9] like "purse"; 10 September 1839 – 19 April 1914) was an American philosopherlogicianmathematician, and scientist who is sometimes known as "the father of pragmatism". He was educated as a chemist and employed as a scientist for 30 years. Today he is appreciated largely for his contributions to logic, mathematics, philosophy, scientific methodology, and semiotics, and for his founding of pragmatism.


Peirce's most important work in pure mathematics was in logical and foundational areas. He also worked on linear algebramatrices, various geometries, topology and Listing numbersBell numbersgraphs, the four-color problem, and the nature of continuity.
He worked on applied mathematics in economics, engineering, and map projections (such as the Peirce quincuncial projection), and was especially active in probability and statistics.[79]
Discoveries
Peirce made a number of striking discoveries in formal logic and foundational mathematics, nearly all of which came to be appreciated only long after he died:
In 1860[80] he suggested a cardinal arithmetic for infinite numbers, years before any work by Georg Cantor(who completed his dissertation in 1867) and without access to Bernard Bolzano's 1851 (posthumous) Paradoxien des Unendlichen.
The Peirce arrow,
symbol for "(neither) ... nor ...", also called the Quine dagger.
In 1880–1981[81] he showed how Boolean algebra could be done via a repeated sufficient single binary operation (logical NOR), anticipating Henry M. Sheffer by 33 years. (See also De Morgan's Laws.)






https://en.wikipedia.org/wiki/Charles_Sanders_Peirce

W Ross Ashby

One of the new names that popped up in my research is W Ross Ashby.

W. Ross Ashby (6 September 1903 in London – 15 November 1972) was an English psychiatrist and a pioneer in cybernetics, the study of the science of communications and automatic control systems in both machines and living things. His first name was not used: he was known as Ross Ashby.Despite being widely influential within cyberneticssystems theory and, more recently, complex systems, Ashby is not as well known as many of the notable scientists his work influenced, including Herbert A. SimonNorbert WienerLudwig von BertalanffyStafford BeerStanley MilgramKevin Warwick, and Stuart Kauffman.[5]


https://en.wikipedia.org/wiki/W._Ross_Ashby



It has been a few years since I used this blog. I had started posting things to Facebook but I am going into a deep dive on a topic and I want to try to gather some posts on that topic. I am currently interested in trying to establish a foundation in how language is used when dealing with computers and how it is used when computers interact. I am going to make a series of posts on influential thinkers as a form of annotated bibliography although the posts are about the people and not their works per se. I may go back and fill in the appropriate writings that I need but for now their brief bios will meet my needs.