Interestingly, I disagree with almost everything you say below. Of course PARC is unlike almost everywhere else :-)
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. 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. 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. 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. It also turns out many of us are using Solr these days, so Java has snuck into the library infrastructure already. 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. 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. If you're a Python shop and want someone who can hit the ground running, that's fine, but Python's not ubiquitous. I don't speak Python except at the most superficial level, and yet I consider myself to be "devoted to my craft". People who have seen my code may disagree :-) For languages that are, shall we say, "less commercial," I think they're useful as an analog for formal computer science training. There are plenty of people who gain great skills and knowledge purely through experience, but formal training is basically designed to short-circuit experience, and I think a formal computer science degree (and esp. a master's) does a great job of training people to think hard (and correctly!) about algorithms and data structures. I expect someone with a CS degree to have been exposed to functional programming, s-expressions, and a variety of data structures. Substantial experience with Erlang or Haskell or Scheme or whatever tells me (as long as the project truly was *substantial*) that the candidate has at least thought hard about issues deeper than the ones one often runs across dashing off a program in PHP or Perl. 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)?? 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. 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. 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. 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- On Wed, Jul 27, 2011 at 10:32 PM, Bill Janssen <jans...@parc.com> wrote: > If I'm hiring a programmer, I want them to know C and Python. C because > all the low-level stuff is written in that, Python because it's simply > the most useful all-around programming language at the moment, and if > you don't know it, well, how devoted are you really to your craft? > > Various flavors of C are acceptable: Objective-C is OK with me, and C++ > is a plus -- it's an order of magnitude more difficult than C to use > properly, and people who can sling it properly are rare. Additional > languages which carry weight with me on a resume are OCaml, Processing, > and any of Common Lisp, Scheme, or Clojure. > > If I was hiring a digital *librarian*, I'd also expect them to know > Javascript, the language at the heart of the EPUB format. But > Javascript is kind of tricky; it's a subtle powerful language with bad > syntax and weak libraries. I certainly wouldn't recommend it to start > with. > > Cary Gordon <listu...@chillco.com> wrote: > > There are still plenty of opportunities for Cobol coders, but I > > wouldn't recommend that either. > > Java is the COBOL of the 21st century, so if you know Java well, there > will be a job in that for the next 20-30 years, I'd expect. Until the > Singularity happens, anyway. I'd think there will always be lots of > enterprise Java jobs around. > > Bill > -- Bill Dueber Library Systems Programmer University of Michigan Library
