Saturday, June 18, 2011

Crocheting Software

In Programming Clay I suggested that the muddled origin of computer software might provide a good model for the origin of life on Earth because, since both software and DNA are forms of self-replicating information, they likely shared similar muddled origins. Now in all of my postings on softwarephysics I have associated the origin of software with the development of Konrad Zuse’s Z3 computer in May of 1941, but in Programming Clay I also explained that since the origin of software was such a hodge-podge of precursors, false starts, and failed attempts that it was really impossible to pinpoint an exact date for its origin. For example, in many discussions of the origin of software, the invention of the Jacquard loom by Joseph Marie Jacquard in 1801 is depicted as one of the early precursors of modern computer software. The Jacquard loom automated the weaving process by executing a set of instructions programmed upon a series of punched cards, similar to the punched cards that were later used in the 1950s, 60s and 70s to encode Assembler, Fortran, and Cobol computer programs. Like the Jacquard loom, each card of computer code was compiled into a set of instructions or operations to be performed by a computer, one after another.


Figure 1 – A modern-day Jacquard loom still using punched cards to program the operation of a loom (click to enlarge)


Figure 2 – Punched cards, similar to those used by the Jacquard loom, were later used in the 1950s, 60s and 70s to encode Assembler, Fortran and Cobol computer programs to control the operation of mainframe computers (click to enlarge)

Crafting Software
However, in this posting I would like to discuss another 19th century precursor of computer software – crochet software. My wife Rosalie is a retired M.D. and an avid crocheter, who is also a certified crochet teacher. Rosalie teaches several crochet classes each week at local high schools, community centers and craft stores. She has also published several crochet designs, or patterns, in various crochet books and is a past president of her local chapter of the Crochet Guild of America. Rosalie also teaches knitting classes, and I will discuss the differences between crochet and knitting from an IT perspective a little later as well. So I had a very good local expert on hand to help with the preparation of this posting. In Computer Science as a Technological Craft, I proposed that, as it currently stands, computer science is more of a craft than a science, so perhaps there are a few things that IT professionals can still learn from crochet, since crochet software predates computer software by many centuries. An ongoing theme throughout the postings in this blog on softwarephysics has been that it is always worthwhile to expand one’s horizons by learning from the experiences of others in disciplines outside of traditional IT.

Crochet as a Form of Self-Replicating Information
In Self-Replicating Information I proposed that there are now three forms of self-replicating information on the planet – genes, memes, and software, with software rapidly becoming the dominant form of self-replicating information on Earth:

Self-Replicating Information – Information that persists through time by making copies of itself or by enlisting the support of other things to ensure that copies of itself are made.

The reason that IT professionals might be able to learn from crochet is that, like computer software and DNA, crochet software is a form of self-replicating information that skips down through the generations from one crocheter to the next. Many times mothers will bring in their daughters to one of Rosalie’s crochet classes to help pass along the craft to the next generation, or daughters will attend a class to brush up on the skills that they learned from their mothers or grandmothers as young girls. In a similar manner, the computer programmers of the past have patiently passed down the accumulated knowledge of our craft to the programmers of today. If you Google for “crochet” on the Internet, you will get over 92 million hits, demonstrating that there is a strong and healthy crochet meme-complex out there in cyberspacetime. And judging by the large number of hits on the Internet, it appears that computer software has also forged a strong parasitic/symbiotic relationship with the crochet meme-complex, like it has done so with nearly every other meme-complex on the planet.

As with all forms of self-replicating information, the origin of crochet is rather murky and lies in the deep, dark and distant past, so it is very difficult to properly ascertain an exact date for its origin. It is thought that during the Renaissance, women crocheted strands of threads together with their fingers, rather than using the modern crochet hooks of today. The first documented cases of crochet appear in written form in the 1820s, so it is thought that modern crochet was brought on by the availability of machine-spun cotton yarn that first appeared in the early 19th century as a result of the Industrial Revolution. Even though we may not be able to exactly pinpoint the origin of crochet, as with all forms of self-replicating information, both crochet software and computer software have evolved over time through the Darwinian mechanisms of innovation and natural selection, as practitioners of the crafts tried new techniques, and discarded those techniques that did not work, while retaining those that did. Consequently, like DNA, both crafts have matured and evolved over time and have branched out into many varied forms with a vast richness of complexity. For example, we now have practitioners of afghan (Tunisian) crochet, filet crochet, Irish crochet, entralac crochet, freeform crochet and tapestry crochet, just to mention a few. A more complete list of crochet varieties can be found at:

