Bill Dueber <[log in to unmask]> wrote:

> Unless you're in a very, *very* different library than mine, "all the
> low-level stuff" written in C and variants are at a low-enough level (and in
> very specialized domains) that I'd never have an expectation that anyone
> working in the library would mess with it. I presume there are people in
> research libraries that muck around with C/C++, rolling their own libraries
> and what not, but I've been at Michigan for six years and I haven't heard of
> it, here or elsewhere. For most of us, I think, doing something in C is
> premature optimization.

Completely agree with most of this.  The issue comes up when you need to
*fix* something in one of these libraries that someone else has
provided, or hook one of them up to your higher-level language.

> I hear the assertion often that a programmer needs to know C/assembly so
> they can truly understand how the machine is working at a deep level, and
> I've grown over the years to dismiss that assertion.

Yes, I'd say "needs" is too strong.

> Almost no one who makes
> a living programming in libraries is going to do a better job "by hand" than
> a modern optimizing compiler, certainly not if you take ROI into account.
> Data structures and Big-O is enough to tell you if you're moving down the
> right path, and then it's just a matter of being smart enough to use
> existing libraries where applicable --- and, again, avoiding premature
> optimization, at the code level or at the selection-of-a-language level. If
> you're hiring someone who's going to have to know the details of cache
> misses and how far to unroll loops or whatnot, you know exactly what you're
> hiring him/her for and don't need advice about hiring a generic programmer.

Yep, and yep.

> For stuff where you need not access to the bare metal but just raw speed,
> Java is mature, super-fast, and has lots of optimized libraries available.

Here's where we differ.  Java is mature, and very well-optimized (though
"super-fast" is perhaps a bit much), but the language itself is rather
poorly designed, and the libraries available are in my experience a sad
hodge-podge of brilliance and stodge.  I've spent far too much time
working around inexplicably years-old bugs in J2SE's standard library.

Some of the J2EE systems are very good, though.

> It also turns out many of us are using Solr these days, so Java has snuck
> into the library infrastructure already.

:-).  I used Doug's text-indexing library when he and Jan wrote it in
Common Lisp at PARC in the early 90's, and I was happy to see it appear
again in more commercially acceptable form as Lucene.  Lucene, and parts
of Solr, are important contributions to the technical landscape, and
Lucene is an example of an excellent Java library (I don't know Solr
well enough to comment).

But I use Lucene through Andi Vajda's excellent PyLucene, and I use a
couple of other Java libraries via JCC, Vajda's wrapper for those Java
libraries worth using.

> 90% of my argument for doing green-field projects in Ruby is that I
> can access low-level Java libraries to do the heavy lifting and get an
> optimizing VM for free.

The thing I've found about Python is that one rarely needs to stoop to
using Java libraries, as there are generally superior Python libraries
available.  This is perhaps just a comment on the relative novelty of
Ruby, which is a fine programming language in its own right.  Though if
my goal was to exploit the Java ecosystem, I imagine I'd use Clojure or
Jython instead.

> I don't care what scripting language you use, as long as you use it well.
> Python, Ruby, Perl, whatever. If you know one, you can learn the others.

I tend to agree about the learning, but that doesn't make them equally
useful.  The size and shape of the user community and the variety of
offerings and third-party libraries available are important
considerations.  A good programmer is aware of that and reflects that
awareness in his skill set.

> I would never foist a project in, say, OCaml or Scheme on my library,
> because who the hell is going to maintain it (and its environment)??

"What kind of programmer can I hire 'off the street'?"  This is an
important and unfortunate commercial consideration which sometimes
forces a trade-off with the quality and functionality benefits available
with higher-level "boutique" languages.

> But I sure want someone who understands side effects and their effect
> on multi-threaded programming, because I've got a lot of idle cores
> sitting around waiting for work.

Yep.  Some nice features in Clojure for exploiting that.
  
> Finally, I always ask someone what their favorite programming environment
> is. I've had a few candidates tell me that they just use Notepad, and I
> don't mind admitting that that's almost a dealbreaker for me. Using a good
> editor or an IDE is a critical part of taking advantage of the language
> ecosystem. A good programming editor is a must.

Yep.

> Not having at least syntax highlighting and checking is, to me, a sign
> that you haven't written enough code for the lack of such
> functionality to drive you nuts yet. Java without an IDE is insanity.

What does that tell you about the language design?

> And if the candidate proudly tells you that she uses vi, well, make
> sure she really knows how to push it around. You don't get street-cred
> for using a 30 year old program shittily.

:-).

Bill