Programming Biology in the Biological Computation Group of Microsoft Research

In the early 1980s, I strongly advocated taking a biological approach to the development and maintenance of software while in the IT department of Amoco. At the time, I was actively working on a simulated science that I called softwarephysics for my own software development purposes while I was holding down a development job in the IT department of Amoco, and looking back, I must now thank the long-gone IT Management of Amoco for patiently tolerating my efforts at the time. For more on that please see Some Thoughts on the Origin of Softwarephysics and Its Application Beyond IT and Agile vs. Waterfall Programming and the Value of Having a Theoretical Framework. The relatively new field of computational biology, on the other hand, advocates just the reverse. Computational biology uses techniques from computer science to help unravel the mysteries of biology. I just watched a very interesting TED presentation on the computational biology efforts at Microsoft Research by Dr. Sara-Jane Dunn:

The next software revolution: programming biological cells
https://www.ted.com/talks/sara_jane_dunn_the_next_software_revolution_programming_biological_cells?utm_source=newsletter_weekly_2019-11-01&utm_campaign=newsletter_weekly&utm_medium=email&utm_content=top_left_image#t-1

in which she explains how the Biological Computation research group at Microsoft Research is applying standard IT development and maintenance techniques to discover the underlying biological programming code that runs the very complex biological processes of cells and organisms. In her TED talk, Dr. Sara-Jane Dunn maintains that the last half of the 20th century was dominated by the rise of software on electronic hardware, but that the early 21st century will be dominated by being able to first understand, and then later manipulate, the software running on biological hardware through the new science of biological computation. Dr. Sara-Jane Dunn is a member of the Microsoft Research Biological Computation group. The homepage for the Microsoft Biological Computation group is at:

Microsoft Biological Computation
https://www.microsoft.com/en-us/research/group/biological-computation/

The mission statement for the Microsoft Research Biological Computation group is:

Our group is developing theory, methods and software for understanding and programming information processing in biological systems. Our research currently focuses on three main areas: Molecular Programming, Synthetic Biology and Stem Cell Biology. Current projects include designing molecular circuits made of DNA, and programming synthetic biological devices to perform complex functions over time and space. We also aim to understand the computation performed by cells during development, and how the adaptive immune system detects viruses and cancers. We are tackling these questions through the development of computational models and domain-specific computational tools, in close collaboration with leading scientific research groups. The tools we develop are being integrated into a common software environment, which supports simulation and analysis across multiple scales and domains. This environment will serve as the foundation for a biological computation platform.

In her TED Talk, Dr. Sara-Jane Dunn explains that in many ways biologists are like new members of an Applications Development group supporting the biological software that runs on living cells and organisms. Yes, biologists certainly do know a lot about cells and living organisms and also many details about cellular structure. They even have access to the DNA source code of many cells at hand. The problem is that like all new members of an Applications Development group, they just do not know how the DNA source code works. Dr. Sara-Jane Dunn then goes on to explain that by using standard IT systems analysis techniques, it should be possible to slowly piece together the underlying biological software that runs the cells that living things are all made of. Once that underlying software has been pieced together, it should then be possible to perform maintenance on the underlying biological code to fix disease-causing bugs in biological cells and organisms, and also to add functional enhancements to them. For readers not familiar with doing maintenance on large-scale commercial software, let's spend some time describing the daily mayhem of life in IT.

The Joys of Software Maintenance
As I explained in A Lesson for IT Professionals - Documenting the Flowcharts of Carbon-Based Life in the KEGG Online Database many times IT professionals in Applications Development will experience the anxiety of starting out on a new IT job or moving to a new area within their current employer's IT Department. Normally, the first thing your new Applications Development group will do is to show you a chart similar to Figure 1. Figure 1 shows a simplified flowchart for the NAS system. Of course, being new to the group, you may have at least heard about the NAS system, but in truth, you barely even know what the NAS system does! Nonetheless, the members of your new Applications Development group will assume that you are completely familiar with all of the details of the NAS system. Even though you have barely even heard of the NAS system, they will naturally act as if you are a NAS system expert like themselves. For example, they will expect that you will easily be able to estimate the work needed to perform large-scale maintenance efforts to the NAS system, create detailed project plans for large-scale maintenance efforts to the NAS system, perform the necessary code changes needed for large-scale maintenance efforts to the NAS system and easily put large-scale maintenance efforts for the NAS system into production. In truth, during that very first terrifying meeting with your new Applications Development group, the only thing that you will honestly be thankful for is that your new Applications Development group started you out by showing you a simplified flowchart of the NAS system instead of a detailed flowchart of the NAS system! Worse yet, when later you are tasked with heading up a large-scale maintenance effort for the NAS system, you will, unfortunately, discover that a detailed flowchart of the NAS system does not even exist! Instead, you will sadly discover that the excruciatingly complex details of the NAS system can only be found within the minds of the current developers in the Applications Development group supporting the NAS system as a largely unwritten oral history. You will sadly learn that this secret, and largely unwritten, oral history of the NAS system can only be slowly learned by patiently attending many meetings with members of your new Applications Development group and by slowly learning parts of the code for the NAS system by working on portions of the NAS system on a trial and error basis.

Normally, as a very frightened and very timid new member of the Applications Development group supporting the NAS system, you will soon discover that most of the knowledge about the NAS system that you quickly gain will result from goofing around with the code for the NAS system in an IDE (Integrated Development Environment), like Eclipse or Microsoft's Visual Studio in the development computing environment that your IT Department has set up for coding and testing software. In such a development environment, you can run many experimental runs on portions of the NAS system and watch the code execute line-by-line.

Figure 1 – Above is a simplified flowchart for the NAS system.

The Maintenance Plight of Biologists
Now over the past 100 years, biologists have also been trying to figure out the processing flowcharts of carbon-based life by induction, deduction and by performing experiments. This flowcharting activity has been greatly enhanced by the rise of bioinformatics. A fine example of this is the KEGG (Kyoto Encyclopedia of Genes and Genomes). The KEGG is an online collection of databases detailing genomes, biochemical pathways, diseases, drugs, and biochemical molecules. KEGG is available at:

https://www.genome.jp/kegg/kegg2.html

A good description of the KEGG is available in the Wikipedia at:

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

Figure 2 – Above is a simplified flowchart of the metabolic pathways used by carbon-based life.

Figure 3 – Above is a high-level flowchart of the metabolic pathways used by carbon-based life as presented in the KEGG online database. You can use the KEGG online database to drill down into the above chart and to dig down into the flowcharts for many other biological processes.

I encourage all IT professionals to try out the KEGG online database to drill down into the documented flowcharts of carbon-based life to appreciate the complexities of carbon-based life and to see an excellent example of the documentation of complex information flows. Softwarephysics has long suggested that a biological approach to software was necessitated to progress to such levels of complexity. For more on that see Agile vs. Waterfall Programming and the Value of Having a Theoretical Framework. The challenge for biologists is to piece together the underlying software that runs these complicated flowcharts.

Computer Science Comes to the Rescue in the Form of Computational Biology
IT professionals in Applications Development face a similar challenge when undertaking a major refactoring effort of a large heavy-duty commercial software system. 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. In order 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 a sense, the Microsoft Research Biological Computation group is trying to do the very same thing by refactoring the underlying biological software that runs carbon-based life.

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 4 – 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 5 – 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. When trying to uncover the underlying biological software that runs on carbon-based life, computational biologists need to do the very same thing. The Microsoft Research Biological Computation group is working on a number of large projects in this effort and I would like to highlight two of them.

(RE:IN) - the Reasoning Engine for Interaction Networks
In order to perform a similar software analysis for the functions of living cells and organisms, the Microsoft Research Biological Computation group developed some software called the (RE:IN) - Reasoning Engine for Interaction Networks. The purpose of the (RE:IN) software is to produce a number of possible models that describe the underlying biological software that runs certain biological processes. The (RE:IN) software essentially outputs possible models consisting of flowcharts and Input-Output Diagrams that explain the input data provided to the (RE:IN) software. To use the (RE:IN) software you first enter a number of components. A component can be a gene, a protein or any interacting molecule. The user then enters a number of known interactions between the components. Finally, the user enters a number of experimental results that have been performed on the entire network of components and interactions. The (RE:IN) software then calculates a number of logical models that explain the results of the experimental observations in terms of the components and the interactions amongst the components. I imagine the (RE:IN) software could also be used to analyze commercial software in terms of data components and processing interactions to produce logical models of software behavior for major software refactoring efforts too. The homepage for the (RE:IN) software is at:

