No, that's complete bull. A real dev can pick up syntax in a week (or a day), but integrating concepts and techniques he's never seen so far and building up new instincts which correctly fit the new language, that does not happen in a week unless the guy is in the "genius" category.

What you really have after a week is a guy who writes $previous_language code in a new syntax. In the way "Real Programmers" can write Fortran in any language.

I'm a latecomer to the Ruby game, and have done a lot of PHP and JavaScript over the last 10 years (though those are far from the only languages I know and have worked in). It's been funny to see what kind of assumptions that means other devs make about what Ruby concepts are going to be big steps for me. I was told by some people that blocks would be a revelation and that metaclass manipulation would melt my brain. But blocks map pretty directly to the familiar concept of passing around functions, and metaclass hacking onto things present in Perl and JavaScript that I'd sometimes wished I'd had in PHP.

Similarly, Haskell and Erlang -- while significantly different from the languages I've used most of my professional life -- both feel pretty familiar after a long-ago stay in the land of Prolog.

I understand the impulse to assume you know something about a developer from the languages they claim proficiency in -- and the impulse to assume that devs who don't know the languages your revelations have come in haven't had those revelations. Generally, for example, I don't think particularly well of a lot of my fellow PHP devs. But when it comes time to make serious judgments like hiring, rather than asking them which languages they know, I want to look at whether they understand certain semantics at a language-independent level, I want to know what they like about the languages they know, what they'd add to the language if they could, and what they'd take away.

Most notably, all code in Ruby blocks, including return, super, and yield, execute as if in the original context. This means that you can return from inside a block, and it will return from the original method the block was created in.

This is especially useful for custom iterators. In contrast, code inside a "built-in iterator" (for and while loops) in JavaScript is executed in the original scope, while code in a custom iterator (forEach, map, etc) is executed in a new scope.

This makes custom iterators in JavaScript clumsier to use than the same in Ruby. ES6 adds a way to implement custom iteration in JavaScript that hooks into the for construct, but the benefit of this feature is not limited to iterators.

Further, the new JavaScript iterators cannot be used to implement functionality like map and reduce (take a look at Ruby's Enumerable module for other examples), they essentially hardcode a forEach construct into the language, which is useful, but is not the same.

Edit: Just to be clear, the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language. Ruby's compliance with Tennet's correspondence principle (x ~ lambda x) creates many new opportunities for block use that may be missed by people familiar with function passing in a non-correspondence language like JavaScript.

Didn't mean to imply they're in every way analogous anymore than I meant to imply that Haskell and Prolog are virtually identical. :)

Mostly I was looking for an example of a concept where other programmers seemed to think it was likely I'd've had limited exposure to and perhaps even trouble wrapping my head around (passing code) until I'd done it the same language where they'd come to understand/use it (Ruby).

"the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language."

If the keyword there is can, I don't disagree, both in the specific and general case. I know that even subtle differences between semantics can be important to both expressiveness and idiomatic constructs, I think it's credible that habit often results in trying to carry idioms over, and that a programmer who is only taught the syntax of Blam could be writing Blub in it for a while.

What I don't agree with some developers on is that this is a matter of constraint instead of trajectory -- that the languages a programmer already knows necessarily indicate the difficulty they'll have with adapting to differences and wielding them effectively.

To work with your example, it may be a decent guess that it might never occur to someone who hasn't worked in a purely TCP language to return or yield from inside a passed block, but I have my doubts that it'd be any kind of reliable predictor of how quickly they could wield the concept after explaining that it's kosher and showing an example where it's advantageous.

I think you're misapprehending the problem. It's not that Haskell programmers can't understand the structure of Blub. Gods, no. It's that it takes time and tolerance to be able to immerse oneself in the Blub culture. Blub has its way of doing things, much of which is more accidental than logical, and alas, much of what passes for colloquial Blub is probably stuff that Haskell was specifically designed to avoid like the plague. There's an initial tendency to either run around waving one's arms like Jeremiah, trying to convert the Blub programmers to the side of Light, or to take to drink in despair at the sheer Rabelaisian sloppiness of the Blub universe. To work through this takes time, and possibly therapy.

It's like anthropology. It's one thing to be a linguist and work your way through library books about the syntactic structure of a family of languages from New Guinea, but it's another thing to be airdropped into New Guinea itself, insinuate yourself into a local village, pray you don't die of any tropical diseases, learn which compliments in your native language are actually mortal insults in your new host culture, try to laugh along with the natives when they convince you to lean against a tree filled with stinging ants, and simulate exquisite happiness when your host offers up a delicious sample of the local insects. It's a cultural problem. Not everyone is up for that experience. One may have to work through a certain amount of shock.

Heck, even ye olde C has a whole litany of detailed spec edge cases you need to know about if you want to understand the finer points and avoid some nasty pitfalls (and an even bigger list if you go to C+POSIX).

Clearly not a hard-and-fast definition. The more "proper" scope of the word culture is, of course, ultimately a giant philosophical issue which I intend to blithely handwave away. ;)

