67

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?

6
  • 13
    I think the word you're looking for is "mastering" a language, "learned" in this context is a bit strange.
    – Pieter B
    Commented Jun 29, 2012 at 14:20
  • 7
    "Words are for meaning: when you've got the meaning, you can forget the words." - Zhuangzi
    – jfrankcarr
    Commented Jun 29, 2012 at 15:12
  • 9
    when you don't have to ask this question, you will have learned what you need to know ...
    – user7519
    Commented Jun 29, 2012 at 17:27
  • 1
    @JarrodRoberson Is this Zhuangzi who said that too?
    – jadkik94
    Commented Jul 4, 2012 at 20:37
  • 2
    According to LinkedIn there is very low bar to put up a programming language on your skill resume... According to my LinkedIn people who've seen Java code before apparently feels comfortable listing it in their skills section.
    – Chris Dale
    Commented Jul 6, 2012 at 9:25

10 Answers 10

74

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.

8
  • 16
    The terms conversational and fluent are rather subjective and while appropriate to natural language, it is difficult to see what they mean when applied to a computer language. Although still subjective, functional and idomatic may work better. Functional implies that you know the syntax well enough to write useful constructs, while having an idiomatic knowledge implies that you not only know how to write in the language but also know it well enough to use the idioms of the language, such as using using in C# or b, a = a, b and generators in python. Otherwise, +1.
    – Mark Booth
    Commented Jun 29, 2012 at 15:16
  • 14
    @MarkBooth Any description short of a score on an exam will be somewhat subjective. The point is to use the familiarity that most people already have with levels of knowledge of human languages as a rough guide to knowledge of a computer language, and to do it in a friendly way that invites further investigation. Conversational C++ is shorthand for "I'm familiar with the basics, but you may need to help me with advanced, obscure, or tricky code."
    – Caleb
    Commented Jun 29, 2012 at 15:31
  • 3
    While I think you're mostly right, I think a lot of people wrongly assume they have learned a natural language when they still have a miserable level. And it applies also to people who say they've learned programming languages.
    – haylem
    Commented Jul 1, 2012 at 13:26
  • 1
    I think your answer is perfect, it even shows how much it's impossible to quantify language knowledge. Indeed, while fluent means you can talk about most anything, with about as much explanations as a native speaker would require, this does not address the fact that most native speakers don't possess a tenth of the language knowledge good old writers have (no, not harry potter or dan brown, real old style hard to read stuff). How would you address that, when in fact nobody has bothered addressing it for languages ? and when in fact it does strongly impact productivity in programming ?
    – Morg.
    Commented Aug 23, 2012 at 12:54
  • 3
    @Morg. What utter rubbish. Programming is as much about communicating with future programmers (including yourself) as it is with telling the computer what to do. Sure, simple write one code might not need to be communicated well, but in the real world making your intentions clear to future maintainers of the code is far more important than getting the computer to do the right thing. Anyway, these comments are no longer serving to help improve this answer, so I would suggest that we take this to Software Engineering Chat if you want to discuss it further.
    – Mark Booth
    Commented Sep 5, 2012 at 12:14
25

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?

2
  • 4
    In interviews, you know it if you know it. In the workplace, you know it if Google knows it.
    – asfallows
    Commented Jul 6, 2012 at 14:07
  • 3
    In interviews, it's "i know it" if the interviewer wears a tie, and it's "please define 'to know'" if he does not ;). To be fair, most interviewers ask if one "has experience with", to which i am more easily inclined to answer with "yes"
    – keppla
    Commented Jul 12, 2012 at 15:17
18

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).
2
  • 3
    Nitpick: await is from C# 5, the major new thing in C# 4 was dynamic.
    – svick
    Commented Jul 5, 2012 at 18:06
  • You're right...I keep losing track of which version of C# goes with which version of .NET Commented Jul 5, 2012 at 21:12
8

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.

4
  • 2
    Idioms change, styles vary from one place to another, and indeed languages themselves change over time. If you can't say that you "know" or "have learned" a language like C++ until you're done learning about it, then there are very few people indeed who can claim to have learned C++.
    – Caleb
    Commented Jun 29, 2012 at 14:46
  • 1
    @Caleb exactly. Commented Jun 29, 2012 at 14:55
  • 4
    If you learning like that, then you don't know even your native language, which is foolish too (at least for most of people)
    – superM
    Commented Jun 29, 2012 at 15:06
  • @Caleb, worse than that, many parts of c++ are better when ignored, as Carmack and Torvalds both pointed out - so .. having learned all of cpp is not exactly beneficial.
    – Morg.
    Commented Aug 23, 2012 at 13:05
3

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.

2

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.

1
  • I can't agree with that. It may be true for the first language or two you learn — you may simply not know what to look for, so even the most bletcherous design failures are indistinguishable from the right way to do things. Once you've learned a few languages, you should start to be able to see language flaws soon after you start learning a new one. But then for a while in your development, you will erroneously equate "different" with "wrong." Until you learn a few languages of each major type (procedural, OO, functional, declarative...) your immediate judgements will be suspect. Commented Jul 2, 2012 at 23:56
2

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.

1

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". ;-)

1

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.
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.