https://www.microsoft.com/en-us/research/project/reasoning-engine-for-interaction-networks-rein/

You can download the documentation for the (RE:IN) at:

https://www.microsoft.com/en-us/research/uploads/prod/2016/06/reintutorial.docx

From the (RE:IN) homepage you can run a link that will start up the (RE:IN) software in your browser, or you can use this link:

https://rein.cloudapp.net/

The (RE:IN) homepage also has a couple of examples that have already been filled in with components, interactions and experimental observations such as this one:

The network governing naive pluripotency in mouse embryonic stem cells:
https://rein.cloudapp.net/?pluripotency

It takes a bit of time to run a Solution to the model, so click on the Options Tab and set the Solutions Limit to "1" instead of "10". Then click on the "Run Analysis" button and wait while the processing wheel turns. Eventually, the processing will complete and display a message box telling you that the process has completed.

Station B - Microsoft's Integrated Development Environment for Programming Biology
Station B is Microsoft's project for creating an IDE for programming biology that is similar to Microsoft's Visual Studio IDE for computer software. The homepage for Microsoft's Station B is at:

https://www.microsoft.com/en-us/research/project/stationb/

The general idea behind Station B is to build an IDE for biological programming like we have with Microsoft's Visual Studio IDE for computer software development and maintenance. Here is the Overview from the Station B homepage:

Building a platform for programming biology
The ability to program biology could enable fundamental breakthroughs across a broad range of industries, including medicine, agriculture, food, construction, textiles, materials and chemicals. It could also help lay the foundation for a future bioeconomy based on sustainable technology. Despite this tremendous potential, programming biology today is still done largely by trial-and-error. To tackle this challenge, the field of synthetic biology has been working collectively for almost two decades to develop new methods and technology for programming biology. Station B is part of this broader effort, with a focus on developing an integrated platform that enables selected partners to improve productivity within their own organisations, in line with Microsoft’s core mission. The Station B project builds on over a decade of research at Microsoft on understanding and programming information processing in biological systems, in collaboration with several leading universities. The name Station B is directly inspired by Station Q, which launched Microsoft’s efforts in quantum computing, but focuses instead on biological computing.

The Station B platform is being developed at Microsoft Research in Cambridge, UK, which houses Microsoft’s first molecular biology laboratory. The platform aims to improve all phases of the Design-Build-Test-Learn workflow typically used for programming biological systems:

• The Design phase will incorporate biological programming languages that operate at the molecular, genetic and network levels. These languages can in turn be compiled to a hierarchy of biological abstractions, each with their associated analysis methods, where different abstractions can be selected depending on the biological question being addressed. For example, a Continuous Time Markov Chain can be used to determine how random noise affects system function, using stochastic simulation or probabilistic model-checking methods.

• The Build phase will incorporate compilers that translate high-level programs to DNA code, together with a digital encoding of the biological experiments to be performed.

• The Test phase will execute biological experiments using lab robots in collaboration with technology partner Synthace, by using their award-winning Antha software, a powerful software platform built on Azure Internet of Things that gives biologists sophisticated control over lab hardware.

• The Learn phase will incorporate a range of methods for extracting biological knowledge from experimental data, including Bayesian inference, symbolic reasoning and deep learning methods, running at scale on Azure.

These phases will be integrated with a biological knowledge base that stores computational models representing the current understanding of the biological systems under consideration. As new experiments are performed, the knowledge base will be updated via automated learning.

For those of you not familiar with Microsoft's Visual Studio IDE, you can read about it and download a free community version of Visual Studio for your own personal use at:

https://visualstudio.microsoft.com/vs/

When you crank up Microsoft's Visual Studio, you will find all of the software tools that you need to develop new software or maintain old software. The Visual Studio IDE allows software developers to perform development and maintenance chores that took days or weeks back in the 1960s, 1970s and 1980s in a matter of minutes.

Figure 6 – Above is a screenshot of Microsoft's Visual Studio IDE. It assists developers with writing new software or maintaining old software by automating many of the labor-intensive and tedious chores of working on software. The intent of Project B is to do the same for biologists.

Before you download a free community version of Visual Studio be sure to watch some of the Visual Studio 2019 Launch videos at the bottom of the Visual Studio 2019 download webpage to get an appreciation for what a modern IDE can do.

Some of My Adventures with Programming Software in the 20th Century
But to really understand the significance of an IDE for biologists like Station B, we need to look back a bit to the history of writing software in the 20th century. Like the biological labwork of today, writing and maintaining software in the 20th century was very inefficient, time-consuming and tedious. For example, when I first learned to write Fortran code at the University of Illinois at Urbana in 1972, we were punching out programs on an IBM 029 keypunch machine, and I discovered that writing code on an IBM 029 keypunch machine was even worse than writing term papers on a manual typewriter. At least when you submitted a term paper with a few typos, your professor was usually kind enough not to abend your term paper right on the spot and give you a grade of zero. Sadly, I learned that such was not the case with Fortran compilers! The first thing you did was to write out your code on a piece of paper as best you could back at the dorm. The back of a large stack of fanfold printer paper output was ideal for such purposes. In fact, as a physics major, I first got hooked by software while digging through the wastebaskets of DCL, the Digital Computing Lab, at the University of Illinois looking for fanfold listings of computer dumps that were about a foot thick. I had found that the backs of thick computer dumps were ideal for working on lengthy problems in my quantum mechanics classes.

It paid to do a lot of desk-checking of your code back at the dorm before heading out to the DCL. Once you got to the DCL, you had to wait your turn for the next available IBM 029 keypunch machine. This was very much like waiting for the next available washing machine on a crowded Saturday morning at a laundromat. When you finally got to your IBM 029 keypunch machine, you would load it up with a deck of blank punch cards and then start punching out your program. You would first press the feed button to have the machine pull your first card from the deck of blank cards and register the card in the machine. Fortran compilers required code to begin in column 7 of the punch card so the first thing you did was to press the spacebar 6 times to get to column 7 of the card. Then you would try to punch in the first line of your code. If you goofed and hit the wrong key by accident while punching the card, you had to eject the bad card and start all over again with a new card. Structured programming had not been invented yet, so nobody indented code at the time. Besides, trying to remember how many times to press the spacebar for each new card in a block of indented code was just not practical. Pressing the spacebar 6 times for each new card was hard enough! Also, most times we proofread our card decks by flipping through them before we submitted the card deck. Trying to proofread indented code in a card deck would have been rather disorienting, so nobody even thought of indenting code. Punching up lots of comment cards was also a pain, so most people got by with a minimum of comment cards in their program deck.

After you punched up your program on a card deck, you would then punch up your data cards. Disk drives and tape drives did exist in those days, but disk drive storage was incredibly expensive and tapes were only used for huge amounts of data. If you had a huge amount of data, it made sense to put it on a tape because if you had several feet of data on cards, there was a good chance that the operator might drop your data card deck while feeding it into the card reader. But usually, you ended up with a card deck that held the source code for your program and cards for the data to be processed too. You also punched up the JCL (Job Control Language) cards for the IBM mainframe that instructed the IBM mainframe to compile, link and then run your program all in one run. You then dropped your finalized card deck into the input bin so that the mainframe operator could load your card deck into the card reader for the IBM mainframe. After a few hours, you would then return to the output room of the DCL and go to the alphabetically sorted output bins that held all the jobs that had recently run. If you were lucky, in your output bin you found your card deck and the fanfolded computer printout of your last run. Unfortunately, normally you found that something probably went wrong with your job. Most likely you had a typo in your code that had to be fixed. If it was nighttime and the mistake in your code was an obvious typo, you probably still had time for another run, so you would get back in line for an IBM 029 keypunch machine and start all over again. You could then hang around the DCL working on the latest round of problems in your quantum mechanics course. However, machine time was incredibly expensive in those days and you had a very limited budget for machine charges. So if there was some kind of logical error in your code, many times you had to head back to the dorm for some more desk checking of your code before giving it another shot the next day.

