Code center > Suggestions

Block coding

<< < (3/3)

EricL:

--- Quote from: Numsgil ---Jaron's world (seriously read this article if you haven't before continuing my post) recently talked about synthetic biology's potential, relating it to software and hardware.  I've been thinking a lot about this recently, and the conclusion I've come to is that the reason software progresses so slowly is that it's so tightly coupled.  You can't grab microsoft word and throw it into world of warcraft to make an in-game text editor.
--- End quote ---

I read the article.  I disgree with many of his statements and conclusions.  Typical of many science writers, he has a niave view of the realities of software development.   New word processors on new computers open new documents at about the same speed as old word processors do on old computers because they are doing so much more on that open then the older code did (new features, new content types, etc.) and also because engineers don't focus on the performance of a certain task once that performance becomes acceptable on the hardware the typical customer is expected to use for that release.  It has nothing to do with "software getting worse over time" or any other such nonsense.  The hardware performance may have increased a thousand fold (not the disk seeks per second though, which is a main aspect of program and document load time) but the software has similarly increased it's functionality over the same time period.

He also misses a huge point in that the complexity of software does not necessarily improve with time, size, increasing hardware speed or number of programmers.  It gets bigger, wider, but not necessarily more complex.  The human brain is the limiting factor.  We don't build sofware the way nature builds things.  It's highly compartmentailized, not nearly as interconnected, etc.  We do this for many reasons not the least of which is that without compartmentalization, it would be impossibile to support or to transfer code ownership.  But the main reason is that the human brain isn't good at thinking about things that have thouasands or tens of thousands of interconnections (like neurons).  The human brain is good at thinking about things that have about 7 parts or connections and if it has more than 7 parts, we break a part down into 7 subparts and so on.

Software progresses slowly not because it is tightly coupled as you say.  Software progresses slowly because it is written by humans with human brains.  Being tightly coupled is a side effect of this.  There may be problems whcih cannot be solved by typical human programming methods.  This is a theme in my book actually adn one reason why I find breeding software so appealing I.e. becuase it holds promise to solving such problems, to producing software complexity no human developer can acheive.


--- Quote from: Numsgil ---So what I'm trying to suggest for DNA is that we move away from the serial strand and move towards a more parallel structure, where genes form an interconnected web, communicating with each other only indirectly through the byproducts of their actions.  I don't know if a purely parallel structure is even possible, but it's an ideal I'd like to move towards.  By specifically limiting what a gene can know about other genes, we force them to decouple.
--- End quote ---
I don't disagree.   I'm a big fan of codules, but they won't be implemented in the VB version.

Numsgil:
I don't think we're going to convince each other, so I'll bow to popular opinion.  If others want the DNA to have the power to govern itself, then I'll hold my tongue.  I just think it will hamper complexity.

Welwordion:
First:
The basic unit of Darwinbots Dna is not what we have named Gene, the true Gene( in that it function is the equivalent of a biological gene) consists of:
1)a store or inc or dec command
2) the code that produces the numbers used by these commands
3) the conditions attached to the fragments of code.

For this reason a virus that addresses DNA from point A to point B might be less constricting, but not less artificial than a virus that transfers a genome cause the parts of a true gene are not necessarily spatially close to each other.
For this I would propose a numeration of genes according to store, inc dec commands and the viruses as well as delgene should use a tracking back mechanism to identify the parts belonging together.
(beware of dup commands as when two or more genes share the values copied by those only the dup command has to be deleted)

Second: Independant of what system of numeration you choose, it is true that, as long a genes work not parallel, the order of genes is important .
Particularly genes that store to the same numbers tend to make their predecessors inactive.(The rule here is if the memory locations that are stored in, are not referred too by other true genes before the new gene, the previous gene is inactive)
To solve this order problem in regards to reproduction schemes, without making viruses to powerful, I propose that  there is a variant of .delgene (or its could be done  by .sexrepro) that leaves an interface a placeholder behind.
This interface basically has 2 functions, it keeps the current numeration intact by reserving a number and
when a virus is inserted into the bot the virus will be placed into the reserved spot, instead of the end of the genome.

Third: There are some thinks like the supposed slow process of software I have my doubt or thoughts about but for reasons of quality and cause I do not have a hundred percent clear opinion yet I will be silent about these for now.
The only thinks I would like to say is what I said already a long time ago many of the solutions, features implemented and proposed to darwinbots are a little artificial compared to their purpose and the inherent structures that predated them, sometimes a little bit more careful and indeep consideration has to be done cause for DNA development easier can often be better (but beware of to easy solutions that destroy complexity)

Navigation

[0] Message Index

[*] Previous page