Point-in-case (Score 1)

Have a look at Clean (http://clean.cs.ru.nl/) for a use of pointers (internally) that makes for efficient execution. An interesting read concerning the subject is found here:

http://clean.cs.ru.nl/contents/Addison__Wesley_book/addison__wesley_book.html

Actual benchmarks to show the efficiency can be examined here (note the comparison is with C-versions of the same algorithms compiled on gcc):

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=clean&lang2=gcc

Here's Java 6 (server version) for comparison:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gcc

You'll notice that differences are mainly in the memory footprint, already known to be attributable to the large number of libraries (classes) loaded into the vm at start-up, something the Clean runtime isn't quite as encumbered with:

(Java) http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFootprint.fm.html

So, the difference in speed is often-times negligible, and it's been shown that the memory footprint can be reduced to a size where you can run an embedded jvm in a mobile phone (really!), and rumour has it that someone even wrote an operating system in Java, but the memory footprint still seems the biggest culprit:

http://www.jnode.org/node/573

In other words, it's not Java - the language, but Java - the massive OO-framework, and JVM - the specific implementation, that's the problem. Even C++ or C with an OO-framework can be made into a large memory footprint, if you can believe it:

http://www.microsoft.com/windows/products/windowsvista/editions/systemrequirements.mspx

Then, of course, memory is cheap:

http://www.simmtester.com/page/memory/memprice.asp

But, the over-use of which, sometimes stays with us as itching bugs for too long:

http://blog.wired.com/monkeybites/2007/11/firefox-3-add-o.html

If memory serves me right (http://www.google.com), there's something to be said of the virtues of garbage-collection applied to systems programming:

http://www.digitalmars.com/d/

and the actual (memory and) time efficiency of such an attempt:

http://shootout.alioth.debian.org/gp4/d.php

But I could be wrong. After all, no-one in their right mind would ever attempt to write an operating system in something like, say, Lisp:

http://cbbrowne.com/info/lisposes.html

- let alone design an actual computer around it:

http://en.wikipedia.org/wiki/Lisp_machine

It simply wouldn't run. No, the skills of an engineer depend solely on the language he/she speaks, not on the abstract concepts he/she masters, applied to whatever tool he/she chooses to use/create.

That is why I propose we all forget about abstraction all-together, and revert to coding like this:

010101100001111010110101101101111101111...

But wait, that is itself an abstraction - Turing must have suffered from premature abstraculation. No, let's hear it for using copperwires instead of silicon, so we can attach some large, hand-weilded levers to control the gates in our processors. Will solve unemployment issues and give a new meaning to "inter-personal communication" and "trains of thought" in the process (pun unattended).

[Disclaimer: I do think keeping the study of algorithms, machine-code, optimization and the like is a more than necessary part of a CS degree, and that the latest fad since the 80s is almost never what it's made out to be (most great advances were made by people in the 50s-70s, some of them on heavy drugs). It was never the languages themselves, though, but the reasoning behind them (the method/model of abstraction) that constituted the advance. So just as medical students aren't just taught symptoms (although they do deal with them alot later on), CS students shouldn't just be taught languages, be it C, C++, Java, Clean, or any other symptom of our times.]