Figure 7 - An IBM 029 keypunch machine like the one I first learned to program on at the University of Illinois in 1972.

Figure 8 - Each card could hold a maximum of 80 bytes. Normally, one line of code was punched onto each card.

Figure 9 - The cards for a program were held together into a deck with a rubber band, or for very large programs, the deck was held in a special cardboard box that originally housed blank cards. Many times the data cards for a run followed the cards containing the source code for a program. The program was compiled and linked in two steps of the run and then the generated executable file processed the data cards that followed in the deck.

Figure 10 - To run a job, the cards in a deck were fed into a card reader, as shown on the left above, to be compiled, linked, and executed by a million-dollar mainframe computer with a clock speed of about 750 KHz and about 1 MB of memory.

Figure 11 - The output of a run was printed on fanfolded paper and placed into an output bin along with your input card deck.

I finished up my B.S. in Physics at the University of Illinois at Urbana in 1973 and headed up north to complete an M.S. in Geophysics at the University of Wisconsin at Madison. Then from 1975 – 1979, I was an exploration geophysicist exploring for oil, first with Shell, and then with Amoco. I kept coding Fortran the whole time. In 1979, I made a career change into IT and spent about 20 years in development. For the last 17 years of my career, I was in IT operations, supporting middleware on WebSphere, JBoss, Tomcat, and ColdFusion. In 1979, when I became an IT professional in Amoco's IT department, I noticed that not much had changed with the way software was developed and maintained. Structured programming had arrived, so we were now indenting code and adding comment statements to the code, but I was still programming on cards. We were now using IBM 129 keypunch machines that were a little bit more sophisticated than the old IBM 029 keypunch machines. However, the coding process was still very much the same. I worked on code at my desk and still spent a lot of time desk checking the code. When I was ready for my next run, I would get into an elevator and travel down to the basement of the Amoco Building where the IBM mainframes were located. Then I would punch my cards on one of the many IBM 129 keypunch machines but this time with no waiting for a machine. After I submitted my deck, I would travel up 30 floors to my cubicle to work on something else. After a couple of hours, I would head down to the basement again to collect my job. On a good day, I could manage to get 4 runs in. But machine time was still incredibly expensive. If I had a $100,000 project, $25,000 went for programming time, $25,000 went to IT overhead like management and data management services costs, and a full $50,000 went to machine costs for compiles and test runs!

This may all sound very inefficient and tedious today, but it can be even worse. When I first changed careers to become an IT professional in 1979, I used to talk to the old-timers about the good old days of IT. They told me that when the operators began their shift on an old-time 1950s vacuum tube computer, the first thing they did was to crank up the voltage on the vacuum tubes to burn out the tubes that were on their last legs. Then they would replace the burned-out tubes to start the day with a fresh machine. They also explained that the machines were so slow that they spent all day processing production jobs. Emergency maintenance work to fix production bugs was allowed at night, but new development was limited to one compile and test run per week! They also told me about programming the plugboards of electromechanical Unit Record Processing machines back in the 1950s by physically rewiring the plugboards. The Unit Record Processing machines would then process hundreds of punch cards per minute by routing the punch cards from machine to machine in processing streams.

Figure 12 – In the 1950s Unit Record Processing machines like this card sorter were programmed by physically rewiring a plugboard.

Figure 13 – The plugboard for a Unit Record Processing machine.

Using Software to Write Software
But all of this was soon to change. In the early 1980s, the IT department of Amoco switched to using TSO running on dumb IBM 3278 terminals to access IBM mainframes. We now used a full-screen editor called ISPF running under TSO on the IBM 3278 terminals to write code and submit jobs, and our development jobs usually ran in less than an hour. The source code for our software files was now on disk in partitioned datasets for easy access and updating. The data had moved to tapes and it was the physical process of mounting and unmounting tapes that now slowed down testing. For more on tape processing see: An IT Perspective on the Origin of Chromatin, Chromosomes and Cancer. Now I could run maybe 10 jobs in one day to test my code! However, machine costs were still incredibly high and still accounted for about 50% of project costs, so we still had to do a lot of desk checking to save on machine costs. At first, the IBM 3278 terminals appeared on the IT floor in "tube rows" like the IBM 029 keypunch machines of yore. But after a few years, each IT professional was given their own IBM 3278 terminal on their own desk. Finally, there was no more waiting in line for an input device!

Figure 14 - The IBM ISPF full-screen editor ran on IBM 3278 terminals connected to IBM mainframes in the late 1970s. ISPF was also a screen-based interface to TSO (Time Sharing Option) that allowed programmers to do things like copy files and submit batch jobs. ISPF and TSO running on IBM mainframes allowed programmers to easily reuse source code by doing copy/paste operations with the screen editor from one source code file to another. By the way, ISPF and TSO are still used today on IBM mainframe computers to support writing and maintaining software.

I found that the use of software to write and maintain software through the use of ISPF dramatically improved software development and maintenance productivity. It was like moving from typing term papers on manual typewriters to writing term papers on word processors. It probably improved productivity by a factor of at least 10 or more. In the early 1980s, I was very impressed by this dramatic increase in productivity that was brought on by using software to write and maintain software. I was working on softwarephysics at the time, and the findings of softwarephysics led me to believe that what programmers really needed was an integrated software tool that would help to automate all of the tedious and repetitious activities of writing and maintaining software. This would allow programmers to overcome the effects of the second law of thermodynamics in a highly nonlinear Universe - for more on that see The Fundamental Problem of Software. But how?

BSDE - An Early Software IDE Founded On Biological Principles
I first began by slowly automating some of my mundane programming activities with ISPF edit macros written in REXX. In SoftwarePhysics I described how this automation activity slowly grew into the development of BSDE - the Bionic Systems Development Environment back in 1985 while in the IT department of Amoco. I am going to spend a bit of time on BSDE because I think it highlights the similarities between writing and maintaining computer software and biological software and the value of having an IDE for each.

BSDE slowly evolved into a full-fledged mainframe-based IDE, like Microsoft's modern Visual Studio, over a number of years at a time when software IDEs did not exist. During the 1980s, BSDE was used to grow several million lines of production code for Amoco by growing applications from embryos. For an introduction to embryology see Software Embryogenesis. The DDL statements used to create the DB2 tables and indexes for an application were stored in a sequential file called the Control File and performed the functions of genes strung out along a chromosome. Applications were grown within BSDE by turning their genes on and off to generate code. BSDE was first used to generate a Control File for an application by allowing the programmer to create an Entity-Relationship diagram using line printer graphics on an old IBM 3278 terminal.

Figure 15 - BSDE was run on IBM 3278 terminals, using line printer graphics, and in a split-screen mode. The embryo under development grew within BSDE on the top half of the screen, while the code generating functions of BSDE were used on the lower half of the screen to insert code into the embryo and to do compiles on the fly while the embryo ran on the upper half of the screen. Programmers could easily flip from one session to the other by pressing a PF key.

After the Entity-Relationship diagram was created, the programmer used a BSDE option to create a skeleton Control File with DDL statements for each table on the Entity-Relationship diagram and each skeleton table had several sample columns with the syntax for various DB2 datatypes. The programmer then filled in the details for each DB2 table. When the first rendition of the Control File was completed, another BSDE option was used to create the DB2 database for the tables and indexes on the Control File. Another BSDE option was used to load up the DB2 tables with test data from sequential files. Each DB2 table on the Control File was considered to be a gene. Next, a BSDE option was run to generate an embryo application. The embryo was a 10,000 line of code PL/1, Cobol or REXX application that performed all of the primitive functions of the new application. The programmer then began to grow the embryo inside of BSDE in a split-screen mode. The embryo ran on the upper half of an IBM 3278 terminal and could be viewed in real-time, while the code generating options of BSDE ran on the lower half of the IBM 3278 terminal. BSDE was then used to inject new code into the embryo's programs by reading the genes in the Control File for the embryo in a real-time manner while the embryo was running in the top half of the IBM 3278 screen. BSDE had options to compile and link modified code on the fly while the embryo was still executing. This allowed for a tight feedback loop between the programmer and the application under development. In fact many times BSDE programmers sat with end-users and co-developed software together on the fly in a very Agile manner. When the embryo had grown to full maturity, BSDE was then used to create online documentation for the new application and was also used to automate the install of the new application into production. Once in production, BSDE generated applications were maintained by adding additional functions to their embryos.

