Evolving System

An evolving system can be described as an OpenFormalSystem?.

Such a FormalSystem is capable of describing its Avatars in its own terms and it has a time dimension associated with it.

If a language can be treated as an EvolvingSystem then its grammar becomes a discrete function of time and language is not a single point in the space of language implementation but an entire region in that space.

LanguageGrammar is associated with DesignPatterns in such a way that the EvolvingSystem appears to be engaged in the process of PatternMining.

Characteristics Of Evolving Systems

An EvolvingSystem is capable of regenerating itself. It appears to be in a state of continuous bootstrapping. Reflection is a very important aspect of such systems. Reflection is implemented using one or other MetaObjectProtocol. See ReflectiveProgramming.

An EvolvingSystem allows reclassification of objects. An object may belong to different classes depending on time and other parameters (dimensions) in such a system. An object may even become a class. I know it is possible to do this with VisualWorks. NeoClassTalk uses this to compose behavior.

EvolvingFrameworks gives good insights into the process of building an evolving system. SqueakSmalltalk is a very good example of an evolving system.

An EvolvingSystem is not just an isolated piece of software/hardware. No system can evolve left to itself. It must allow interaction and interact with other systems. Evolution of a system is closely related with increasing complexity of interactions. Over time, as the system evolves (becomes more complex internally) the complexity of interactions is reduced and it becomes a more natural part of its environment. Evolution of a system drives it towards specialization(s) as if it is seeking its special role. Please explain.

Complexity must increase in an expanding universe (DissipativeSystems?). This is reflected in all systems, natural and man-made. Increasing complexity is not a bad thing. It only means that patterns become more and more interesting. Systems continue to survive and evolve as long they are able to recognize and internalize these patterns. "In effect, any open system survives by its ability to change some aspects of its structure or behavior in order to maintain stability in those areas that define its core identity"[2]. In other words, an evolving language must provide new words and grammatical constructs to describe more and more complex phenomena. It will become extinct if it fails to do so.

The problem of EvolvingSystem is related with PatternRecognition and PatternMining. It is important to include MarketProcesses?, BusinessProcesses, SoftwareEngineeringProcesses? in this context. Other processes like SocioPsychologicalProcess?, OrganizationalProcesses?, and TechnologicalAdvancement? also play a crucial role.

The evolution of a system is reflected in the refinements it brings to its constituent processes. Process A' is a refinement of Process A when it is faster, cheaper and better (happier) than Process A. Also, Process A' consumes less energy.

It is important to remember that an EvolvingSystem is not just a cartesian sum of its parts. Feedback loops abound not only within layers but across layers. ChangeAndStability? become contradictory requirements. However, an EvolvingSystem continuously renews itself. IllyaPrigogene?, in his work on the characteristics of self-organizing systems, calls this "irreversible non-linear transformation under conditions far from equilibrium." Stability apparently emerges from the depths of chaos.

Measuring Evolving Systems

Yes, one way to do this is to learn to be happy no matter what.

Examples Of Evolving Systems

PlanetEarth NeoClassTalk SqueakSmalltalk WikiWikiWeb

Software applications are usually EvolvingSystems: see EvolutionaryProgramming .

If you are interested in seeing how these concepts can be used in the real world of IT in support of commercial software you need to start using some softwarephysics. As an IT professional, I have been using biological concepts to support commercial software for over 30 years. Let me explain.

From 1975 – 1979, I was an exploration geophysicist exploring for oil, first with Shell and then with Amoco, until I made a career change into IT in 1979. When I transitioned into IT from geophysics, I figured if you could apply physics to geology; why not apply physics to software? So like the exploration team at Amoco that I had just left, consisting of geologists, geophysicists, paleontologists, geochemists, and petrophysicists, I decided to take all the physics, chemistry, biology, and geology that I could muster and throw it at the problem of software. The basic idea was that it seemed as though over the past 60 years the IT community had accidentally created a pretty decent computer simulation of the physical Universe on a grand scale, a Software Universe so to speak, and that I could use this fantastic simulation in reverse, to better understand the behavior of commercial software by comparing it to how things behaved in the physical Universe. Softwarephysics is a simulated science that depicts software as a virtual substance, and relies upon our understanding of the current theories in physics, chemistry, biology, and geology to help us model the nature of software behavior. So in physics we use software to simulate the behavior of the Universe, while in softwarephysics we use the Universe to simulate the behavior of software.

