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.
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.
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...
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
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.
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.
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.
"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?
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.
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.
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.
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.
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).
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.
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.
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.
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)
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 :)
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.
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.
>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?
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.
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.
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.
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 :)
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 :).
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 :)
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
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.
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.
140 comments
[ 9.3 ms ] story [ 254 ms ] threadFor 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.
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.
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...
Python
C++
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.
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)
Perl - Hacking
C# - Bread and Butter
Python - Happy
Although, there's quite a bit of overlap.
Happiness - LISP is becoming a BLISS!!
Hacky - Python :):)
Day Job - Very sadly :( :( .... JAVA!!
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:
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 ;)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.
* Erlang,Python,Octave/Matlab,awk
* C/C++,Java,JavaScript,VBScript,PHP,bash
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.
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.
Three languages is too limiting though - I plan to reintroduce Haskell and Scheme at some point into the fold.
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.
vs.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 :)
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.
>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 fact, Moose took many ideas from CLOS (and Smalltalk, Ruby, Perl 6, ...)
you write:
true, but don't forget Perl itself has changed a lot, too.[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 :).