How do you prove this? Do I have to know everything about it? What are the important things you should know about a language to say you are a professional in that language?
EDIT: in more details what are the things which the professional programmer already knows but the normal does not?
For example if I am C# developer but I do not know MSIL, can I say "I am professional in C#" ?
Taking from sports, maybe a professional is just someone who works with that language for a living ?
You do not need to know every thing about it, but you need to be able to know how to retrieve that information when you require it (as well as being aware it exists). I wouldn't say someone who didn't know LINQ was not a professional C# developer but it helps they know of it's existence and could utilise it when required.
When you can use the language reasonably quickly and easily and without referring to documentation for rival matters ,as well as having some experience, then you call yourself professional. (imo)
I'd say that you have to have done a reasonable amount of paid work to be called a professional at anything. If you've done that then you should be able to provide examples of your work and/or references. If you haven't done that then you're not "a professional". You might be experienced, proficient, accomplished, or any number of other things, but I don't think you can reasonably claim to be a professional unless you've been paid by a customer/client/employer.
You're are a professional at anything you get paid to do.
Most of the best athletes in the world are amateurs and yet some very weak footballers (soccer to most of you) are considered professional.
There are three layers to skill: Apprentice, Journeyman (or Professional) and Master. In programming, the master craftsmen separate into designers and architects, See McBreen's book on Software Craftsmanship.
Basic Level of Competence -- Journeyman
Can you write code? Does it compile? [Seriously, if you have trouble getting things to compile, you're not very professional.]
Can you write unit tests for that code? [If you don't have or use unit testing tools, you're not really very professional.]
Does the code work when you're done writing? [If you have debugging problems, or there are details that never seem to work right, you need someone to oversee your work; you're an apprentice, not a professional.]
Does it meet minimum quality standards? If you posted it here would you be ignored because it was acceptable? Would you be upvoted because it was actually good?
Does it look like open source projects in the same language?
Do you know what are in the libraries that come with your language?
Can you find things in the library documentation?
[None of this involves trivia or obscure language features. This is basic, core skills at building stuff that works.]
If you purport to be a web developer, can you build and install into a the web server and show that it actually works?
If you purport to be a desktop developer, can you build something that someone else can install and run and see that it actually works?
The next level of skill is being a master craftsman and designing for journeymen. You need to know more because you have to do the above things without personally typing the code, but guiding others to typing the code you imagined.
The next level of skill is architecting so that journeyman can become master craftsmen by creating designs for apprentices to implement. Here you need to imaging how people will create designs from your architecture.
My rule of thumb: if I can write code for more than 2 hours without accessing any documentation, I feel that I've reached at least a moderate degree of competence with a given technology. Having reached this level of comfort, I would then be comfortable offering the use of this knowledge as a "professional" knowing that my client would be paying me to write something for them rather than paying me to learn.
Of course, the risk here is that you fall into "when you only have a hammer, everything looks like a nail" mentality!
Having read some of your responses to the answers here Ahmed, I'm going to assume you're talking about proficiency in a language, and it sounds like you're talking about it in a resume/interview style manner.
For me, to say that you're proficient in a given language mean that you're able to grasp the majority of the syntax, and able to competently map a domain problem to your language 'tool', and make it work.
I find the difference between a proficient programmer in language X and a non-proficient programmer in language X is not that they don't ask questions, but that they ask different ones.
Proficient programmer: "What language features can I best use to make the program do what the domain specifies?" Non-proficient programmer: "What are the language features, and how do they work?"
Perhaps a bit simple, but I'm trying to illustrate the point as best as I can.
I felt my skills were there once people were consistently coming to me with questions about the language/framework. The idea of "professional" is very subjective, so I can agree with a lot of the points made here. Being professional can simply mean you're paid to do it. That certainly doesn't say anything about your skill in said language/framework.
Technically, a "professional" in the true sense of the term is part of a recognized profession which amongts other things has a code of conduct for all professionals. Examples: Doctors, Lawyers, Accountants, Engineers (basically anyone who can sign a passport (in Canada))
Programming/Software Development is not a profession.
The lay-term however: If you develop software for a living (pay isn't necessarily important - see OSS), don't get fired and the client approves of the result... I'd call you a professional.
If you go by Merriam-Webster's definition, you're a professional when you: