Defending Wittgenstein’s Tractatus

In my article “My view of the book: Wittgenstein’s poker” (5/2/2021), I wrote:

I have not finished my reading of the book, Wittgenstein’s Poker (Copyright 2001 by David Edmonds and John Eidinow), cover to cover, and I suspected that I wouldn’t read through it since it seemed obvious to me a misrepresentation of Wittgenstein.”

Now, having finished the reading of the book cover to cover, I feel that I have better data to defend my opinions about Wittgenstein’s philosophy in his Tractatus (1922).

First, let’s see what are misunderstandings of Tractatus among those “deceased and great philosophers,” Bertrand Russell (1872-1970) and Karl Popper (1902-1994), to name the two.

Bertrand Russell, seventeen years older than Wittgenstein, a well-known mathematician (the author of The Principle of Mathematics) and a philosophy professor at Cambridge University, convinced Wittgenstein to give up his engineering study and become a philosopher student. Wittgenstein took Russell’s mathematical logic course at Cambridge in 1911 and started his ambition to solve the philosophical problems. In spite of his participation of the world war I (1914-1918), Wittgenstein completed this task in seven years, finished his writing, and truthfully and succinctly reflected his thoughts in its preface written in 1918. At the same time, Wittgenstein, sent his writing to Russell for critiquing. Unfortunately, Russell never truly understood Wittgenstein’s philosophy expressed in that writing.

Russell’s misunderstanding seems rather mysterious, so I will put it on side for now and concentrate on Karl Popper’s misunderstanding of Wittgenstein’s philosophy.

Karl Popper, thirteen years younger than Wittgenstein, a Viennese like Wittgenstein, a converted Jewish offspring like Wittgenstein, decided to make Wittgenstein his enemy in his philosophical endeavor (page 5 of Wittgenstein’s poker, “Popper saw Wittgenstein as philosophy’s ultimate enemy.”) Therefore, he annoyed, to say the least, and angered Wittgenstein greatly on October 25, 1946, while Wittgenstein had little idea who Karl Popper was and had never met him before attending that dramatic MSC meeting, leaving the legendary tale about Wittgenstein’s poker during Popper’s professional lifespan and beyond.

Let me analyze Popper’s critical views about Wittgenstein’s philosophy.

Problems or Puzzles

The later Wittgenstein used to speak of “puzzles,” caused by the philosophical misuse of language. I can only say that if I had no serious philosophical problems and no hope of solving them, I should have no excuse for being a philosopher: to my mind, there would be no apology for philosophy. –Popper (page 221, Wittgenstein’s poker)

According to the authors of Wittgenstein’s poker,

Russell was ultimately to regard the task attempted by Principia Mathematica as more Sisyphean than Herculean– or “unmitigated rubbish” in his words — and the real significance for philosophy came when he transferred the techniques he had employed in this work to the study of language and then to the perennial problems of metaphysics: the nature of existence, knowledge, and truth. … The great puzzle for philosophers was the relationship between language and the world. (page 223, Wittgenstein’s poker)

These were exactly motivated Wittgenstein to solve philosophical problems, and he concluded with “the misunderstanding of logic in our language.” (quoting from the 1918 preface of the 1922’s Tractatus.)

I could not agree with the conclusion more! As a computer language expert and a professional computer software maker, I think that human languages are no differences from computer languages in terms of making expressions. I would make a further claim that language is logic, parallel with “I think therefore I am.” (Descartes, 1595-1650)

Now, back to the concept of philosophical problems to Popper or the philosophical puzzles to Wittgenstein.

I am with Wittgenstein and I assume philosophical problems were dissolved into the logic or the language problems. Therefore, it is more accurate to use puzzle to describe philosophical issues since philosophizing over an issue is to clarify and elucidate the issue at hands. If all pieces of a puzzle is at hands, we can definitely solve the puzzle. Otherwise, we need to figure out where are the rest of puzzle pieces.

According to the authors of Wittgenstein’s poker,

For Popper–a philosopher in the grand tradition– the real problems with which his fellow philosophers should engage ranged from the structure of society to the nature of science, from the relationship between mind and body to the meaning of infinity, probability, and causation. Several of these topics were on stage in the H3 drama. (Page 243, Wittgenstein’s poker)

The meaning of infinity, probability, and causation

Wittgenstein’s anger came clearly as if Popper did not understand his explanations of issues argued on purpose. For example, to Wittgenstein, the induction problem, a 200-years old problem, can be easily explained. The probability problem is a scientific one but non-sense. The infinity problem is a mathematical one, and can always have a practical solution in reality.

