I think Indian infrastructure is going to have a hard time coping with this.

Tried getting anywhere in New Delhi recently? A 10km ride can take HOURS. I'm not exaggerating or kidding. You will literally stand in one spot for half an hour. Nobody obeys traffic rules and gridlock is the norm.

The Indian middle class is looking to copy the west, and they want their SUVs and their tall lattes too.

In late afternoon in New Delhi (about 6:00pm or so), you can STARE AT THE SUN without feeling any queasiness in your eyes. That's how bad the pollution is.

Instead of looking to other cultures and trying to NOT make the same mistakes, India is eager to copycat them. Heh... you think Americans go a little bit overboard with the bling and the super-size-me? Just wait.. just wait.

-Laxitive

I had the same impression, except I didn't want to say it in quite the direct way you did. I'm not in crypto.. I just have a math/cs degree and work in biotech. The whole thing seemed kind of hokey to me, but I don't have the expertise to dissect it properly from a crypto perspective.

Couple notes for people who haven't read the paper:

1. Their scheme is not in-vivo (they're not actually working with DNA and proteins). It's a computational process that is based on the information transformations that occur inside a cell.

2. It's kind of cute and nifty, but not particularly applicable. They discuss weaknesses in the attack, but in a pretty handwavey way. The core problem is that their "encrypted text" will include their entire plain text, just split up into pieces. Secondly, it doesn't seem to offer anything particularly new when compared to traditional block ciphers.

3. Mathematically, this has nothing to do with biology. It's just loosely based on biological processes, and it's not really clear that these biological processes have anything particular to contribute to development of encryption. Transcription is just a mapping (from genomic DNA to mRNA), and translation is just a lossy mapping (from 3-tuples of mRNA to peptides). Mathematicians and cryptographers have been aware of generalized versions of these functions these for a long time (homomorphisms and reverse homomorphisms). There's not much new being introduced here.

-Laxitive

Let's say that Fox runs an awesome show that develops a dedicated fan following. That's bad for FOX, because they no longer have control over that market segment. Good shows take time and effort, and passion and dedication by good people who will in general expect to receive respect for their creative output. That's bad for FOX executives because they suddenly have to consider the opinions and needs of a bunch of plebes at the bottom.

It's good to keep people hooked on perpetually churning set of "hot thing of the moment" shows based on replaceable talent and commodifiable appeal.

I mean, who cares if the top star in American Idol has a beef with the producers and walks out? They'll just film it and make more money running a special "Sandra breaks down and leaves!" episode. It's beautiful.

Good TV is a craft, not an assembly line. The assembly line is more efficient, it seems, and Fox has realized it.

-Laxitive

We're not talking about not having null references at all. Nullable references are in fact very useful in many situations, as you point out.

The problem is that in many languages, it is not possible to describe a non-nullable type. I.e. a type that guarantees that the value it annotates is not null.

This is useful because the vast majority of actual code doesn't really deal with 'null' references, and in fact will break if 'null' references are passed in. Right now, there are two ways to ensure your code is safe:

1. make assertion-type checks everywhere. This is a pain in the ass to write and maintain compared to providing a non-nullable type. It's also slow to throw in unnecessary null checks everywhere during runtime.

2. don't check aggressively, but ensure in an ad-hoc way that all not-null preconditions are met. Basically, you just make sure to never call the relevant methods with null values. This has the problem that you have to keep track of EVERY SINGLE PLACE a null may be introduced and eventually find its way into the method. This may be easy in simple applications, but can become very tedious in large applications.

Providing a non-nullable type constructor saves all of those things. The compiler can ensure that a NULL never makes it into a variable marked not-null. You don't have to care about it. You can split your code up into the sections that are "pure" and sections that are "impure", and keep all your null-sanity-checking in the (what should be a relatively small) 'impure code', which calls into the pure code, with the compiler ensuring the calls are all valid.

No work, just a simple type annotation. That's the potential.

-Laxitive

Oh no! You were exposed to the same information from two different sources!

Call homeland security! This gross indecency must end!

Doesn't the short fragment size produced by the Solexa machines negatively affect your ability to assemble them?

My impression of sequencing efforts is that while the Solexa platform is great for other analysis (say SNP detection, gene expression profiling, marker identification, etc.), but not the best tool for full-scale use in genome assembly.

I think you're being way too sensitive. We're not creepy at all. If only girls would understand that. Like this one girl I thought about a lot. I meticulously collected her hair over the course of weeks and used it to create a greeting card with the words "I'm thinking of you" spelled out using a mixture of her hair and my saliva.

Even after that gracious welcome, she dropped out of the class shortly after joining. Guess CS is not for chicks after all.

-Laxitive