When choosing a first programming language, there are many issues that need to be considered. Many of these have been considered in the answers above. I include 3 more as these were a part of my answer to the closed question ( https://cs.stackexchange.com/questions/1946/criteria-for-choosing-a-first-programming-language ) that originally inspired this question. I've copied my answer here (and modified it) based on the current policy of deleting closed questions. Here are 3 points to consider, using a few programming languages as examples. Programming in the large vs programming in the small ---------------------------------------------------- When first learning to program, one needs to learn how to _program in the small_, before moving on to learn mechanisms to help _programming in the large_. By programming in the small, I mean writing programs with fewer than 100 lines. These programs will involve algorithms that manipulate simple data structures, have simple control flow, and will solve simple problems. They will in general not be considered as _applications_. By programming in the large, I mean writing large programs built from many components/classes, building on top of an API, with a GUI, a database, possibly in a client-server configuration. The things a programmer needs to think about when programming in the small are very different from when programming in the large. Programming in the large requires the programmer to think about modularity, good interfaces, good design, reusability, and many other issues. Modern programming languages provide many constructs to help program in the large. These constructs include classes, modules, interfaces, information hiding, etc. When programming in the small, these issues are much less important. A programming language such as C++ has many features to help programming in the large, but it is more difficult to sit down and start writing a very simple program. Java is similar. On the other hand, a language like Python, Ruby, Scheme or Haskell makes it much easier to directly write a program. High-level vs low-level ----------------------- Languages like C++ and C are rather lower-level language. They enable the programmer to manipulate references into memory directly. Although, this allows one to write very efficient code, the low level details can be difficult for a first programmer to learn the language. Some would argue that these low level details get in the way of writing the logic to solve the problem. A higher-level language like Python makes it easier to express concepts more directly in terms of the problem domain. Staticallly Typed vs Dynamically Typed ------------------------------------- C++, Haskell, Java and many more languages are statically typed. This means that the compiler automatically finds places where potential errors occur based on the expected types of values at each location in the code. There is a bit of a religious war about whether static typing is a good thing or not, but I will steer clear of that one. One problem with static typing for new programmers is that the error messages reported by the compiler are often difficult to understand. This is especially the case with C++ templates and Haskell programs in general. Python, Ruby and Scheme are dynamically typed. This means that errors are detected while the program is running. One can argue that this is too late to detect the errors (but one can also use testing to avoid such errors). Again, avoiding the religious argument, the advantage of the kind of errors that one encounters when writing simple programs in a dynamically typed programming language are of the sort _this object does not know how to do this operation_. In the context of a small program, these errors are easy to understand and track down. Languages like C have weak typing, meaning that although the compiler helps out with some errors, the run-time fails to trap others that occur, such as invalid memory accesses. As a result, the error message returned to the programmer is akin to "Program crashed". A dynamically typed language would trap these errors and convert them into a more comprehensible error message. Others ------ For other languages different considerations may come into play, such as the support provided by the programming environment, the available APIs, quality of books and online tutorials, etc.