Hacker News new | past | comments | ask | show | jobs | submit login
The 3 Programming Languages you need to Know (mathgladiator.com)
174 points by mathgladiator on Nov 11, 2010 | hide | past | favorite | 135 comments



Meaningless. I do not have a thinking language or a bread and butter language or a GTD language. I have apps (or tasks) that involve thinking, or are "just programming", or are "just get it done".

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.


>I don't think in Perl or Haskell or C or anything. I think in programming.

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).


"The only thing that sounds strange to me is that in every situation you end up with either perl or Haskell."

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?


I agree. I dont think in a particular language, I think in programming terms. What is the best I can use to perform what I need.


Hey you kids, get off my lawn!

  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
[EDIT: Added "s" to change significance from year to decade.]


Was there really a time period where BASIC and QBasic were bread and butter languages? I thought they were toy languages, like Logo.


Was there really a time period where BASIC and QBasic were bread and butter languages?

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.


Good to know... but that's not the description of a "bread and butter language", at least, not by the definition in the OP. Or else, Lisp, Haskell and Prolog would all be BBLs! I wasn't around in the 60s to witness software development, but when I think of a BBL today, I think: Java.

If you want to revise your history made in jest, I'd be curious to see the result.


No way, it's the exact definition:

> 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.


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.


Absolutely. But that's why BASIC is his bread and butter.


Ah, so that's where the confusion comes from. I thought that edw519's post was about "The typical bread-an-butter language in the 70's, in the 80's, etc."

I'd still be curious to know what were the de facto languages to get a good salary in the 60s, 70s and 80s.


Yeah. When I was younger I used to look down on things like VB. Now that I've pulled my head out of my ass, I realize many of those apps were a net win and would have been less of a win in a man's language like C++.


Lots of PC business apps were written in BASIC dialects in the 1980s.

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.


BASIC was one of the standard tools for 3rd party software. It was pretty easy to learn (compared to C or FORTRAN) and was migratable (I wouldn't say portable, but stuff written in certain dialects would generally be fairly straightforward to port to slightly different dialects or reimplementations on other platforms).

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.


>10 PRINT "STEVE IS THE BEST!"

Apple fanboism runs deep in this one

;P


My name is Steve. This was on a Commodore PET (8032 I think), then as a general rule I did this on every system with BASIC that I could as a check to make sure everything works, and as a little in-joke for myself.

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.


(I know, twas just a joke... my first exposure to BASIC was on an apple IIe(?) in 7th grade.)


A lot of Apple 2 apps were written in Basic, if I remembered correctly.


C# didn't appear until 2001. Perhaps you should clarify 2000-2009 decade?


Give the guy a break. He's old. Memory is the first thing to go :)


Memory is the first thing to go

My wife claims that it's the second thing to go.


... but she forgets what the first thing is?


Is sex drive first?


The years are only specified to 3 significant digits.


Actually less, I guess. Because the range is so narrow. The offset of around 2000 years doesn't really add any information.


That's why I edited my comment to say something about decades.


Then how come I see teams that boast 20 years of C# experience? Huh?!?!


The first year of the 2000's decade was 2001


I think you're confusing the whole "there was no year 0, so the millenium starts in 2001" business with decades. Decades start on the 0.

If you were to say "the 200th decade CE", that'd be a different story :)


I think the Hack-it-out and Bread and Butter languages are consistently transposed in this list.


uhh wait.. people actually use ruby at work? Perhaps 3% but calling it bread and butter is just plain untrue.

Java/PHP/C# would be more fitting, those make up a huge percent of the jobs.


To answer the unasked question: You're being downvoted because the list isn't the majority, but his personal experience. You should also review the article again, since his comment is on topic with what it discusses, and your's isn't.


As a downvoter, for me it was 'people use $LANGUAGE at work?'

These kinds of wars are not helpful.


And if you're going to ask those questions, you can at least ask it like this: http://news.ycombinator.com/item?id=1896245

"Curious and inviting further discussion" tends to beat "snide and dismissive" here, hands down.


One of the best related comments I've seen on this topic was by coffeemug a few weeks ago:

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.


I'd suggest ML rather than (or as a complement to) Haskell. The pervasive laziness in Haskell makes it rather unique - sometimes in a good way, but it means that algorithms often don't translate well to non-lazy languages.

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.


Thanks, that's good to hear. I'm working through the Little MLer right now. Good intro, but I'd be interested recommendations for other good books on ML.


_The Little MLer_, first and foremost - it seems to be the best intro to the ML-style type system.

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.


Great list, thank you. I've been eying Purely Functional Data Structures on Amazon, good to have a HN testimonial on that one. Will add that to my shopping cart for the next batch I buy.

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?


> 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)


