I have so far successfully avoided Perl, but I have programmed a little in Python. I completely understand those statements, and I can make guesses about differ

I have so far successfully avoided Perl, but I have programmed a little in Python. I completely understand those statements, and I can make guesses about difference in some corner cases. I think it's relatively common to know what those statements mean. I agree that a programmer that doesn't know how variables are passed probably doesn't understand the language. I don't agree with the conclusion though. I think that a programmer "knows" a language if he/she understands the idiomatic way of representing an idea. For example, if a functional language programmer comes to C, perhaps he/she might write a summing function this way: int sum(int* arr, int count) { if (count == 0) { return 0; } return *arr + res(arr++, count--); } And an assembly programmer might do it this way: int sum(int* arr, int count) { int sum = 0; int i = 0; loop: if (i == count) return sum; sum += arr[i]; i++; goto loop; } Neither are writing idiomatic C code, but both show they know different corners of the syntax. I would argue that one does not "know" a language until their first reflex in solving a problem is to write it the most idiomatic way for that language. When I write code in a language, I try to follow the idioms of that language: * Go: multiple return values and interfaces * Java: small, polymorphic classes with tons of getters and setters * Javascript: prototypes, callbacks and array methods * Python: list comprehensions, generators, and tuples * D: templates, "auto" and parameter storage classes (in, out, ref, inout) A programmer doesn't have to know the nitty gritty details of a language to "know" the language. I think the programmer can omit omit learning crazy #define macro foo, the "comma" operator, type coercion rules, bit alignment in structs (for cheap struct serialization) and the like and still "know" the language. Conversely, the more of these details you know, the more likely it is that you won't write idiomatic code. If you know, for example, that x << 0 is faster than parseInt(i, 10) is faster in Javascript, you'll tend to use that more often than the more idiomatic way. This is an implementation detail and shows that you don't understand the idiomatic way of writing Javascript code. I use a language depending on the problem domain. Some languages lend themselves to certain problems better than others. I don't, however, know the implementation details that only a compiler designer should know, but I don't feel that precludes me from "knowing" a language.