Over the past few years, I have been working on a blog on softwarephysics to help the IT community better cope with the daily mayhem of life in IT. However, in laying down the postings for this blog an unintended consequence arose in my mind as I became profoundly aware of the enormity of this vast computer simulation of the physical Universe, and of its potential scientific value. One of the nagging problems for many of the observational and experimental sciences is that many times there is only one example readily at hand to study or experiment with, and it is very difficult to do meaningful statistics with a population of N=1. But the computer simulation of the physical Universe that the Software Universe presents provides another realm for comparison. For example, both biology and astrobiology only have one biosphere on Earth to study and even physics itself has only one Universe with which to engage. Imagine the possibilities if scientists had another Universe readily at hand in which to work! This is exactly what the Software Universe provides.

From a paleobiological perspective, softwarephysics provides a good starting point for the comparison of the evolution of software architecture over the past 60 years with the evolution of life on Earth over the past 4 billion years. Both have followed a very similar path due to convergence. Software and living things are both forms of self-replicating information that have had to contend with the second law of thermodynamics and deterministic chaos in a nonlinear universe, and consequently, have both come up with very similar solutions.

All the postings for my blog on softwarephysics are available at: http://softwarephysics.blogspot.com/

However, to cut to the chase, I would recommend the following postings in this order:

A Proposal For All Practicing Paleontologists: http://softwarephysics.blogspot.com/2009/04/new-introduction-to-softwarephysics.html This posting provides a road map for getting started.

Introduction to Softwarephysics: http://softwarephysics.blogspot.com/ This posting provides an overview. I keep pasting it in as the first posting as I add additional posts behind it.

SoftwarePhysics http://softwarephysics.blogspot.com/2006/07/softwarephysics.html This is my original post on softwarephysics. The second half of the posting describes how softwarephysics was used by the IT department of Amoco (now a part of BP) from 1985 – 1991 to grow several million lines of production code with my BSDE – Bionic Systems Development Environment tool. BSDE generated a 10,000 line of code embryo from a set of genes for a new business application. The programmer then grew the embryo into a fully developed application by turning its genes on and off within BSDE, which performed a maternal function during development. BSDE was also used to grow code for itself. The next generation of BSDE was grown within the current version of BSDE, and over a period of 7 years, more than 1,000 generations of BSDE were generated, and BSDE slowly evolved into a very sophisticated tool through small incremental changes. Below is a Google Docs document from 1989 featuring an overview of BSDE that I wrote for the Amoco IT Training Department’s course on BSDE. https://docs.google.com/Doc?id=dhjzddgs_156dfzhf6kh

SoftwareBiology?: http://softwarephysics.blogspot.com/2008/06/introduction-to-softwarephysics-ii.html The second half of this posting will be of most interest. The first half just covers Darwinian thought and a little geology for IT professionals, who frequently are quite lacking in these areas. Just scroll down to the section on SoftwarePaleontology? which provides a thumbnail sketch of the evolution of software architecture.

Self-Replicating Information: http://softwarephysics.blogspot.com/2008/06/new-introduction-to-softwarephysics.html This posting features Freeman Dyson’s two-stage theory for the origin of life as it pertains to the origin of software and the concept of self-replicating information.

The Origin of Software the Origin of Life: http://softwarephysics.blogspot.com/2010/05/another-introduction-to-softwarephysics.html This posting features some of Stuart Kauffman’s work on complexity theory as it pertains to the origin of life and how it might have led to the origin of software as well.

Software Symbiogenesis: http://softwarephysics.blogspot.com/2008/07/introduction-to-softwarephysics-ii.html This posting applies the ideas of Lynn Margulis to software evolution.

When Toasters Fly: http://softwarephysics.blogspot.com/2010/09/new-introduction-to-softwarephysics.html This posting applies the ideas of Stephen Jay Gould to software evolution.

SoftwareChemistry?: http://softwarephysics.blogspot.com/2008/01/softwarechemistry.html This posting proposes that the interactions of lines of code in software represent a very good computer simulation for the interaction of organic molecules.

How to Think Like a Softwarephysicist http://softwarephysics.blogspot.com/2008/10/introduction-to-softwarephysics.html This posting sums up softwarephysics and explains how it can be used on a daily basis by IT professionals.

CyberCosmology?: http://softwarephysics.blogspot.com/2009/02/introduction-to-softwarephysics-ii.html This posting covers where it may all be leading.

Regards, Steve Johnston

CategoryEvolution