Since BSDE was written using the same kinds of software that it generated, I was able to use BSDE to generate code for itself. The next generation of BSDE was grown inside of its maternal release. Over a period of seven years, from 1985 – 1992, more than 1,000 generations of BSDE were generated, and BSDE slowly evolved in an Agile manner into a very sophisticated tool through small incremental changes. BSDE dramatically improved programmer efficiency by greatly reducing the number of buttons programmers had to push in order to generate software that worked.

Figure 15 - Embryos were grown within BSDE in a split-screen mode by transcribing and translating the information stored in the genes in the Control File for the embryo. Each embryo started out very much the same but then differentiated into a unique application based upon its unique set of genes.

Figure 16 – BSDE appeared as the cover story of the October 1991 issue of the Enterprise Systems Journal

BSDE had its own online documentation that was generated by BSDE. Amoco's IT department also had a class to teach programmers how to get started with BSDE. As part of the curriculum Amoco had me prepare a little cookbook on how to build an application using BSDE:

BSDE – A 1989 document describing how to use BSDE - the Bionic Systems Development Environment - to grow applications from genes and embryos within the maternal BSDE software.

I wish that I could claim that I was smart enough to have sat down and thought up all of this stuff from first principles, but that is not what happened. It all just happened through small incremental changes in a very Agile manner over a very long period of time and most of the design work was done subconsciously, if at all. Even the initial BSDE ISPF edit macros happened through serendipity. When I first started programming DB2 applications, I found myself copying in the DDL CREATE TABLE statements from the file I used to create the DB2 database into the program that I was working on. This file, with the CREATE TABLE statements, later became the Control File used by BSDE to store the genes for an application. I would then go through a series of editing steps on the copied in data to transform it from a CREATE TABLE statement into a DB2 SELECT, INSERT, UPDATE, or DELETE statement. I would do the same thing all over again to declare the host variables for the program. Being a lazy programmer, I realized that there was really no thinking involved in these editing steps and that an ISPF edit macro could do the job equally as well, only very quickly and without error, so I went ahead and wrote a couple of ISPF edit macros to automate the process. I still remember the moment when it first hit me. For me, it was very much like the scene in 2001 - A Space Odyssey when the man-ape picks up a wildebeest thighbone and starts to pound the ground with it. My ISPF edit macros were doing the same thing that happens when the information in a DNA gene is transcribed into a protein! A flood of biological ideas poured into my head over the next few days, because at last, I had a solution for my pent-up ideas about nonlinear systems and the second law of thermodynamics that were making my life so difficult as a commercial software developer. We needed to "grow" code – not write code!

BSDE began as a few simple ISPF edit macros running under ISPF edit. ISPF is the software tool that mainframe programmers still use today to interface to the IBM MVS and VM/CMS mainframe operating systems and contains an editor that can be greatly enhanced through the creation of edit macros written in REXX. I began BSDE by writing a handful of ISPF edit macros that could automate some of the editing tasks that a programmer needed to do when working on a program that used a DB2 database. These edit macros would read a Control File, which contained the DDL statements to create the DB2 tables and indexes. The CREATE TABLE statements in the Control File were the equivalent of genes, and the Control File itself performed the functions of a chromosome. For example, a programmer would retrieve a skeleton COBOL program, with the bare essentials for a COBOL/DB2 program, from a stock of reusable BSDE programs. The programmer would then position their cursor in the code to generate a DB2 SELECT statement and hit a PFKEY. The REXX edit macro would read the genes in the Control File and would display a screen listing all of the DB2 tables for the application. The programmer would then select the desired tables from the screen, and the REXX edit macro would then copy the selected genes to an array (mRNA). The mRNA array was then sent to a subroutine that inserted lines of code (tRNA) into the COBOL program. The REXX edit macro would also declare all of the SQL host variables in the DATA DIVISION of the COBOL program and would generate code to check the SQLCODE returned from DB2 for errors and take appropriate actions. A similar REXX ISPF edit macro was used to generate screens. These edit macros were also able to handle PL/1 and REXX/SQL programs. They could have been altered to generate the syntax for any programming language such as C, C++, or Java. As time progressed, BSDE took on more and more functionality via ISPF edit macros. Finally, there came a point where BSDE took over and ISPF began to run under BSDE. This event was very similar to the emergence of the eukaryotic architecture for cellular organisms. BSDE consumed ISPF like the first eukaryotic cells that consumed prokaryotic bacteria and used them as mitochondria and chloroplasts. With continued small incremental changes, BSDE continued to evolve.

I noticed that I kept writing the same kinds of DB2 applications, with the same basic body plan, over and over. At the time I did not know it, but these were primarily applications using the Model-View-Controller (MVC) design pattern. The idea of using design patterns had not yet been invented in computer science and IT, so my failing to take note of this is understandable. For more on the MVC design pattern please see Software Embryogenesis. From embryology, I got the idea of using BSDE to read the Control File for an application and to generate an "embryo" for the application based on its unique set of genes. The embryo would perform all of the things I routinely programmed over and over for a new application. Once the embryo was generated for a new application from its Control File, the programmer would then interactively "grow" code and screens for the application. With time, each embryo differentiated into a unique individual application in an Agile manner until the fully matured application was delivered into production by BSDE. At this point, I realized that I could use BSDE to generate code for itself, and that is when I started using BSDE to generate the next generation of BSDE. This technique really sped up the evolution of BSDE because I had a positive feedback loop going. The more powerful BSDE became, the faster I could add improvements to the next generation of BSDE through the accumulated functionality inherited from previous generations.

Embryos were grown within BSDE using an ISPF split-screen mode. The programmer would start up a BSDE session and run Option 4 – Interactive Systems Development from the BSDE Master Menu. This option would look for an embryo, and if it did not find one, it would offer to generate an embryo for the programmer. Once an embryo was implanted, the option would turn the embryo on and the embryo would run inside of the BSDE session with whatever functionality it currently had. The programmer would then split his screen with PF2 and another BSDE session would appear in the lower half of his terminal. The programmer could easily toggle control back and forth between the upper and lower sessions with PF9. The lower session of BSDE was used to generate code and screens for the embryo on the fly, while the embryo in the upper BSDE session was fully alive and functional. This was possible because BSDE generated applications that used ISPF Dialog Manager for screen navigation, which was an interpretive environment, so compiles were not required for screen changes. If your logic was coded in REXX, you did not have to do compiles for logic changes either, because REXX was an interpretive language. If PL/1 or COBOL were used for logic, BSDE had facilities to easily compile code for individual programs after a coding change, and ISPF Dialog Manager would simply load the new program executable when that part of the embryo was exercised. These techniques provided a tight feedback loop so that programmers and end-users could immediately see the effects of a change as the embryo grew and differentiated.

Unfortunately, the early 1990s saw the downfall of BSDE. The distributed computing model hit with full force, and instead of deploying applications on mainframe computers, we began to distribute applications across a network of servers and client PCs. Since BSDE generated applications for mainframe computers, it could not compete, and BSDE quickly went extinct in the minds of Amoco IT management. I was left with just a theory and no tangible product, and it became much harder to sell softwarephysics at that point. So after a decade of being considered a little "strange", I decided to give it a rest, and I began to teach myself how to write C and C++ software for Unix servers and PCs. I started out with the Microsoft C/C++ C7 compiler which was a DOS application for writing C/C++ DOS applications. But I converted to Microsoft Visual C/C++ when it first came out in 1993. Microsoft Visual C/C++ was Microsoft's first real IDE and the predecessor to Microsoft's modern Visual Studio IDE. Visual C/C++ was so powerful that I knew that a PC version of BSDE could never compete, so I abandoned all thoughts of producing a PC version of BSDE.

