The 3 Programming Languages you need to Know
blog.mathgladiator.com
blog.mathgladiator.com
Sometimes I write quick scripts in Haskell. Sometimes I write them in Perl. Sometimes I write complex web applications in Haskell. Sometimes I write them in Perl. I choose the language based on good libraries for the task I am trying to achieve? I use Perl for network servers because libev performs better than GHC's select-based threads. I use Haskell for things that need to start up quickly. I use Perl for glue.
I don't think in Perl or Haskell or C or anything. I think in programming. I often find a nice way to express what I mean in the language I chose. Some problems look nicer in Haskell than in Perl. In the end, though, it's just programming. And while the programming part is 90% of the work in creating a working application, the other 90% is interacting with the outside world built by other people. Elegant syntax and beautiful algorithms are meaningless if you can't connect to the Foo server and get your data.
Incidentally, I always use C for libraries that need to be used my many people. C is not my favorite langauge, but I've accepted that if I manage memory correctly (client always allocates, data structures are structs with foo_ok flags) and don't use cstrings, C is not that bad. You just kind of tell the computer what to do, and it gets done. And then I can use it from Perl and Haskell with only a few more lines of code. And you can use it from OCaml and Python with just a few more.
This is a good point, I tend to do this as well. I think up how I want to attack the problem first and then how to translate it into the language I'm going to use.
The only thing that sounds strange to me is that in every situation you end up with either perl or Haskell. Is this a job constraint? I would think, for example, that in certain cases Erlang might be the best choice if one is doing work that lends itself to message passing, object database, etc.
Personally, after I've come up with how I'm going to do something I tend to choose the language that will be the least amount of work (constrained by what languages are an option of course, in the case of programming for dollars).
And C.
Perl sounds a little bit like his "get things done" language.
"I choose the language based on good libraries for the task I am trying to achieve."
With CPAN, that is going to be Perl the most of the time, certainly much more often than Haskell or C.
C sounds a little bit like his "bread and butter" language:
"Incidentally, I always use C for libraries that need to be used my many people."
Not exactly the same concept, maybe, but the importance of working on a team effectively is there.
I will have to take his word for it the jrockway does not have a Happiness language. But Haskell is certainly a good candidate for one.
Maybe a better definition of a Happiness language is a Just for Fun language. What language do you gravitate towards when you do not have a dollar denominated task in front of you, but just want to have some fun on your computer?
1960s:
Happiness Language: Lisp
Hack-it-out Language: Assembly
Bread and Butter: COBOL
1970s:
Happiness Language: Lisp
Hack-it-out Language: FORTRAN
Bread and Butter: BASIC
1980s:
Happiness Language: Lisp
Hack-it-out Language: C
Bread and Butter: QBasic
1990s:
Happiness Language: Lisp
Hack-it-out Language: C++
Bread and Butter: Visual Basic
2000s:
Happiness Language: Lisp
Hack-it-out Language: C#
Bread and Butter: PHP
2010s:
Happiness Language: Lisp
Hack-it-out Language: Python
Bread and Butter: Ruby
My wife claims that it's the second thing to go.
If you were to say "the 200th decade CE", that'd be a different story :)
I supported one in the latter half of the decade that handled all the accounting, financial reporting, statistical reporting on food and labor costs, payroll, etc. for a franchise fast food restaurant. It was really quite a comprehensive and easy to use system.
Yes. From the time they were introduced until today.
I thought they were toy languages...
Don't kid yourself. I am aware of 3 different full blown enterprise packages written in 100% BASIC. Inventory, accounting, production, order processing, ERP, CRM, etc. still running multi-billion dollar companies all over the world. Now here comes the good part...2 or them were written by 2 people and the third was written by one person.
This thread started out a little in jest, but there is (and always was) a moral to the story: You can write almost anything in almost any language. The proficiency of the practitioner is way more important than the tool being used.
If you want to revise your history made in jest, I'd be curious to see the result.
> This is the language that you can use to keep yourself alive when life hands you lemons. This is the language that you know just in case you need to hustle yourself to provide for yourself and your family.
If you're the one dude who wrote an entire package that runs a billion dollar multinational, you can pretty much charge whatever you want. It's like the ultimate job security. Any changes have to be made through you.
That's true regardless of the language.
I'd still be curious to know what were the de facto languages to get a good salary in the 60s, 70s and 80s.
Not to mention a whole generation of people (myself included) for whom BASIC was their first programming language. To this day, I remember my first program:
10 PRINT "STEVE IS THE BEST!"
20 GOTO 10
A lot of computer games in the early 80s were written in BASIC with bits of machine code (no pun intended) thrown in for effects, copy protection etc.
Of course, the pinnacle of BASIC programming came in the form of QBasic, specifically GORILLAS.BAS.
Apple fanboism runs deep in this one
;P
I've done equivalents in nearly every language I've written in. I'm sure if anyone sees me doing it they must think I'm a right idiot but it's my personal equivalent of Hello, World.
Java/PHP/C# would be more fitting, those make up a huge percent of the jobs.
These kinds of wars are not helpful.
"Curious and inviting further discussion" tends to beat "snide and dismissive" here, hands down.
http://news.ycombinator.com/item?id=1747713
"1. Be good. Be very good. Don't be the "front-end guy" or the "back-end guy", or some other "guy". Once you know what you want to build, building software is about five things: algorithms that solve your problem, programming languages that express your algorithms, computer architecture that makes your algorithms run efficiently on real hardware, the practical toolchain, and the management of complexity of real software. So study algorithms, and then graduate algorithms, and then advanced graduate algorithms. Do every challenge problem online. Study programming languages to express those algorithms. You can get away with three: C, Lisp, Haskell. Everything else is crud. ..."
I interpreted that to mean that C, Lisp, and Haskell are best at expressing the most difficult algorithms and concepts in computer science and software engineering, while simultaneously giving one the conceptual understanding and ability to quickly use easier languages like Python or Ruby for glue, utility, etc.
ML is just as good for algorithms & complex data structures (H-M+ inferred static typing, pattern matching, etc.), and has optional laziness (in OCaml, and IIRC as an extension to some SML implementations), but is usually easier to translate to more conventional languages as necessary.
My ML experience has mostly been OCaml-flavored. The best OCaml book I've seen is _Developing Applications with Objective Caml_ (In French, but a free English translation is online at http://caml.inria.fr/pub/docs/oreilly-book/html/index.html). It covers a slightly older version of the language, but that mostly impacts libraries.
Andrew Appel's _Modern Compiler Implementation in ML_ and _Compiling with Continuations_ are both great compiler books, which happen to use SML for the code.
Joshua Smith's _Practical OCaml_ is bad. Really bad. I was shocked. Avoid.
Chris Okasaki's _Purely Functional Data Structures_ is a great data structure / algorithm book, and uses SML (but has an appendix with Haskell versions). Also quite good.
Finally, experience with Lisp, Prolog, and Haskell carry over to ML somewhat, if you've used those.
I've also been looking at Modern Compiler Implementation in ML, but have no experience in compilers (no courses, work, anything). Should I read Aho first, or is that one I could dive right into?
I haven't read the newer edition of the dragon book, but MCIiML is a much better starting place than the old dragon.
Relevant recent comments: http://news.ycombinator.com/item?id=1820858 (on parsing + how I feel about the dragon book) http://news.ycombinator.com/item?id=1822515 (more book, etc. suggestios)
For me, Python has at some point or another been in each category, though at most two simultaneously.
And for those of us who do web development, "bread and butter" can easily include a half dozen languages or more. After leaving a project where I personally (no joke) used AS3, Awk, C, C++, C#, Java, JavaScript, Perl, PHP, Python, and SQL (sqlite, MySQL, and Postgres!) [1], my current position is just a trivially "polyglot" mix of C++ and Java desktop apps. Before that, I was constantly afraid that I'd forever be doomed to be a jack of all trades, master of none, but now the majority of my time is gobbled up by languages I don't like very much. Can't have it both ways...
[1] mostly by accident, as the powers that be could never make up their minds about what they actually wanted
Python Python Python
Hacking: Python, because I know python really well, it has a very complete set of libraries and when all is said and done, for most tasks, I'll simply finish it faster in python than in any other language.
BnB: Python, because my last two jobs have been working on python apps. But also more and more javascript as we are moving some of our stuff to webapps.
I get paid to develop Java, but use Clojure to call our Java libraries for quick prototyping of ideas and building tools for little tasks that come up. Other people at my company use Jython for this, so I end up doing some of that as well, which also works very well.
Every language that's not Lisp, while obviously inferior, usually has some domain-specific use.
I do get a huge kick out of C and assembly when I get the chance to do something low-level. It's a lot of fun to get in there and make something totally non-portable that runs 1000 times faster than the equivalent C++ program.
Getting small things done quickly used to mean Perl, but recently I've started to use Lisp for short scripts because Perl's built-in data structures are so poorly implemented. Last week I was playing around with parsing huge volumes of U.S. census data, which should have been Perl's bread and butter, but ten lines into the Perl script I missed map and nested lists so I switched to Lisp and was done in short order.
I've done a few things with Python, but nearly every design decision they made early on rubs me the wrong way.
I like Javascript for the same reasons I love Lisp. I have a feeling I'd really like Haskell if I could find the time to learn it fully.
And then there are the languages I consider to be abominations, like C++ and Java. Still, they have some great IDE's and libraries which make up for the language in some cases. I haven't gotten around to C# or F# yet. I don't know if I want to.
There are so few honestly awful programming languages. I have been forced to use a few, including Visual Basic for Applications, Matlab script, and a few other proprietary domain-specific languages that I've long since forgotten.
So three languages? Pssh. Learn as many as you can, enough to complete a useful project or two in each. After you do that, you'll realize that Lisp is the best by far and you've wasted most of your time. But at least you'll KNOW.
my @list2 = map { ($_ . '', $_ += 0) } @list;
I wont get a nice list of pairs but just one flat list. This is a silly limitation to have to think about when you're used to proper high level functional languages.
>>Perl doesn't have it. It has an imitation. Since perl can't do lists of lists (you have to use what it calls "refs") if I do something like: my $l = map { ($_ . '', $_ += 0) } @list; I wont get a nice list of pairs but just one flat list. This is a silly limitation to have to think about when you're used to proper high level functional languages.
my @l = map { [$_ . "", $_ + 0] } @list;
my @l = map { ($_ . "", $_ + 0) } @list;
>I don't see how the necessity of doing...
Because I'm used to being able to have lists of lists and now I have to deal with "refs" everywhere. In creating, in getting the values. The given example doesn't highlight it, but imagine in instead of the simple anonymous function given there the call to map called a function that returns a list? I have to remember to turn that into a "ref" or change the function to look at context and return a "ref" itself. I may not own the function in question.
The point is that these are all artificial problems that the programmer shouldn't have to give any thought to. You don't have to in Python. Not in Ruby. Not in Lisp. The only language I have to deal with this kind of limitation I can't think of off the top of my head is C (even C++ can handle lists of lists).
Yeah, the references of Perl sucks. Just has to be learned.
The Perl feature is that it is flexible. You'll get more library and language capabilities with CPAN than using anything else I know of.
The disadvantage is that you have to learn quite a bit of extra stuff. It is the natural language inspiration shining through (not a mathematically elegant and minimal notation, exactly :-).
I don't have three languages anymore; just now I only do Perl. This is a choice I made, because it is fun.
(I consider going functional again, next. Or, if the Android competition don't work out, maybe Objective C.)
But this is part of the larger point: it doesn't have to be learned. Just use something else that doesn't have this frustrating design flaw.
>The Perl feature is that it is flexible.
As opposed to, say, Lisp? CLOS, the most powerful OO system in existence [1] and it was initially just a library on the language. When people say things like this about perl they're usually talking from '98 or so when perl was the most flexible game in town. A lot has changed since then.
>You'll get more library and language capabilities with CPAN than using anything else I know of.
Java has more libraries, hands down. I'd say most common programming languages cover every use case that 99% of programmers will encounter, so CPAN/Java libs are only the only hope for a small amount of people in a very small amount of situations.
>It is the natural language inspiration shining through
You mean the English inspiration shining through. A lot of the ambiguity problems we have in real life (faithfully replicated in perl for us!) are a bigger problem in English than, say, German.
>This is a choice I made, because it is fun.
To each his own. I would try out some of the more advanced languages though. Lisp has some really cool things like the condition system [2], with Haskell you can easily play with infinite sequences, an incredible type system, etc.
>Or, if the Android competition don't work out, maybe Objective C
I would advise learning Smalltalk first and playing with that. It's a purer implementation of what you'll be doing with Objective C so it will help you learn good behaviors when you are ready to do some iOS programming. The Smalltalk image is also a fascinating concept.
[1] If you disagree, point me to one that is more powerful. And the way I'm judging power is by how many patterns I have to know to use it. In CLOS I don't even have to override a function and then call the base version, I can just use :before/:after methods.
[2] This is probably Lisp's nicest feature that hasn't yet been copied by mainstream languages. Which is a shame, software would be a lot more robust if it used this kind of system as opposed to the crippled exception system we use today.
Nothing compares to Lisp there, really. Perl is probably closest of the modern ones. But I talked about those I know.
CL was a favorite when I studied, but has gone the way of my German and French... I don't know it anymore. :-(
Pity it lost out in the market place. Today, CL has too bad library support, afaik.
[Edit: I don't know much about the Perl 6 macro system, but it seems harder to use than CL macros. Hard to make it as neat, for a roughly Algol-like language like Perl.]
>>CLOS, the most powerful OO system in existence
It was more or less copied in Perl's Moose.
I wrote "You'll get more library and language capabilities with CPAN than using anything else I know of."
And got the counter example "Java".
Afaik, you don't get language extensions like a new OO system in Java...?
So after comparing with CL for flexibility -- you compare amount of libraries with a system language, with roughly half the development speed (and a lot more pain) compared to scripting languages and Lisp...?
>>You mean the English inspiration shining through.
Oh, please... that was irrelevant bashing.
I take your point re Smalltalk, I've only read about the language.
Edit: Fixed syntax, clarity.
I'm not convinced. :)
>Pity it lost out in the market place.
The games not over yet. Clojure has been coming on strong lately.
>Afaik, you don't get language extensions like a new OO system in Java...?
You're running into a "good is the enemy of the great" issue here. Perl probably has Moose because the "OO" it comes with it is awful. Java actually has a pretty workable OO system right out of the box, so no one is willing to go to the trouble to put something even better on when they could just write more code with what they have. I'll give you that modifying the language is easier in perl if you need to.
>So after comparing with CL for flexibility -- you compare amount of libraries with a system language, with roughly half the development speed (and a lot more pain) compared to scripting languages and Lisp...?
The point of that example was purely to counter the oft claimed "CPAN has more libraries than any other language!". It's not true, though the libraries it has might be easier to find than some.
>Oh, please... that was irrelevant bashing.
I just get tired of hearing about Larry's supposed linguist credentials. Perl has English behavior and it's amusing to me that a supposed linguist would pick language features that cause the most misunderstandings in real life! Why on earth would I want my programming language to be as prone to misunderstanding as spoken language? That's the exact opposite of what I actually want.
Perl, as opposed to e.g. Java, has a tradition of being extensible; Moose is not the only example.
Common Lisp wasn't OO in the first silver book either.
>>counter the oft claimed "CPAN has more libraries than any other language!". It's not true, though the libraries it has might be easier to find than some.
Not what I wrote; I wrote "The Perl feature is that it is flexible. You'll get more library and language capabilities with CPAN than using anything else I know of."
You needed to go to Lisp (which sadly isn't really commercial today) for flexibility -- and Java for libraries. (And as you note -- I'm willing to believe there is more open source for Java, but finding it...?)
Re linguists -- you need to give exact examples of your claims for me to understand what you talk about. Compare with e.g. German, as you claimed there were some difference?
Etc.
> In CLOS I don't even have to override
> a function and then call the base version,
> I can just use :before/:after methods.
in fact, Moose took many ideas from CLOS (and Smalltalk, Ruby, Perl 6, ...)
you write:
> When people say things like this about
> perl they're usually talking from '98 or so
> when perl was the most flexible game in
> town. A lot has changed since then.
[1] Use statements to bring in the right libraries, turn off bad defaults, turn on needed features, etc. Stuff that is the default behavior in today's languages.
The way I rate the power of a language is based on how many "patterns" you need when using it. For example, I find Smalltalk an extremely powerful language but it does have one weakness: dispatching on more than one type requires a pattern (e.g. double dispatch, visitor, etc.). CLOS doesn't have this limitation. But Lisp does have a pattern that Haskell doesn't have: delayed evaluation. Every time you need it you have to reach for a closure or a macro and each of these have design side effects (e.g. macros can't be used as first class functions). Haskell doesn't have this problem because delayed evaluation is how the language works by default.
It comes down to static vs. dynamic.
For some reason I feel this taints me with a stereotype that doesn't necessarily fit, so (somewhat defensively) I'd like to preempt that by saying I've been writing code for the last 25 years (give or take a year or two). Also, I've never been to Starbucks and I don't use TextMate (but I do own an aging MacBook).
Granted, no one can match Perl in that respect :).
Fun: C
Hack it out: BASH
Bread and Butter: LaTeX
For me, Perl would be a "keep me alive" language. Yet I recognize that there's a lot of truly esoteric and impressive stuff in Perl. My "bread and butter" and my "hack it out" has been Smalltalk, which to a lot of people would be an esoteric "happiness" language. As it happens, it's a language with substantial libraries with which one can get some serious work done. Many languages have played two or all three roles for many different people. Also, lacking a "bread and butter" language is not a sign that someone has difficulty working in teams. It can also be a sign that someone is very good at navigating career pitfalls.
Often what a programmer thinks of a language and how they use it really says more about the programmer than it does about the language.
GTD - Python (Also my happiness language)
Bread and butter - Java (although that might change too given the recent developments)
I find my "bread and butter" and Getting things done" languages are both Perl.
[1] Now I've got Arduino driven lasers-on-servos, I need to implement face recognition on live video next...
Second, the Happiness language should be your Bread-and-Butter language. If you have a few years to work at learning a language really well, you should devote it to the most powerful language that exists. If you make your Bread-and-Butter language the most powerful language, and your Happiness language the same, you will have a very large programming lever and will be able to get the most done with the highest quality.
Hacky: Lisp, Python, Bash, Ant
$$$ : C# at the moment, but this one doesn't matter much in practice. My selling point is that with my language experience I can come up to speed on most any language quickly.
Personally I think it's important to learn the most advanced (and pure to that category as possible! [1]) language in each category to get the most tools in your tool belt you can.
OO: Smalltalk (classic OO) and Self (prototype, changes a lot about OO), Lisp (most advanced OO system I'm aware of and different than the rest) Functional: Haskell and Ocaml (for functors).
[1] Multi-paradigm is good for practicality but gives you an easy out when learning something new.
If I ever sit around wondering about what your "happiness language" is, you guys all have my permission to throw a pie in my face.
Seriously, one can personalize and over-generalize these things very easily. Programmers are famous for taking three examples and trying to build a templated framework of reality around them. It's probably the worst stupid people trick we have..
I love OCAML and F#, C++ and C#. I can tolerate Javascript and VB in a pinch. I do databases and all sorts of web programming.
But no thanks. I do not need or have a happiness language.
Happiness - LISP is becoming a BLISS!!
Hacky - Python :):)
Day Job - Very sadly :( :( .... JAVA!!
Three languages is too limiting though - I plan to reintroduce Haskell and Scheme at some point into the fold.
I don't get the reasoning behind this. If there should be some languages everyone should atleast now, it would be one of each of these categories:
hardware (asm or atleast some basic knowledge of how the thing works you program for)
low-level (C, good base for procedural programming)
high-level (java, good base for object oriented programming)
script (.pl, .py, lua, etc.)
Blub. How could you possible know that you need something you don't know about?
Ah, fair point.
>I also know that i don't need to learn brainfuck, just don't ask me how i know that
Well, objectively, what would BF teach you? What is it, a stack language? Then Factor or something would be a better place to start. I don't know enough about the language but I'm sure it's the lowest category of whatever category it resides in.
The point was that i don't have to learn something only to learn that i didn't need to learn it in the first place.
I was looking at more from the point of view of being a large hole in your knowledge base, and one that's likely to get really important soon. I know when I learned my first functional language, Ocaml, it was a really mind bending experience. It took me about a week to finally "get it", where as normally languages are so similar that a couple of hours is easily enough to grasp all the concepts, the rest of time is just getting faster.
Languages I've found particularly mind-blowing: Perl (esp. coming from C++), Scheme, OCaml, Prolog, Erlang, J / APL.
It's basically a virtual machine with less than ten bytecodes, which can be trivially implemented in a page of C. It's way too simple to be practical, but an hour or two toying with it should give a solid foundation for further study.
After that, I'd recommend implementing a Forth (and/or reading the excellent Jonesforth notes (http://www.annexia.org/forth)), and the Lua source. Lua's VM is really well designed, but the code is still small and reasonably easy to follow.
Hack-it-out: Python
$$$: Sadly at the moment Javascript (ugh)
I realize in the current 'zomg everyone hates flash' environment my choice for happiness language might make people look at me a bit strange, but AS3 is really a nice language. As ECMA dialects go I would rather write for the AVM than the browser any day. And when I think in code, it's usually Actionscript. Three years of hard-core Flex hacking will do that.
Python shows some signs of edging its way in as a replacement for my brain-speak, but I sadly don't use enough in my job right now for it to take over.
My happiness language isn't the one I think in. I think in Java, and a bit of Javascript for functional programming. However, neither of these are very fun for me. When I have spare time to hack for fun, I'm usually using Ruby or Scala.
My GTD language is PHP, and Java when I need things PHP doesn't provide.
My $$$ languages are Java, PHP, Javascript, and Objective-C (iOS). All of these are languages I'd rather not be coding in, but it's where the jobs are mostly.
There is a lot of overlap there. I think it's because for me productivity IS fun.
Mathematical notation might be a better language to think in than any programming language; but even that is constraining - since mathematicians are constantly inventing new notation, and many mathematicians think in pictures or even... intuition.
Of course, he really meant for coding; I just wanted to note the bigger picture.
Mine is Scheme, so, yeah. :)
hack it out: ruby
Bread and butter: C# / php
You wouldn't happen to know any good recommendations for books/online resources to get up to speed quickly? How did you get into the language to the point that it's now your happy language?
Also check out the F# guide on Wikibooks: https://secure.wikimedia.org/wikibooks/en/wiki/F_Sharp_Progr...
There is a really cool tutorial on writing the game of life in 32 lines of F# or writing the game of life that executes on the GPU using a similarly small amount of code.
http://tomasp.net/blog/accelerator-life-game.aspx
Start with a small project and learn the language, once you have a quite specific 'How do I do X?' question there are plenty of examples. I've never been the type person who could pick up a language from a book.
If you're doing ASP.NET google for F# + MVC + NHAML. There is a great tutorial for getting an ASP.NET project going in F#.
I'd say the primary thing that you need to learn for F# is how to convert loops to recursive functions and vice-versa. Also, look into the pipe operator, and figure out how to abuse the hell out of Seq.reduce and Seq.scan.
If you like LINQ and lambda's in C# you'll probably like F#, I'd say that's what really got me interested, I ended up loving LINQ and lambdas and wanted to know more about this whole F# deal. Using the pipe operator makes the whole thing look much more pretty IMHO.
[0..10]
|> List.map (fun x -> x*x)
|> List.reduce (fun a b -> a + b)
Enumerable.Range(0,10)
.Select(x => x*x)
.Aggregate((a,b) => a+b)And yes, I like LInQ quite a bit. I love how it lets you write your code a lot more declarative and in the process allows you to speed up your code by avoiding creating new collections while defining your transform.
Now I've added a F# Interactive tab to my console2 session and I guess I'll see if I manage to get into F# properly this time around :)
I have to agree with you though, knowing English and Mandarin are better (at least for me) than knowing programming languages.
But this just demonstrates the general sentiment of the community - programming languages should only be thought of in one, narrow way.
Ok!
Human languages defines what concepts we are able to think and reason about. I believe that George Orwell showed this perfectly in 1984. By taking away a lot of vocabulary, you are taking away a lot of ways of to express yourself. I think that the term "expression" in regards to programming languages explains why this is important.
I only know Dutch, English and Latin (plus just enough German and French to get around when I´m buying a bread or asking for directions) so in no way I've experienced how a language like Mandarin changes the way in which your thoughts take shape. However, I did have the experience of playing around with Haskell and Lisp (not saying I'm experienced or whatever, I've just toyed around with them in my free time) and they did change some things of how I percieve and think about code. I can´t write code in these languages where I work, but just learning them (and learning their different, but just as valid, viewpont on programming) has changed the way I think about some problems and how I should solve some problems.
Language (whether it's human or programming) is all about expressing ideas in the broadest sense of the word. Knowing more just let's you express more...
... have no idea what classes and objects mean ...
* Erlang,Python,Octave/Matlab,awk
* C/C++,Java,JavaScript,VBScript,PHP,bash
Ruby - happy language
Perl - hacky language
Java - $$$ language
Of course, you'd have to paid a lot to do it.
That might not be the case if you're specialized in SAP (ABAP, FICO, ERP), Oracle (PeopleSoft, CRM, Financial). Sometime it is due to the nature of the information you're dealing with.
Python
C++
Perl - Hacking
C# - Bread and Butter
Python - Happy
Although, there's quite a bit of overlap.
I really like some other languages other than C. But it's hard for me to make as strong of a case for any other language as a "must know" language.
Do you want to look at a good object oriented language? Take a look at one of Python, Java, C#, Ruby and probably Perl with the right modules.
Do you want to take a good look at functional programming? Look at one of Haskell, OCaml, SML or something along these line.
Do you want something to prototype rapidly? Python, Ruby, probably Scala.
Do you want web programming? Ruby on Rails, Django, PHP, one of those.
Do you want embedded programming? Well.. look at C. Or C++ with C embedded, as some maniacs use it.