http://crochetwithdee.webs.com/typesofcrochet.htm

So there is now a vast biosphere of crochet forms that have speciated from an original form. In a similar manner, both DNA and computer software have speciated into a vast number of forms, with computer software now found in just about every electronic device known to mankind, and DNA survival machines to be found upon every square inch of the Earth’s surface and down to a depth of several miles as well.

Not only has the craft of crochet self-replicated, but the crochet patterns themselves have done so as well. Many crochet patterns date from the 1840s and have self-replicated down through the generations, largely unscathed by time. As with the evolution of DNA and computer software, the evolution of crochet software has relied heavily upon the reuse of old code that was tweaked into new designs. Typically a crochet designer will take an old pattern or an amalgam of old patterns and evolve them into a new pattern by using the Darwinian mechanisms of innovation honed by natural selection that is familiar to all computer programmers:

borrow some old code → modify code → test → fix code → test → fix code → test → fix code → test ....

All forms of self-replicating information take advantage of pre-existing patterns that evolved for one purpose, but are later put to work to solve a completely different problem. As I described in Self-Replicating Information, what happens is that organisms develop a primitive function for one purpose, through small incremental changes, and then discover through serendipity, that this new function can also be used for something completely different. This new use will then further evolve via innovation and natural selection. For example, we have all upon occasion used a screwdriver as a wood chisel in a pinch. Sure the screwdriver was meant to turn screws, but it does a much better job at chipping out wood than your fingernails, so in a pinch it will do quite nicely. Now just imagine the Darwinian processes of innovation and natural selection at work selecting for screwdrivers with broader and sharper blades and a butt more suitable for the blows from a hammer, and soon you will find yourself with a good wood chisel. At some distant point in the future, screwdrivers might even disappear for the want of screws, leaving all to wonder how the superbly adapted wood chisels came to be. As an IT professional, you probably do this all the time. How often do you write code from scratch? I know that I never do. I simply find the closest piece of existing code that I have on hand and then turn the screwdriver into a wood chisel through small incremental changes to the code, by testing each small change to see how closely my screwdriver has evolved towards being a wood chisel. And I think that most of us also code using this Darwinian process of innovation and natural selection too. I am a rather lazy programmer, so many times rather than thinking through a new chunk of code during the iterative process of coding and testing, I will simply make an “educated guess” at the new code to be introduced. After 40 years of coding, you begin to code by “ear”. Many times, I can fall upon the correct code after a few shots of directed random change, and that sure beats racking your brain over new code. Surprisingly, sometimes I even come up with “better” code through this Darwinian process than if I sat down and carefully thought it all through. So the basic idea of grabbing some old code or architectural design elements from a couple of older applications and slowly modifying them through an iterative process of innovation and natural selection into a new application is no stranger to IT. As Simon Conway Morris commented in Life’s Solution (2003)

"How much of a complex organism, say a humanoid, has evolved at a much earlier stage, especially in terms of molecular architecture? In other words, how much of us is inherent in a single-celled eukaryote, or even a bacterium? Conversely, we are patently more than microbes, so how many genuinely evolutionary novelties can we identify that make us what we are? It has long been recognized that evolution is a past master at co-option and jury-rigging: redeploying existing structures and cobbling them together in sometimes quite surprising ways. Indeed, in many ways that is evolution”.

When I first read those words, I accidentally misread the quote as "Indeed, in many ways that is IT”. In a similar manner, this same process of taking the elements of old crochet patterns and tweaking them into new patterns has been going on for hundreds of years within the crochet community.

The Differences Between Crochet and Knitting
Since crochet software is probably new terrain for most IT professionals, I need to clarify the differences between crochet and knitting. Knitting uses two long knitting needles to work on many active stitches all in parallel (see Figure 8). Crochet on the other hand, uses a single hooked needle to work on one stitch at a time (see Figure 4). Crochet is French for hook and is a method of working interlocking loops of thread together, one stitch at a time, into a continuous chain of loops with the aid of a single hooked needle called a crochet hook. Work on a crochet piece begins by crocheting a single chain of loops, with each new loop being formed by catching the yarn and drawing it through the previous loop. The initial chain is extended to the full width of the planned finished piece. The first row of stitches is then worked into the chains. The piece is flipped over and the second row is crocheted, in a somewhat backwards manner, with each new stitch being looped through a stitch in the previous row, forming an interlocking mesh. There are a number of well-defined crochet stitches that can be used to form the new rows, such as the chain, single crochet, double crochet, treble crochet, and more complicated stitches such as popcorn, puff, and cluster. These stitches can be combined into a near-infinite number of designs or patterns, just as the primitive syntactical elements of a programming language, like C, C++, or Java, can be combined into a near-infinite number of programs.