Conclusion
I think that the impact that software development IDEs had on the history of software development and maintenance in the 20th century strongly suggests that Microsoft's Project B to build an IDE for biological programming will surely provide a similar dramatic leap in biological programming productivity in the 21st century, and this will allow for the harnessing of the tremendous power that self-replicating biological systems can provide.

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

Life is Like a Box of Timelines

In my last posting Digital Physics and the Software Universe, we covered the idea that our Universe might seem to behave like a large network of quantum computers calculating how to behave, if not in an actual literal sense as the realists would have us believe, at least, perhaps, in a positivistic manner that makes for a good model that yields useful predictions about how our Universe seems to behave. Recall that positivism is an enhanced form of empiricism, in which we do not care about how things “really” are; we are only interested in how things are observed to behave. With positivism, physicists only seek out models of reality - not reality itself. In keeping with that observation, I would like to recommend two offerings on Netflix. Now if you do not currently have Netflix, you can easily stream it for free for 30 days on a trial basis, so I do not feel conflicted about making this recommendation. The first recommendation comes from the Black Mirror series on Netflix that features stories from the dark side of IT. This particular Black Mirror feature is an interactive movie entitled Bandersnatch. The second recommendation is the Netflix series entitled Russian Doll. Both Bandersnatch and the Russian Doll are based on the idea that our Universe may be composed of software running on some kind of cosmic quantum computer, and both feature a computer game developer operating under a tight deadline for a new computer game. While Bandersnatch takes place in 1984 and the Russian Doll series takes place in the present day, both convey the time-pressures that developers experience while working on new code under a tight deadline, but with a twist. In both features, the computer game developers slowly come to the realization that they are caught in some kind of "bad" cosmic code themselves that keeps looping in time. In fact, the line "Life is Like a Box of Timelines" comes from the Russian Doll. Both developers then try to debug and fix the bad cosmic code that they are stuck in. As with all code, debugging and fixing bad cosmic code can be very frustrating and time-consuming. It takes many runs of the bad code with trial code fixes to unit test the cosmic code until it finally performs as intended - see How Software Evolves for more on that.

Fortunately, for the last few decades, we have had IDEs (Integrated Development Environments) like Eclipse that allow developers to step through bad code and watch the variables change with time and also to follow the code logic to see how the code branches at various conditional branch-points. In an IDE, you can also set breakpoints at various points in the code that allow the code to run until the breakpoint is reached. When a breakpoint is reached, the code then stops executing and the developer can then examine the state of all the current code variables. At a breakpoint, the developer can even change the value of a variable on the fly in order to run the code down a different logical path at a conditional branch-point than the code would normally run. Bandersnatch allows the viewer to do this very same thing. At certain points in Bandersnatch, a breakpoint is reached and the viewer then gets to choose which path the cosmic code takes. This allows the viewer to interactively run through the Bandersnatch cosmic code nearly an infinite number of different ways. However, sometimes the viewer will run down a dead-end code path that causes the cosmic code to complete and the credits then begin to roll. At that point, you have to rerun the Bandersnatch cosmic code from the very beginning again. Here is a tip. The Bandersnatch cosmic code also seems to run in the background as a daemon process when you stop debugging the code and come back several hours later. So do not be surprised when you come back and start up Bandersnatch again and find yourself in a different section of the cosmic code than you previously left. All developers should be quite familiar with all of these debugging activities and, therefore, should find debugging cosmic code to be fairly straightforward. Now, in Digital Physics and the Software Universe, we saw that some very bright people hold the position that the best model for explaining the very strange way that our Universe behaves at the microscopic level of atoms and particles is to think of the Universe as some kind of cosmic code running in a quantum-mechanical IDE. But for that, you need some understanding of quantum mechanics. For a brief introduction to quantum mechanics see Quantum Software.

The reason why you will find quantum mechanics useful is that both Bandersnatch and the Russian Doll are based on the idea that our Universe may be composed of software running on some kind of network of cosmic quantum computers, and therefore, also bring in some of the more mind-bending ideas to be found in some of the more esoteric interpretations of quantum mechanics. It should be noted that the more esoteric interpretations of quantum mechanics are also now more important because the classic Copenhagen Interpretation of quantum mechanics no longer seems to carry the weight that it once did many long decades ago. For example, in Quantum Computing and the Many-Worlds Interpretation of Quantum Mechanics we covered Hugh Everett's Many-Worlds Interpretation of quantum mechanics and in Is the Universe a Quantum Computer? we covered John Cramer's Transactional Interpretation of quantum mechanics. Reading both of those postings in advance would help to clarify some of the strange scenes found in both of my Netflix recommendations. For example, in order to explain the strange quantum-mechanical effects that we observe in the lab, the Many-Worlds Interpretation of quantum mechanics relies on timelines in multiple parallel Universes, while the Transactional Interpretation of quantum mechanics relies on a Universe that features multiple timelines moving both forwards and backwards in time at the same time. And both Bandersnatch and the Russian Doll have scenes that display such phenomena. Now to make it a bit easier to understand such phenomena, let us briefly review the Copenhagen Interpretation, the Many-Worlds Interpretation, the Transactional Interpretation and the Decoherence Interpretation of quantum mechanics. But in order to do that we need to know a bit about quantum mechanics and how physicists use the wave model to explain certain phenomena.

The Wave Model
The chief characteristic of the wave model is that waves tend to be everywhere, but nowhere in particular, at the same time and simultaneously explore all possible paths. To see a wave in action, drop a small pebble into a still pond of water containing many obstacles and watch the resulting waves spread out and reflect off the obstacles and interfere with each other before eventually reaching a particular destination near the edge of the pond.

In 1801, Thomas Young conducted a series of experiments with waves. First, using water waves in a shallow ripple tank, he demonstrated the concept of interference. When a water wave encounters a barrier with two slits, the ripples passing through the slits interfere with each other on the other side of the barrier (Figure 1). Where two crests intersect, the wave amplitude doubles in height, and where a crest meets a trough, the two waves cancel each other out entirely. Next, Young used a distant light source with two closely spaced slits in an opaque barrier. On the other side of the barrier, he placed a white projection screen. When light from the distant light source passed through the double-slit barrier, Young observed an interference pattern of alternating bright and dark fringes projected onto the screen which demonstrated the wavelike behavior of light.

Figure 1 – The interference pattern from two slits (click to enlarge)

You can easily repeat Young’s experiment with a piece of thin cloth. At night, hold up a single ply of a pillowcase in front of a distant light source, such as a far-off street light or the filament in your neighbor’s decorative front door light that uses a clear light bulb. Instead of a single diffuse spot of light shining through the pillowcase, you will see a pronounced checkerboard interference pattern of spots, because the weave of your pillowcase has both vertical and horizontal slits between the threads.

The Birth of Modern Quantum Mechanics
As we saw in Quantum Software, Erwin Schrödinger first developed the Schrödinger equation in the winter of 1926 to explain the strange behavior of electrons in atoms and the fact that the electrons only radiated light at certain frequencies when excited. The 1-dimensional version of this famous equation is:

-ħ²    ∂²Ψ  =  iħ ∂Ψ
──      ──            ──
2m    ∂x²            ∂t

In the above 1-dimensional Schrödinger equation, Ψ is called the wavefunction of a particle and is pronounced like the word “sigh”. In quantum mechanics, the wavefunction Ψ contains all of the information that can ever be known about the particle.

Now if the particle is just quietly sitting around on its own and not interacting with other particles, like an electron that has been sitting quietly in an atom for a billion years, it means the wavefunction Ψ should not be changing with time, and we can use the 1-dimensional time-independent version of the Schrödinger equation that does not have the time variable "t" in the equation:

-ħ²  d²ψ(x)   +   V(x) ψ(x)  =  E ψ(x)
──  ──────
2m     dx²

The lower-case wavefunction ψ is still pronounced like the word "sigh", but we use the lower-case ψ to signify that this is a time-independent wavefunction that does not change with time. When the 3-dimensional Schrödinger equation is solved for the hydrogen atom consisting of just one electron trapped by one proton in an electromagnetic well we get a number of quantized wavefunctions as solutions:

