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