Great, thank you!


I strongly suspect that these three are not intended to be mutually exclusive.

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


Happiness: Clojure GTD: Clojure (for hacking stuff together on top of Java) Bread and butter: Java

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.


Yeah that was my answer:

Python Python Python


Mine was similar, Python Python C/Java. Though there are half a dozen others that I am perfectly comfortable with.


I had to answer Python/Python/what the project requires, just to be realistic. Not every organization jumps of joy hearing "python", some (who have no idea) perceive it like a perverted bash scripting. So have to use C/java/php depending on the task.


IMHO it is more important that you can reason why you chose a language as your Happiness/Hacking/Bread-n-Butter languange, than which language you chose. I think it's perfectly valid to have a language in more than one category.


Happiness: Python because it has such an amazing number of really fun libraries like numpy,matplotlib,openopt,mayavi, pybrain,simpy etc. etc. Clojure is a close second, but I think it might catch up with python as a) I get better at it and b) more interesting numeric libraries start to show up

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.


Lisp is my happiness language, and everything else isn't. So for me there are really two types.

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.


How did you miss map when Perl has it? Also, when you say Perl's builtin data structures are poorly implemented, are you referring to the necessity of refs to do lists of lists and other nested structures or something else?


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 @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.
Well, you won't get a flat list either since you're calling map in a scalar context :) I don't see how the necessity of doing

  my @l = map { [$_ . "", $_ + 0] } @list;
rather than

  my @l = map { ($_ . "", $_ + 0) } @list;
is a problem with map rather than a problem with Perl's arrays and lists only being able to contain scalars.


Rats, you caught me before the edit. I thought I got away with it. Perl is actually (unintuitive) a strongly typed language, which is what caught me.

>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).


>>The point is that these are all artificial problems that the programmer shouldn't have to give any thought to.

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.)


>Yeah, the references of Perl sucks. Just has to be learned.

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.


    > In CLOS I don't even have to override
    > a function and then call the base version,
    > I can just use :before/:after methods.
that is possible in Perl, too, with method modifiers: http://search.cpan.org/~drolsky/Moose-1.19/lib/Moose/Manual/...

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.
true, but don't forget Perl itself has changed a lot, too.


Yea, as I said, Moose looks pretty good. And I realize perl has changed itself. Today it looks like the biggest issue with perl5 is you need a page long preamble [1] to get a relatively modern language.

[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.


>>[flexible] As opposed to, say, Lisp?

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.


>Perl is probably closest of the modern ones. But I talked about those I know.

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.


>>You're running into a "good is the enemy of the great" issue here.

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.


I agree with much of what you've said but every language is not inferior to Lisp. I would say Haskell is on par (in some ways superior).

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.


Clojure has some lazy stuff but I agree that Haskell is better in some ways but Haskell has no cool makro-system.

It comes down to static vs. dynamic.


Haskell has a cool macro system : template haskell. So it comes down to typing.


When I said every language is inferior to Lisp, I meant that in the most tongue-in-cheek way possible :-)


Ruby Ruby Ruby

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).


I was under the impression that Ruby doesn't fit the kitchen sink aspect of the list. It certainly is a bankable language right now, especially if you are a web dev, and it seems to make lots of people happy. But my impression is the library support is still in the growing stage compared to perl/python.


That may be true in the "Rails ecosystem", but Ruby has a really vibrant community of people writing tiny gems for everything. It rarely has one accepted library for one problem, usually, there are 2 or 3. Actually, as a Rubyist, I do feel the same issue when using Python: I don't know my way around the community, thus I never find the hidden gems or which libraries are hot (or not). I thinks its more a problem of perspective then reality.

Granted, no one can match Perl in that respect :).


Ruby gems provide enormous amount of functionality. You can do almost anything you want with Ruby, and even when there isn't a library to do exactly what you want, there are enough supporting libraries for you to quickly write the library you need.


I concur writing new gems is a good idea as CPAN is often the only reason I have to return to perl for some quick tasks. As CPAN is the grandfather of all package management systems and probably of (inet) shared libraries too it is perfectly clear why rubygems lacks the amount of available solutions to certain problem spaces. Doesn't mean we cannot get there some day :) So I'd say I. let's build more & sometimes better gems and II. use wrappers for C libs where money/time constraints are too significant to DIY (e.g. https://github.com/ffi/ffi/wiki/Basic-Usage ) Bottom line: try to share and contribute whenever possible. Love your language diversity :)


