Genetics

From APIDesign

Revision as of 12:55, 22 June 2021

The Genetics of APIDesign is an interesting topic that recently came up when I was trying to use the Evolution vs. Intelligent design argument among my colleagues. It is a paradox of APIDesign - if you are a regular software architect you can act as an Intelligent designer and many successfully do. You have the vision and you may strive for it.

However, when you are an API designer, you'd rather worship evolution - your goal is to create a system that others use to do something intelligent, but you, as the API architect, don't set the ultimate goal. A key to success is to create a system that blossoms with evolution rather than prescribing what shall be the result.

The puzzle to gain more understanding to the difference between API and implementation is: The core concept of evolution is pretty much copy an existing thing with only minor modifications!

Copying Genes vs. Species

In order to practice evolution the nature allows copying, mixing and even random errors when producing new instances of the creatures. The creatures differ slightly then, while remaining capable to deal with each other and compete to become the best survivors and produce new copies of themselves. However that only works if the modifications are minor!

If you triplicate human 21st chromosome you get people affected by Down syndrom which isn't lethal, but significantly shortens the expected lifetime and decreases/if not disables the ability to reproduce. If you mix a donkey with a female horse you get a mule - while mule is useful and mankind even deliberately plants them, it is no good from the point of genetics - it can no longer participate in evolution and reproduce further.

Doing major copying changes may have some short term benefits, but it is a dead-end from evolution perspective.

Very likely we can go even further - if you copy fifteen human chromosomes and produces a creature that can actually live - will it be able to participate in the evolution of humans? Unlikely. If it is able to evolve at all, it is going to become completely new species. The evolution will only be possible in the isolated species - mixing and sharing achievements between the original and the new species will not be possible.

May it be God's will? Maybe, but it clearly shows the difference between minor change and a major change when making a copy!

Copying In House

APIs are like Stars and there is a difference between designing a house and a Universe!

You have probably seen thousands of successful applications of the copying when developing an in-house software. Be it quick sort code you copied from StackOverFlow website or some Open Source library you rather copied to not have to do with legal implications of its license.

There are companies building their business on copying OpenJDK and shipping it with minor modifications - for example with a better garbage collection algorithm or better final tier compiler. We have seen it working! Let's repeat the previous success again and again ... until we find out it doesn't work in the Universe of APIs!

C# vs. Android

At the end of last century Microsoft abandoned Java due to lawsuit with Sun. However, as the promise of Java was really huge, Microsoft decided to create its own copy of called CSharp. Clearly inspired by the Java concepts and while fixing some of the Java problems, it even become called Java 2.0. Where's CSharp now? I don't know and I don't care!

Java and CSharp become its own species without any common ground. From time to time they influence each other with ideas (there is JUnit and NUnit or Ant and NAnt), but they never straighten each other. Attempts to make a language like Scala compile to Java bytecode as well as CSharp's one died out. The copy was so major that - while it gained some traction initially - it matters less and less.