Based on their merits?

From what I have read, Temple Grandin does not support your arguments. From her essay Animals Are Not Things: A View on Animal Welfare Based on Neurological Complexity:

Her opinions do not support your assertion that "the motivation and perception of a pig is incredibly different from that of a human," or that animals do not resemble human behavior or emotional responses.

Whoa, don't blow my mind quite so hard. I'm not sure I can handle all this wisdom at the same time.

C'mon, you think I execute shell commands by writing a C program that calls fork(), exec(), and pipe()? You think I write web pages pixel by pixel? Obviously high-level languages and programming paradigms are appropriate in many cases.

I'm sticking it to the Java weenies who think that C and C++ are obsolete. The people who year after year say that *now* Java is "often as fast as C++ and sometimes faster." The people who still won't acknowledge that there is a real reason C and C++ are still the languages of OS kernels.

It's not premature optimization to write libavcodec in C. Likewise with OS kernels, virtual machines, rendering engines, DSP plugins, and many other applications where the code will almost certainly be on the critical path of a resource-intensive application. It's not premature optimization to use manual memory management in applications that need to move lots of data around with low latency.

Chrome got me where it matters most - raw speed.

This is why I never understand how people can say "sure, maybe Java/garbage-collection/50mb-binaries/etc. are a little slower, but computers are SO FAST these days and programmer productivity is SO much more important. Hardware is cheap, programmers are expensive." etc.

Speed still matters! And it always will.

The stuff in the linked articles is nothing, read this: The Injustice Collector: Is James Joyce's grandson suppressing scholarship?

Stephen Joyce to a James Joyce scholar he disagreed with: "You should consider a new career as a garbage collector in New York City, because you'll never quote a Joyce text again."

Firefox is already multithreaded (if it weren't the UI would freeze during downloading, rendering, etc).

It does freeze during rendering and downloading. Simple way to reproduce: navigate to a 100MB file and see what happens to the UI.

FLAC is years older than Apple Lossless. FLAC was sitting out there for the taking when Apple decided to implement their own.

Your "abstract solutions" all take orders of magnitude more memory than C, and still suffer garbage collection pauses.

Why isn't your web browser written using these "abstract solutions"? The answer is the same reason that having real machine code on the client is a win, for those who want to go to the trouble.

A couple addenda to my last post:

• I said BigTable is "the" data storage system we use. I should have said "a" data storage system we use -- of course it is not the only one.
• I work for Google, but of course to not speak for them.

That's because MapReduce is a data processing system, not a data storage system. You should read about BigTable, which is the data storage system we use (I work at Google), which does support updates.

In your comments on this thread, I think you miss the key difference between an RDBMS and a system like BigTable. BigTable is almost perfectly horizontally scalable. When you need more capacity, it really is as simple as throwing more machines at the problem.

RDBMS's can never give you this kind of horizontal scalability, because they make a promise to you that you can transactionally modify any two bits of data anywhere in your database. Fulfilling this promise requires that either your whole database lives on a single machine, or that you use a distributed transaction protocol like 2PC (which totally kills performance).

So when your database gets busier than a single machine can handle, you have to manually partition your database into multiple physical databases. All the nice RDBMS features like transactions, joins, foreign keys, triggers, etc. can only (reasonably) work within a single physical database. The divide between physical databases is something your application code has to deal with -- it has to know to direct its queries to the correct partition. And repartitioning your data to run on more machines later is an invasive procedure, both operationally and to your application's code.

BigTable is designed around the reality that a database of any significant size will need to run on more than one machine. It only guarantees that you can transactionally modify data within a single row. This gives BigTable the ability to move rows around between machines without the application even knowing this is happening. If you add more machines, BigTable can immediately start moving some subset of your rows onto this new machine.

I recommend reading this paper for a far more in-depth look at this pattern. The key point of this paper is:

A scale-agnostic programming abstraction must have the notion of entity as the boundary of atomicity.

BigTable calls such entities "rows."

Maybe in your field, but these are by no means universal.

There's a point where your software is running on enough machines at the same time that the developer cost of optimizing it is cheaper than the hardware cost of buying more machines.

Just because you've never worked in a situation where this was the case doesn't mean it doesn't exist.