

Programming in a Vacuum - edw519
http://www.stanford.edu/~pgbovine/programming-vacuum.htm

======
aaronblohowiak
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.

~~~
SirWart
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.

------
huhtenberg
> Libraries are key

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 :-)

------
TrevorJ
Damn my visual memory, I actually picture somebody sitting in a Vacuum cleaner
programming. Sorry, I know that adds nothing to the conversation.

~~~
Prrometheus
Programming in Space!

~~~
aaronblohowiak
reading that, i thought of
<http://en.wikipedia.org/wiki/Whitespace_>(programming_language)

