From the article: "Libraries are key. Think about it: most programming tasks involve organizing and gluing together library code; most programming tasks do not involve the creation of novel algorithms that compel the use of sophisticated programming language constructs (emphasis on most --- I do admit that the benefits of a more powerful or applicable language are greater when one is trying to solve harder problems)."
The author seems to completely miss the fact that you can have semantically dense high-level languages act as the glue between libraries implemented in whatever language they happen to be written in.
"Those who don't understand UNIX are doomed to reinvent it."
The notion of using the best tool for the job is correct, and the notion of chosing the best libraries is correct, but the assumption that you must use Foo to consume libraries written in Foo to construct a program is wrong.
One of the metrics we don't see enough (IMHO) chatter about is how well languages play well with others.
There are SEVERAL ways to accomplish integration.
At the moment, I enjoy using JRuby because ruby has minimal pain and java has a cornucopia (glut?) of libraries. Things like the translation of MIPS machine code to JVM bytecode are interesting, but I need to check them out more before I recommend them.
I think higher level languages built on top of the JVM or .Net are very compelling because of the intersection of painless backwards compatibility and higher level constructs. Building bindings to higher level languages is usually a pain, and by working directly with those virtual machines you eliminate that.
Compiling from one language to another works better if you are going from a higher level language to a lower one, so machine code to JVM is probably not going to work very well but JVM to MIPS is not that hard.
The last thing you want is to use a library that segfaults now and then, relies on a bubble sort and occasionally allocates a couple of gigs of memory. Unfortunately, a vast majority of libraries are exactly of this kind.
I'll give you two real-life examples.
1. netsnmp - de facto open-source standard library for working with SNMP. This piece of engineering marvel makes close to a one million calloc() calls when handling SNMP requests for certain kind of static data. The kind of query that technically does not require even a signle memory allocation.
2. I used to work with a fanboy of ACE, who decided to replace two pages of trivial C code with 10 pages of ACE goodness. Which is fine with me, whatever gets the job done. However then his code, running on a production system, deadlocked deep in the guts of ACE. He spent a week troubleshooting it and in the end he still requested we'd hire "ACE consultant" to help him out.
The point is that even mature libraries have bizarre problems. With a rare exception of super widely used libraries (such as libc, openssl, etc), the library code needs to be reviewed prior to being included into a production code. Caveat emptor.
Vacuum or not, it really comes down to whether you want to debug someone else's bugs at 4 AM on a live server :-)
The author seems to completely miss the fact that you can have semantically dense high-level languages act as the glue between libraries implemented in whatever language they happen to be written in.
"Those who don't understand UNIX are doomed to reinvent it."
The notion of using the best tool for the job is correct, and the notion of chosing the best libraries is correct, but the assumption that you must use Foo to consume libraries written in Foo to construct a program is wrong.
One of the metrics we don't see enough (IMHO) chatter about is how well languages play well with others.
There are SEVERAL ways to accomplish integration.
At the moment, I enjoy using JRuby because ruby has minimal pain and java has a cornucopia (glut?) of libraries. Things like the translation of MIPS machine code to JVM bytecode are interesting, but I need to check them out more before I recommend them.