views:

1653

answers:

17

I find myself constantly reading books on programming languages, design patterns, etc. and playing around writing small programs to just test the waters. Often I am reading more than one book at a time on different subjects (reminds me of school days now that I think of it). Out of your experience (subjective of course), is it better to be a master of a few programming languages or more of a jack of all trades so to speak? By jack of all trades, I mean being relatively competent in the programming languages, as opposed to having used it a few times.

[UPDATE]

Thanks for all the answers everyone! I think I'll keep doing what I'm doing and continue reading all that I can. I'll just have to make sure not to spread myself too thin. I do like the idea that many of you have suggested: Learn a language fairly well from each programming paradigm.

+6  A: 

There is no need to specialize in more than a few programming languages.

In particular I would suggest specializing in only one of each of the following categories:

  1. lower level language (Example C/C++)
  2. Managed languages (Example Java, .Net, ...)
  3. scripting language (Example Python, Perl, ...)
  4. functional language (Example Haskell, Scheme, ...)
  5. Web related technologies (HTML/XML/CSS/Javascript)

It is a lot better to specialize your experience with one language in each of those categories than to know the basics of several languages within the single category.

For example I wouldn't recommend to be an expert in both Perl and Python. There is no huge benefit in specializing in both of them.

As you get into more interesting topics it won't matter which language you use anyway. The syntax of a language really wont' help you with the underlying topics. There are a lot more interesting things you could spend your time learning than learning language after language.

Brian R. Bondy
I would have voted up this answer except it ignores the managed platforms of Java and DotNet; and I think things like saying "no point" instead of "of less value" is a little too strong.
Software Monkey
Thanks for the comments Kiwi, I fixed up my answer.
Brian R. Bondy
I think there would be some value in knowing both perl and python, they accomplish and specialise in different areas. Maybe not the best 'comparison' to make?
Josh Smeaton
fixed word knowing to specializing
Brian R. Bondy
+1  A: 

Specialize in a language. Having in-depth knowledge of a language (and increasingly, platforms like the Java API and .NET) is going to be more valuable. After all, value arises from specialization in our society, so being an expert at one field would be a distinguishing factor from others.

However, knowing multiple different types of langauges is highly beneficial. I would say the following:

  1. Know a language or platform that is feature-rich
  2. Know a scripting langauge
  3. Know a language close to the metal

If you want write an application but don't want to sweat the details for the networking and user interface code, then pick a feature-rich platform like Java or .NET.

If you want to do a one-time job that you don't want to spend too much time on, then pick a scripting language like Perl.

If you want to write a high-performance application and want to keep fine control over memory management, pick a low-level language like C or assembly.

It's important to be specialized in one thing, but it is also important to know multiple languages, so you can choose the right tool for the right job.

coobird
The problem with specialization is that it's a bet. Bet right and you can win big, bet wrong and you can lose big. Also, it's limiting, you may not even know what you're missing. Think about all the people who specialized in the early 90s and missed out on Java, .NET, Python, and the web.
Wedge
That's a very good point. I feel specializing is important, but probably equally important is to keep up with current trends to prevent "missing the boat" so to speak.
coobird
+2  A: 

Personally, I find it more helpful to learn many languages as you find interesting quirks of every language. The broadness of experience allows you to apply things that are common in one language to push your use of another language.

For instance, I recently completed a project in Ruby and used RSpec for unit testing. RSpec has a nice mock object framework because of the dynamic nature of Ruby. At my current job, using mock objects is not in vouge, so I used my experience with Ruby to question the practice of shunning mock objects and I am pushing the use of a mock framework in Java, EasyMock.

Kevin
+1  A: 

I prefer being a Jack of All Trades, personally. Variety can be a good thing if you don't like to get bored and don't want to be doing the same thing day in and day out. I'd also note that there have been many changes over the past decade in my area of development so it is helpful to think in more generic terms rather than have 90% of one's code be all in the same language.

JB King
+20  A: 

Master a few, but study many. Programming language paradigms change every decade or so; you'll want to be flexible enough to be able to pick up whatever the latest one is.

Learn about the classics so you can see how languages have evolved and how the newest ones select the best features of the older ones.

Barry Brown
While I agree that "you'll want to be flexible enough to be able to pick up whatever the latest one is," I disagree that "programming language paradigms change every decade or so." It is not the *fundamental paradigms* that change, but rather the *fad languages*, which may emphasize different ones.
Mattias Andersson
I think they do change. Twenty-ish years ago we saw the shift to structured procedural (Pascal); about a decade ago object-oriented took over; now we're starting to see a renewed interest in functional because of its usefulness in parallel programming.
Barry Brown
I think you're making my point, for me. :-) According to Wikipedia, Lisp was "originally specified in 1958" and "the second-oldest high-level programming language in widespread use today; only Fortran is older". The functional and procedural paradigms are not new, just more or less popular.
Mattias Andersson
To be fair, new paradigms certainly are developed, over time (such as object-oriented, which is not as old as functional or procedural), but that's not what I read your response to mean.
Mattias Andersson
I think we're both right. The paradigm that is "in vogue" changes over time. Sometimes it's a new one (such as OO), sometimes it's a return to older ones.
Barry Brown
A: 

I'd be more inclined to be competent in many languages rather than master of one or two. Expand your toolset and provide yourself with knowledge that you can solve a particular problem using the best tool for the job. Eventually, by using many languages, you'll learn techniques that so-called 'masters' use.

And more importantly, if a job ever comes up that requires expertise in a particular language, you'll be armed with an ability to learn quickly and find the expertise you need.

Rarely is language mastery required, and when it is - stackoverflow.com

Josh Smeaton
+6  A: 

Master one or two, then get familiar with as many others as possible.

Why?

You need to delve into the details in order to build a thorough knowledge of techniques and alternative implementations, and to develop your own coding style. You need to get to the point where the language is a facilitator and you're fluent enough to put your thoughts into code without stumbling over keywords and syntax.

But like spoken languages, programming languages can be so different (consider Lisp, C, COBOL, and SmallTalk) that they affect the way you think about solving problems, and sometimes one particular language will start you thinking in a direction that can be implemented with another, giving you the best of both worlds.

Your question transfers directly to the concept of learning one spoken language well, vs learning several conversationally. I think you need both ... there's no "royal road" to experience!

Adam Liss
A: 

It's much better to be competent in many languages. Being proficient in only one (or several that are similar) gives you an "everything is a nail" outlook on things programming. You do not want this. If you know several languages that are quite different, then you will have learned the difference between "Programming a computer" and "Programming a computer with language X". It will mean you understand the process in dissecting an algorithm, as opposed to merely translating it to a programming language. It will help your debugging skills and improve your systems design skills.

A decent mechanic has dozens of tools in his toolbox. As a programmer, you similarly need several tools at your disposal.

staticsan
+4  A: 

Fancy gets you noticed; fundamentals win ballgames. Learn the fundamentals of programming (see Knuth, Don), well, fundamentally, and you will be valuable, regardless. The patterns are all essentially the same.

Jared Farrish
A: 

It depends on what you want to achieve and what you are capable of.

If it's enough that you simply enjoy collecting knowledge, go ahead. Maybe you'll design the next awesome language.

If you want to be generally employable, you should aim to be quite competent in three or four languages, each from a different "family" (for instance, C, Java and Ruby). Anything beyond that is a bonus. Being a "master" is rarely a necessity.

If you want to be productive, it helps to have a spread of experience and be able to use a language that's well suited to the problem. However, knowing a language inside-out can also be helpful.

My advice is to go with what you enjoy. Maybe you'll end up writing a book or creating a new language.

Artelius
A: 

Become a master of solving problems. Languages are tools used to accomplish those solutions. Learn several languages. Be really good at a few. If you keep it up you'll get better at the ones you use. It's good to learn from different languages, even ones you don't end up using. Don't get stuck in a rut, be open to change, but don't chase every new language looking for the holy grail.

So as long as your research and playing around doesn't get in the way of you accomplishing your work, keep it up.

bruceatk
A: 

I don't think you should specialize in any language, until you have learned several different languages. That way you have a better idea of which languages are better suited to what you want to use them for.

Brad Gilbert
+18  A: 

To answer your question, "It depends on the languages."

