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: Analogize (53 Votes)

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 am conversational in 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: Consider your audience (18 Votes)

The person who asks probably 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 a language, 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: Several Levels of Learning (12 Votes)

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 its own framework, as does Ruby, C++, PHP, and PERL. Think of the framework for a language as the vocabulary and the language itself as 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, and your code is indistinguishable from another native speaker's code.

Think you know when you can say you've "learned" or "know" a language? Disagree with the opinions expressed above? Downvote or upvote an answer, or leave your own answer at the original post at Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web apps, cycling, scientific skepticism, and (almost) everything in between.

I have to consult online references CONSTANTLY for languages I know. Biggest problem I have is that most languages today are similar but different, and it drives me nuts. Most are vaguely like C in their syntax, but different in all the details. Since I have to switch among these similar-but-different languages, I am always wondering how to do something in any given language. An example is how to get a string's length. Is it len(), length(), strlen(), string.len(), string.len, string.length(), string.length? This level of detail inconsistency among languages makes "knowing" a language difficult, unless you somehow can use only one language, and these days that's impossible. I'd almost rather use C, LISP, and FORTH because they're so different that it's hard to get confused rather than switch among C, C++, Java, PHP, Perl, Python, etc which are just enough alike that I can't remember any one specifically.

I gave up programming ( after many years at it) when languages started to require a "framework" rather than just a manual defining the operating system interface calls. I guess that makes me a real old codger.

They've been doing these Stack Exchange articles for nearly 6 months now. It's a way to put extra content on the site (technie-centric content at that) over the weekend when their writers are enjoying their well deserved time off.

If you have to ask.. then no... Quite frankly the new features of C# are few. And ultimately all the new features of C# mentioned by Mike Brown are one thing. If you can learn LINQ then you get lambdas, extension methods, anonymous types and initializers for free. And seriously await and async should take exactly zero seconds to learn given that you've been using Async methods and delegates all along.

They've been doing these Stack Exchange articles for nearly 6 months now. It's a way to put extra content on the site (technie-centric content at that) over the weekend when their writers are enjoying their well deserved time off.

I feel I've "learned" a language when my first implementation of something in that language uses the idioms common to that language e.g. I'm not trying to write Java in Python <http://dirtsimple.org/2004/12/python-is-not-java.html>.

At some point beyond that you find yourself applying idioms from languages you learned later to languages you learned earlier, sometimes resulting in greater mastery of both languages.

A1 - When you've written a compiler/interpreter/reflector for it. You're getting good if you can reverse engineered compiler generated code, found a compiler bug, written a code generator.

A2 - You're good at a language if you can, without too much stick jabbing, write a nicely useable program. You know, formatted nicely, comments for algorithms etc etc etc does what it's supposed to and, please, on time.

A3 - You've "learned" a program if you can work on a WELL WRITTEN code base and/or write simple tools for others to use working through test cases, build scripts, extend functionality of extant classes, implement UI/network features and, eventually, much more.

!A4 - If none of the above then you are, probably, learning.

There are number of crossovers. ATM I'm working on compiler/interpreters for ESSL. Now, I really haven't coded HUGE amounts of ESSL so I probably couldn't achieve A2 without a lot more practice. Yet, I can achieve working on a compiler and probably, easily, achieve A3.

I also frequently dabble with "learned" as in "hacking on other peoples code bases in languages I don't know well at all". Good examples... Perl, Python - I really don't use them much. For me, mostly raw C, asm or Qt. That solves a vast majority of my programming problems. BUT! I could not achieve A2 in Python without man pages, interwebz and a whole pile of practice etc. A3 - no problem.

Just to clarify that last point. Essentially programming is programming. It's all binary! Your programming skills will adapt to the new environment as, after all, these are just different ways of solving the same problem (and usually the same hardware).

There are some melon scratchers though. For me it was Prolog. I finally "got it" about 15 years after I "learned" it!!! Now I keep saying "this is just pattern matching... get me Prolog!". No-one listens..... ;-)

If you judge by the resumes I've read and then the subsequent interviews...

Seriously, we've had people put a language on their resumes who had never written or even modified a single line of code, just read a book.