Let us give the benefit of the doubts to Popper being a serious debater in the “H3 drama.” What could be the obstacle for him to acknowledge the explanations by Wittgenstein in the debating happened on Oct. 25, 1946?

I believe that the problem lies to the metaphysical ability of the two philosophers. Humans’ faculty to think relies on humans’ metaphysical ability. The higher our metaphysical ability is to think about issues, the deeper we understand them. Metaphorically, we may call this human nature a metaphysical mountain. The higher we climb, the better we can overlook the surrounding with issues, thus, we can be better at clarifying and elucidating to these issues we are philosophizing.

Automation, how much impact it had on human civilization

Civilization

Human interests are rooted in human needs. 

Creations and inventions are rooted in human genes.

As far as tools of human invention are concerned, we call these inventions the progress toward civilization.

When I was growing up in the 1960s, the critical difference between Humans and other animals was in the use of tools; this is no longer the case after scientific progress in biology. Or we may have to redefine the category of tools to settle the claim. Human inventions, such as the wheel and the pulley, are simple tools, and no other animals have done that except humans. 

Automation

My bachelor’s degree was earned at an engineering school in China, majoring in Automation, and Industrial Automation was the full name and implied. That was in the early 1980’s, and we had both electric and electronics within one academic department, and students were sharing many fundamental courses. 

The word Automation was starting used in the early 20th century, and it should not be confused with other words with the prefix auto- such as automaton (1645), automatism (1838), automobile (1769 in France. or 1876 in England or 1885 in German). 

Automation is in the context of a system operation without human intervention, and a human substitution was done, initially, a mechanical/electrical /electronic feedback loop, and is, nowadays, a computer.

Computer and Automation

Historians define the abacus as the earliest computer. Without question, all modern automated systems have computers, even if a modern computer was initially defined by the concept of Automation: 

“A computer is a machine that can be programmed to carry out sequences of operations (arithmetic and logical operations) automatically.” 

 The concept of a computer nowadays is no longer as concrete as an organ or an apple; it runs the analogy with the idea of fruit, simply as edible and growing on plants.

IBM is a company that makes computer hardware and computer software. It also claims to be a manufacturer of Artificial Intelligence and Cloud computing. It was founded in 1911 in Endicott, New York, as the Computing-Tabulating-Recording Company (CTR) and was renamed “International Business Machines” in 1924. IBM is incorporated in New York and has operations in over 170 countries. If one wants to learn the history of modern computers, learning the history of IBM will suffice. 

Artificial Intelligence

My Ph.D. degree was earned at an engineering school in the United States, studying Artificial Intelligence (AI) under Computer Science Department. It was in the late 1990’s, and it was the AI winter in the U.S. academically while Asians were still in love with AI. I was neutral about giving up my AI study because I understood that American scientists were practical; so was I, especially. 

Is there a difference between Artificial Intelligence and Automation?

In my Ph.D. dissertation, I wrote about the competition between IBM Deep Blue and Garry Kasparov, https://en.wikipedia.org/wiki/Deep_Blue_versus_Garry_Kasparov to make my point in my long and dedicated years of AI research. 

My conclusion remains true then and now. Artificial Intelligence is the same as Automation, and it will always be making of tools. So, it is part of the progress in human civilization. 

Natural vs. Nurtural– a study of software maturity

It is not too far off if we run the analogy between the life of a human maturity process and that of software. Arguably, a human being starts from conception. A life goes in stages: the pregnancy, the birth, the nursing of a baby, the schooling with kindergarten, the twelve grades, college or technical school, then, the entry to the workforce, the prime of being an expert in a particular field, and the change of this field naturally as desirable or as needed; each individual is actively anticipating a development maturity while every one of us being useful and enjoying our lives.

To a logical mind, it is remarkably similar between a successful individual life and a software product. Let us continue this analogy to illuminate what software is and how to ensure software quality.

A. The conception

There is a broad range of reasons to conceive a life or create software! Without a doubt, the forefront reason is the result of our passion and our love. It could also be an accident or a deliberated act strategically or tactically. One strategic software project that immediately jumped to my mind was the one D. L. Parnas wrote in his paper [1]. He stated that he had his concerns about the health of that project vociferously. In hindsight, we knew that the primary purpose of the project was strategically aligned with our national interests during the cold war. Fortunately, we can say that this project ended with success because of the ending of the USSR. Meanwhile, there were plenty of software products that continued useful with longevity. An obvious example would be the office automation suites.

B. The pregnancy

Software requirement development is similar to the pregnancy stage of human life. The process should be carried out by a responsible individual who can bring such a life into the world. Although the stakeholders of software may be more than one individual, the final decision for bringing about a particular software product ought to stop at one responsible individual. Many examples supported such analysis; among them, there is in the AIR JAM report [2]. Without doing so, the requirement specification often induces failure with its skyrocketing cost as the symptom.

