When do you know a language?
by Mithrandir
One of my teacher used to say that we don’t know Matlab because we don’t know that there is a guide command which does what it does. Yesterday, I’ve created my Haskellers profile and I saw that there are a lot of topics in Haskell about which I know almost nothing. This made me write this post, trying to get the answer to the following question: «How much should you know about one language to be certain that you can say you know the language?».
There are a lot of levels of knowing a language. The basic one is to know only the syntax. Yet, I don’t know if knowing one language’s syntax and special constructs and being able to decipher the basic examples written in that language count as knowing it. I might say that I know Brainfuck or Piet very well, although I’ve never written a single piece of code in these languages by myself (though I did it with some tools and genetic programming).
Next, one can say that one language is known if you know about some of the obscuring constructs it has. Knowing about C’s extern and volatile may help you on one task or the other but this surely depend on what type of task you are working on. However, from this level onwards, each person may say that he knows a language, if he understand more than 50% of the code snippets written in that language.
The next level is represented by the ability to juggle with all the libraries a language has. For example, I know a guy who knows almost every Python module. Not to the very last detail but his knowledge is enough to know when one module is better than the other at the same task.
Lastly, there are only two people that I know of (and only on the internet) who know not only every library a language uses but also any other related tool. For Haskell, this include Cabal, darcs and Hackage internals, though the list is not limited to them.
Now, the question remains. Rephrased it sounds like this: «How much must one know from one programming language to be able to put that language in a CV?»
PS: just remembered a quote from Perlis, in Epigrams on Programming: «A language that doesn’t affect the way you think about programming, is not worth knowing». According to it, this means that one can say he knows a language when his thinking about programming is changed?
PPS: written with another testing version of HaCoTeB.
Syntactically speaking, one doesn’t need to know anything about the standard library of a language to use the language itself properly. Yes, you can say you know a language when you know its keywords (
volatile,staticandexternincluded) among other things.Java is such an example. When you do a program in a certain field, you usually use less than 50% of the Java standard library. Counter examples are C (only sometimes, though), Scheme and other languages built on the „minimal features in the language, more features in the standard library” paradigm.
From my (rather short) experience with CVs and cover letters, I can say that putting a language on a CV equals zero information for the employer (unless it’s something more exotic, like Haskell). A good specialist is usually focused on a certain field (e.g.: system programming), and he can mention he does that better in a certain language. Surely, a good programmer must be in sync with the company’s technologies/languages. However, a language’s features can be assimilated in a really short time (with the exception of Haskell), while other (more important) things, like learning how to think, can take years.
And Haskell is one of the exceptions especially because it changes one’s way of thinking, in the context of OO and procedural languages.
I’d say knowing a [programming] language is a question of art, akin to mastering, say, chess, cubism or the waltz. There are many levels of understanding, starting from the basic syntax (i.e. not shooting yourself in the foot), going through common paterns of use (competence) and culminating with “grokking” the philosophy of the language (grand mastery, wisdom, etc.). Each time you ascend to the next level, you can’t help but realize how little you have actually understood up to this point.
My math teacher said that math is like climbing a mountain. Only when you are at the top you realize how much you’ve learned. But going there is very hard and, at each step, you see that you’ve climbed a little and still have a lot to go upwards.
[...] This post was mentioned on Twitter by Mihai Maruseac, planet_haskell. planet_haskell said: Mihai Maruseac: When do you know a language?: One of my teacher used to say that we don’t know Matlab because we d… http://bit.ly/b4SI0N [...]
From my point of view, first, there’s the syntax, then there’s the paradigms the languages supports, which are closely coupled with that language’s idioms. Then, there are those routines part of the standard library that you can’t get without (arithmetic and boolean operators, string manipulation, functions to manipulate built-in data structures like arrays or lists). The last step would be those other libraries, be them part of the standard library or third party (network access, JSON, XML, etc).
So, if you know 80% syntax, 80% supported paradigms/idioms and routines dealing with the language’s primitives, then you know a language. Knowing the rest of the libraries (built-in or third party) means that you know more than a language, you know a platform. Case in point, a developer that knows lots of JavaScript in the browser, will be almost unable to build anything useful in his first days with nodejs.
Usually, companies will require that you know both a language and a platform, but if you’re lucky, they’ll reckon that syntax and standard libraries are just a matter of looking up the docs, and they’ll insist more on the paradigms/idioms of the language. I bet knowing Haskell can help one get an OCaml developer position very easily. The same with the C# and Java, and maybe Python and Ruby.
One can know about the paradigms a language supports, the theoretical concepts it is built upon, and the philosophy which explains why this and that has been included, and combined in the way it is, and other things have been excluded — all without actually knowing the syntax or being able to write a meaningful program in the language. With that in mind and in analogy to natural languages, I propose that knowing a language is _not_ about knowing its concepts and philsophy (after all: can you give a justification for including words from Latin or Greek or French in many natural languages? You can only give reasons, most of the time it’s really quite arbitrary).
You know a language when you are able to express what you think in it (this entails knowing the syntax, the typing rules, and additional constaints which may be imposed by a specification or implementation of the language) in a natural way (knowing the idioms and the standard library of the language). Mastering a language also entails that you know about additional libraries and the finer points of syntax and semantics, and can explain idioms in a way that can be understood by people who know far less than you.
For me the real question is: How important is it to really know many languages? Or more precisely: What is the important lessen you take away from getting to know a language? I think it’s the concepts, the theory, and the philosophy, sometimes the idioms and patterns if they are widely applicable. But this does not necessarily mean that you really know a language, it often suffices to have read a little about the concepts in order to change your view of programming or the expression of certain problems. Writing a bigger program in any given language may be a great and fun exercise, but it is mostly useless because it does not guarantee that you learn the important lessons the language can teach you. So my position is: Knowing a language (and using it) is mostly irrelevant, knowing about a language is what makes you a better programmer. This is akin to the principle of proof irrelevance. It’s good and often enlightening to know that there are several ways to proof a theorem (i.e. give a program that produces a witness for is truth in the constructive interpretation of logic), but it’s irrelevant which way you chose, as long as you arrive at the desired conclusion.
The simple answer to your question of “when do you know a language enough to put it in your resume?” is
“when someone asks you an interview question and you can write the answer on a white board OR describe what you would do with that language”.
How much know? I would say I know language, if I could implement correct compiler for it with enaugh time resources, without looking into specification more than few times. :) For me this will probably mean C, D, Bash, PHP and Erlang. I know also Java/C++/Perl and Haskell, but do not have so deep knowledge, or like them all to actually investigate some corner cases.
Over the years I’ve touched a bunch of languages, as I’m sure most developers have. Now I’m back in my .NET phase. I last touched .NET, oh, 3+ years ago? No doubt I’ve forgotten things. Things have changed. There’s sure plenty I never knew in the first place. So when asked, do I know it, or not?
I explained it to my new boss like this : .NET for me right now is a little like high school French. At some point in my past I made a dedicated, lengthy attempt to learn it, use it, and become proficient at it. I may have even spent a semester abroad to make practical use of my knowledge. But I haven’t had call to use it in years, so it’s rusty. I’ll refer to my reference books more than someone who speaks it regularly. I won’t know the same idioms – I’ll sometimes do what the book says, when a native speaker wouldn’t dream of saying it that way.
Here’s the important thing, though – the more I use it, the more I’ll be refreshing the knowledge I already had. This is very different than having to learn things from scratch. Sure, there are always new things to learn, just like you could speak English all your life and still occasionally need to lookup a word in the dictionary. But in this case I’ve already paid the cost to gain the foundation of knowledge in my language, and now my fluency in it is directly proportional to the frequency with which I use it. You want me to use it more, and therefore I will become better at it every day.
I know you’re being sarcastic, but it isn’t really uncommon for me to dream in any language that I work with for a few hours right before I sleep, and the majority of the work I do right before sleep involves messing around with programming languages that I don’t know at all and will never get a chance to use during my workday.
No, dead serious. Granted I only know a spit of german and my ASL is different than an auditory language. But I was told by a friend of mine a few years back that when she came to America, her teacher told her that she would be an English speaker when she had one full dream in English.
And I can relate somewhat. I worked with 4 deaf people for 5 years and since I had never heard their voices, they were always confused in my dreams. I can’t remember any dreams clearly where I saw them sign, but I am certain they never spoke.
I’d say knowing a programming language is the same as knowing a language language.
You know it (i.e. you’re fluent) when you can think easily in that language and write code that others proficient in the language would agree is a/the right way to do it.
That is to say, you don’t “code funny”, like the French tourist asking you if you have a “little fire” for his cigarette.
I think that you “know” a language when you can use it to write a fully-functional program of impressive complexity. Anything before that, and it’s like knowing only part of a spoken language.