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

Okay, IAAEOC++0x (I am an expert on C++0x), one of my group's PIs is Bjarne Stroustrup and my committee consists of members from both the Indiana & Texas concepts proposal; the extended group is responsible for lambdas, concepts, variadics, for-each constructs, etc. Credentials aside, "templates" != "generic programming". Concepts were designed to provide a predicative type-system for templates [think of this as a kind-system] which allows us to get rid of most of the template metaprogramming hacks (SFINAE enable-if/disable-if, type computations, etc.). Variadics (also for templates) get rid of list-like type-computations. At the cost of adding a relatively light-weight description of an interface (think of a concept as a compile-time only interface) we can get rid of almost all of the hairy bits of template coding.

The reason why concepts was rejected is due to some of the uglier corner cases stemming from a requirement for soundness in the type-system using concepts. As we are slowly approximating second-order types with C++ (all typeful languages end up doing this to increase expressivity) there are bound to be some hiccoughs. What happened at ISO (as far as I know) came from an argument on the reflector which revolved around the default of whether a concept was auto(matically) satisfied by a type or if it must be explicit [a fairly arcane argument], in addition to the handling of associated and intermediate generated types. It is not clear if a simpler solution can be constructed for a decidable type-system.

You're desire is for a language that supports "gradual typing"; read about it here: www.cs.colorado.edu/~siek/pubs/pubs/2006/siek06:_gradual.pdf

Let me amend that last line of code for you (C++0x, auto variables and for-range loops):

for (auto it : list)
  cout << (*it)->name << "\n";

... although, I am not going to argue that, in general, C++ is a damn wordy language.

Whoah, there, Sparky. Natural selection is well-and-alive; the dogs that are the cutest, most adequately serve function, match form best, etc., are selected for in their environment. Remember that the "natural" part of natural selection is similar to nondeterminism: it is something that happens "from the outside." In this case "outside" is the non-Dog world. Just because a terribly complicated (possibly intelligent) force is acting on the dogs doesn't change anything.

Hey ... I've been looking for this state, UK, for like an *hour* now. It sounds New-Englandish, is it next to Delaware?

It appears to be free marketing for some webcompany. I don't speak or read marketroid in any language, but it appears to be a UI designer for web-apps. So... probably 3% of the functionality of Visual Studio (15% of Anjuta) but 1000x slower.

I've got the pencil in my left ear to stay. Do I roll up the paper, or what? Should I cut a hole in it and hang it on my nose?

IAAECXRPX (I am an ex-computational-x-ray-protein-crystallographer). Lasers a bit left wing, since we usually use anode sources for x-rays on the home source and synchotrons for MAD sets. However, if the laser has tight enough phases (60-degrees) and coherency this is not just big but HUGE. Currently, there are two difficult steps in PX: (1) crystallization; and (2) phasing. The first is becoming easier using automated screening and robots (although we are only at the beginning of this process, so probably still 5--10 years out). The second has been considered one of the outstanding problems in (at least) biology if not all of science. To put this in perspective, it was only a few years ago that just *finding* the structure (phasing) was enough to warrant a Nature or Science paper. Nowadays you're gonna need some function, too, but the phasing is still spectacularly hard. If these guys have really done this, and they're getting good power, this will be a watershed event for all of biology.

The wind can shake a sail, but the sail will not make a nor'westerly.

Make sure the touch screen works through pressure and not some electric effect. If it's in the kitchen you'll soon find you need to put some sort of saran wrap on the computer because the back-splatter from grease will coat the damn thing. Also, make sure the covering is easy to remove and replace, as this will need to be done fairly regularly, depending on your menu. We had a similar problem for a small company w.r.t. children and food.

Given a fast-as-C javascript engine, you could have a pretty decent VM to share between several dynamic languages, and due to JS's dynamic nature compiling these languages to JS is fairly trivial.

You made me snort coke out of my nose. Hold on ... let me contact Goto, and tell him to port Goto BLAS to JavaScript right now!

Wait ... let me try to understand this: you mean a good offense is the best defense? BRILLIANT!