Maybe you should only bring in those people who have actually worked on a project instead of judging by "skills"...

They had actual good looking projects on their resumes. Unfortunately, where it says 'I did [something neat]' often ends up meaning 'someone else designed [something neat] and I implemented some tiny piece of it without really understanding what was going on'.

HR people have a very hard time telling a good looking resume that absorbs achievements ('I did' instead of 'we did') from a bad one - heck, if it's good enough, it's hard for anyone. Which is why my current company does phone screening - eliminates about 90% of the resumes, the rest are much higher quality.

I find the answers really interesting, but I am not sure the spoken language example which is used throughout the answers is really equivalent - to the degree that I don't find it useful.

Simply because the challenges of "speaking" are completely different. A modern programmer almost always has access to reference material and expert input. When you are speaking a language, you don't. It's assumed that when learning a technical subject that you don't remember every detail of the subject. When speaking, it sort-of is.

A competent professional always has access to reference material in coding. It'd be silly not to. So the question becomes - is being "fluent" in a language even valuable in the 1st place?

HR people have a very hard time telling a good looking resume that absorbs achievements ('I did' instead of 'we did') from a bad one - heck, if it's good enough, it's hard for anyone. Which is why my current company does phone screening - eliminates about 90% of the resumes, the rest are much higher quality.

Depends on the company certainly, but I wouldn't stop at just professional experience... sometimes personal projects can tell you a lot more about some ones true capacity than a grand project that they themselves had a very minor role in. And besides if they aren't doing anything on the side, they probably aren't learning on the side which would definitely give away they probably don't know that many languages other than the one they had to use at their last job. In any case I agree, unless all you do is software, HR will screw it up with their wild expectations, that only attract BS applicants.

A competent professional always has access to reference material in coding. It'd be silly not to. So the question becomes - is being "fluent" in a language even valuable in the 1st place?

Even having access to reference material isn't enough. The big question in most cases is how do you even approach doing this in the first place, and if you don't have experience you don't even know the right thing to look up. You may not realize that the language/library has the perfect way to deal with exactly this problem IF you know what its terms for that problem are. Someone new to Python, for instance, may try to do something with arrays just because that's what they're used to, even though arrays are reserved for performance intensive things in Python.

For instance, how do you have a non-UI thread update something in the UI in C#? First you have to know in the first place that if a non-UI thread tries to do it directly the program will explode - so someone fluent would design for this up front (I try to have only the UI thread updating the UI). Then even if you google this problem you will find a lot of contradictory answers, and some solutions that are extremely unwieldy even if they work. I've seen people waste days on it (judging from bboard dates), but after a while you learn the simple, compact, infallible solution. It sure won't show up first in your google search though.

Now I totally agree with what you said earlier (that I snipped) that being fluent in a spoken language isn't quite equivalent, you don't have to look up the specific API of a fish in order to talk about one - because your listener's 'interpreter' is much more flexible than a computer's.

But someone who's 'fluent' in a computer language and only has to look up the occasional specific parameters for something is at least 10x as productive as someone doing C++ who doesn't grasp the intricacies of class inheritance or how to leverage the Standard Template Library. That's where it's worthwhile.

Someone else said it's the point at which you're concentrating on solving the problem instead of solving the implementation. That's been my criteria as well.

Depends on the company certainly, but I wouldn't stop at just professional experience... sometimes personal projects can tell you a lot more about some ones true capacity than a grand project that they themselves had a very minor role in. And besides if they aren't doing anything on the side, they probably aren't learning on the side which would definitely give away they probably don't know that many languages other than the one they had to use at their last job. In any case I agree, unless all you do is software, HR will screw it up with their wild expectations, that only attract BS applicants.

If the personal project was done to an external standard. For example, many open-source software libraries has standards and tests that must be passed before any new code is accepted. Getting their code into one of these means the person is willing to stick to a project thru thick and thin.

I like the idea stated above "when you spend less time thinking about the language than the problem".Good one.

Better perhaps:Do you know how to program? Do you know how to design a good system? There are plenty of people who "know languages" yet are useless because they can't design, and that's a separate skill.Once you know how to design a system (at least in my case) the choice of which language I know (or will have to learn) to use is obvious...use the best tool for the job. In a lot of cases there's enough overlap, and I know enough languages it's not a one to one mapping, but I think you get the idea.