I think there is a little value in learning different languages with variations in syntax.

I think there is a lot of value in learning different languages with variations in paradigm.

In my opinion, learning languages that teach you new ways of thinking about design and implementation will make you a much better programmer--even in other languages. The additional perspectives will help you find and use the best approach, even if it's not native to the language you're using.

Some example paradigms:

  • Event-Driven (such as VB or Delphi)
  • Imperative (such as C or Basic)
  • Declarative (such as Prolog or Haskell)
  • Functional (ideally "pure", such as Haskell)
  • Object-Oriented (such as Java or C++)
  • Low-Level (such x86 Assembler)
  • Relational-Database-Oriented (such as SQL)
  • Data-Transformation-Oriented (such as XSLT)

The list goes on. The wikipedia page on programming paradigms is an interesting place to dig into more possibilities. (The programming languages by category page may also be interesting.)

However, if you just want to jump right into one new language, I recommend Lisp! :-) Lisp has so many interesting things to offer, I think every developer should know it.

Enjoy!

Mattias Andersson
One of my most memorable programming projects from uni was a genetic algorithm we had to write in Lisp. Nothing like breeding trees of code that are themselves data and then executing them!
Tom Leys
Actually I have dabbled in Lisp a little (inspired by Paul Graham). What better way to mix my two passions of golf and programming than writing a golf handicap calculator in Lisp... just because =)
Jason Down
A: 

Hello as someone already hinted at. What is important is to get familiar with various programming paradigms. Each paradigm will provide new ways to think and to attack a problem.

I think the years of monolithic design using a single language and a single programming paradigm are behind. What's coming is multi-paradigm and multi-language solution. Knowing which tool to use for the right job is very valuable. OO and Procudural will not go extinct but with ever increasing parallism Functional is going to join them IMO.

In addition to paradigms I would suggest looking at various type-systems. Dynamic and Static type systems, both strong and weak. Each has its strengths and weaknesses, its role. For exemple after learning any language that uses Hindley-Milner type system you will no longer look at types the same ways. The same is true of mastering a language with more dynamic typing.

Learning a language which provide dynamic meta-programming facility like Lisp or Ruby is good too, getting the knack for code generation/manipulation is very enlighting, the famous code is data and data is code mantrum!

As someone pointed out it may help to have mastered one language as it becomes a reference against which it can be easier to appreciate what other languages bring to the table.

Last thing make sure you taste more than one flavor of OO, if all you've ever seen of Object-Oriented programming is C++ or Java there might be surprisingly a lot yet to learn of an OO language which is more dynamically typed, like Obj-C or Smalltalk. The more dynamically typed OO language use aggregation more than derivation.

A: 

You cannot be competent in a language without spending a great deal of time learning all the nuances and gotchas involved. When you know these things you can create programs fast.

Learning different languages then only improves your overall understanding of how code works and what it does under the hood. This does not directly improve your productivity with the language you are being paid to create something in.

The reality of the world it that many work places specialise (e.g. a "microsoft shop")

The choices you make on the languages you learn will affect the opportunities available to you, but at the end of the day, it is not a big deal to learn a new language once the one you have specialised in dies away a little. A year at a slightly lower salary maybe and you will be back on fire.

In summary, specialise in what you need to to earn your wage and play with what you want to enjoy your free time.

Specialisation is key to income and your specialisation will change as technology progresses.

Nat
+1  A: 

You talk of the two as if they are mutually exclusive.

I am a strong believer that by studying more than one programming language you will learn more about your preferred language. In essence, using one language is like using a tool, using many languages means you understand your tools in general.

Study as many differing paradigms as you possibly can. If you're already a capable programmer contribute your knowledge to the development of tools in another language (i.e. application development in Haskell, writing libraries for D, etc). Not only will you become better in that language, you will mingle with other programmers and learn from those like you.

Learning one tool is obviously good if you only plan to use that tool. However, by learning as much as you can you will learn things about languages that you would never have noticed if you didn't have the foundation knowledge of language design from your practical experiences.

EnderMB
+3  A: 

I assume your purpose is to enhance your knowledge and understanding; if your question is about making it easier to find a job or to complete your next project, my answer is not what you are looking for.

