Your favourite programming language is not good enough

I highly doubt that this has much to do with laziness and much more to do with a nasty positive feedback cycle of post-purchase rationalization (for most time is the most important thing they can invest) and commitment bias.<p>There are a huge number of languages out there and it takes a large investment to become highly proficient in any one of those. Once you make that choice and sink all that time into becoming great with it you start to fall prey to the trap of post-purchase rationalization by seeking out confirmation of your decisions. Once you have placated your doubts, you rationalize the increased investment to become even better (that's commitment bias, also known as irrational escalation). And then you start the cycle all over again.<p>The exact same phenomenon occurs in all investment scenarios be it phones (android v. iphone), video games (xbox v. playstation), or programming languages.

I've been going through many, many programming languages over the years. Many of them I can't even remember anymore. Some of them I have stuck with for a long time, simply because they were most suitable for the kind of problems I was trying to solve at the time.<p>Originally I was very much in favour of finding the 'One language to rule them all'. Being able to do everything with a single language seemed like a no-brainer. But what all these years of try-outs have taught me is that such a language simply does not exist. And I will go one step further to state that they shouldn't exist.<p>The problem with every single language which tries to be good at everything, is that it inevitably ends up being mediocre at best and a major clusterf*ck at worst (I am looking at you, c++). Yes, it may be able to solve every problem out there, but not at significant cost to the programmer and development cycle. Inordinate amounts of complexity make the whole business of writing a useful application nothing short of a nightmare. A nightmare that you just do not have to put up with.<p>Lately I have come to realize that the quest for that one language has been a monumental waste of time. I have since settled on a DSL strategy. Pick a problem and then find a language/toolset that is uniquely suited to solve that problem in the most efficient way possible. Not only does this make the development cycle less painful, it teaches you a great deal about the problem domain your are facing, without having to deal with all the superfluous nonsense that a general-purpose language would impose upon you.<p>By adhering to this strategy, the obvious side effect is that there is no such thing as a favourite programming language. It all depends on what you are trying to accomplish. For the time being, my focus lies on Go. Not because I think it's the best thing that ever happened to the world, but because it solves /my problems/ elegantly and (almost) painlessly. This doesn't mean I will be using it for everything though. I would not even consider using it for something UX/UI related. For the simple reason that it is definitely not the ideal tool for this job. Just like I won't consider using Javascript to build servers and other distributed systems.<p>Use the right tool for the right job.<p>Edit: When it comes to DSLs, I would even add this: If you can't find a suitable toolset/language for your problem, consider creating your own.

I wouldn't say that programmers are too lazy to learn new languages. It's just difficult to keep so much in your head and to reliably use all the different languages without having to recall the particularities of that language, its build and run time oddities, IDE, etc. My advice is to pick a few languages and learn them well. It's a waste of your brain-power to only know 10% of ten different programming languages and to have to learn how the other nine do that (whatever that may be). You're far better off knowing 60% of three languages. That's my experience anyway.<p>Edit: The three I suggest are:<p>1. C or C++<p>2. Java or C#<p>3. Python or Ruby<p>4. (optional) Linux Bash scripting or Windows PowerShell

I tend to believe that it's important for a developer to pick up a couple of languages. But a point that I often see people miss is that it isn't so important to learn the language's libraries and basic syntax, as it is to learn the languages idioms.<p>There have been many times that I have seen Java guys learn ActionScript3 only to misuse properties (unecessary Java style setter methods everywhere, no closures, etc) and other features simply because they didn't learn the core values of the platform. I doubt that they really gained much lasting value from the exercise in the end, despite using it for a few months.<p>A few days with Clojure or another functional language in which they really focused on the core idioms of the language would have been more valuable from a learning standpoint, IMO.

See, my problem is that I realized that productivity is not bounded by the language itself but also bounded by the tools and ecosystems around it.<p>Once I finished writing the code, I still have to debug, refactor, produce some sort of code documentation, do a build and deployment, handle dependencies, package it up, and probably signed the code (optional..), potentially produce a nicely formatted changelog.<p>Writing _just_ the code is half of the battle unless writing sample code is all you do.

The reason I am annoyed with Python is simple.<p>It isn't that Python is a <i>bad</i> language--it's just not very good. Which is fine: plenty of languages are not very good and I don't mind. The issue is that it is <i>extremely</i> overrated, especially here on HN. And this translates to real inconvenience for me--I am forced to use Python when I would be better off with something else.<p>So the issue is not that I'm not willing to learn--I am! I even know Python fairly well (I do use it both at work and in classes, after all). And I am familiar with plenty of other languages, some worse but several better. So it <i>is</i> going to annoy me when somebody--yet again--presents Python as the best language you absolutely have to learn.<p>If you already know some similar languages, learning Python next is <i>not</i> your best option. Learn something interesting and different: Scheme, Scala, Clojure, Haskell, C, Go, assembly, Smalltalk...etc.

As with everything else in life, this is a compromise. It's a compromise of programming knowledge vs. the time to learn it and the time to keep learning. 10 programming languages, like others have mentioned seems exorbitant and you'll likely be spreading yourself thin. Knowing a functional language, an OOP language or two should be sufficient as your core languages. This isn't to say you shouldn't dabble in new languages and frameworks as they come out, but unless you're willing to cross bridges, the amount of time you'll spend learning the language, getting accustomed to new tools etc. will cost you more in time than is worth it to keep up to date with your core languages (especially if they're as fast-paced as Ruby).

If I can and have built good or even excellent software in language X and then run into people telling me that X stinks then it's quite easy to find myself defending it. Not on the basis that it's a perfect language, but that it's a workable tool for many situations. Realizing that no language is perfect and that different languages better suit different tasks, it's not uncommon to find yourself being defensive.<p>I do agree with the points the author makes. I'm just pointing out that there are other reasons to be defensive, and some of them actually stem from knowing multiple languages and programming paradigms.

I prefer this reasoning for why people get emotional about programming languages:<p>When someone says, "Your programming languages sucks", they're also saying, "The way you go about approaching problems sucks", and essentially, "The way you think is wrong".<p>I think its reasonable for people to get emotional about a claim like that.

Ahh, he obviously only thinks this because he hasn't learn Haskell yet ;-)

Just reading the title I knew Haskell or Lisp will be mentioned.<p>I agree that every programmer should learn one of the functional languages, although I personally wouldn't want functional programming to be my daily job.

Bravo. Language selection is almost always preference. But does it stop at languages?<p>I have been a bit of a polyglot in the past 15+ years. Not really by choice but how work led me. I picked up tips and tricks in several languages. Being able to use more than one language is like having more than one toolbox for the job. My dad had a toolbox for plumbing, another one for electrical, another one for general stuff.<p>Knowing more than one language is akin to being well traveled, being less ignorant of other cultures and people and generally noticing that people everywhere have more in common with how they live (or code).<p>Maybe English is as close as we have for a general language, perhaps folks who are a little zealous about their language of choice and inadvertently look down on others are wanting their language to become the english of programming.<p>Maybe we see difference when we want and connection when we want.<p>If we look in the Web space, the reality is most languages paired with a capable MVC framework for the Web, all are pretty capable in many of the same areas.<p>If we have an equally capable Ruby (with rails or Siatra), Python (with Django), PHP (with Cake or CodeIgniter) and let's an asp.NET MVC developer.. They would probably all come out with a pretty similar result.<p>First, all of these languages are all pretty old. Started in the 90's. The frameworks that we get attached to being hip, to me are our equivalent of culture, what's in fashion and capable today, ready to be replaced tomorrow by the next fashionable thing.<p>The tools don't guarantee success. Work with tools that are more rigid, and you have one kinds of problems. Work without any structure and you can make a horrible mess in any language. After having seen messes in every language, I am not convinced that any language is incapable of making a mess.<p>There are few things, and few times where any framework + language will provide a huge difference over another time wise. Where you save time in one, it'll take more time elsewhere compared to another framework + language.<p>If there is a language that truly gives you a feature, or an edge for your specific app, so be it. But in the web app space, I don't always see it so much, with so many great tools in so many capable languages.

"Why are so many developers so very emotional when it comes to their favorite programming language?"<p>Even more to the point... Why are developers so emotional about things like editors? All of these things (computer languages, editors, compilers, etc.) are just a means to an end: the end being a software system that, hopefully, makes the users life easier and/or provides them with something new to do.

I understand why people form attachments to a specific language and I can't deny that I have my own preferences. However when you stick to just one or two languages you're really limiting yourself and your projects, I see the tendency to try and pigeon hole every task into whatever language people are comfortable with and ignore others that might be better suited for that specific task. When you strip away frameworks most of the languages are very similar and jumping between them is not very difficult.<p>Primarily I use Objective C, PHP and Javascipt however I have done projects in python, Ruby, C++ over the years.<p>TLDR: The word for dog in Spanish is perro, however both dog and perro represent the same thing and a dog can always be trained to bark no matter what language you use to tell it to bark.

I feel that I've already wasted too much time deliberating with myself over which language to use. Sometimes the choice may be obvious (e.g., C for embedded devices). But when it's not obvious, most likely any of the languages you are even considering would get the job done.

This article makes the naive assumption that you can only use one language per project.<p>If I could pick one <i>combination</i> of languages for all my projects, I would rather have the combination of C++ and Lua for example (and maybe also C#, if I'm developing a Windows app) than a single language like Java, Python or Haskell.<p>I expect that is why C has survived so well - so many languages integrate well with it (and C itself integrates well with assembly.) Go does not have that advantage, and for that reason I doubt it will ever replace C.

Some commenters seem to think the only reason to learn a bunch of languages is to have a bunch of tools ready to apply to whatever problem comes along next, and yes, it is difficult to know many languages well enough to do that. However, I think they're missing the point of this blog post: dabbling in a bunch of significantly different languages makes you aware of the limitations of the (smaller set of) languages you use heavily enough to count as "ready to apply."

...for what?<p>If I'm a systems programmer for 100% of the time, chances are if I've chosen C or Go, then it probably actually is good enough (compared to the alternatives).

I tend to find that Go is so multi-paradigm that it fits all my use cases well. It's a perfect high and low level language, fits entirely in your head, has decent testing support, scales code-quantity wise very well and is very fast.<p>It traditionally replaces all the areas I'd use Python, C# and C beforehand.<p>I see less requirement for "picking a language for the job" thanks to this.<p>It only sucks as a shell scripting language for which I use sh.

I've said it (or some variant of it) before: domain knowledge is tremendously valuable. If I have full access to my toolbox of personal libraries, I can be extremely productive in C++. If I don't, or if my new employer bans Boost, or STL, or importation of libraries (all very common C++ problems), then I suddenly feel like a junior programmer again, plodding along.<p>I agree that language exposure broadens your horizons. Even old PHP changed my approach to some degree, and right now I'm working on learning functional languages. That doesn't change the fact that I'm dramatically more productive on my primary platform.

exch writes in the comments "Lately I have come to realize that the quest for that one language has been a monumental waste of time.".<p>I'm not sure. For one, that quest is how better languages are developed.<p>But there is another thing that bothers me. A lot of languages are good enough, and could be considerably better, if only the designers were not stubborn, or if only they had the resources and the will to break backwards compatibility for a while.<p>Take Python for example. Wouldn't it be better with:<p>- A better default UI kit than TK. - The GIL removed. - A JIT of JVM calibre. - Something like goroutines. - Optional static typing (and/or type inference). - Some way of AOT compilation (with an appropriate runtime). - Proper and easy to use closures (like Ruby/JS etc). - A better syntax to replace the double underscore thing. - Something like Virtualenv built-in. - Something like PIP built-in. - A redesigned base library, with the cruft removed and simpler interfaces<p>For a lot of those, there exist workarounds, half-baked implementations, etc.<p>Now, some people will say: "those will complicate the language", etc. But most of those changes are orthogonal, remove very real pain points, and some are even totally transparent to the programmer (like the GIL removal, or the JIT presence), while others enable totally new ways of using it. So, most complaints are of the "I don't want any change" variety.<p>Consider this thought experiment, to obliterate those complaints: if Python DIDN'T ALREADY EXIST AT ALL, and you were presented with two languages, one like the above (Python-A) and another like the existing 3.0 one (Python-B), which would you prefer?<p>I'd say that despite the complaints from current Python users on the changes above, 100% of the people would take Python-A. Right?<p>Now, nothing on the list is technically impossible (most are quite normal). But they require: the will of the core maintainers, a community to do them, money to back them up, etc. Actually, it just takes a major lead like Guido to be hell-bent on them, and lots of money, but not that much.<p>So, while a "perfect Python" (or a 100% improved one) is a possibility, it's sad to see that it's not actually achievable.<p>I can find similar pain points for most other languages (a PHP with a re-organized basic library with sane conventions and namespacing, a Javascript that's at Harmony-level on every browser, Ruby with better performance, Go with some way to write generic code besides interface{}, C with actual fuckin' strings, etc etc).

If you need to program in C, use Go. For everything else, use Python.