What does it mean to be good in a programming language?

Question

What does - 'Knowing a language' really mean?

I'm sure it's more than knowing just the syntax.

Is it

• knowing all/most of the available libraries
• knowing how the features of the language are implemented

How did you learn the language you are proficient in?

Answer 1

"Knowing" a programming language is very similar to "knowing" a human language - you're fluent when you don't have to keep flipping back to a book or pausing to remember the right word.

I think "knowing a language" means being able to read and comprehend most programs (~90%) without looking anything up in a reference resource, and knowing exactly where to go to find the technical details on more obscure parts of a framework. For languages/platforms that don't have a "framework" per se, it is having that knowledge of the major libraries commonly accepted by the community.

For writing in that language, it means spending ~90%+ time on the design of what you're writing - including research on the design - and less than 10% looking up technical reference information.

Answer 2

Really 'knowing' a language to describe yourself as 'good' means

• you know about all the features of the language, including both
  • the unique/good features and when to use them, as well as
  • the dusty corners and what to avoid
• you know about the common conventions
• (as you mention) you know the libraries of the platform
• you know the entire toolchain (IDEs, build projects, debuggers, profilers) so that you can be proficient with the language

Answer 3

I think it really depends on the definition of "good", or the purpose of "being good".

For example, let's consider Java.

Most jobs wouldn't settle for you being good in the core language, they'd expect you to be proficient with specific APIs (e.g., Swing for GUIs) or even third-party APIs (like all the Apache stuff). You don't necessarily have to know every corner case.

Academic and industrial research may require you to really know the language inside and out. For example, if you write a static analysis tool or a compiler optimization, it's best to know of the edge-cases.

In education and in QA, it's often important to know all the weird corners and their risks. This is typical with C++. In education, because you can count on students making these mistakes accidentally. In QA, because that is where some of the weirder bugs lie (E.g., race conditions in static initialization).

As for how features are implemented, I think you can be a great programmer without knowing how certain things are implemented (e.g., details of the VTBL in C++), but it's important to know how other things are implemented (e.g., garbage collection, memory management, some libraries) to write really good and efficient code.

Answer 4

Given an algorithm, if you can implement a solution that is

• faster (than many other programs)
• efficient (use less resources than many other programs)
• smaller (uses a small memory footprint)
• elegant (easy to understand and maintain)

I think you know the language better ...

Answer 5

In my opinion it means that you can think in that language. Able to see parts of the code emerge in your mind as you go through the problem statement is a good indication of how proficient you are in a language.

Answer 6

Given a line of code in language X, that line is written once and likely to be read many more times (and potentially modified, of course). So proficiency in a language is, in large part, reading comprehension. For a corpus of programs written in X, how quickly can you read the programs and understand what they are doing?

Is it

• knowing all/most of the available libraries ? I don't think so, since there is an arbitrary number of commonly used libraries that are created while you are learning it. Even the base libraries for many languages today have thousands of distinct concepts (classes) and tens of thousands of functions.
• knowing how the features of the language are implemented ? That's a property of a given implementation of the language rather than the language itself. But I think it does contribute. Knowing that regular expressions are often implemented as state machines (and knowing the theory for this) is pretty relevant to understanding of regular expression languages. Though knowing how Java byte code works has never had any relevance in Java applications I've worked on... [1] I guess some languages have a cleaner separation from their possible implementations than others: this may be a key difference between high and low level languages.

If you have a particular language in mind, a good test is to look at serious examples in it. For the case of C, reading (e.g.) the Linux kernel, GNU OS utilities, PostgreSQL or Subversion, and figuring out how they work is not only an indication but can be good practice, too.

[1] There was that one assignment about static analysis of bytecode; but the actual solution could have been written in anything.