Figure 2 – The n=1 and n=2 orbitals or wavefunctions for the hydrogen atom.

The Strange Motion of Quantum Particles in Space and Time
Now for quantum particles like electrons or photons that are on the move we need to use Richard Feynman’s "sum over histories" approach to quantum mechanics. In Feynman's "sum over histories" approach to quantum mechanics, the wavefunction amplitude of an electron or photon is the same in all directions, like when you drop a pebble in a still pond, but the phase angles of the wavefunction will differ depending upon the path that is taken. So to figure out the probability of finding an electron or photon at a particular point, you have to add up the amplitudes and phases of all the possible paths that the electron or photon could have taken to reach the destination point. Although there are an infinite number of possible paths, the key insight is that most of the paths will be out of phase with each other and will cancel out like the destructive interference shown in Figure 1. This produces some rather strange experimental observations. Imagine a very dim source of photons or electrons that can fire one photon or electron at a time. If we fired the particles at a screen with two slits, as in Young’s experiment, we would expect to see a pattern similar to Figure 3 build up over time, based upon the particle model for electrons and photons.

Figure 3 – What common sense and the particle model would predict for a source that fires electrons or photons one at a time

However, what is actually observed is an interference pattern similar to Figure 4, even though the electrons or photons pass through the slits one at a time. According to quantum mechanics, the individual electrons or photons interfere with themselves as they go through both slits at the same time! This means that if your neighbor could turn down the light by his front door to a very low level, so that it only emitted one photon at a time, and your eye could record a long exposure image, you would still see a checkerboard pattern of light spots through your pillowcase, even though the photons went through the fabric mesh one at a time.

Figure 4 – We actually observe an interference pattern as each particle interferes with itself

Now here comes the really strange part. If we put detectors just in front of the slits so that we can record which slit the electron or photon actually passed through, and keep firing one particle at a time, the interference pattern will disappear, and we will see the pattern in Figure 3 instead. If we turn the detectors off, the interference pattern returns, and we see the pattern in Figure 4. For some reason, Nature will not allow us to observe electrons or photons behaving like particles and waves at the same time. It’s some kind of information thing again. But it gets worse. If we put the detectors at some distance behind the slits and turn them on, the interference pattern again disappears, but if we turn the detectors off, the interference pattern returns. Now, this is after the electrons or photons have already passed through the slits! How do they know whether to behave like a wave or a particle in advance, before they know if the detectors are on or off? In fact, experiments have been performed where the decision to turn the detectors on or off is not made until after the individual electrons or photons have already passed through the slits, but even so, if the detectors are turned on, the interference pattern disappears, and if the detectors are turned off, the interference pattern returns! This means that the present can change the past! This is the famous delayed-choice experiment proposed by John Wheeler in 1978 and actually performed by Alain Aspect and his colleagues in 1982. In another experiment, the detectors are placed beyond the observation screen to detect cloned photons that are created in a splitting process. By observing the cloned photons, it is possible to determine which slit an individual twin photon passed through after its twin has already hit the observation screen. When these distant detectors are turned on, the interference pattern once again disappears, and if the detectors are turned off, the interference pattern returns. Again, the decision to turn the detectors on or off can be made after the photons have already hit the observation screen. This means that the future can change the present!

In 1928, Paul Dirac combined quantum mechanics (1926) with the special theory of relativity (1905) and came up with a relativistic reformulation of the Schrödinger equation. Now, strangely, the solutions to Dirac’s equation predicted both the existence of electrons with a negative charge and positive mass energy and also positrons, the antimatter equivalent of electrons, with a positive charge and a negative mass energy. But in 1947 Richard Feynman came up with an alternate interpretation for Dirac’s positrons with negative mass energy. Feynman proposed that positrons were actually normal electrons moving backwards in time! Recall that the full-blown wave function of an object with constant energy can be expressed as a time-independent wavefunction ψ(x) multiplied by a time-varying term:

Ψ(x, t)  =  e^-iEt/ħ  ψ(x)

Now the solutions to Dirac’s equation predicted both the existence of electrons with positive mass energy and also positrons, the antimatter equivalent of electrons, with negative mass energy. For a particle with negative mass energy, the above equation looks like:

Ψ(x, t)  =  e^-i(-E)t/ħ  ψ(x)

but since:

-i(-E)t/ħ = -iE(-t)/ħ

Feynman realized that an equivalent equation could be written by simply changing the parenthesis yielding:

Ψ(x, t)  =  e^-iE(-t)/ħ  ψ(x)

So a positron with negative mass energy –E could mathematically be thought of as a regular old electron with positive mass energy E moving backwards in time! Indeed, today that is the preferred interpretation. All antimatter is simply regular matter moving backwards in time.

Figure 5 – Above is a Feynman diagram showing an electron colliding with a positron, the antimatter version of an electron.

In Figure 5 we see an electron colliding with a positron, the antimatter version of an electron. When the two particles meet they annihilate each other and turn into two γ gamma rays. In the Feynman diagram, space runs along the horizontal axis and time runs along the vertical axis. In the diagram, we see an electron e^- with negative charge and positive mass energy on the left and a positron e⁺ with positive charge and negative mass energy on the right. As time progresses up the vertical time axis, we see the electron e^- and the positron e⁺ approach each other along the horizontal space axis. When the two particles get very close, they annihilate each other and we see two γ gamma rays departing the collision as time proceeds along the vertical time axis. But notice the red arrowheads on the red arrow lines in the Feynman diagram. The red arrowhead for the negative electron e^- is moving upwards on the diagram and forward in time, while the positive positron e⁺ is moving downwards on the diagram and backwards in time! So in the diagram, the positive positron e⁺ is portrayed as an ordinary negative electron e^- moving backwards in time!

The Copenhagen Interpretation of Quantum Mechanics
In 1927, Niels Bohr and Werner Heisenberg proposed a very positivistic interpretation of quantum mechanics now known as the Copenhagen Interpretation. You see, Bohr was working at the University of Copenhagen Institute of Theoretical Physics at the time. The Copenhagen Interpretation contends that absolute reality does not really exist. Instead, there are an infinite number of potential realities, defined by the wavefunction ψ of a quantum system, and when we make a measurement of a quantum system, the wavefunction of the quantum system collapses into a single value that we observe, and thus brings the quantum system into reality (see Quantum Software for more on wavefunctions). This satisfied Max Born’s contention that wavefunctions are just probability waves. The Copenhagen Interpretation suffers from several philosophical problems though. For example, Eugene Wigner pointed out that the devices we use to measure quantum events are also made out of atoms which are quantum objects in themselves, so when an observation is made of a single atom of uranium to see if it has gone through a radioactive decay using a Geiger counter, the atomic quantum particles of the Geiger counter become entangled in a quantum superposition of states with the uranium atom. If the uranium has decayed, then the uranium atom and the Geiger counter are in one quantum state, and if the atom has not decayed, then the uranium atom and the Geiger counter are in a different quantum state. If the Geiger counter is fed into an amplifier, then we have to add in the amplifier too into our quantum superposition of states. If a physicist is patiently listening to the Geiger counter, we have to add him into the chain as well, so that he can write and publish a paper which is read by other physicists and is picked up by Time magazine for a popular presentation to the public. So when does the “measurement” actually take place? We seem to have an infinite regress. Wigner’s contention is that the measurement takes place when a conscious being first becomes aware of the observation. Einstein had a hard time with the Copenhagen Interpretation of quantum mechanics for this very reason because he thought that it verged upon solipsism. Solipsism is a philosophical idea from Ancient Greece. In solipsism, your Mind is the whole thing, and the physical Universe is just a figment of your imagination. So I would like to thank you very much for thinking of me and bringing me into existence! Einstein’s opinion of the Copenhagen Interpretation of quantum mechanics can best be summed up by his statement "Is it enough that a mouse observes that the Moon exists?". Einstein objected to the requirement for a conscious being to bring the Universe into existence because, in Einstein’s view, measurements simply revealed to us the condition of an already existing reality that does not need us around to make measurements in order to exist. But in the Copenhagen Interpretation, the absolute reality of Einstein does not really exist. Additionally, in the Copenhagen Interpretation, objects do not really exist until a measurement is taken, which collapses their associated wavefunctions, but the mathematics of quantum mechanics does not shed any light on how a measurement could collapse a wavefunction.