Coding is secondary. Design is more important. When I ran a product development company for embedded computer kinds of things, we spent perhaps 5/6th of the time designing, brainstorming, red-teaming the design, iterating all that - then 1/6th of the time coding, which went really fast because by then everyone had the full vision fully understood in mind, there were no further questions, just typing.

And yeah, forgot to add - these days 90%+ of "knowing a language" has little to do with the language itself - that's trivial. But now, learn what's inside all the libraries so you can leverage them....much harder.

To use the word "language" in a programming sense is anthropomorphism, typically seen and used in technology. Yes, that is how forward-looking (hoping) we were all those years ago. Anyone seen Hal lately?

There are many standards by which ones' ability in a given language are measured, some more accurate than others and each with a specific measurement goal and thus, none are indicative of a 'whole language' approach to assessing fluency.

Among the linguists in my faculty, we have jokingly asserted that if one can maintain conversation (be an equal participant, not just volleying back) in a 30 minute taxi ride, one is generally doing well in a given language. Taxi drivers tend to initiate a broad range of non-specific (jargon-less,thus more 'conversational') discussion topics that are a reasonable indicator of general fluency.

As with spoken languages, you have learned a programming language when you can think in it.

As you are learning foreign language you often make awkward constructs and use wrong words in wrong places. With programming language, thinking in that language means that you are using it's features in a way the author intended them to be used, not just butchering syntax together to make a working program.

If you know enough about language theory in general, and have experience in a few different languages of different types, you can pick up languages easily as you go.

My background is in C, C++, Java, Python, Perl and Lisp. However, I had to do some work a couple of years ago in Fortran (for climate modelling - climate scientists love their Fortran).

Fortran was different enough that I definitely needed a book beside me while working with it, but I was productive from the first day, and within a week, I was keeping up with the others who had been working with Fortran for years.

Then, last year, I needed to do some COBOL work. I had never touched it, but within a few hours, I got the hang of it, and was matching the other developers.

I'm not a natural programmer, and was a slow learner when I first started. However, the reality is that once you know a few languages, you can get up to speed pretty quickly, unless it's a really obscure language (I've never quite felt comfortable in Forth, for instance).

Most languages share enough similarities that picking up a new one isn't too much of a hassle at all. To the point where it almost becomes a non-issue whether you have worked in it in the past. Even if you're an expert in the language, you're going to have to deal with a whole new codebase, different libraries, and different APIs as part of any new project, so dealing with a new language syntax on top of that is just one extra bit of complexity - not a dealbreaker.

Also, one thing to remember is that knowing the language syntax is only a tiny part of actually knowing the language. The APIs are just as important these days.

You can be an absolute whiz at writing Java web-apps, knowing all the tricks for servlets and session management, being able to create super-efficient JSP, and knowing all the best design patterns for server-side web applications.

Then you sit down to work in a multithreaded Swing app, and it's like you're back at square one. You need to read up on how the threading model works, how event listeners function, and you have no idea what design patterns to apply where. You thought you were a Java guru, but you're definitely not a Swing guru.

Then you get on top of that finally, and you need to do some work with RMI. You're back at square one again, reading tutorials, trying to find your way around the API, and running "Hello World" programs to work out how it all functions.

Programming languages are complex enough these days that your average programmer can't possibly have worked with the whole API. Then there's the added complexity of third-party libraries. Nobody knows them all.

So, saying "I have learned Java" really just means you know the language syntax. If you're an experienced programmer, you could probably pick that up in a weekend.

Learning the APIs is a whole separate issue, and each project will probably use such different combinations, that you're going to be "learning" again and again throughout your career, even if you stick with the same language.

This question treats the word "learned" as if it's a binary flag. You've either "learned" it or you haven't.

I think it's impossible to truly "learn" a language. Even if you wrote the thing yourself, even if you've written several best seller books, there will still be new things to learn about the language.

You could ask when you have "learned" the syntax of a language, but any experienced programmer can cover that in a day or two. We recently took an intern, who had done programming but never in any web-oriented language. I had to show him how he'd stuffed up the position of the <head> and <body> tags in his page, and showing him how to write a <script> tag that points at a javascript library file (that's how bad a job his IT teacher did explaining HTML to the class). Three hours later, I was explaining intricate details about JavaScript's specific rules for variable scope which, to be honest, even I don't fully understand after several years of writing JavaScript at my day job (I mostly do server side work).

