Absolutely, but that's true of most information as well. For example, the information in the article is relative to the context of understanding our language and the body of assumed knowledge and references of a reader of the New Yorker.
My understanding of biology is very limited. I've heard how physically small microbes are in every article out there. But never how information-small they are. Fascinating from a software developer's perspective.
I wonder what code golf for a virus would look like.
Like viriods, which make a virus look huge by comparison:
> Viroids are plant pathogens that consist of a short stretch (a few hundred nucleobases) of highly complementary, circular, single-stranded RNA. Viroid genomes are extremely small in size, ranging from 246 to 467 nucleotides (nt), and consisting of fewer than 10,000 atoms. In comparison, the genome of the smallest known viruses capable of causing an infection by themselves are around 2,000 nucleobases in size. The human pathogen hepatitis D virus is similar to viroids.
> Viroid RNA does not code for any protein. Their replication mechanism uses RNA polymerase II, a host cell enzyme normally associated with synthesis of messenger RNA from DNA, which instead catalyzes "rolling circle" synthesis of new RNA using the viroid's RNA as template. Some viroids are ribozymes, having catalytic properties which allow self-cleavage and ligation of unit-size genomes from larger replication intermediates.
The action of ribozymes led to the RNA world hypothesis, as the mechanism for how you could have a simple system from which DNA and proteins can come as later optimizations on particular aspects. Some ribozymes are able to go as far as catalyze the building of their own RNA structure in the right environments (albeit, with limited success so far).
Right. It's so much context dependent that the "hardware" of a different animal may react very differently to it - perhaps even ignoring it altogether.
The genetic information is really the 4.8 kB of "code" PLUS the entire information already contained in the cellular hardware reading it. One doesn't make sense without the other.
At the very bottom, the whole thing depends on the laws of quantum mechanics in this universe, governing the minute details of molecular interaction. That, too, should be considered to go into the "code". Make a tiny change to the Plank constant, and the Zaire ebolavirus code will do something very different.
Thank you for saying that! Its so often repeated that our DNA contains the entire program for a human being. That's patently false. The cellular machinery provides almost all of the OS; DNA is just a script.
I liken DNA to a paper tape containing one of two punches: MAN or MOUSE. Feed it into a bio-replicator and get a man or a mouse. Does the paper tape define the man? Of course not.
> I liken DNA to a paper tape containing one of two punches: MAN or MOUSE
I don't think that really captures it. Yes, it requires external machinery to actually do anything, but DNA is much more information dense and carries much more of an exact definition of the organism to be produced.
Personally, I prefer the analogy of compiler source code. Sure, it can't do anything on its own. But it defines how an working external system (another compiler or an functional cellular environment) can produce a second possibly different system
I don't think that's accurate at all. The DNA has no effect on the cellular soup - the RNA etc - that are the bioreactor. That you got from some ancestral Eve. It changes perhaps over time, like anything else through random chance. But its independent of the DNA, which is a tiny part of the whole.
It's important to think about your performance needs before you add any kind of third-party dependency. In production, you might consider using IcoMoon to create your own font with just the icons you need.  This library provides everything you need to do that.
The predefined classes give you flexibility when you're developing, but there's nothing stopping you from using your own names. There's also @extend in SASS that allows you to mix in icon styles to your application's classes without adding duplicate rules. 
+1 for IcoMoon. I tried a few of the other icon compilation apps and IcoMoon is by far and away the easiest to use with the best selection. There are slightly snazzier apps out there, but they just weren't as flexible as IcoMoon.
I think there are a couple reasons Mori and other libraries like it haven't caught on in the JS mainstream:
1. It's clunky to use them in vanilla JS compared to the default mutable objects and arrays. While you gain simpler semantics, the code becomes harder to read, and that tradeoff isn't always worth it.
2. Most JS developers are not experienced with building programs around immutable values.
would you mind simply explaining a little more what an immutable value is? I Understand immutable as something that cannot be changed.
> all of our collections are immutable
How can a collection which is data that eventually ties into a db be unchangeable?
var fooString = "foo";
var secondFooString = fooString;
secondFooString; // => "foo"
fooString = "bar";
secondFooString; // => "foo"
var firstArray = [1, 2, 3];
var secondArray = firstArray;
firstArray = 100;
firstArray; // => [100, 2, 3]
secondArray; // => also [100, 2, 3]
But, using Mori, collections are values, just like strings:
var firstVec = m.vector(1, 2, 3);
var secondVec = firstVec;
firstVec = m.assoc(firstVec, 0, 100);
firstVec; // => [100, 2, 3]
secondVec; // => still [1, 2, 3]
Instead of modifying firstVec in place, mori.assoc creates a new vector that is identical to firstVec except for the change we want. We then assign the result to firstVec. secondVec is unchanged. We are unable to go in and change the underlying values because a vector is a value, not a place.
The most obvious way to build this would be to deep-copy the entire collection when it's changed, but that would of course be way too slow and wasteful — imagine copying a one-million-long array just to change one element. Clojure, ClojureScript and Mori minimize unnecessary copying using a very thoughtfully designed data structure you can read about here: http://hypirion.com/musings/understanding-persistent-vector-... The short story is that, surprisingly, you get "effectively O(1)" copying when you use assoc.