The collapse of the wavefunction is also a one-way street. According to the mathematics of quantum mechanics a wavefunction changes with time in a deterministic manner, so like all of the other current effective theories of physics, they are reversible in time and can be run backwards. This is also true in the Copenhagen Interpretation, so long as you do not observe the wavefunction and collapse it by the process of observing it. In the Copenhagen Interpretation, once you observe a wavefunction and collapse it, you cannot undo the collapse, so the process of observation becomes nonreversible in time. That means if you fire photons at a target, but do not observe them, it is possible to reverse them all in time and return the Universe back to its original state. That is how all of the other effective theories of physics currently operate. But in the Copenhagen Interpretation, if you do observe the outgoing photons you can never return the Universe back to its original state. This can best be summed up by the old quantum mechanical adage - look particle, don’t look wave. A good way to image this in your mind is to think of a circular tub of water. If you drop a pebble into the exact center of a circular tub of water, a series of circular waves will propagate out from the center. Think of those waves as the wavefunction of an electron changing with time into the future according to the Schrödinger equation. When the circular waves hit the circular walls of the tub they will be reflected back to the center of the tub. Essentially, they can be viewed as moving backwards in time. This can happen in the Copenhagen Interpretation so long as the electron is never observed as its wavefunction moves forward or backward in time. However, if the wavefunction is observed and collapsed, it can never move backwards in time, so observation becomes a one-way street.

The Many-Worlds Interpretation of Quantum Mechanics
In 1956, Hugh Everett working on his Ph.D. under John Wheeler, proposed the Many-Worlds Interpretation of quantum mechanics as an alternative. The Many-Worlds Interpretation admits to an absolute reality but claims that there are an infinite number of absolute realities spread across an infinite number of parallel universes. In the Many-Worlds Interpretation, when electrons or photons encounter a two-slit experiment, they go through one slit or the other, and when they hit the projection screen they interfere with electrons or photons from other universes that went through the other slit! In Everett’s original version of the Many-Worlds Interpretation, the entire Universe splits into two distinct universes whenever a particle is faced with a choice of quantum states, and so all of these universes are constantly branching into an ever-growing number of additional universes. In the Many-Worlds Interpretation of quantum mechanics, the wavefunctions or probability clouds of electrons surrounding an atomic nucleus are the result of overlaying the images of many “real” electrons in many parallel universes. Thus, according to the Many-Worlds Interpretation wavefunctions never collapse. They just deterministically evolve in an abstract mathematical Hilbert space and are reversible in time, like everything else in physics.

Because Einstein detested the Copenhagen interpretation of quantum mechanics so much, he published a paper in 1935 with Boris Podolsky and Nathan Rosen which outlined what is now known as the EPR Paradox. But to understand the EPR Paradox we need a little background in experimental physics. Electrons have a quantum mechanical property called spin. You can think of an electron’s spin like the electron has a little built-in magnet. In fact, it is the spin of the little electron magnets that add up to make the real magnets that you put on your refrigerator. Now in quantum mechanics, the spin of a single electron can be both up and down at the same time because the single electron can be in a mixture of quantum states! But in the classical Universe that we are used to, macroscopic things like a child's top can only have a spin of up or down at any given time. The top can only spin in a clockwise or counterclockwise manner at one time - it cannot do both at the same time. Similarly, in quantum mechanics, a photon or electron can go through both slits of a double slit experiment at the same time, so long as you do not put detectors at the slit locations.

Figure 6 – A macroscopic top can only spin clockwise or counterclockwise at one time.

Figure 7 – But electrons can be in a mixed quantum mechanical state in which they both spin up and spin down at the same time.

Figure 8 – Similarly, tennis balls can only go through one slit in a fence at a time. They cannot go through both slits of a fence at the same time.

Figure 9 – But at the smallest of scales in our quantum mechanical Universe, electrons and photons can go through both slits at the same time, producing an interference pattern.

Figure 10 – You can see this interference pattern of photons if you look at a distant porch light through the mesh of a sheer window curtain or a pillowcase.

When you throw an electron through a distorted magnetic field that is pointing up the electron will pop out in one of two states. It will either be aligned with the magnetic field (called spin-up) or it will be pointing 180^o in the opposite direction of the magnetic field (called spin-down). Both the spin-up and spin-down conditions are called an eigenstate. Prior to the observation of the electron’s spin, the electron is in a superposition of states and is not in an eigenstate. Now if the electron in the eigenstate of spin-up is sent through the same magnetic field again, it will be found to pop out in the eigenstate of spin-up again. Similarly, a spin-down electron that is sent through the magnetic field again will also pop out as a spin-down electron. Now here is the strange part. If you rotate the magnetic field by 90^o and send spin-up electrons through it, 50% of the electrons will pop out with a spin pointing to the left, and 50% will pop out with a spin pointing to the right. And you cannot predict in advance which way a particular spin-up electron will pop out. It might spin to the left, or it might spin to the right. The same goes for the spin-down electrons – 50% will pop out spinning to the left and 50% will pop out spinning to the right.

Figure 11 - In the Stern-Gerlach experiment we shoot electrons through a distorted magnetic field. Classically, we would expect the electrons to be spinning in random directions and the magnetic field should deflect them in random directions, creating a smeared out spot on the screen. Instead, we see that the act of measuring the spins of the electrons puts them into eigenstates with eigenvalues of spin-up or spin-down and the electrons are either deflected up or down. If we rotate the magnets by 90^o, we find that the electrons are deflected to the right or to the left.

The EPR Paradox goes like this. Suppose we prepare many pairs of quantum mechanically “entangled” electrons that conserve angular momentum. Each pair consists of one spin-up electron and one spin-down electron, but we do not know which is which at the onset. Now let the pairs of electrons fly apart and let two observers measure their spins. If observer A measures an electron there will be a 50% probability that he will find a spin-up electron and a 50% chance that he will find a spin-down electron, and the same goes for observer B, 50% of observer’s B electrons will be found to have a spin-up, while 50% will be found with a spin-down. Now the paradox of the EPR paradox, from the perspective of the Copenhagen Interpretation, is that when observer A and observer B come together to compare notes, they find that each time observer A found a spin-up electron, observer B found a spin-down electron, even though the electrons did not know which way they were spinning before the measurements were performed. Somehow when observer A measured the spin of an electron, it instantaneously changed the spin of the electron that observer B measured. Einstein hated this “spooky action at a distance” feature of the Copenhagen Interpretation that made physics nonlocal, meaning that things that were separated by great distances could still instantaneously change each other. He thought that it violated the speed of light speed limit of his special theory of relativity that did not allow information to travel faster than the speed of light. Einstein thought that the EPR paradox was the final nail in the coffin of quantum mechanics. There had to be some “hidden variables” that allowed electrons to know if they “really” were a spin-up or spin-down electron. You see, for Einstein, absolute reality really existed. For Einstein, the apparent probabilistic nature of quantum mechanics was an illusion, like the random() function found in most computer languages. The random() function just points to a table of apparently random numbers that are totally predictable if you look at the table in advance. You normally initiate the random() function with a “seed” from the system clock of the computer you are running on to simulate randomness by starting at different points in the table.

However, in 1964 John S. Bell published a paper in which he proposed an experiment that could actually test the EPR Paradox. In the 1980s and 1990s, a series of experiments were indeed performed that showed that Einstein was actually wrong. Using photons and polarimeters, instead of the spin of electrons, these experiments showed that photons really do not know their quantum states in advance of being measured and that determining the polarization of a photon by observer A can immediately change the polarization of another photon 60 miles away. These experiments demonstrated that the physical Universe is non-local, meaning that Newton’s spooky “action at a distance” is built into our Universe, at least for entangled quantum particles. This might sound like a violation of the special theory of relativity because it seems like we are sending an instantaneous message faster than the speed of light, but that is really not the case. Both observer A and observer B will measure photons with varying polarizations at their observing stations separated by 60 miles. Only when observer A and observer B come together to compare results will they realize that their observations were correlated, so it is impossible to send a message with real information using this experimental scheme. Clearly, our common-sense ideas about space and time are still lacking, and so are our current effective theories.