On the other hand, not all software projects can be associated with an individual’s responsibility. The requirements of those projects were part of the circumstances discussed by Neil Maiden in “Trust Me, I am an Analyst [3].” In his analysis, trust has been of the highest importance. Although it makes some sense, arguably, the responsibility must be emphasized at the forefront; specifically, the desirability and the feasibility must be differentiated clearly in an engineering sense under its software architect(s).

Software development professionals, who are specialized in software requirement engineering, must not only be able to “listen” to descriptions of stakeholders, but also to participate, like those movie actors or investigating reporters, who are taking active roles in the subjects they play or investigate. Learning what are the needs by participating, such as a banker developing a finical system or a controller developing an air traffic control system.

Good actors can quickly make sense of the roles they play. Requirement engineers can do the same as well. It is a must for experienced software engineers to do so because we understand both evolved technologies used to create software. We can effectively bridge the gap between the desirable requirements and the feasible implementation with available technologies.

C. The education

As human beings, whether one is useful/influential or not, it is judged by their knowledge and their capability in actions. A software product is the same if built with efficient knowledge structures for addressing its requirements. The key to efficient knowledge structures is the subject of studies in software architecture. An excellent software product with longevity must have enduring software architecture. Just as people in their workplaces, knowledgeable workers have resulted from their excellent educations, good software products come from good design and development. Architectural analysis is most important in software design. Good architecture is sustainable to software systems with continuously learning and continuously improving.

D. Entering the workforce

If the commencement at the end of schooling is a youngster’s entry into the workforce, the same is true for software to be first released to the real world. Software is tested during its development, but the key to being useful is in use in the real world by its end-users. Arguably, the most critical growth of a software product starts at this stage, unlike the following descriptions of the software project management life cycle of the past:

We built what we were told to build, managing it the best we could; and after it was over, we breathed a sigh of relief (or despair) and moved on to the next project [4].

Here, Favaro’s word “over” is not the end of software life cycle management but the project delivery to the operational people and maintenance engineers. It indicates the ending of the software-development and the beginning of the software-maintenance stage in the traditional software life cycle management. This point of view might be applicable 30 years ago. With modern software, the difference is that software matures through its use:

The more customers use it, the more feedback the software gets for improvement. It is essential for college graduates to learn-by-doing and to accumulate their real-world-knowledge at work. The same is true whether a software product is popular or not at its entry point. We should judge how it grows and how its customers react to it. It is often the case that if its design is sound, it grows better and serves better.

Defects in software products are inevitable, just as teenagers’ imperfection; continuous improvement is also inevitable while maturing within their life cycle, both young persons and newly developed software. As a person learns and corrects his unwanted habits to fit in society, software defects may be fixed whenever and wherever surfaced while being used. 

Even though we don’t call a college graduate “version 2,” he or she becomes a better “version” compared with the “version” at his high school commencement ceremony. He has learned more comprehensive knowledge and special skills, provided that critical thinking develops throughout their education at a college. He/she is more capable of doing complex tasks and capable of serving society.

Judging software is like judging people; we want to see how one is educated/capable. In software, defects can be removed not only when it occurs while being tested before entering the market, but also when it occurs while being used. A Hewlett Parker study has shown that many defects of a software product may never have the chance to be exposed during its service. It depends on how its customers’ usage of it [5]. 

Both code reviews and extra efforts spent for defect removal advocated by experts of software development in the past [6] [7] may or may not be efficient uses of developers time if the software is a commercial product or a freeware, typically developed in an Agile development environment, rather than mission-critical software with potentially catastrophic effect [8] if anything goes wrong. 

I have proposed a model of software defects to address software product quality issues [9], which is also part of a solution to software development under the software maturity modeling approach.

E. Maturing with lifelong learning

At the prime of our professional career, mature human beings are most productive and motivational in learning driven by unknowns provided that the more one learns, the more one may realize that what one do not know and want to know. The same happens in software products. If a software product is useful, it promotes the need to make the product even more useful. Improving a software product can be challenging, but it is feasible. 

Demands for software changes can be given in two forms:

1. A problem addressed by software may change when the environment that defines it has changed;
2. The solution to the problem addressed by the software is improving. 

In order to implement these changes, architectural changes may be necessary, and the cost of changes may be evaluated. In describing software aging caused by those preventable changes, Parnas wrote:

Changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade. Under those circumstances, changes will be inconsistent with the original concept; in fact, they will invalidate the original concept. Sometimes the damage is small, but often it is quite severe. After those changes, one must know both the original design rules and the newly introduced exceptions to the rules, to understand the product. After many such changes, the original designers no longer understand the product. Those who made the changes never did [10].

This description reflects reality in many legacy systems, but it does not have to be this way if the responsibility of design ties with individuals. A close analogy between software designers and architects of landmark buildings may be appropriate. Individual responsibility should tie with the fame or the shame of the software systems, especially those important ones. Many failures in Robert Charette’s survey article [2] can be avoided if applying this software maturity model. Tying the responsibility with the architects of the software system could be a two-way street. Connecting the software architecture with an individual can be used as licensing approach for evaluating software architects if desirable, not for life but any particular software system. It goes nicely with the suggestion made by Maiden: requirements analyst should show their previously successful work.

Another close analogy runs with how FAA issues licenses to pilots, where flying hours and the types of airplanes they operate are the primary indications of pilot’s skills. In fact, that is how pilots get rated.

In her Quality Time column piece in IEEE Software, S.L. Pfleeger introduced Manny Lehman’s notion of program (referring his Life Cycles and the Laws of Software Evolution, Proc. IEEE, IEEE, Piscataway, NJ Vol. 68, No. 9, Sept. 1980, pp1060-1076,) a program describes a system in terms of the way it relates to the environment in which it operates. She pointed out: “Unlike programs handled in the abstract, the real world contains uncertainties and concepts we do not understand completely.” In my analysis, the dada uncertainty is the cause of our inability to test general systems behaviors with a particular input. It could be meaningful input to the environment but not to the program particularly. The system behavior in response to untested situations may seem odd to users, but it should not be seen as strange to developers when such is happening. She continued: “The more dependent a system is on the real world for its requirements, the more likely it is to change [11].” The same reason has motivated me to write this article. We must model software maturity as a life cycle management approach. 

F. Retiring

Like the story of Compact Disc, when the CDs came along, recording music on cassette was inferior in terms of the sound quality, ease of retrieving, and storage capacity. Software products are retired due to their quality as well. 

However, the differences between software and hardware change the dynamics in reality. The flexibility in software allows improvements constantly. The same is true in software engineers, as long as one keeps learning. The fact that software engineers are good at learning with being curious about possible self-improvement is natural. If computer hardware is to human bodies, then computer software is to human brains. Many religions in the world honor human souls as eternal; it couldn’t be a more appropriate analogy with computer software. While hardware is degrading/upgrading, the essential in software lives forever. Arguably, one should never retire a high-quality software product. The apparent high cost to “maintain” usually can be exchanged with technology transfers.

[1] D.L. Parnas. Software Aspects of Strategic Defense Systems, and SDI: A Violation of Professional Responsibility, In Chapters 26 and 27 of Software Fundamentals, Collected Papers by David L. Pamas, Edited by Hoffman and Weiss, Addison-Wesley, 2001 .

[2] R.N. Charette,” Why software fails”, IEEE Spectrum,Vol.42 No.9, p42-49, Doi:10.1109/MSPEC.2005.1502528.

[3] N. Maiden, “Trust Me, I’m an Analyst”, Software, IEEE, vol. 27, no. 3, June, 2010, p46-47, doi: 10.1109/MS.2010.22. 

[4] J. Favaro, “Guest Editor’s Introduction: Renewing the Software Project Management Life Cycle”, Software, IEEE, vol. 27, no. 3, June, 2010, p17-19, doi: 10.1109/MS.2010.9.

[5] A.P. Wood, “Software reliability from the customer view”, Computer, vol. 36, no. 8, Aug. 2003, p37-42, doi:10.1109/MC.2003.1220580.

[6] R.L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, c2003.

[7] A.M. Davis, 201 Principles of Software Development, McGrow Hill, Inc, 1995.

[8] G. Le Lann, “An analysis of the Ariane 5 flight 501 failure — a system engineering perspective”, in Proceedings., International Conference on Engineering of Computer-Based Systems, Mar 24-28, 1997, p339-346, doi: 10.1109/ECBS.1997.581900

[9] B.H. Wu, “Modeling Defects in Software Systems”, IEEE International Conference on Granular Computing (GrC2011), Kaohsiung, Taiwan, November 8-10, 2011, p739-744, doi: 10.1109/GRC.2011.6122690.

[10] D.L. Parnas, Software Aging, In Chapter 29 of Software Fundamentals, Collected Papers by David L. Pamas, Edited by Hoffman and Weiss, Addison-Wesley, 2001.

[11] S.L. Pfleeger, “The nature of system change”, Software, IEEE, vol. 15, No.3, 1998, p87-90, doi:10.1109/52.676964 .