Since the beginning of internet, when first bytes began to flow between networked computers, script kiddies have been asking the age-old question on message boards, forums and mailing lists: "What is the best programming language?" Much to their disappointment, even after vigorous debate lasting many decades, this question still does not seem to have a definite answer. Of course, those with a little more experience have figured out that there is no such thing as one language that is best for all situations. So why do people ask it? It takes a lot of time and effort to become proficient with even one language. So they don't want to hear that they need to learn three or four languages, especially when they are just starting their career and it can feel overwhelming.
If we cannot declare any language as the best, we are left with trying to figure out what characteristics make a good programming language. Here are some of my thoughts regarding what qualities are important in a language, and also what qualities are generally not so important, but are perhaps given too much weight.
One of the most important features of a programming language is that it is easy for humans to read. This fact is often overlooked because we software developers tend to think of code as something for computers to read and interpret. But generally more effort goes into reading code than into writing it. This is because code is normally maintained, reviewed and refactored over an extended period of time after it was written. The best kind of code is something that a new person can look at, who is not involved in the project before, and quickly understand what it does without reading comments or documentation. In addition to the syntax of the language itself, giving good and descriptive names to your functions, classes and variables is absolutely essential. It has been said that naming is the most important thing in programming.
The second most important thing in a language is the other side of the coin: that it is easy to write. More generally, we want a language and a programming environment that maximizes developer productivity. Often this has more to do with tools (also called toolchain) around the language, rather than the syntax of the language itself. If the code contains an error, the developer should receive a clear error message that describes the problem and the exact location of the error (file and line number). There should be minimal delay between making a change and then running the code and seeing the new result. Long build times are absolute poison for productivity. There should be a debugger that is easy to use for inspecting the internal state of the program and executing it step-by-step. The language should have a good documentation with special emphasis on being able to quickly look up a specific thing. It should also have a good standard library for common tasks instead of relying on third-party packages.
If you optimize your choice of language around what is easy to read and easy to write, you are on a very solid foundation. But what about the other considerations that can pull you the wrong way? Runtime speed is the most dangerous one, in my opinion. We all want to write programs that run fast, so it is easy to be seduced with this in our selection of language. Now, there are absolutely many cases where speed is important, and should even be the primary factor in language selection. In some situations you simply need the speed that languages like C and C++ provide and there is no way around that. I would not want my operating system, for example, to be written in a slower language than C. But I would go as far as to say that in the vast majority of cases today, development speed is more important than runtime speed, and we just need a language that is fast enough. My experience is that the vast majority of problems with "slow" languages are problems caused by a developer that is using the language inefficiently or even incorrectly.
Another factor to consider is the popularity of a language. There are two aspects for popularity which must be separated. First, of course it is better if many people are using the language. This means there are more jobs available, more third-party libraries to choose from, and a large community to ask for help if you get stuck. This is the good kind of popularity. Another kind of popularity, which I consider the negative kind, is similar to fashion. It deals with the whim of the moment. What is popular right now? What is the hot new language or framework that just came out and every cool developer is using? I think this kind of thinking is one of the most harmful influences for choosing a language or tools. Yet I see it all the time. An argument to use some new technology can be as unsound as "That is what everyone is using now." Unfortunately many companies make choices on such subjective opinions rather than evaluating things more objectively.
In fact, I would argue that if the language is old, and still widely used, that should be counted as a hugely positive factor. In our selection of languages and tools, we should prefer things that have stood the test of time rather than chasing the trendy flavor of the moment. In addition to looking at the past, we should also look into the future and make an educated guess as to whether a language will still be around 5 or 10 years from now.
To summarize, the common thread here is that we should prefer languages, frameworks and tools that benefit humans the most by giving developers tools that maximize their productivity. In essence we want humans to do less work and machines to do more. That is sort of the whole point of having computers and similar machines in the first place. That does not remove the need to optimize our code so that the machine runs it faster. And it does not free the developer from learning the necessary skills and knowledge to write efficient code. But optimizing for humans should be prioritized instead of optimizing for computers in most tasks in software development today.