The number of available and useful gems makes Ruby my favourite for the kitchen sink. I recently had to build a web spider very quickly for a concept, and there was a gem that provided a multi-threaded spider. Obviously, Ruby wouldn't be my choice for an actual production spider for larger projects, but it let me get a prototype done very quickly :)


  Fun: C
  Hack it out: BASH
  Bread and Butter: LaTeX
Welcome to systems research in academia.


Kind of funny in the sense that the bread and butter language of the academia lacks a grammar.


Seriously, Python fits the bill for all three categories for me.


I like how MathGladiator managed to say something meaningful about programming languages and mostly steer clear from inciting the language war the headline implied.


Really? I took it as a "clever" hack for flattering everyone that actually indicates the author has even more to learn. To wit: there's a lot more relativism involved that one might expect at first inspection.

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.


No one language can keep me happy for a long time. So my happiness language changes every year.

GTD - Python (Also my happiness language)

Bread and butter - Java (although that might change too given the recent developments)


My happiness language changes regularly too - at the moment it's Arduino's cutdown c/c++ language. Since I got that bit of the hardware working it's going to be Pocessing's java-a-like language next[1]. (A month or two back it was Atmel assembler).

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...


Actually a GTD language means that the Happiness/Bread-and-Butter language is not powerful enough. If your Happiness/Bread-and-Butter language is powerful enough, and you really do use it whenever you can, then you should know how to either find all the libs that you need, or have hacked together the ones that you can't find.

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.


Happy: Lisp, Haskell, Smalltalk, Ocaml, Self, Newspeak, Erlang

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.


I'm a lot more interested in algorithms than in languages these days. I used to be a big language aficionado but I get a lot more out of, for example, teaching myself a new machine learning technique than picking up another language now.


Wow, the generalizations are running strong and swift with this article.

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.


3 languages you need to know: 1) a functional language, 2) an imperative/OOP language, 3) an interpreted language.


I guess "Happiness language" and "Hack-it-Out" might overlap.

Happiness - LISP is becoming a BLISS!!

Hacky - Python :):)

Day Job - Very sadly :( :( .... JAVA!!


I use a combination of Python, Javascript and Lua. I use Lua with my editor(Textadept), Python for most server side work and Javascript client side. Am currently working on using JS server side as well.

Three languages is too limiting though - I plan to reintroduce Haskell and Scheme at some point into the fold.


Actually: no.

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.)
Somewhere in between there may be a functional languague (erlang, lisp, haskell, etc.) but i, myself, never needed one. What really came handy overall is to know some basic stuff (assembler) for insight in how stuff works, plus C knowledge because the tools, libraries and languages you use are likely based on C. Plus Java, because it's almost everywhere and some script language to get things done ;)


Even if you never use it in directly, knowing a functional language can give you a new way of thinking about how you structure your code in procedural or OO languages. That can sometimes lead to more elegant code. Apart from that detail I agree with you.


Yes, i guess so. It's on my list of things to learn.


>but i, myself, never needed one

Blub. How could you possible know that you need something you don't know about?


I meant, that in no project, i have been involved in, a functional programming language was used, thus i didn't _need_ to learn one. I will probably just to broaden my horizon. I also know that i don't need to learn brainfuck, just don't ask me how i know that ;)


> meant, that in no project, i have been involved in, a functional programming language was used, thus i didn't _need_ to learn one.

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.


I would point someone to brainfuck if they were trying to understand virtual machines, Turing machines, and fundamental computation concepts.

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.


Brainfuck is generally considered an esoteric programming language and by the definition of Wikipedia esoteric programming languages are not meant to be used for " real-world programming" and are even only written as a "joke". To learn stack based programming one should look at assembler in my opinion, which i already mentioned.

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.


>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.


With many common languages, "learning" the language has more to do with learning APIs and minor syntactic quirks. You'll learn more if you chase after languages with very different models of computation.

Languages I've found particularly mind-blowing: Perl (esp. coming from C++), Scheme, OCaml, Prolog, Erlang, J / APL.


You have probably used Excel, the world's most popular functional programming language.


1. Python (used to be Lisp) 2. Python (used to be Perl) 3. C++ and occasionally Python


I've got my bread-and-butter (PHP) and Python is rapidly becoming my Hack-it-out / GTD language, but I don't have a happiness language. However, Python is making me pretty damn happy...maybe that means I'm just a practical programmer.


Happiness language: Actionscript 3

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.


Like others, for me these overlap a lot.

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.


Language you think in is constraining... unless your language is the best that could ever exist. Of course, if you can only think in it, you couldn't imagine anything better.

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.


> unless your language is the best that could ever exist.

Mine is Scheme, so, yeah. :)


