There is no single best language. Instead, what you get from any sufficiently good programming language is a series of tradeoffs. Haskell, for example, provides the benefits of pure functions (lazy evaluation, composable memory transactions, ability to reason about code) but in so doing it takes away your ability to arbitrarily mutate state and perform IO. That's a tradeoff. Python provides a clean, easily readable syntax that leverages whitespace. But you can't define multi-line lambdas. That's a tradeoff. Most of the languages on the author's list use garbage collection, yet another trade off.<p>Importantly, it is nigh on impossible to understand the pros and cons of these tradeoffs unless you learn the language first. So get a dart board out and pick a language at random. Learn it well enough to find things you don't like about it. Then learn another language that fixes the problems you had with the first and figure out what you don't like about <i>that language.</i> And so on.<p>Also, be aware that this process will never, ever end. Because there is no single best language.<p>Except Haskell ;)
Analysis paralysis!<p>The computer is a machine. It understands one language. Everything else is sugar on top. The language you should choose is the one that exists at the right level of abstraction for the problem you're trying to solve. That's a very academic way of saying, "choose the right tool for the job."<p>Personally I'm of the opinion that you can get really far knowing C and Common Lisp. They represent two fundamentally different models of computation and all of the other languages (save the Smalltalk offshoots and obscure ones I haven't had the pleasure of experimenting with yet) are essentially sub-sets of functionality from one or both of these two languages.<p>It's too easy to get caught up in the "feature creep," of all of the languages available today. Some will claim "immutability by default," is a feature. It's not. Any sufficiently sophisticated evaluator of a language can stratify a program into a process capable of emulating a machine that can treat all memory as "immutable by default." It's important to remember that often these languages are created to solve a specific problem and then evolve over time to become more general. It is best, in my experience, to just go straight to the source and work down to what you need.
The graphics in this are not very helpful, inconsistent and in some cases wrong. Your 3-d size/cpu/memory was impossible to read, there was no origin.<p>Secondly, the intended uses and paradigms were wrong. Lisp can do object-oriented programming with the CLOS and I'm pretty sure C++ was designed to be a general purpose language. In the intended uses, you have so many categories that are one off or very similar to others: what's the difference between web, web application and client-side?<p>Also, the graphics were not sharp and looked hazy. And the languages choices were not consistent, you have Clojure on some of them but not others. And in general, benchmarks don't mean anything without context.<p>This article has very little insight and has quite bad presentation.
I don't understand these questions:<p><i>“Is optimization of speed premature while productivity languishes?”; “Are semantic elegance and lexical simplicity just means by which to further our productive capacity?”</i><p>The flowery language is confusing me. Is there any real content here? I've never heard anyone talk about programming languages like this. Writing like this just makes it harder to understand and seems like putting on airs
I write Python & Objective-C most of the day, used to work for several years in a PHP/JS shop and have to code in Ruby and/or C from time to time. I recently felt the urge to learn a new language which is distinctly different from what I know so that I can learn new things. I considered Erlang, Common Lisp, Clojure, Go, Haskell, Scala and Elixir. I plan to use it for server side web development and if possible for command line scripting (where I currently oftentimes use Python). After much back and forth I ended up having to decided between Clojure, Erlang or Scala. I then went with Scala because it seemed to offer the best of both worlds: It has a good actor library with Akka, it has macro support, it is functional, it offers good OOP support (to ease the transition for me), and as a boon it also allows to develop for Android, something I may want to tackle in the future. So far I'm really happy. The only downsides are that the REPL starts up pretty slow (I'm used to Python, which starts up way faster), and package installation (especially of Java packages) confuses me at times. I still may want to go to Clojure or Common Lisp from here, but right now I'm happy with my choice.
I suspect like a lot of people who came late to programming my choice was initially dictated by simple pragmatic concerns:<p>What can I learn quickly? ...that has a fairly simple forgiving syntax ...that has a ton of online help and resources ...that I can get a prototype product out simply with ...etc - I think it's a not atypical set of concerns.<p>For me, because of all the online help and community and ease of getting something useful working quickly I landed on ruby, at first using rails.<p>My analysis may have been simpler than the OP but as I learned more I was able to understand more of what I needed, where my choices were good, where not. I was able to pick up other tools and languages as my interest was piqued.<p>So no one choice is right for everyone but this approach worked for me, but more than anything the key is to drop the analysis and learn SOMETHING ...once you start it's easier to pick up more.
The RedMonk chart measures language popularity by activity on GitHub and StackOverflow. Top business languages Cobol, Transact-SQL, and PL/SQL aren't included at all in the 84 languages listed so the popularity measurement criteria is flawed.<p>The Redmonk measurement also seems to be gamed because the second cluster in the chart includes some languages with backers who are heavily promoting the popularity of the language, including using Stack Overflow as their primary documentation effort and creating numerous shell projects on Github.
Seriously how many people here write programs to solve k-means or n-body problems? Who fucking cares how many lines of code it takes to write k-means, and who fucking cares how long it takes to execute or how much memory it consumes.<p>Most of us write software that moves bits from an API or DB to a screen. If we're lucky we translate a couple of those values to a color or something.<p>Why are benchmarks so focused on code no one writes? How many successful YC companies aren't CRUD apps?<p>Type the problem you have into google, write your stuff in the language that has the most concise stackoverflow answers on how to solve that problem.
The graphs seem to imply that functionality wise C# is the best choice....
I don't know much about languages but if that's true I wonder why it's not taught more often in schools, most classes I've seen are either for java or c++, and then assembly and matlab
How does a non-programmer write a guide to programming languages that has any value? Full of errors and misinformation gleaned from far too many hours reading websites and far too few hours writing code.