At what point can I say I've "learned" a language?

Question

In my few years of programming, I've toyed with everything from Ruby to C++. I've done everything from just learning basic syntax (Ruby) to completing several major (for me) projects that stretched my abilities with the language. Given this variety (and the fact that truly learning a language never stops), when can I say I know (or have learned) a language?

Answer 1

At what point can you say that you've "learned" a language like English or French? I think most people would accept that you've learned a language when you can use it to communicate. You don't have to know every word or understand every idiom, but you should know most of the (rather small) subset of the language that people use in daily conversation. Having "learned" a language to that extent, you can continue to learn more as you use the language daily and expose yourself to more and more of it. By the time you die, you still won't know all there is to know about the language, but nobody will say that you never "learned" the language.

So it is, I think, with computer languages. You can say that you "know" a language like C++ or Ruby when you can write useful programs in it. If you need to quantify the degree to which you know the language, use the same terms that you'd use for a human language. Say "I know a little C++" or "I know conversational C++" or "I'm fluent in C++" to mean that you know just enough to scrape by, enough to get useful things done, or that you're an expert, respectively.

Answer 2

It depends on who is asking

The person who asks propably has a certain idea what level of skill is expected from someone who says that he has "learned a language."

Basically, i encountered two archetypical scales, by which people judge the answer to the question "have you learned X?"

For most nerds it is a trick question to weed out posers This is already demonstrated by the other answers to your question ;). If you say you learned it you fail in seeing the scope of the task, which is implicitly "perfection", and, much worse: you fail in humility.

For most bosses, you "have learned it", if you can solve their problems, a criterion oftentimes already met if your code compiles. Answering his question in a humble way will lead to him assigning the task to a poser who may also be a relative.

So, what's your audience?

Answer 3

I think people are focusing on the finality of the word "learned" being perfect tense it means you're finished learning. And as everyone noted, programming languages are living entities just like spoken languages. For example someone who had complete mastery of C# 2 would look at C# 3 with LINQ, Lambdas, var keyword, object/collection initializers, and extension methods and find that a lot has changed from what he learned for the previous version. The same is happening with C# 4 with await, async keywords and other new language constructs.

And we're just talking syntax here. We forget that most languages are paired with a framework. C# has the .NET framework, Java has it's own framework, as does Ruby, C++, PHP, and PERL. Think of the framework for a language as the vocabulary and the language itself is just syntax. Knowing the language means you know how to make a sentence in the language. Knowing the framework means you can express yourself well in the language. Finally, once you know the syntax and vocabulary, you need to learn the idioms so that you write code as a "native speaker".

I'd say there are several levels of learning.

1. Hello World (you can write the most rudimentary programs.)
2. Proficient (you can write basic programs but need to consult online help regularly)
3. Fluent (you can write advance programs with some reference needed).
4. Native speaker (you can write advanced programs with minimal online help, your code is indistinguishable from another native speaker's code).

Answer 4

You can rarely say you've learned a language. That implies you're done learning about it, which is... foolish.

Saying you know a language is fine when you can write code that isn't blatantly breaking idioms in the language (maybe after a week of de-rusting the knowledge) without referring to a syntax reference.

Answer 5

This is more of a opinion based factor. In all technical terms "Learned" would mean having a complete knowledge of, as in you would be expected to know EVERYTHING of the language.

However in the world of programming I believe it's more about if you can program fluently in the language to complete a objective/task. It also probably means if you're comfortable with the language. Sure you could go out there and get a degree after years and years of college, but that's only to get noticed? You define when you can say you've learned a language.

Answer 6

My personal answer for this is when,

1. I know the basics to write a simple production-level program.
2. I've spent at least 3 straight hours solving a problem that seemed simple but wasn't.

From there on, I wouldn't call it learning, but mastery.

Answer 7

When you start noticing its flaws. Once you start learning a language you are usually still busy learning now to do stuff or are much involved in it to notice where it fails (of course, this is unless you start learning it from a negative point of view just to see how worse it is compares to your favorite language so far). I'd say you don't truly know a language until you are acutely aware of the areas where it fails.

Answer 8

At the point when your application or component can read mail, i.e. Zawinski's law, which states:

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” Coined by Jamie Zawinski (who called it the “Law of Software Envelopment”) to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that).

This was updated when RSS became popular to "... can read RSS feeds" and probably could be updated these days to "... can read Twitter feeds". ;-)

Answer 9

This topic is obviously very subjective, but I want to dispel some rumours that are demonstrably false:

1. You know a language when you can comfortably solve a wide variety of different problems in it without referring to syntax references, and without feeling like you are "translating" from another language.

   You can be all this, and be writing efficient code, and still suck at the language: I studied C and loved it, there was a winter break before we started to work on C++. I wanted to get a head start, so I pulled up problems from the SPOJ website to practice solving them in C++. The algorithmics was sometimes fun - but otherwise they were all extremely easy. I realised that I'd fallen into a trap: I was 99% coding just like it was C, with the occasional cout, new/delete or class thrown in. Needless to say I knew basically nothing at all about C++.

   More generally, it's very easy to hop into a new language that uses at least one of the programming paradigms that you feel comfortable in, see an example little program in that style, and then code away. After a few hours of this you probably won't feel like you're "translating" anymore, probably won't need to look at references - you'll only be doing that because you want to write the code in a better way. However, if this is all that's needed to "know" a language, then the term is completely meaningless.

2. Saying that you "know" a (difficult) language, or (when asked) you score yourself highly (say, 8/10) implies that you're subject to the Dunning-Kruger effect; ie. you're likely so incompetent that you're unaware of your incompetence.

   This is just plain hazing. The term is completely subjective, so please don't use it as a diagnostic tool. To me, scoring yourself 8/10 at a job interview implies that you're signalling that you think you're in the top 20% of candidates (whom may all be fresh graduates). Recall that interviewees are expected to sell themselves to be able to land the job. But importantly, it's just so vague that it really should be irrelevant.

---

I'd say there are some pretty good techniques for getting to know a language better:

1. Find x: a paradigm or fundamental tool in the language that's new to you
2. Use and abuse x.
3. Find situations where x is clearly a superior choice for solving parts of the problem.
4. Find situations where you can solve a problem using x, but it's clearly bad.
5. Begin making judgement calls as to when x is a good choice.
6. Learn/observe some of the differences between some of the compilers/interpreters.
7. Read various expert-written code by different authors, with different aims and domains.
8. Find code written by experts where you don't understand why they didn't do y instead. Try to implement it yourself using y (you'll probably find that y isn't better).
9. Read some of the language standards that's relevant to you.
10. Compare it to other languages you know. Reflect on its strengths and weaknesses.

Answer 10

I think you have learned a language when you don't see it. You don't see the for cycles and data accesses, but the workflow of the algorithm.

You don't play tricks with parameter passing and array processing, magic macros. You don't think of your code as a self marketing material to show to your friends and teachers, but to express your understanding of a problem, and your will to the computer the most readable way.

You have habits that help you avoiding lots of mistakes just by following them, like: use {} code blocks and () in expressions even if you are absolutely sure that "it will be only one line" or "I am no fool and know operator precedence order".

You stop counting how many classes, patterns and framework APIs you know. This is what intellisense, the references and tutorials, and the Google is for. But when you look at a problem, you immediately know what parts it can be split, and with what tools and algorithms you will solve them.

What you do works, is elegant and small. You enjoy coding and easily find your bugs. Yes, masters also make bugs because they are humans - but they find them quickly because their code structure leads them to the right place.

And finally realize: you have learned to think, analyze and solve problems; compared to them, the actual language is secondary, just the current box of rules and tools.