If you are an IT professional supporting legacy software, you may have experienced the joys of refactoring old code into modern code. In IT, refactoring is the process of rewriting code so that it behaves exactly like an existing application that was written in older code. The reason for refactoring old code is that many applications can exist for more than a decade or more and a lot can change in a decade. Software and hardware are both rapidly changing and something that made sense a decade ago probably does not make much sense today. Plus, over the course of a decade, many programmers have worked on the code and have come and gone. It is very hard to work on the code that was written by a dozen different programmers over the years, each with a differing coding style. For example, in the early 1980s, I was given the Task of refactoring a FORTRAN II program written in the early 1960s into a FORTRAN 77 program. I kept finding this line of code in the FORTRAN II program:
S = BLINK("GREEN")
but I did not have the source code for the BLINK() function so I was stuck. So I went to one of the old-timers in my group, and he explained that in the olden days the computers did not have an operating system. Instead, they had a human operator who loaded the cards for a job into the vacuum-tube computer and then watched the computer do its thing. The BLINK("GREEN") call was a status call that made a light on the computer console blink green so that the operator knew that everything was okay with the job and that the program was still running. That explained the final line of code in the program.
S = BLINK("RED")
In a refactoring effort, ancient software that was written in the deep past using older software technologies and programming techniques is totally rewritten using modern software technologies and programming techniques. To do that, the first step is to create flowcharts and Input-Output Diagrams to describe the logical flow of the software to be rewritten.
In Agile vs. Waterfall Programming and the Value of Having a Theoretical Framework, I described the Waterfall project management development model that was so popular during the 1970s, 1980s and 1990s. In the classic Waterfall project management development model, detailed user requirements and code specification documents were formulated before any coding began. These user requirements and coding specification documents formed the blueprints for the software to be developed. One of the techniques frequently used in preparing user requirements and coding specification documents was to begin by creating a number of high-level flowcharts of the processing flows and also a series of Input-Output Diagrams that described in more detail the high-level flowcharts of the software to be developed.
Figure 1 – Above is the general form of an Input-Output Diagram. Certain Data is Input to a software Process. The software Process then processes the Input Data and may read or write data to storage. When the software Process completes, it passes Output Information to the next software Process as Input.
Figure 2 – Above is a more realistic Input-Output Diagram. In general, a hierarchy of Input-Output Diagrams was generated to break down the proposed software into a number of modules that could be separately coded and unit tested. For example, the above Input-Output Diagram is for Sub-module 2.1 of the proposed software. For coding specifications, the Input-Output Diagram for Sub-module 2.1 would be broken down into more detailed Input-Output Diagrams like for Sub-module 2.1.1, Sub-module 2.1.2, Sub-module 2.1.3 ...
When undertaking a major software refactoring project, frequently high-level flowcharts and Input-Output Diagrams are produced to capture the functions of the current software to be refactored.
However, when refactoring code it is important not to simply replicate the Output of a given Input. One needs to shoot for the general case. For example, during the 1970s there were not many IT professionals with a degree in computer science. Most of us came from the sciences, engineering or accounting. We simply took a single course in FORTRAN or COBOL in college and instantly became qualified to be an IT professional. For example, in the early 1980s, I had a new hire join our development group and I was given the job of helping him to get started. He was working on some code that Output city names from some arrays based on some Input criteria. The code worked great, but he could not get the code to spit out "Chicago" for one set of criteria, so he simply hard-coded the string "Chicago" in his code for that set of criteria. I had to explain to him that his solution did work but that we needed to make his code work for all cases. I had to explain that hard-coding Output to fix a bug was frowned on in IT.
Refactoring Manual Systems in the 1970s
Back in the 1970s, computers were still very magical things for the general public and the business community too. People thought that computers could work miracles and magically solve all of their business problems. We were still refactoring manual systems back in those days that consisted of flows of paper forms being manually processed by clerks. The clerks had an Input box and an Output box. Input forms would arrive in their inbox, the clerks would then perform some manipulations on the Input information using their business knowledge and a mechanical adding machine and then transcribe the Output information on an Output form that went into their outbox. The Output forms were then delivered to the next clerk by another clerk using a mail cart on wheels for the next processing step. For example, when I first transitioned from being an exploration geophysicist for Amoco to becoming an IT professional back in 1979, Amoco's IT department had two sections - computer systems and manual systems. The people in manual systems worked on the workflows for manual systems with the Forms Design department, while the computer systems people programmed COBOL or FORTRAN code for the IBM MVS/TSO mainframes running the OS/370 operating system. Luckily for me, I knew some FORTRAN and ended up in the computer systems section of IT, because for some reason, designing paper forms all day long did not exactly appeal to me. Getting into the computer side of IT was also a fortunate career move at the time because now I am very concerned about the impact of climate change on the planet.
Figure 3 - Above is a typical office full of clerks in the 1950s. Just try to imagine how many clerks were required in a world without software to simply process all of the bank transactions, insurance premiums and claims, stock purchases and sales and all of the other business transactions in a single day.
The problem with refactoring a manual system back in the 1970s was that, because people still thought that computers were magical, their expectations were way too high. They wanted the computer to do everything for them by magic. In fact, they frequently wanted the computer to do impossible things for them! For example, they always knew the Output that they wanted, like how many red cleaning rags would be needed by a certain refinery next month. But we were stuck with trying to come up with some code that could produce that Output. So sometimes we had to tell our business partners that computers were really not magical and that there were some things that computers simply could not do. Fortunately, many times we could construct some code that could do what they wanted by adding additional attributes to the Input to the process. For example, given the production capacity of a refinery, the projected production volumes for next month, the number of employees working at the refinery next month and how many red cleaning rags they used last month, we could construct some code that would give them the projected number of red cleaning rags for the next month.
But sometimes we found that we could not construct the code to Output the number of red cleaning rags that a refinery would need next month no matter what information we Input into the constructed code because our Input-Output diagram was hiding a deeper principle. For example, it was accidentally discovered that when the number of red cleaning rags required each month by a given refinery increased, so did the likelihood of a dangerous personal injury accident happening at that refinery! Clearly, something more fundamental than simply ordering red cleaning rags was going on. The number of red cleaning rags used by a refinery was a sign of unsafe working conditions at the refinery. For more on code refactoring see the Wikipedia article:
Code refactoring
https://en.wikipedia.org/wiki/Code_refactoring
Constructor Theory
In a similar manner, David Deutsch and Chiara Marletto at Oxford would like to refactor all of physics using what they call constructor theory. Constructor theory is a set of fundamental first principles that all other theories in physics seem to follow. These fundamental first principles are similar to the postulates of mathematics. In this view, all of the current theories in physics that are to be refactored by constructor theory are called subsidiary theories. Thus, Newtonian mechanics, Newtonian gravity, classical electrodynamics, thermodynamics, statistical mechanics, special relativity, general relativity, quantum mechanics and the quantum field theories of the Standard Model are all to be considered subsidiary theories that could be derived from the fundamental first principles of constructor theory. The basic principle of constructor theory is that
I. All other laws of physics are expressible entirely in terms of statements about which physical transformations are possible and which are impossible, and why.
Constructor theory replaces the current theories of physics with Input-Output diagrams that describe possible and impossible transformations of Inputs and Outputs in order to find the more fundamental principles that underlie how the Universe behaves. Currently, the way we do physics is to determine the initial conditions of a system and then apply a theory usually framed in terms of some differential equations to determine how the system will evolve over time.
Figure 4 - Given the initial conditions of a cannonball with velocity V0 and a cannon angle of inclination θ0 we can use Newton's laws of motion and gravity to predict its path.
For example, given the initial position and velocity vector of a cannonball leaving a cannon, we can use Newton's equations of motion and Newton's theory of gravity to predict how the cannonball will move with time. Or, for a more accurate path, we could use Einstein's general theory of relativity. But does that really tell us about the fundamental essence of the cannonball's motion? Sometimes with this approach to physics using initial conditions and dynamical laws, we stumble on some more fundamental principles, like Lagrange's principle of least action which states that the cannonball will follow a path that minimizes the difference between its kinetic and potential energies over the path that it follows. Or using the general theory of relativity, find that the cannonball will follow a path that maximizes the proper time of the cannonball. The proper time of the cannonball is recorded by a clock riding along with the cannonball. When the cannonball is closer to the ground, time moves slower for the clock than when the cannonball is high in the air because the gravitational field is stronger closer to the ground, so the cannonball will move in such a way to move quickly through the zones of slower time near the ground and more slowly through the zones of faster time high in the sky. That way the cannonball's clock will record the greatest time of flight and maximize its proper time.
See Dr. Matt O'Dowd's PBS Space Time video for more on that:
Is ACTION The Most Fundamental Property in Physics?
https://www.youtube.com/watch?v=Q_CQDSlmboA&t=964s
Some of the other fundamental first principles are the conservation of energy, momentum, angular momentum, electrical charge, and the fact that matter, energy and information cannot travel faster than the speed of light. But David Deutsch and Chiara Marletto suspect that many of the current theories of physics may be hiding even more fundamental first principles. Yes, the current theories of physics do a great job of predicting what will happen to systems in a positivistic manner, but they would like to have a framework that explains why things happen in terms of fundamental principles, and not just what happens. You need a collection of fundamental principles for that and so constructor theory strives to start from these fundamental first principles to determine if things are possible or not possible.
Figure 5 - A constructor theory Input-Output diagram consists of a Task that is performed on Input to produce an Output. The Task is performed by a Constructor.
To do that they use constructor theory Input-Output diagrams to essentially refactor the current theories of physics. A constructor Input-Output diagram consists of an Input, Task and an Output. The Task is a process that can transform the Input into an Output. The Task is a possible Task if a Constructor can be fabricated that successfully performs the Task.
For example, the Input could be two monomer molecules and the Output could be a polymer molecule consisting of both monomer molecules stuck together. The Constructor could be a catalyst that successfully performs the Task. If such a catalyst can be fabricated then the Task is a possible Task. If not, then the Task is an impossible Task. Or, the Input could be a Maintenance Request and the Output could be a Work Order. The Constructor would be a program that turns Maintenance Requests into Work Orders. If such a Constructor can be programmed, then the Task of creating Work Orders from Maintenance Requests would be a possible Task. If you cannot write a Constructor program that tells you how many red cleaning rags a refinery will need next month, then it is an impossible Task. As an IT professional, I guarantee that many occasions will arise when you will be forced to tell your business partners that certain Tasks are simply impossible. Unfortunately, they will likely just respond with, "Okay, but it has to be done by Friday". Fortunately for David Deutsch and Chiara Marletto, they just have to reduce all of physics to constructor theory Input-Output diagrams consisting of possible and impossible Tasks and it does not have to be done by Friday.
The Constructor Theory of Information
Constructor theory is a product of combining classical information theory and quantum information theory. For IT professionals, its most profound application is to the theoretical study of the fundamental nature of Information. We saw in Entropy - the Bane of Programmers, The Demon of Software, Some More Information About Information and How Much Does Your Software Weigh? - the Equivalence of Mass, Energy and Information how the concept of Information slowly crept into physics by accident as an incidental byproduct of learning how to build better steam engines and learning how to transmit digital messages over noisy transmission lines. Now, for the first time, constructor theory provides a formal mechanism to theoretically study the nature of Information from fundamental first principles. For more on that see:
Constructor theory of information
David Deutsch and Chiara Marletto
https://www.constructortheory.org/wp-content/uploads/2016/03/ct-info.pdf
For an excellent overview of constructor theory see:
Dr. Matt O'Dowd's PBS Space Time video:
Will Constructor Theory REWRITE Physics?
https://www.youtube.com/watch?v=hYc97J2MZIo&t=698s
Also, take a look at the constructor theory homepage at:
CONSTRUCTOR THEORY
https://www.constructortheory.org/
Comments are welcome at scj333@sbcglobal.net
To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/
Regards,
Steve Johnston
No comments:
Post a Comment