Learn many paradigms, not many languages. Java, C++, C#, Delphi are 5 languages but share a single paradigm. That does NOT mean mastering one of them is enough to master them all -- specifically, "Java The Language" is a very small part of "Java The Ecosystem" (which includes the JVM, The libraries, the idioms and well, the language as well); Same goes for C#. But once you've mastered one of them, you will be learning different syntax and ecosystems for the others, not a new paradigm.

What would my recommended list be (in random order):

  • Assembly Language (any - x86, x86_64, PowerPC, 68k, 6502 -- the paradigm is what's important). Paradigm: bare metal.
  • C -> C++/C#/Java/Delphi (do yourself a favor, start with C if you don't already know it or one of the languages in this list). Paradigm: Imperative -> Object Oriented programming (but .. still keeping enough of the concrete machine visible, boxing etc.)
  • Lua, Python, JavaScript, Smalltalk, Ruby: Paradigm - "everything is an object, everything is bendable, every method call goes through a dispatch table that is modifyable".
  • Lisp, Scheme, Dylan, Pliant, Clojure, Linj: (Preferably scheme or Common Lisp): Paradigm: Code is data is code.
  • OCaml, Haskell, Clean, Microsoft Excel / OpenOffic Calc: Functional programming. Yes, a spreadsheet is the most common example of a functional programming system. It's a lot easier to program than the others, but has limited scope. Regardless, representing a program as a set of functional equations rather than imperative statements (contrast with all languages mentioned so far) is a paradigm that's worthy of studying.
  • APL, J, K, A+: Vector languages. It turns out that programs can be very concise yet easier to write and prove correct if you use a good set of axiomatic building blocks. K programs are typically 10-100 times shorter than their Java/C/Python counterparts, yet still execute at comparable (often faster) speed, and are easier to prove correct. You will obviously not believe this one until you've grokked it.
  • Prolog, Erlang: Paradigm - failure as a thought (rather than an afterthought). Perhaps these two shouldn't be lumped together -- e.g. there's much to learn from Erlang about building reliable, redundant servers. However, I feel that it's part of Erlang's ecosystem rather than a language feature; e.g. you can have erlang style concurrency in Python with CANDYGRAM.
  • Ometa: Everything is a parsing problem. Really.

Also, I would look at a few languages as NEGATIVE examples -- that is, try to understand the motivation of the design, in order to realize what makes a BAD decision:

  • COBOL - Make code readable by making it all English.
  • SQL - Make programmers unneeded by making it all English (yes, one of the main design criteria for SQL was that managers would be able to pull reports from the database themselves without those pesky programmers along the way. Wonder how well that worked out?)
  • Java - study the evolution of Java, and realize it's been driven by Marketing rather than technical merit. The first language (rather than language implementation) to have a marketing budget. The decision to cut off C things like the preprocessor in Java 1.0 because they were considered bad practice, but not providing another solution for the things that they needed, etc.
  • C++ - trying to put everyone's ideas of how things should be result in a language that is ridiculously complex. STL was hailed as a technical solution based on theoretical beauty without "field testing" (which is generally not how standards are set), resulting in a standard library that is hard to use and whose implementation fail to deliver on many of the promises.
I strongly disagree with your statement that "Java, C++, C#, Delphi [...] share a single paradigm." They may all employ the procedural paradigm, but they are vastly more varied than this. As I noted, in my answer, several of these languages are excellent example languages for *other* paradigms.
Mattias Andersson
Also, I think you misunderstand the value of SQL: like every language, it is imperfect, but it based upon the "Tuple Relational Calculus", just like how Lisp is based on the "Lambda Calculus" and C is based upon a deterministic machine (like the "Turing Machine"). These are very valuable concepts!
Mattias Andersson
Well, there's a gray area between language, idiom and ecosystem. We probably have different definitions. I see no way in which Java, C++, C# and Delphi are materially different in their paradigms.
Also, about SQL: I think I do understand it -- it sucks. relational calculus is not sufficient for what SQL is used for, as evidenced by e.g. the "ORDER BY" clause which is part of the language (and violates relational principles). It is needlessly verbose, very limited. Can't even have temporaries!