Happiness: F#

hack it out: ruby

Bread and butter: C# / php


Working mostly with .NET, I'm really trying to get a grip on F# these days. I have no ambitions on becoming as fluent as I am with C#, knowing pretty much all the ins and outs of the language, but just good enough to fool around with it and getting stuff done(tm).

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?


Like every language I learned to program in I had a project and then decided to use that language with that project. I have to admit the first project was killer, it took me a long time to even get the code compiling. But once I had finished and looked at the lack of code I was sold that this was the way to go.

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)
vs.

  Enumerable.Range(0,10)
   .Select(x => x*x)
   .Aggregate((a,b) => a+b)


Minor refactoring note, since F# seems to bring that out in me: you could change the last bit to "List.reduce (+)". Or you could do the whole thing as "[0..10] |> List.sumBy (fun x -> x*x)"


Thanks for the response. The game of life sample was pretty awesome, and the way HW acceleration was added just made it neater.

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 found this to be a pretty good resource when starting out with F#: http://www.ctocorner.com/fsharp/book/

Also check out the F# guide on Wikibooks: https://secure.wikimedia.org/wikibooks/en/wiki/F_Sharp_Progr...


I found the ctocorner stuff pretty straight and to the point. Thanks for the links :)


1. Euskara (Basque) 2. English 3. Mandarin


I think people downvote you because the topic is about programming language, not human language.

I have to agree with you though, knowing English and Mandarin are better (at least for me) than knowing programming languages.


Ha, actually my point was that human languages ARE programming languages.

But this just demonstrates the general sentiment of the community - programming languages should only be thought of in one, narrow way.

Ok!


I don't want to turn this into a philosophical debate, but if what you are saying is true (I hope not), the community is wrong IMHO.

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...


How do those languages you mentioned as knowing (the human ones) fit into the 3 categories described in the original post?


Anything with first class functions works for me. I pretty much program with closures and have no idea what classes and objects mean. Incidentally the first language I really learned was Ruby but I fell in love with how it handled blocks/lambdas and I haven't really looked back since.


    ... have no idea what classes and objects mean ...
I hope you don't have to look for a job with that resume!


Looked at any clojure, erlang, javascript, scala, etc. postings lately? Objects and classes are out. Functional programming is in so I'm in good company and you don't have to pray for me at night.


Happy: Ruby, javascript Hacky: Ruby, bash BnB: php, javascript, java


Happiness - Python or oddly PHP Hack it out - PHP for web or Python for anything else Bread and Butter - C# and Java but I throw in Python to keep me sane


* My own DSLs

* Erlang,Python,Octave/Matlab,awk

* C/C++,Java,JavaScript,VBScript,PHP,bash


Clojure --> FUN! mmhh maybe bash for hacky stuff and VB to make money <-- bäähh


I guess mine would be:

Ruby - happy language

Perl - hacky language

Java - $$$ language


I think you can get more $$$ with PL/SQL, T-SQL, or ABAP.


You'd be wrong. There is a lot of money in Java right now.


I'm pretty sure the average ABAP developer earns a lot more than the average Java developer - but it's a pretty specialized niche.

Of course, you'd have to paid a lot to do it.


The thing about Java developer is that they're getting easier to be replaced (outsource or offshore).

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.


Happiness: Python, Scheme, Erlang Hack-it: Python Bread/butter: C#


Haskell

Python

C++


Python, Bash, PHP


For me it's:

Perl - Hacking

C# - Bread and Butter

Python - Happy

Although, there's quite a bit of overlap.


C is the only language that there's a strong argument for it being a fundamental language to know. Because almost every other language, OS and device driver is written in it. Not everything, of course, but it's a huge percentage.

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.


I think this difficulty to make a strong point towards a single other language is that the area where languages excel are usually populated by multiple languages.

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.


C is portable assembly, and since assembly will always be the interface to the hardware, C will probably be around for a long time. Everyone should know C and one high level language (be it Lisp, Haskell, Lua, Python, Ruby).


happiness+GTD+bread&butter = Python at the moment, thankfully


Python Python Java .




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: