There were two *great* comments prior to mine:
(1) Have rock-solid algebraic (symbolic) manipulation skills;
(2) Really know your trigonometry.

My family has been using Sylvanus P. Thompson's "Calculus Made Easy" for several generations (the book was first published in 1910). It really is a wonderful introduction to Calculus (targeted at high-school students). There are two versions:
(1) The classic text, search for "Sylvanus P. Thompson" and "Calculus Made Easy";
(2) The updated text co-authored by "Martin Gardner".

The only reason Scheme or Lisp can do so much is because they were originally written in Emacs.

Yes. There is a large focus on two different aspects in a lab I used to work with a few years ago:
(1) Retinopathies (problems of the eye);
(2) Preventative treatments for cancer.

Here are some links:
[1] http://inbt.jhu.edu/biosensor-targets-retina-cells/2006/11/15 -- a multilayer "machine" which executes a biochemical program;
[2] http://nanohub.org/resources/3541/download/2007.10.15-leary-nt501.pdf -- lecture notes on the state-of-the-art nano- magneto- and silicon particle drug delivery as of late 2007.

I was about to call BS on this; however, after reading the links it me want to read "Hamlet" in the original Klingon.

As someone who knows plenty of people in the "7 digit income class" I can guarantee you that they consider themselves upper-middle class. I think you should probably start at the 8-digit range, i.e., large companies.

I spent years in Texas schools, and we were always told it was a giant brass armature. When did God put in the bling?

So ... wait. You're claiming every Texan is responsible for a few judges, probably locally elected? This sounds like gross generalization of guilt, to me. How about I turn around and make a responsible demand: since you demanded punitive action against every person in the state of Texas regardless of guilt, how about having your personal citizenship revoked?

Also, having lived/stayed in a number of states now, I can say that racism and other breeds of bigotry are universal (or not), and that none of the states I've been to have I met people more/less bigoted than anywhere else [mostly not bigoted]. Well, except upstate New York and northern California; some of the people I met up never got past the 1950s.

Now, when he says "truly correct", I'm assuming he doesn't mean formal proving. That would be absurd, especially for an operating system as complex as Windows or Linux (or really anything with limited resources). Anything short of the formal proof and you just have empirical evidence that it works - but if there's a billion branches and trillions of code paths, nobody will hit all of them with all data.

I used to hear similar sentiments with regards to compilers. Check out Xavier Leroy's work: http://pauillac.inria.fr/~xleroy/ Yeah, that's mainly the work of one guy; his students' work is related, but not necessarily in support of his project.

There are a lot of us who are spending serious time understand Coq et al. because formal verification is advancing to the point where if you don't understand the technology and how to use it, you're going to be out of a job.

Screw the heat, you're going to have an IO and power deliver problem. Assuming a cubic uptake of density of transistors, you'll only have quadratic uptake in IO ports. Right now we use the 3rd dimension to help increase IO and power density (lifiting it up/down a layer; because we have a quadratic/linear problem with current chips). By the time you've managed to solve those problems (lowering transistor density to allow IO/power paths) you'll end up with a plain-old-chip, anyways.

Hold on, there, Sparky. Assembly, C/C++, your-favorite-compiled-language ... are all just as "fast" as each other. They're all dependent upon the compiler for "speed". I recently moved to Big Company where we do Serious Embedded Programming. The old-skool assembly programmers were always bitching that "compilers were no good" and that to get real speed you had to "program to the iron." Here's what I observed: they redesigned the algorithms when moving to assembly. So, basically, they had algorithmic improvements. This was generally true except, in certain cases, when it was impossible to completely annotate the "hot" variables and how register spill/fill should be performed. In this case I suppose we are just dealing with a lack of expressiveness, and not any sort of fundamental problem with "high level" (or lower level) languages.

None. Copyright should protect against commercial uses -- as was its original intent.

Just read through the patent. (1) The writing is quite clear and understandable -- kudos; (2) the patent is obvious to any member of the field. I cannot believe that any software engineer/equivalent-expert could sit in front of a court and claim that it is not obvious without perjuring themselves. Literally, all this patent does is separate the "control" codes from the "content", where the control codes include indirection information. Even in school when we had to encode data with metadata, this is one of the techniques we used (the other is markup).

School of hard knocks?

I don't even know where to begin a serious criticism of this. Let me start by asking a question: which computer is it, exactly, that you use supports a native array type? In x86 I suppose the closest would be a 4-way SSE vector? This only captures a subset of the cases you mention. Let me continue point by point:

(1) Escape hatch. Name a real language without an escape hatch? Haskell, O'Caml, LISP, Java, C#, VB, Cobol, FORTRAN, etc. can all link to C-binaries.
(2) Distinction between arrays and pointers. Misinformation: the problem is that an array decays to its equivalent pointer type with little effort. Any conformant C++ compiler can, will, and does reject passing an explicit array, i.e., char-string literals, to a parametric type expecting a scalar; even GCC does this.
(3) "Responsible for most buffer overflows". Is it? Data? My recent reading of bug-sources in the literature does not support this.
(4) "C++ didn't have &". Again, C++ inherited the array-decaying-to-pointer from C. Maybe this is a bad idea. If you could please write a short document explaining a backwards-compatible fix for this, that'd be great.
(5) I don't really understand your STL comment. At what point is the STL --- an algorithms library --- going to replace a data-structure? Perhaps you mean that the limited set of containers in the std namespace don't fully replace an array? Perhaps. I think there are some missing random-access containers: fixed-length arrays and wrappers around raw pointer-buffers are examples. There is also a regrettable lack of trie's, R-trees, quadtrees, 2-3-trees, and the rest.
(6) "Most modern languages approach iteration...". Sure. That's why C++0x is introducing a for (i : X) [foreach] construct.
(7) "Safety." First, there is no definition of "safety." Second, even if I admit there is a workable definition of "safety", it has never been a concern for C or C++.