It simply is what they predicted, like it or not
Sorry, @Argon, "both"sides ended up employing design thinking.
1 Like
Repair components are subject to mutation as well. The idea here is “mutational load”. There are quite a few papers which discuss the maximum amount of functional sequences that can be carried in genomes. I think a few papers are discussed or referenced in some of the blog posts I linked. Here’s one from Dan Graur that discusses mutational load issues. The take-home message is that for any given mutation and reproduction rate, a species’ genome can only sustain so many functional sequences before too many errors accumulate.
T. Ryan Gregory also posed the “Onion Test” in which he asks people who think the genome is 100% functional to explain how it is that an onion requires about 5x the amount of non-coding DNA as a human. Larry Moran explains and clarifies the onion test in much deeper detail here. It’s a test of explanations for functionality.
Aside: This figure is one of my favorites from Dan Graur. It illustrates some of the problems with the earlier ENCODE paper which equated transcription with function.
2 Likes
From a “coding” perspective, we do not adjudge a portion of code “nonfunctional” just because is not, or is rarely, accessed, am I correct?
I’d recommend reading a number of the links I presented earlier. They get into the definitions and characterizations of the terms used.
1 Like
Thanks; maybe this evening. Cheers!
2 Likes
I’m doing some coding today… Brushing up on “R”, the preferred language of pirates, I guess.
Actually, code that is not accessed is ‘crap’. That’s a technical term…maybe. I’ve got an unsettling amount of ‘crap’ in some of my programs that has accumulated over the years. Most of these are blocks of code that I bypassed with later revisions or made excess with improved blocks. In many instances, they are definitely nonfunctional. In a sense they’re like pseudogenes. These persist because I’m a hack of a programmer and keeping code clean is not a high priority. Also, I don’t use version control repositories all that consistently. So historical relics persist.
Every blue moon or so, when I’m feeling particularly embarrassed, I sometimes go through the most recent program versions and strip out the ‘crap’ (non-functional, uninformative parts). This creates something that is, at least, aesthetically less irritating. Those deletions don’t affect the software’s performance but makes maintenance easier and certainly makes it easier for me to see what’s going on.
Agreed. It’s just that in a dynamically partitioned program, unlike most systems, which is always running, it’s incredibly difficult to determine “useless fragment” status, because the fragment may actually be functioning as a signal tag for where to continue or edit an unusual transcription, as we’ve come to recognize the transformative roles some “pseudogene” snippets can play. Evaluating and editing your own custom written code is not the same as evaluating and understanding someone else’s, right?