Too many languages

There are thousands of programming languages.

The purpose of a programming language is to express programs. The
purpose of learning programming languages is to build up a toolbox for
reasoning about and synthesizing programs in any one given language.

There are diminishing returns on learning programming languages, and
time is scarce.

Therefore one must select between programming languages to study.

A good selection of languages has both
+ breadth
  + satisfies a number of real world economic needs.
+ focus
  + exploits similarity between languages and incremental learning.
  + some unifying basis

A good member of a particular selection meets a number of the
following criteria:
+ Satisfies one particular school of thought on programming languages.
+ Significant difference from predecessors
+ Significant influence on successors
+ Economically significant
+ Advanced i.e. no direct, established and proven heir.
+ A good language.
  + Easy to express programs with
  + Easy to read programs expressed with
  + Easy to reason about programms expressed with

No one of these criteria are sufficient or even necessary conditions.

A bad member satisfies the opposite criteria.

>>113
Except that isn't true. A user space garbage collector can use system calls like mincore to check whether an operation is going to cause a page fault or not. I'm not aware of any well known GCs that actually do this, though - changing page mappings is itself a potentially expensive operation so it may be better to avoid such tricks. The same goes double for cache line management - you'd really need to benchmark heavily to tell whether there is a benefit to doing what you suggest. There are well known cases where trying to second guess the CPU's cache management actually hurts performance.

To argue from ignorance a bit - if added hardware support were really so useful, you would see the implementers of popular language VMs like Hotspot, CLR, or V8 recommending new intrinsics for the CPU designers. The market for hardware that runs these VMs is certainly large enough for folks like Intel to consider it worthwhile to add such things.

The last time I checked this was not happening - the language implementers seem to spend a lot more of their time talking to the kernel people to improve code paths that their VMs exercise heavily. Unless you take the position that the language folks are ignorant of what hardware can do for them I'd judge that hardware support isn't the panacea you say it is.