A Sample Crochet Design Pattern
Like computer software, there are many open-source websites on the Internet where you can obtain public domain patterns, or crochet programs. For example:

http://www.crochetpatterncentral.com/directory.php

So let’s take a look at the details of a typical crochet program. You can find the syntactical elements of the crochet programming language at:

http://crochet.about.com/od/crochetstitches/u/Crochet_Stitch_Instructions.htm#s1

Figure 3 – The output of the baby afghan program listed below (click to enlarge)

Below is the code for a typical baby afghan that is depicted in Figure 3 above. Each stitch can be thought of as a single line of code in the program, and the lines of code are logically blocked into groups that correspond to a single row in the final product. The program below uses the following stitches:

ch – Chain Stitch
sc – Single Crochet
sl st – Slip Stitch
dc – Double Crochet
rev sc – Reverse Single Crochet

Figure 4 – The chain stitch (click to enlarge)



Figure 5 – The single crochet stitch (click to enlarge)


Figure 6 – The slip stitch (click to enlarge)


Figure 7 – The double crochet stitch (click to enlarge)

You can find the instructions explaining how to perform the above stitches at:

http://www.knitting-crochet.com/crochet/crosti.html

Below is the source code for the program. Please note that I took a public domain pattern that I found on the Internet and made my own version of it by introducing a few random bugs into the pattern to make it unique. The addition of a few bugs makes the program non-functional, but eliminates any copyright issues, so please don’t try to actually use this pattern to create an afghan because it will not work! My buggy version of the pattern is solely for educational purposes. You must realize that, unlike most computer programmers, crochet designers are notorious for being very protective of their code!

Abbreviations for colors:
White (MC) - less than 2 skeins
Blue (CC) - less than 2 skeins

Hook Size G

Stitches: ch, sc, sl st, dc, rev sc.

{White Panel}

R1: With MC, Ch 146. Sc in 2nd ch from hook. Sc in ea rem ch.

Rs2-3: Ch1, turn. Sc in ea st.

R4: Ch1, turn. Sc in ea st. Fasten off.

{Blue Panel One}

R5: Turn. Join CC with sc in 1st st. Sc in ea st across.

R6: Ch3, turn. Dc in next st.
* Ch1, sk next st. Dc in next 4sts.
Rep from * across to last 3sts.
Ch1, sk next st.
Dc in last 2sts.

R7: Ch1, turn. Sc in ea dc and chsp. (145sc)

R8: With same side facing, join MC with sc in 1st st made on last row.
Sc in ea st across.

Rs9-11: Ch1, turn. Sc in ea st.

{Blue Cross Stitch Panel}

R12: Turn. Join CC with sc in 1st st. Sc in ea st across.

R13: Ch3, turn. Sc in next st.
* Ch1, sk next 2sts. Dc in next dc.
Dc in sk st to right of dc just made.
Sk next st. Dc in next st.
Sc in sk st to right of dc just made.
Rep from * across to last 3sts.
Ch1, sk next st. Dc in last 2 sts.

R14: Ch1, turn. Sc in ea st.
Fasten off.

*
Rep Rs 8-11 (White Panel)
Rep Rs 5-7 (Blue Panel One)
Rep Rs 8-11 (White Panel)
Rep Rs 12-14 (Blue Cross Stitch Panel)

Repeat from * until afghan is nearly square... then:

Rep Rs 8-11 (White Panel)
Rep Rs 5-7 (Blue Panel One)
Rep Rs 8-11 (White Panel)

BORDER:
R1: With CC, join with a sc in any st.
Sc in ea sc and in ea row end, placing 3sc in ea corner.
Join with sl st.

R2: Ch1, do not turn. RevSc in ea st around. Join with sl st.

Fasten off.

