Edit: The three I suggest are:
1. C or C++
2. Java or C#
3. Python or Ruby
4. (optional) Linux Bash scripting or Windows PowerShell
You should include one flavor of Lisp, a statically typed functional programming language (like Haskell or ML) and another declarative programming language (like Prolog).
Of course, by being proficient in any of the languages you mentioned will probably guarantee you a safe job, but having broader horizons in programming and computer science will make your programming career more diverse and interesting.
Even if you know several of those languages, if you've coded in one for a while, the odds are good you won't remember the syntax intricacies, the gotchas, etc when moving to the next one, not to mention what the name and argument order of every function in the standard library is.
Blaming programmers for being too lazy to learn new languages is silly. We use languages to solve problems. Working in an unfamiliar language makes the problem harder to solve, not easier. Unless the new language is a much better fit to the problem at hand. That's why its handy to know a few with widely different characteristics.
If there's a language that can hit many positive characteristics at once, it's more useful to know well than one that doesn't. That isn't laziness. That's called being smart.
I have also dabbled in C++, C#, Ruby, and Perl, you need to experiment occasionally
It traditionally replaces all the areas I'd use Python, C# and C beforehand.
I see less requirement for "picking a language for the job" thanks to this.
It only sucks as a shell scripting language for which I use sh.
But if you are conformable with it, by all means use it.
Most every complaint I read about Perl (too flexible, weird sigils) is a direct reflection of the system it was replacing. It's funny to read how people love that there's more than one way to do just about anything in Linux, but gasp that there are too many ways to do equivalent actions within Perl. They're one in the same. (I am not going to re-re-address its "readonly" nature since that's a red herring which applies to any language.)
Python, on the other hand, would need some helper functions to make the interface intuitive. But you only need to define them once, and then off you go.
http://dlang.org/rdmd.html
#!/usr/bin/rdmdOriginally 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.
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.
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.
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.
Use the right tool for the right job.
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.
Whether it's good for the organization is situational. Wherever you go, new hires have to learn the codebase before they can be really effective. It helps if it uses common tools and languages, but it also helps if it is well-factored. If using a custom DSL results in much better-factored code, it can be a net win.
There are so many languages out there. It's hard to get a job by leveraging your skill in the small subset you know without passing up a lot of opportunities involving the ones you don't.
A question that arises from this, how can you communicate this with too many intelligent developers that foam at the mouth for what they use, and don't waste a moment to scoff, snide or look down on others?
That behaviour, itself is kind of ironic, because in school I'm sure most of us weren't very popular or cool because no one knew what the internet was, nor were computers universally cool(er).
I wonder sometimes if it's not like continuing the uppity behaviour some may not have gotten over and instead turn on their fellow developers.
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.
Have you never met a tradesman who can talk at length about their drills and powertools? It's the same thing.
If you mean to ask why developers believe their setup to be universally superior to all others, well, then it's most likely because they're too caught up in their own world to understand how subjective they're being.
Hell, even Go is (even used for some Google end-user visible web stuff).
So the only point in your snark comment was "you will also need javascript". Well, duh. But that's in the client code, no reason to have it in the backend.
Plus, you could even code your javascript in Python, with Pyjamas ;-P
It isn't that Python is a bad 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 extremely 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.
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 is going to annoy me when somebody--yet again--presents Python as the best language you absolutely have to learn.
If you already know some similar languages, learning Python next is not your best option. Learn something interesting and different: Scheme, Scala, Clojure, Haskell, C, Go, assembly, Smalltalk...etc.
1. Tons of 3rd party libraries. AutoIt had nearly none. In Python I use Numpy, PIL, NLTK, OpenCV, and more.
2. The language worked. AutoIt had bugs. At least one bug was part of the language, I found it through coding that would happen in a college level class. Popular languages have bugs too, but they have been tested more thoroughly, and problems are pushed to be fixed more.
3. The language was supported. AutoIt programs were thought to be a virus by my computer. Python on the other hand is even supported by Eclipse, and I have been using PyDev lately.
4. The basic features were good. AutoIt only had a list data structure nothing else. While AutoIt had a lot of specialty functions, there were many more I ended up building from scratch that I should not have needed to. Also, Python has lots of nice features, such as list comprehensions.
5. People knew what I was talking about. Whenever I told people I coded in AutoIt, they were always confused and had no idea what I was saying. I love being able to tell people I am a Python programmer and they are like, hey cool, do you like this feature?
Now AutoIt is an extreme example as I haven't heard of it even on Hacker News so the languages you mention might not have such problems. But I'm guessing some of those problems exist in some form. Just my two cents on a personal experience of how popularity can actually matter in some ways.
All of the languages I've listed have very good open source implementations and active communities. (Except assembly. But assembly is special, so let's ignore it.) Additionally, all the languages work and are stable.
Really, AutoIt is almost a straw man: it does not compare to any of the languages I listed at all. Reading about it, it seems that almost any modern programming language is going to have much better features, support, implementations, performance...etc.
If AutoIt is the standard you're holding Python too, of course Python is going to seem wonderful! But that's not very telling: any modern language is going to seem magical in that comparison.
If you've only ever used AutoIt and Python, you should really consider learning some other languages. It will give you a much better perspective, and make you think in new ways. I particularly suggest learning a statically typed functional programming language like Haskell.
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 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.
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.
The exact same phenomenon occurs in all investment scenarios be it phones (android v. iphone), video games (xbox v. playstation), or programming languages.
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.
Rarely facts. Ironic for such a fact driven group (developers).
I think there's a big difference between being defensive (caring to change the other persons mind) and clarifying (telling people they don't have all the facts and leaving it at that).
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".
I think its reasonable for people to get emotional about a claim like that.
If I could pick one combination 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.
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.
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.
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.
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.
Writing _just_ the code is half of the battle unless writing sample code is all you do.
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.
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.
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).
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.
Maybe we see difference when we want and connection when we want.
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.
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.
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.
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.
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.
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.
Primarily I use Objective C, PHP and Javascipt however I have done projects in python, Ruby, C++ over the years.
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'm not sure. For one, that quest is how better languages are developed.
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.
Take Python for example. Wouldn't it be better with:
- 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
For a lot of those, there exist workarounds, half-baked implementations, etc.
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.
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?
I'd say that despite the complaints from current Python users on the changes above, 100% of the people would take Python-A. Right?
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.
So, while a "perfect Python" (or a 100% improved one) is a possibility, it's sad to see that it's not actually achievable.
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).