Hugh Everett solves this problem by letting the electrons be in all possible spin states in a large number of parallel universes. When observers measure the spin of an electron, they really do not measure the spin of the electron. They really measure in which universe they happen to be located in, and since everything in the Many-Worlds Interpretation relies on “correlated” composite wavefunctions, it should come as no surprise that when observer A and observer B come together, they find that their measurements of the electron spins are correlated. In the Many-Worlds Interpretation, Hugh Everett proposes that when a device, like our magnets above, measures the spin of an electron that is in an unknown state, and not in a spin-up or spin-down eigenstate, the device does not put the electron into a spin-up or spin-down eigenstate as the Copenhagen Interpretation maintains. Instead, the device and the electron enter into a correlated composite system state or combined wavefunction with an indeterminate spin of the electron. Hugh Everett explains how this new worldview can be used to explain what we observe in the lab. In fact, he proposes that from the perspective of the measuring magnets and the electron, two independent observational histories will emerge, one with the measuring magnets finding a spin-up electron and one with the measuring magnets finding a spin-down electron, and both of these will be just as “real” as the other. For them, the Universe has essentially split in two, with each set in its own Universe. That is where the “Many-Worlds” in the Many-Worlds Interpretation of quantum mechanics comes from.

While doing research for The Software Universe as an Implementation of the Mathematical Universe Hypothesis I naturally consulted Max Tegmark’s HomePage at:

http://space.mit.edu/home/tegmark/mathematical.html

and I found a link there to Hugh Everett’s original 137-page Jan 1956 draft Ph.D. thesis in which he laid down the foundations for the Many-Worlds Interpretation. This is a rare document indeed because on March 1, 1957, Everett submitted a very compressed version of his theory in his final 36-page doctoral dissertation, "On the Foundations of Quantum Mechanics", after heavy editing by his thesis advisor John Wheeler to make his Ph.D. thesis more palatable to the committee that would be hearing his oral defense and also to not offend Niels Bohr, one of the founding fathers of the Copenhagen Interpretation and still one of its most prominent proponents. But years later John Wheeler really did want to know what Niels Bohr thought of Hugh Everett’s new theory and encouraged Everett to visit Copenhagen in order to meet with Bohr. Everett and his wife did finally travel to Copenhagen in March of 1959 and spent six weeks there. But by all accounts, the meeting between Bohr and Everett was a disaster, with Bohr not even discussing the Many-Worlds Interpretation with Everett.

Below is the link to Hugh Everett’s original 137-page Jan 1956 draft Ph.D. thesis:

http://www.pbs.org/wgbh/nova/manyworlds/pdf/dissertation.pdf

I have also placed his thesis on Microsoft One Drive at:

https://onedrive.live.com/redir?resid=21488ff1cf19c88b!1437&authkey=!ADIm_WTYLkbx90I&ithint=file%2cpdf

in Quantum Computing and the Many-Worlds Interpretation of Quantum Mechanics, I step through the above document page-by-page and offer up a translation of the mathematics into easily understood terms.

The Transactional Interpretation of Quantum Mechanics
In Is the Universe a Quantum Computer? I covered John Cramer's Transactional Interpretation of quantum mechanics and compared it to TCP/IP transactions on the Internet. In an email exchange with John Cramer, I learned that such a comparison had never been done before. Now in the Copenhagen interpretation of quantum mechanics, the wavefunctions Ψ of particles and photons are not “real” waves, they are only probability waves – just convenient mathematical constructs that don’t “really” exist. But in Cramer’s Transactional Interpretation of quantum mechanics, the wavefunctions Ψ of particles and photons really do exist. For a physics student new to quantum mechanics, this is truly a comforting idea. Before they teach you about quantum mechanics, you go through a lengthy development of wave theory in courses on classical electrodynamics, optics, and differential equations. In all these courses, you only deal with waves that are mathematically real, meaning that these waves have no imaginary parts using the imaginary number i where i² = -1. But in your first course on quantum mechanics, you are introduced to Schrödinger’s equation:

-ħ²    ∂²Ψ  =  iħ ∂Ψ
──      ──            ──
2m    ∂x²            ∂t

and learn that generally, the wavefunction solutions to Schrödinger’s equation contain both real and imaginary parts containing the nasty imaginary number i. Consequently, the conventional wisdom is that the wavefunction solutions to Schrödinger’s equation cannot really exist as real tangible things. They must just be some kind of useful mathematical construct. However, in the same course, you are also taught about Davisson and Germer bouncing electrons off the lattice of a nickel crystal and observing an interference pattern, so something must be waving! I would venture to suggest that nearly all students new to quantum mechanics initially think of wavefunctions as real waves waving in space. Only with great coaxing by their professors do these students “unlearn” this idea with considerable reluctance.

As we saw previously, the imaginary parts of wavefunctions really bothered the founding fathers of quantum mechanics too. Recall that in 1928, Max Born came up with the clever trick of multiplying the wavefunctions Ψ by their complex conjugates Ψ* to get rid of the imaginary parts. To create the complex conjugate of a complex number or function, all you have to do is replace the imaginary number i with –i wherever you see it. According to Born’s conjecture, the probability of things happening in the quantum world are proportional to multiplying the wavefunction by its complex conjugate Ψ*Ψ. Mathematically, this is the same thing as finding the square of the amplitude of the wavefunction. Now earlier in this posting, I mentioned how Richard Feynman pointed out that instead of thinking of positrons having negative mass energy, you could also think of positrons as regular electrons with negative charge moving backwards in time by shifting the position of the “-“ sign in the wavefunction of a positron. But that is just the same thing as using the complex conjugate Ψ* of an electron wavefunction for a positron. So mathematically, we can think of the complex wavefunction of a particle Ψ* as the wavefunction of the particle moving backwards in time. Cramer suggests that Born’s idea of Ψ*Ψ representing the probability of a quantum event is not just a mathematical trick or construct, rather it is the collision of an outgoing “retarded” wave Ψ moving forwards in time with an incoming Ψ* “advanced” wave moving backwards in time. Essentially, John Cramer's Transactional Interpretation of quantum mechanics sees the collision of outgoing “retarded” waves Ψ moving forwards in time with incoming Ψ* “advanced” waves moving backwards in time.

The Transactional Interpretation easily explains all of the apparent paradoxes of quantum mechanics. As we have seen, there is actual experimental evidence that electrons and photons seem to “know” in advance what they will encounter on the other side of a double-slit experiment. This is easily explained by the Transactional Interpretation. The electrons or photons send out retarded waves into the future which interact with whatever lies beyond the slits. If there are detectors that are turned on, the retarded waves interact with them, if there are no detectors, the waves interact with some electrons on a projection screen instead. In either case, an advanced wave is sent backwards in time from the detectors or the projection screen to the point of origin of the electrons or photons so that they “know” how to behave before they get to the two-slit screen.

The Decoherence Interpretation
Quantum decoherence is another popular interpretation of quantum mechanics. In quantum decoherence, there are again a large number of parallel possibilities for the wavefunctions for things like electrons, but many closely related wavefunctions interact with each other and become quantum-mechanically “entangled” with each other in a quantum superposition of states, forming a Universe of their own. This interpretation of quantum mechanics seems to be very popular amongst the quantum mechanical engineers working on quantum computers because they are always fighting with decoherence. Quantum computers are very delicate machines. If you try to measure the output before the run completes, the whole thing will abend. The problem is that the results of a computation are not in our universe alone; we can only obtain a solution to a computation by looking at the interference of the various results in all the parallel universes together. If we try to take a peek before all these parallel runs complete, the whole system of qubits will decohere because we have taken a measurement of the system, and our quantum calculation will crash.

Conclusion
I hope that some of the above quantum-mechanical craziness that we observe in our Universe helps with watching both of the Netflix features Bandersnatch and the Russian Doll. I would also like to thank Netflix for producing these fine quantum-mechanical productions that can help the general public to become more familiar with the phenomena of quantum mechanics and with the potentials of quantum computer software.

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