Reverse Engineering

Joined
Jul 14, 2011
Messages
12
A few years ago, a book came out by Jack Horner, entitled How to Build a Dinosaur.(Online Bookstore: Books, NOOK ebooks, Music, Movies & Toys)
In order to spare you a few dollars (although I would definitely still recommend it to any that haven't read it), I am going to quickly summarize the main points, and what they have to do with cephalopods.

The statement "Ontogeny recapitulates phylogeny" is no longer accepted as true. The principle, though, is at least slightly valid. While not every stage in the evolution of an organism is displayed during development, many past traits are. When traits disappear or change, the genes coding for them usually aren't deleted, merely switched off by the creation of new genes. Every gene causes a cascade of effects, meaning that they each affect the expression of maybe (just throwing a random number out) a dozen other genes, which in turn affect a dozen more genes, and so on. This means that, to simplify it, newer DNA is built on top of older DNA. Often, newer genes are not switched on until partway through the development of an embryo.
A man named Hans Larsson, at McGill University, is working on finding the point in the development of chicken embryos at which the formation of the characteristic therapod tail halts and instead leaves the chicken with a pygostyle (stumpy, non-muscular, chicken-style tail). Once that is done, he intends to determine what changes occur in the biochemistry of the embryo at that, and by reversing them, prevent the inhibition of development of a muscular tail. This process has already been done with teeth. Granted, the chickens didn't hatch, but they did develop teeth. Apparently, since the introduction of the genes involved in building a beak, so much has been built on top of them that switching them off prevents the development of a functional chicken. However, teeth did develop before the embryos died, and they were consistent with those of other archosaurs.


Now, for the fun part. Given the obvious facts that cephalopods are not exactly the same through every stage in their development, and that their DNA builds on top of itself just like that of everything else, this process for recreation of archaic traits should be just as possible in cephs as in chickens. It would be theoretically possible to reconstruct archaic nautilus traits in modern nautilus. It would also be possible, theoretically, to simply monitor changes in various elements of the biochemistry in the organism throughout development, and select and reverse several of them, one at a time, and thereby prove that certain traits were posessed by the ancestors of the organism at some point. One would have to be careful in doing that, though, as it would be quite possible to generate something not within the evolutionary history of the organism, by having combinations of genes switched on at the same time that weren't prehistorically, thus producing unique traits that weren't present in the ancestors of the organism. However, it would be possible to work around this by simply using the fossil record for confirmation of being "on the right track". Given the considerable gaps in the fossil record, it would be wise to have a backup. Perhaps one could confirm that the traits produced were not affected by later genes by working backwards through the biochemical changes; starting with those latest in development and then working earlier from there. This would, of course, take quite a while to work back to a trait of any significant distance from the present era. Also, in order to ensure that the newer genes aren't affecting the development of older traits, they would have to be switched off independently for each test. Switching them off biochemically, without actual manipulation of genetic material, would be the only feasible method of achieving this, as adding new to genes to switch them off could affect the expression of the older genes, and removing the genes completely could be difficult. Therefore, unfortunately, the process of switching off genes manually would have to be repeated each time, and would greatly increase the farther back you went. It would, though, (looking on the bright side) be possible, and it wouldn't really be enormously surprising (if still very impressive) if someone on Tonmo managed it to a certain degree.

Please, keep in mind that I am not an expert on genetics or cephalopods. If you find any errors, feel free to point them out.
 
Interesting thoughts. I read an article in the last year that worked with a gene we still have but is inoperative in humans as well as chickens (but operative in newts and a number of other animals). The gene allows for recreation of a severed limb. In the case of the experimental chickens (still in the egg), the wing was severed and grew back. Exciting but a long way from any practical help, the obvious result of getting it wrong was cancer.

Experimenting with octopus eggs is not likely to produce a lot of interesting changes though as the current form has been around even longer than previously thought and is now estimated at 95 million years with little change
 
That's one thing that I thought of about ten minutes later. You are, of course completely right about the great distance that you would need to go back in order to come up with any significant changes in octopuses. This would render it completely impractical to simply work backwards and generate traits, but it could still be feasible to identify a single trait and recreate it. For example, one might create octopuses with fins if he or she was to focus simply on the one trait, as there would undoubtedly be references for what it should loook like (to help recognize the trait when it occurs, and recognize when it is being strangely affected by other genes).
 
It is very tricky to recreate the genetic sequence by working it backward. It is rather like guessing at the version changes in complex software (in the case of humans, something like 30,000 sophisticated and interacting subroutines). You change something, but it was originally modified in conjunction with another change and will no longer compile and run properly (i.e., produce a viable organism).

In fact, the DNA system is indeed software, but it has what a programmer could consider to be a horrible feature: You can't really make a syntax error. Every possible combination of the three "letters" spells a valid "word" (codes for a particular amino acid or stop code). So you're not limited to things that make sense — which makes way too many possibilities that won't. Everything will compile, even if it will never "run."

If there can be no misspellings, the idiot and the genius get the same score in the bee.

Nevertheless, as we understand more about the effects of the changes, we can learn something, and this knowledge can guide us. Octopuses accomplish an amazing amount of cognition with a few hundred million neurons that mammals might use one or two orders of magnitude more to do.

And the partially distributed brain of an octopus has no comparable analog in the vertebrate world. A bunch of brain in each arm! How very strange is that! No mere spinal cord, the arm brain makes decisions and directs action. It means that certain types of skill learned by an octopus with one arm would have to be at least partially re-learned with another. If an octopus learned to write, he'd need to do it again to an extent.

But genetically, how far back does the distributed brain go? Your suggested exploration holds the promise of clues here, independent from the morphological differences in modern cephalopods, of how those differences came about.

This article from a couple of years ago talks about gene expression differences between the octopus and mouse brain:
http://blogs.sciencemag.org/origins/2009/10/tackling-brain-evolution-with.html

The development of living organisms is a complex sequence of programming, and also depends upon environmental aspects (everything from chemical signals to pressure to gravitational orientation). All of this operates to produce a meta-effect as astounding as the pattern of a snowflake from the simple rules of hydrogen atoms. Almost, but not quite, unpredictable in the case of life.

At some point in the future, we will have software that allows us to model what a genetic change would produce, by reproducing in software the environmental clues and the cellular mechanisms that carry out the instructions. We're a long way from that, but I can imagine such code.

And you can put it to use! How did their brains get so good? And how, then, to make them even better?

Chess, anyone? Better come to the game fully armed.
 
Level_Head;185215 said:
It is very tricky to recreate the genetic sequence by working it backward. It is rather like guessing at the version changes in complex software (in the case of humans, something like 30,000 sophisticated and interacting subroutines). You change something, but it was originally modified in conjunction with another change and will no longer compile and run properly (i.e., produce a viable organism).

Hence, unfortunately, toothed chickens that won't hatch.
 
We do gene-tweaking runs in a batch
Evolution, reversed, we might catch
Chicken teeth we discern
Still can help us to learn
For those chickens count before they hatch!
 
Interesting thread, not being "fully armed" :heee: I can't really add to the discussion, but am following along. Level Head, I love the software analogy, made it all a little more clear.
 
Thank you. I have a notorious bad habit of poetry as well. I wrote a bit about DNA as a programming language some years ago. Rather than send you haring off to some site which might have politics, let me just bring that little essay in here. Wow — more than eight years ago (November 2002):

Many of my friends and readers here are computer savvy, to various degrees. Another computer-savvy friend in a different venue was trying to understand DNA and chromosomes. An analogy occurred to me, so I wrote him this:

Think of DNA as an simple programming language, one that is very readable and follows specific rules. It is arranged in subroutines (programmers generally shorten this to "routines"), each of which perform a particular function. Some of these are long, others fairly short. They generally run from dozens to a several thousand words long.

In humans as in most animals, there are lots of leftover routines that aren't called anymore. In humans, in fact, this is true of more than 97% of them -- there are about 30,000 "active" routines. These are the "genes".

On the "disk" in the nucleus, the overlay code files (chromosomes) contain bunches of routines in each one, and in humans there are 46 overlay files, 48 in chimps. However, combining two overlay files (two pairs, in this instance) does not do anything to the subroutines themselves; they can still be called regardless. The library mistake that stuck files together doesn't have much other effect.

These files, or chromosomes, can be thought of as DNA wound around protein "cores" to keep it from getting tangled -- the DNA in any human or chimpanzee cell, were it unwound and connected together, would be over five feet long! But think how long a printout would be of everything on a 3.5 inch hard drive...

Even rearranging the order of subroutines in a file does not hurt the subroutines themselves -- except that where the breaks occurred in the middle of a routine, those routines are screwed. If the break happened between them, no problem, but in the middle, that subroutine is then broken. We can see that between the chimp's 2p and 2q chromosome, and the human's chromosome 2 where these two have been joined, that there are nine sections of code swapping as well. But the subroutines are still valid.

So, the rearrangement of files (chromosomes) that The Grappler describes, and the reversals of order, don't control what the routines do.

Now, since humans and chimps separated into two different versions of this code package millions of years ago, two different programmers have been working on them. These programmers are idiots, by the way; they are random mutation -- fortunately, as I'll explain, almost any code you can string together compiles and does something. It usually does something very wrong.

The code librarian — chance chromosome fusing and damage, and sexual reproduction (and asexual in some critters) also does damage from time to time — you know how badly a poor code librarian can screw up a project. This one is kept way too busy.

The end-user — natural selection — is very picky, and will reject almost all code changes. If it doesn't work at least as well as what she's got, it's scrapped. And it won't really get used much unless it's very much better, usually in some area that she cares about in her current job.

So how can an idiot programmer, who types like he's wearing fingerless mittens, get this stuff to compile? It's fairly easy.

DNA "letters" in the language are base pairs. There are only four letters on the keyboard. Picture keys three inches square.

DNA "words" in the language are called "codons" — and every three letters makes a valid word. If you think about it, this makes 64 three-letter combinations, since there are only four letters possible. Every single one of those 64 codons does something — it codes for adding a particular amino acid to the end of a protein chain. You can't spell a word wrong — if it's a multiple of three letters at a time, it means something. And leftovers are ignored, mostly.

Now, just like with computer subroutines, there's some required "routine starts here" at the top and a "return to calling program" at the bottom. If Hamfist types in these areas, it is likely to screw things up. In fact, sometimes our clubfooted clod will put the "return" sequence in the middle of a routine, and at that point two things happen:

(1) It probably (but not always) does something really stupid, and
(2) If it's kept, the later portion of the routine is now unused junk.

In the meantime, the lazy librarian has too much on the desk at once. It's really easy when making copies of this stuff to make too many copies, even of individual pages. What a mess! This often results in multiple copies of individual subroutines becoming part of the project, and useless routines that didn't get completely copied because they didn't start or end exactly on a copied page. But often, when this happens, it happens in pretty big chunks — and a bunch of stuff gets duplicated.

Fortunately, it means that one subroutine will still do the main thing it does, even if the mental midget code pounder screws up the other one. And in fact, it's actually useful, because the *other* one might eventually do something else useful, without losing the original trick that the first copy still performs.

The end user has the world's worst bad attitude. She is not often impressed by "improvements", and scraps 99 percent of the changes offered, and ignores other routines that are modified "extra copies" tucked into her program — she just does her basic job, and they rarely improve on that.

But once in a while, when her job description changes (like a new middle-manager asteroid dropping by and changing all the policies!) she'll start looking around to see what some of those other functions actually do.

Why now? Because, with the rule change, she's got to handle new job functions, or be fired. So what does she have to lose?

So in a sense, each organism alive today is simply a living, breathing version control nightmare, programmed in an extremely easy language by an idiot, who once in a while — despite himself — does something actually useful. It's a good thing the DNA language is so easy to get to compile.

You can see why genetic scientists want to get in there and play with the code. It is irresistible. And once in a while, even they do something right, although the overall program is extremely complex and we aren't yet much better than complete idiots at this. The "big picture" of the project is still way too big.
 
L_H, Love it but I am one of the few that will likely understand all the terminology.

However, combining two overlay files (two pairs, in this instance) does not do anything to the subroutines themselves; they can still be called regardless. The library mistake that stuck files together doesn't have much other effect.

Nothing odd here, they are either just in the same namespace or methods of an object :wink:

Now, just like with computer subroutines, there's some required "routine starts here" at the top and a "return to calling program" at the bottom. If Hamfist types in these areas, it is likely to screw things up. In fact, sometimes our clubfooted clod will put the "return" sequence in the middle of a routine, and at that point two things happen:
Fascinating. This is very what we used to do to patch software that was flawed. The routine would not simple return but would go to another routine that provided a proper fix. Additionally, the duplicate code, combined with this thought sounds a lot like the patch areas we would reserve for the code fix.

Love the analogy!
 

Shop Amazon

Shop Amazon
Shop Amazon; support TONMO!
Shop Amazon
We are a participant in the Amazon Services LLC Associates Program, an affiliate program designed to provide a means for us to earn fees by linking to Amazon and affiliated sites.
Back
Top