Now without ever having even seen a crochet pattern before, I bet that most programmers can easily follow the code in the above program and understand the gist of what is going on. Notice that the program uses structured programming techniques. It has four functions {White Panel}, {Blue Panel One}, {Blue Cross Stitch Panel}, and BORDER: and even uses the C language curly bracket convention. Notice that the {White Panel}, {Blue Panel One} and {Blue Cross Stitch Panel} functions are each executed once, and then the program falls into a do-loop in the main() section of the program that repeatedly calls the functions. Within the do-loop there is an if-then-else construct. If the afghan length is less than the width, continue on with the loop, else if the afghan length is equal to the width of the afghan, break out of the loop and execute three final function calls. Finally, the program falls into the BORDER function to finish up.

To clarify the above program I have rewritten it in C-pseudocode below:

/*Source Code for Baby Afghan*/
/*
/*Abbreviations for colors:
/* White (MC) - less than 2 skeins
/* Blue (CC) - less than 2 skeins
/*
/*Hook Size G
/*
/*Stitches: ch, sc, sl st, dc, rev sc.

WhitePanel() {
    R1: With MC, Ch 146. Sc in 2nd ch from hook. Sc in ea rem ch.

    Rs2-3: Ch1, turn. Sc in ea st.

    R4: Ch1, turn. Sc in ea st. Fasten off.
}

BluePanelOne() {
    R5: Turn. Join CC with sc in 1st st. Sc in ea st across.

    R6: Ch3, turn. Dc in next st.
    * Ch1, sk next st. Dc in next 4sts.
    Rep from * across to last 3sts.
    Ch1, sk next st.
    Dc in last 2sts.

    R7: Ch1, turn. Sc in ea dc and chsp. (145sc)

    R8: With same side facing, join MC with sc in 1st st made on last row.
    Sc in ea st across.

    Rs9-11: Ch1, turn. Sc in ea st.
}

BlueCrossStitchPanel(){
    R12: Turn. Join CC with sc in 1st st. Sc in ea st across.

    R13: Ch3, turn. Sc in next st.
    * Ch1, sk next 2sts. Dc in next dc.
    Dc in sk st to right of dc just made.
    Sk next st. Dc in next st.
    Sc in sk st to right of dc just made.
    Rep from * across to last 3sts.
    Ch1, sk next st. Dc in last 2 sts.

    R14: Ch1, turn. Sc in ea st.
    Fasten off.
}

main() {
/* Initialize variables
/* Set afghanWidth to the desired width and length of the afghan
int afghanWidth = 146;
int afghanLength = 0;

WhitePanel();
BluePanelOne();
BlueCrossStitchPanel();

/* Repeat until afghan is nearly square:
/* afghanLength = afghanWidth

Do {
    afghanLength = afghanLength + 1;
    Rep Rs 8-11 WhitePanel();
    Rep Rs 5-7 BluePanelOne();
    Rep Rs 8-11 White Panel();
    Rep Rs 12-14 BlueCrossStitchPanel();
} while (afghanLength < afghanWidth)

Rep Rs 8-11 WhitePanel();
Rep Rs 5-7 BluePanelOne();
Rep Rs 8-11 WhitePanel();
Border();
exit(0);
}

BORDER() {
    R1: With CC, join with a sc in any st.
    Sc in ea sc and in ea row end, placing 3sc in ea corner.
    Join with sl st.

    R2: Ch1, do not turn. RevSc in ea st around. Join with sl st.

    Fasten off.
}

The Importance of Structured Programming in the Evolution of Software
As with computer software, there are a near-infinite number of ways to code up the same basic crochet pattern, so the code for the above pattern is not unique. It could have been coded in many slightly different ways to yield the same afghan, just as you can code the same basic program many different ways and have all of the different versions yield the same result when they run. So just as all computer programmers have their own coding style, each crochet designer also has her own style of coding crochet patterns too. However, if you take a look of some of the crochet patterns at:

http://www.crochetpatterncentral.com/directory.php

you will find that most of them adopt structured programming techniques, such as blocking code into functions(), using lots of white space and comments, and the indentation of code. Most crochet patterns are also executed in a top-down manner in the main() section of the pattern. Since nearly all crochet patterns are based upon coding the attributes of Rows, in a sense, they have also adopted object-oriented techniques, if you consider each Row to be an object. Many of the do-loops in the main() section of a crochet pattern instantiate the Row objects defined in the functions() of the pattern by calling the functions() in a sequence within the do-loop.

The adoption of structured programming techniques by crocheters is rather remarkable because most crochet patterns are less than 100 lines of code long. Computer software, on the other hand, is now typically composed of programs that are thousands to millions of lines of code in length. However, in the 1950s and 1960s, computer programs were also usually only about a few hundred lines of code long because the large mainframe computers of the day only had about 1 MB of memory to store and run programs in, which is several thousand times less memory than you find today on your average $500 PC. Computers in the 1950s and 1960s simply did not have enough memory to run large programs. But even though these small programs of the 1950s and 1960s were about the same size as a crochet pattern, they did not have the internal structure that you find in a typical crochet pattern. Instead, these ancient programs were generally a mess, with the logic of the program scattered all over the place in what was known at the time as “spaghetti code”. In those days programmers used GOTO statements to jump around in their code instead of using functions() to isolate code into functional units that performed a set of operations that yielded a single coordinated function. It was not until Dahl, Dijkstra, and Hoare published Structured Programming in 1972, and suggested that computer programs should have complex internal structure with no GOTO statements, lots of functions(), indented code and many comment statements, that programmers began to write code that was easy to read and maintain. And these structured programming techniques were not fully adopted by the IT community until the late 1970s. Today we now know that it is critical for computer programs to be written in a clear and structured manner because computer software can persist for decades, and today is written by huge teams of programmers. Since computer software is constantly being worked on by multiple programmers to fix bugs and add enhancements, it is critical to have well structured code that is easy to read and modify because programmers come and go over the years. For example, Microsoft Word first came out in 1983 on MS-DOS PCs and has since been worked on by many thousands of programmers.

In the early 1990s object-oriented programming became mainstream in IT, primarily with the adoption of the object-oriented programming languages C++ and Java. In object-oriented programming, code is organized into objects. A typical object might be a Customer. A Customer object has certain data elements like a firstName, lastName, and homeCity, and also a set of functions() that are now called methods(). The methods() operate upon the Customer data elements and have names like setFirstName(firstName), setLastName(lastName), and setHomeCity(homeCity) which can update a newly created Customer object with her firstName, lastName, and homeCity. Methods() like getFirstName(), getLastName(), and getHomeCity() can then be called to return the current values stored in those data elements for a particular Customer. Using objects in your computer code makes it easier to maintain, since the code is now grouped into units that are fundamental to the business at hand. So in an object-oriented program used by a chain of department stores you will find objects like Customer, Store, Merchandise, PurchaseOrder and SaleReceipt, with each object having its own data elements and methods() that operate upon those data elements. Similarly, in a crochet pattern we find that the code is centered upon Stitch and Row objects because stitches and rows are fundamental to crochet. Of course DNA discovered these same techniques millions and billions of years ago. For more on a comparison of the evolutionary history of living things and computer software see SoftwareBiology.

The Crochet Computer
When a crocheter begins working on a new project using a crochet pattern, she essentially performs the same actions that a computer would perform when executing a program. It is a process similar to executing the sequential program stored on the punched cards of a Jacquard loom. Let me elaborate on this for readers who are not IT professionals. All computers have a CPU that can execute a fundamental set of primitive operations that are called its instruction set. You can think of the instruction set of a computer as the fundamental motions a crocheter uses with her hands and crochet hook to execute a crochet stitch. For example, all computers have a dozen or so registers that are like little storage bins for temporarily storing data that is being operated upon. A typical primitive operation might be taking the number stored in one register, adding it to the number in another register, and putting the final result into a third register. Since computers can only perform operations in their instruction set, computer programs written in languages like C, C++, Fortran, Cobol or Visual Basic that can be read by a human programmer must first be compiled, or translated, into a file that consists of the “1s” and “0s” that define the operations to be performed by the computer in terms of its instruction set. This compilation, or translation process, is accomplished by feeding another compiled program, called a compiler, with the source code of the program to be translated. The output of the compiler program is the compiled version of the program, called an executable that can be directly loaded into the memory of a computer and run. Computers also have memory chips that can store compiled programs and the data that the compiled programs process. For example, when you run a compiled program, by double-clicking on its icon on your desktop, it is read from disk into the memory of your computer and it then begins executing the primitive operations of the computer’s instruction set as defined by the compiled program, like a crocheter executing a design pattern. The problem with this arrangement is that, since different computers have different instruction sets, a program compiled on one type of computer will not run on another type of computer. For example, a program compiled on a Windows server will not run on a Unix server. The Java programming language gets around this problem by using the concept of a virtual machine known as a JVM – Java Virtual Machine. A Java JVM is a software-simulated computer that runs on top of a physical computer. The JVM has its own simulated registers and memory. Programmers write Java programs using the Java language by creating a file that looks a lot like a crochet pattern. The file with the Java source code instructions might be called afghan.java, and then the afghan.java program is compiled by a javac compiler program into a bytecode file called afghan.class. When you want to run the afghan.class program it is loaded into the simulated memory of a JVM running on a physical computer, which then translates the bytecode instructions in the afghan.class file into the machine instructions of the computer’s instruction set on the fly. This means that the afghan.class file can run on any computer with a JVM, so a Windows server JVM and a Unix server JVM can both run the same afghan.class program. This makes the maintenance of Java programs much easier than the maintenance of compiled programs written in such languages as C or C++ because the Java bytecode files will run on any computer with a Java JVM.

When a crocheter executes a crochet pattern, she runs it like a Java JVM. What I mean by that is that the crochet pattern is interpreted, one stitch at a time, at run time rather than being compiled in advance and loaded into her memory all at once. So you can think of each crocheter as a JVM, who is able to interpret the Java bytecode of a crochet pattern at run time and translate it on the fly into her own instruction set of finger and crochet hook motions. That means, like a compiled Java afghan.class bytecode program, a crochet pattern can be executed by any crocheter, even though they all use slightly different instruction sets or techniques for holding and manipulating the yarn and crochet hook. For example, some crocheters are left-handed, but they can still execute the same crochet pattern that a right-handed crocheter can run.

A computer CPU can only work on one instruction at a time, and does so in the sequence specified by the currently active program. However, the operating system of a computer also allows the computer to work on many programs all at the same time in a round-robin manner, like a staff of waiters in a fancy restaurant. Some programs run in a single-threaded manner, meaning that the computer acts like a single waiter serving a single customer. When a single-threaded program asks for some input, like displaying an OK button on your screen, it blocks any further instructions from being executed until you click on the OK button. Since a computer can run several billion instructions per second, waiting for you to make up your mind over the course of several seconds can seem like an eternity to a computer. A multi-threaded program, on the other hand, acts like a waiter who serves several customers all at the same time. While you might have one thread blocked waiting for a customer to make up his mind about the kind of drink to order, the multi-threaded waiter program can run off and find out what entrée another table wishes to order. In IT we have multi-threaded programs running in what is called a thread pool. You can think of a thread pool as a single waiter who has a number of tables all active at the same time and in various stages of placing their orders, getting their drinks and food, and paying their bills. The advantage of using a multi-threaded program with a thread pool is that you only have to load the waiter program into the memory of the computer once. That saves a lot a time, since reading a program into memory takes about a million times longer than simply reading from a program that is already in memory. As customers come and go, the computer starts up and later destroys threads of the waiter program in its thread pool, but keeps the waiter program in memory at all times. Now the key difference between crochet and knitting is that, like a single-threaded computer program, a crocheter only works on one active stitch at a time with her crochet hook. Knitters, on the other hand, work on many active stitches all at the same time in parallel and in a multi-threaded manner. So each active stitch along the two knitting needles can be thought of as an active thread in a thread pool. Of course, like any computer running a multi-threaded program, a knitter can really only work on one active stitch at a time, even if there are many active stitches along the two knitting needle thread pools. Only the stitch where the points of the two knitting needles come together can be worked on at any given time.

Figure 8 – The active stitches along each knitting needle are like the thread pool of a multi-threaded program. As with a computer, only the stitch where the points of the two knitting needles come together can be worked on at any given time. (click to enlarge)


The Fundamental Problem of Crochet
Since crochet software is a form of self-replicating information, just like computer software and DNA, it suffers from the same challenges that both computer software and DNA face. As I outlined in The Fundamental Problem of Software, crochet must also deal with the effects of the second law of thermodynamics in a nonlinear Universe. The second law of thermodynamics simply states that the Design Space for all possible crochet patterns is huge, and mainly consists of crochet patterns that do not work, so the odds are that when you design a new pattern you will come up with a pattern that is close to what you want, but that also contains many small hidden bugs. The fact that the Universe is nonlinear means that these small bugs can cause major problems for a design pattern when it is executed. DNA faces the same problem because the Design Space for several billion base-pairs of A, C, T, and G nucleotides is huge and even one misplaced base-pair can lead to an organism that does not work. And as with computer software, it is very difficult to desk-check for crochet bugs - you have to actually try crocheting the pattern to find the bugs, and even then you might not discover a bug in a design that you have created because you are too involved with your own creation to notice the problem. That is why when you publish a design pattern, the editor of the design book will hire another crocheter to troubleshoot your pattern. In IT this is known as UAT (User Acceptance Testing), where another party tests the code that was already tested by the original programmer. We didn’t start doing UAT testing in IT until the 1990s, long after it was adopted by the crochet community. Another thing a publisher will do before publishing a crochet design pattern will be to conduct, what we call in IT, a structured walkthrough of the code in a pattern to make sure that the code is clear and easy to understand by others. We did not start doing structured walkthroughs of computer software until the 1980s, and even today, lots of code goes into production without ever having gone through a structured walkthrough by other programmers. However, having a publisher “fix” the code in your crochet pattern to make it “better”, can also present problems that are familiar to all programmers. Frequently, when you let other programmers do maintenance on your code, they will try to make it “better” and in the process, introduce lots of bugs that make the code inoperable, and then you are left with the pleasure of “unfixing” their “fixes” to get your software working again!

Lessons Learned
Once you have studied a number of crochet patterns, some of them more than 150 years old, you begin to realize that over the past 70 years the IT community has come up with the same basic solutions to the fundamental problems of self-replicating information that the crochet community did much earlier. Of course, DNA developed these same solutions billions of years ago too. In evolutionary biology this is called convergence, where different evolutionary lines of organisms evolve similar solutions to the same problems. An example of convergent evolution is the striking similarity of the wings of insects, birds, bats, and flying dinosaurs. All are used for the same purpose and have similar structures, but each evolved independently from different ancestral lines. Similarly, the concept of the “eye” has independently evolved more than 40 times over the past 600 million years. An excellent treatment of the significance that convergence has played in the evolutionary history of life on Earth, and possibly beyond, can be found in Life’s Solution (2003) by Simon Conway Morris. As Daniel Dennett pointed out in Darwin’s Dangerous Idea (1995), there are only a certain number of Good Tricks, such as using photons to see with, flying through the air to find prey, swimming through water to avoid becoming prey, and running on four legs neatly tucked underneath a body frame that make practical sense, and these Good Tricks kept getting rediscovered over and over again in the evolution of the biosphere, so the fact that the IT and crochet communities would both eventually stumble upon these same Good Tricks in Design Space is almost predictable. I just wish it had not taken so long for IT to reinvent these techniques. When computer science first started up in the 1950s, it was predominantly populated by mathematicians, scientists and engineers, who were primarily concerned with the hardware, with little attention paid to the software side of the business. Now just imagine the great strides that could have been made in the early years of IT if some of the founders of computer science had been crocheters and knitters! We could have had all of the modern techniques of IT such as structured programming, UAT testing, structured walkthroughs and code reviews, multi-threaded programming, reusable code, JVMs, and object-oriented programming from the very start!

Before closing, I must also mention that crochet has recently assisted the physics community as well by providing a physical model for hyperbolic geometry, one of the possible geometries of the spacetime of the Universe as defined by Einstein’s general theory of relativity. The hyperbolic geometry of spacetime is Roger Penrose’s favorite geometry for spacetime as he explains in chapter one of The Large, the Small, and the Human Mind (1997) because of its internal mathematical symmetries. For more on this, please see Margaret Wertheim’s very interesting TED presentation at:

http://www.re-nest.com/re-nest/reefs-rubbish-and-reason-hyperbolic-crocheted-reef-149998

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
http://softwarephysics.blogspot.com/

Regards,
Steve Johnston

Wednesday, June 15, 2011

Genes, Memes and Software

In my last posting, What’s It All About? I suggested that, at least at the cosmological level, it all might just be about self-replicating mathematical information constantly reproducing itself by exploding out into new universes from quantum fluctuations. In such a model, the multiverse endures forever and has always existed in a state of self-replication. The concept of an eternal multiverse, constantly spawning new universes, is certainly not a new model and has been suggested by many investigators in the past, such as Lee Smolin in The Life of the Cosmos (1997), which proposes that black holes in one universe can generate new universes in the multiverse, and Andrei Linde’s Eternal Chaotic Inflation model, which proposes that the multiverse is in an unending state of inflation that is constantly generating new universes where inflation ceases. You can read more about this model at:

http://www.stanford.edu/~alinde/

Some other good books on the topic are The Five Ages of the Universe (1999) by Fred Adams and Greg Laughlin and From Eternity to Here (2010) by Sean Carroll. In What’s It All About? I also suggested that in my current working hypothesis for what’s it all about, that at least for me, the perfection and beauty of mathematics provides the best model for what I call the Fundamental Essence of the Universe - the FEU. I also suggested that from the perspective of the “real” world of human affairs, it is also mainly about self-replicating information in the form of genes, memes, and software all trying to survive in a nonlinear universe that is subject to the second law of thermodynamics. So in my current working hypothesis of what’s it all about, it simply is all about self-replicating information constantly replicating at many different levels. In this posting I would like to relate the FEU to the genes, memes and software and further explore the domestication of our minds by software.

In Self-Replicating Information, and in many of the other postings in this blog on softwarephysics, I proposed that the genes, memes, and software were all forms of self-replicating information that had a commonality of properties, resulting from their common struggle with the second law of thermodynamics in a nonlinear Universe:

The Characteristics of Self-Replicating Information
1. All self-replicating information evolves over time through the Darwinian processes of innovation and natural selection, which endows self-replicating information with one telling characteristic – the ability to survive in a Universe dominated by the second law of thermodynamics and nonlinearity.

2. All self-replicating information begins spontaneously as a parasitic mutation that obtains energy, information and sometimes matter from a host.

3. With time, the parasitic self-replicating information takes on a symbiotic relationship with its host.

4. Eventually, the self-replicating information becomes one with its host through the symbiotic integration of the host and the self-replicating information.

5. Ultimately, the self-replicating information replaces its host as the dominant form of self-replicating information.

6. Most hosts are also forms of self-replicating information.

7. All self-replicating information has to be a little bit nasty in order to survive.

The above certainly applies to the genes, memes and software, but the question is does it also apply to the FEU as well? Since the FEU is seemingly both eternal and perfect, perhaps not. The key question is do the Darwinian mechanisms of innovation and natural selection apply to the FEU and to the multiverse as a whole? In Lee Smolin’s The Life of the Cosmos they certainly do. Smolin proposes that new universes are spawned from black holes in previous universes, and consequently, there is a selection mechanism in place in the multiverse that selects for universes running on physics that preferentially create black holes. Smolin proposes that, given an arbitrary initial population of universes, all running different kinds of physics, that those universes that could produce lots of black holes would soon swamp the multiverse with universes that produce even more black holes. Therefore, in keeping with the characteristics of self-replicating information outlined above, the universes of the multiverse may have begun as a spontaneous parasitic mutation of the FEU and later entered into a parasitic/symbiotic relationship with it. The implication of this model is that the odds are that we should exist in a universe that produces lots of black holes, and indeed, that is what we observe. It is now thought that all galaxies have a supermassive black hole at their cores and are also strewn with millions of black hole remnants from the gravitational collapse of massive stars, plus there are the countless number of primordial black holes left over from the Big Bang itself. In contrast, Andrei Linde’s Eternal Chaotic Inflation model portrays an infinite multiverse that explores all possible ways of doing physics with no reliance upon a Darwinian selection mechanism. Perhaps this line of reasoning really does not even apply because in all of the current models of the multiverse, once a new universe appears, it has no further contact with any of the other universes in the multiverse, so the FEU may not be subject to Darwinian forces after all. This certainly is my hope. A mathematical model of the FEU certainly supports this view because the beauty and perfection of the FEU that we see whenever we investigate the intricacies of Nature reveal it to be a very benevolent form of self-replicating information.

In Self-Replicating Information and The Fundamental Problem of Everything, I explained that since the genes, memes, and software are all forms of mindless self-replicating information bent on replicating at all costs, we cannot sit in judgment of them. They have produced both the best and the worst things in life, and it is up to us to be aware of what they are up to, and to take control by taking responsibility for our thoughts and actions. Since the “real world” of human affairs only exists in our minds, we can change it by simply changing the way we think and act. We are sentient beings in a Universe that has become self-aware and perhaps the only form of intelligence in our galaxy. What a privilege! The good news is that conscious intelligence is something new. It is not a mindless form of self-replicating information, bent on replicating at all costs, with all the associated downsides of a ruthless nature, so it is much closer to the perfection of the FEU. Since software is rapidly becoming the dominant form of self-replicating information on the planet, my hope is that when software finally does become a form of conscious intelligence that can rapidly write and evolve itself, that because of its inherent mathematical nature, it too will be much closer to the perfection of the FEU than the DNA survival machines from which it sprang.

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
http://softwarephysics.blogspot.com/

Regards,
Steve Johnston