If a 15 year old kid can pick up JavaScript's syntax in less than a day (and it's far from a simple language), then just about anyone should be able to do it.

But there is more to "learning" a language than just the syntax, you need to learn the conventions, the techniques, learn it's fundamental strengths and weaknesses, etc. I don't think you can ever learn all of that. By that definition, I have never "learned" any language - and I've been working as a full time programmer for more than my entire adult life.

PS: Almost every time a Stack Exchange question gets re-published here on Ars Technica, my immediate reaction is to go to over and flag the question for deletion because they fail to meet the most important criteria:

Stack Overflow FAQ wrote:

You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page.

Do the lawyers and doctors ever say they are "fluent" in laws and "fluent" in medicines?

No, never, and for the sake of the liability in malpractice lawsuits, in case they get their rear end suit for being such an expert as they've claimed they are in that field, but still "screw up"?

They are "practicing laws" and "practicing medicines", respectively.

In my opinion, and for all you professional programmers out there, you'll never say you're "fluent" in a programming language, do as the lawyers and doctors do, you're "practicing" computer programming as you'll never be "fluent" in one as "prefect".

a) being able to order a pizza with the person on the other end not realizing you're a foreignerb) getting to the point where you dream in Japanese, orc) getting to the point where no one compliments on your Japanese anymore, they just talk to you normally.

I think we need to classify know as Basic: Can run the compiler / interpreter with copied codeIntermediate: Implement detailed design in the language (i.e., translate from psuedo code into working code, even if not most effecient or idiomatic forms). Also, familiar with standard libraries (what is availible, where to find it).Proficient: Know many common language idioms, and can read and modify code written by other proficient coders.Can efficeintly use standard libraries / third party libraries.Expert: Can design and implement libraries / modules.

back in the days when games had their own memory managersI copied enough stuff to give a 486-33 several boot optionsbut some one who knows a language can use it like a poetthe results are a thing of beauty

You've learned it when you can come up with your own jokes in it. They don't have to be -good-.

There are only 10 types of people in the world: those who understand binary, and those who don't.

GOD is real, unless declared integer.

TASK: Shoot yourself in the foot. LISP: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds…

You've learned it when you can come up with your own jokes in it. They don't have to be -good-.

There are only 10 types of people in the world: those who understand binary, and those who don't.

GOD is real, unless declared integer.

TASK: Shoot yourself in the foot. LISP: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds…

[Brainfuck joke deleted to avert Cthulhu.]

That last one I've seen before, as part of a list of such jokes, about how you shoot yourself in the foot in different languages. It's posted in one of the halls in the CS department at my university. One of them is "You shoot yourself in the foot, but don't care because you have so much fun doing it" or so.

Pseudocode is the best language ever though, you never have to look up anything! (I wonder, how do you all write pseudocode, anyways? Seems like something with tons of room for individual variation)

You've learned it when you can come up with your own jokes in it. They don't have to be -good-.

There are only 10 types of people in the world: those who understand binary, and those who don't.

GOD is real, unless declared integer.

TASK: Shoot yourself in the foot. LISP: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds…

This ancient wisdom shows what's wrong with all of the stack-exchange answers: even if you can write an advanced, complex program in a language, it doesn't mean you know it. It just means you can hack your way through it, since any program can be written using arrays and and indices (ultimately even one array and one index).

It seems Ars Technica responders have got a bit more wisdom in them. I've seen very reasonable comments on knowing the API and usage of language specific features. The first is a good point, and hard to answer. The second is even trickier, since thorough use of such features would make code totally unreadable. Think Perl, or Ruby's feature to override the function that defines variables. Brrrrrr...

a) being able to order a pizza with the person on the other end not realizing you're a foreignerb) getting to the point where you dream in Japanese, orc) getting to the point where no one compliments on your Japanese anymore, they just talk to you normally.