|
> months that's a drastic overestimate. at some point, procedural languages really are all more or less the same. sure, there are different notions of types, variable scope, modularity/oo-ness, etc., but someone who knows a bunch of languages knows what concepts to get straighted out from the beginning and can be productive in days. if you find someone who knows a handful of procedural languages and haskell and lisp, they'll be able to pick up whatever language you're interested in. now, picking up a bunch of toolkits is a different matter, because they really can be just a quirky as their designers want them to be. for example, using gson yesterday, i ran into a bug with json serialization that was pretty quick to diagnose by stepping through a few lines in the debugger, but it took over a half hour of searching and browsing api docs to find out that Maps weren't being serialized properly because i hadn't called GsonBuilder.enableComplexMapKeySerialization(), which it seems like really ought to be enabled by default. then -- and not even finally in general, just finally for the sake of keeping this post briefish -- there are frameworks, which are like a perpendicular axis to the original language question. perhaps someone really familiar with rails or django and a little java background would be a better choice for a java project built on play than an expert java desktop developer with no server-side experience. so in summary, if you can find someone who has basically already built your exact project before, yeah, you'd better hire him or her, but otherwise, intelligence, the ability to figure new things out, is always going to trump experience along any single line of expertise that one can attempt to draw through a software project. |