(I suppose one could try to argue that all of C++ is a cultural artifact, and C and assembly for that matter, but sooner or later you'll reach the Turing machine, which if you chip away at it you'll soon discover is just the tip of an iceberg which consists of all of mathematics, and then folks like Plato will turn up on the battlefield looking for a fight and holy cow, look at the time, gotta run.)

> concepts and techniques he's never seen so far and building up new instincts

"techniques" and "instincts" have to do with the language's idioms, tools and ecosystems. The tools (libraries) and part of the ecosystem may be similar to ones you knew, but you'll still need to learn the new ones. The idioms may very well be brand new.

To use a real-world example, while they're fundamentally based on the same concepts (class-based OO, dynamic single dispatch) Python is not Java [http://dirtsimple.org/2004/12/python-is-not-java.html]. And acquiring Python "instincts" after a significant time of Java is not easy. It's not hard either, but it's not the "5 days to complete proficiency" necro asserts. And those are ultimately very similar languages.

That said, I'm sure there are a lot of Python specific techniques that still elude me and I continue to read through the source for libraries I'm using.

I dare to differ. Hiring a dev for things web, I could ask what language they prefer and why. Someone saying he prefers PHP because it is clean and well organised would get a downvote. If he says it is because it is fast, and that the dirtiness can be avoid by proper training, that would be better. To someone who'd say Ruby, I'd ask what he dislikes about it, or is there any pitfalls. If he knows of no pitfalls, I would have a downvote. Someone saying he don't care at all, would have a double downvote. A good answer would probably be "I'm happy to work with any language but if I have to build something new and can choose the technology I would consider python because I like this tool very much and I'm quite seasoned with it".

Same with code editor: Engineers, developers are using tools and if they have a little bit of a love affair with their job, which is necessary if one want to work hard creating a nice product, they probably have some strong feelings about these tools, which are not all made equal before God.

Instead I'll add this:

"Whenever I interview a candidate I always work in some variation of a very simple question: 'How would you change your favorite programming language to make it better?'

"I don’t really care what the answer is (that is, I don’t mind if we disagree). However, I care very much that people think critically about the tools that they use and love."

http://blog.fogus.me/2011/04/26/my-favorite-interview-questi...

I'd rather hire someone that can give you an approximate assembly of a C function (as executed by a CPU), understand how XML documents are stored in memory for efficient querying and parsing, know how to avoid cross-domain browser security problems, have an understanding of multithreading (locks, semaphores, race conditions, etc) and an application of recursion in some other language. I wouldn't care what the knowledge is, as long as it is well rounded and demonstrates that the candidate is capable of pulling apart complex systems to gain a deep understanding in a short period of time. The ability to reason (with passion and authority) about which language or pattern is best suited to a given scenario is also vital.

Time is a terrible measure, partly because it fails to recognise that 5 years of bad/shallow/incorrect experience is worse than 2 weeks of gaining a deep understanding of a new language/pattern.

Anecdotally, Not only is time a a poor measure of ability, those who use it as such demonstrate a lack of accomplishment. Compare those who write "N years of Language X" vs "Wrote A,B,C in Z using ...".

I find "I've used X for N years" to mean "I've done one year of X over and over and over" :-)

This sentiment is true for many languages, as the difference between them is not conceptual, merely syntax and some details.

Learning a programming language that uses different concepts and not just different syntax (e.g: Haskell, Ocaml) will take significantly longer (and IMO will be worth it).

Even when the core conceptual difference is small and looks like "merely syntax and some details", different languages use different idioms, different standard tools and different methods, usually with reasons (stated or not) behind that. It's the idea behind PJE's (fairly old by now) "Python is not Java": going from Java to Python, the differences look superficial. You declare classes differently, names don't have types and methods are preceded by `def`.

Yet if you just translate your Java code into Python 1:1, you usually end up with an unmaintainable and slow morass, and although the core abstractions are the same Python and Java offer different toolsets to deal with actual problems.

So am I not a real developer because it took me longer than a week to get a hang of Haskell? Hell, it even took me many months before I understood JavaScript well enough to find the right mix of patterns and practices to write solid code in it.

Javascript has closures and functions-as-first-class-objects. Haskell has monads and all that jazz (I haven't used it yet). I'm guessing you didn't take months to learn the syntax of javascript, but to think in javascript.

It's similar to the difference between being functional in a natural language versus being fluent in said language.

In essence, I'm agreeing with everything you said, just wanted to clarify the reason for my post.

1) If you can, find someone with good, demonstrable SQL and PL/PGSQL experience.

2) If you can't find that, get someone who is competent in developing on Oracle.

"What?" comes the reply, "Don't they need to know Perl?"

I tell them that the use of Perl we have is getting more minimalistic and simpler, and that we are trying to make it so any competent developer can pick it up quickly.

The same would go if I was writing something similar in PHP. The issue is what sorts of fundamentally different technologies you can address, and the extent to which you feel comfortable working in both declarative, set-oriented worlds and object oriented approaches. The syntax on top of that is really less of an issue.

EDIT: login -> logic

The thing though is that one can always get a consultant to do sales tax logic. The big thing is if you know SQL and HTML the rest can come easily enough.