Hacker Newsnew | comments | show | ask | jobs | submit | rads's comments login

It's a joke, people. Among the other things he's doing in Thailand, he actually is selling keyboards and seems to be quite content with his situation:



Yeah, but don't forget the complexity of the hardware you need to run ebola versus a website. Our bodies provide most of the implementation details.


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.

Source: http://en.wikipedia.org/wiki/Viroid

In case you were wondering what a ribosyme is

> A ribozyme (ribonucleic acid enzyme) is an RNA molecule that is capable of catalyzing specific biochemical reactions, similar to the action of protein enzymes.

Source: http://en.wikipedia.org/wiki/Ribozyme

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


Yet the dynamic biochemistry of the cell is orders of magnitude larger and more complex than DNA. So its larger than a paper tape, sure, but the comparison is pretty good really.


Paper tapes can't catalyze their own creation and modification. DNA can with the addition of ribonucleotides.


Mitochondria for example are (mostly?) independent of your DNA.


And yet the paper tape of a plant or animal genome (as opposed to a virus) also contains the instructions for the OS and the bio-replicator, which is part of what's so fascinating about it.


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.


The interpreter is ridiculously complicated in order to make up for the conciseness of the programming language.


you could make that argument for certain hardware optimizations, too (like SSE, GPU, PPU, etc). A computer is not a raw turing machine.


A little further down the same post [1]:

Given that a safe path through the JavaScript minefield isn’t enough, it seems like we need a detailed map of the minefield. Many books and blogs have been written to provide that map. JavaScript: The Definitive Guide by David Flanagan is one of the most detailed of those books. The JavaScript Garden is a good place to start learning about the mines online. [2]

[1] http://www.walkercoderanger.com/blog/2014/02/javascript-mine...

[2] http://bonsaiden.github.io/JavaScript-Garden/


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. [1] 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. [2]

[1] http://icomoon.io/app

[2] http://sass-lang.com/documentation/file.SASS_REFERENCE.html#...


The flexibility with icomoon it fantastic, once you get it wired into the app. And the ability to add your own, custom svg's is very handy!


Yeah, the ability to quickly make my own icons when the icon set I've bought doesn't have exactly what I need is pretty awesome.


Icomoon is great, I just wish it provided Compass markup so I could have the cross-browser support Compass provides.


+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.


yes I love icomoon!


I couldn't find a specific email address to send the application, so I just used info@pathable.com. Is there a better way to contact you guys?


This sounds like a case of simple, not easy: http://www.infoq.com/presentations/Simple-Made-Easy

You could add a timestamp to each todo with two changes:


    (defn handle-new-todo-keydown [e {:keys [todos] :as app} owner]
            (om/update! app [:todos] conj
              {:id (guid) :title (.-value new-field)
               :created-at (js/Date.)  ;; <-- add this line
               :completed false :order (count todos)})

    (defn todo-item [{:keys [id title editing completed] :as todo} {:keys [comm]}]
                ;; change this line
                (dom/label #js {:onDoubleClick #(handle-edit % todo m)} (str
    (:title todo) (:created-at todo)))


The main features David talks about in the post are available in vanilla JavaScript:

> If you're a JavaScript developer, I think taking a hard look at React is a really good idea. I think in the future, coupling React with a persistent data structure library like mori could bring JS applications all the way to the type of flexible yet highly-tuned architecture that Om delivers.

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.


That's true, on all counts.

Meteor could use Miro inside minimongo on the client, for example, and turn objects into vanilla JS before passing them to the app, if that implementation offered significant performance benefits (or equal or better performance and cleaner code, though the size of the Miro payload would also have to be weighed). Once the app has to deal with Miro objects, though, it starts to feel less like the JavaScript people know.


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?


Think of strings in JavaScript. Those are already immutable:

    var fooString = "foo";
    var secondFooString = fooString;
    secondFooString;  // => "foo"
    fooString = "bar";
    secondFooString;  // => "foo"
We set the variable fooString to point to a different string, but the original, underlying string hasn't changed. In JavaScript, we can think of a string as a value.

This is not the case with arrays in JavaScript:

    var firstArray = [1, 2, 3];
    var secondArray = firstArray;
    firstArray[0] = 100;
    firstArray;  // => [100, 2, 3]
    secondArray;  // => also [100, 2, 3]
Because we can change the underlying contents of the array, an array in JavaScript isn't a value. It's a place: a reference to a location in memory. The underlying value could be changed at any time.

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.


http://en.wikipedia.org/wiki/Persistent_data_structure :)


I've seen two libraries suggested on the React mailing list:



The first one uses the same data structures from ClojureScript.


Welcome to the Microsoft Outwars Website!


Some advantages:

- Yes, built-in async support is very important

- Everyone has to write JS at some point anyways -- it helps to take advantage of what everyone already knows

- You can easily share code between the client and the server

- There are tons of modules available on NPM already

- The compile-to-JS languages are getting more practical every day, and you can integrate them with existing JS code

If you consider time spent learning a platform compared to what you get out of it, Node.js is probably the best bang for your buck today.



Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact