-9

There are a number of programming languages available today. My question is given a specific job what is the criteria one should use to eliminate other programming language choices which serve the same purpose? What does one need to know about the language to say confidently that we are not going to use this language for this job? I am specifically looking for languages which are used to write back-end of web applications? How did you decide that you wanted to write back-end in language x and not in y,z or w?

EDIT

Ok. Here is more specific version.

1) My question is only concerned about languages which are used to write web-applications.

2) Given 3-4 top choices, could you describe what features of language one must study in order to know if the language is suitable for the task. I just want a list of criteria which must be considered before making a choice of language?

closed as too broad by Bart van Ingen Schenau, user40980, user7043, GlenH7, gnat Oct 25 '14 at 18:13

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Paintings are made by artists, not brushes. – JeffO Oct 26 '14 at 11:15
  • @JeffO I appreciate that, but an artist needs to know what type of brush to use for specific painting. Oversimplification isn't always the answer. – working Oct 26 '14 at 23:16
  • The question which overrides all others is "which language is the team most familiar, comfortable and experienced with?". The only time you should choose a language other than that one is when the primary goal of the development is to broaden your skills, and the actual resulting product is only a secondary goal. – Carson63000 Oct 28 '14 at 5:16
6

Usually you cannot choose a language per job. There just isn't enough time to learn it, master it, and do the same for its packaging techniques, its ecosystem of available modules and programmers, its debugging quirks, and so on. To say nothing of the economics of investing in tools, learning, and ramp-up time.

So usually language choices are based more on "What do I know?" and "What's the closest thing I know to the job being considered?" Only rarely to we truly encounter zero-based, greenfield, clean sheet of paper decisions. Your pre-existing skills and your baggage must be taken into account.

But occasionally we do get to add another language / environment / approach to our skillset, or modernize/reconsider what tools we're using in a field we already know. Then we have a much less bounded decision. Some common considerations for eliminating possibilities:

  1. Degree of Difference If I were a professional Perl coder (i.e. for a pragmatic, dynamic, usually single-threaded language), I might decide to jump over to Python or Ruby (other dynamic, pragmatic languages). I'm a lot less likely to wholeheartedly embrace languages like OCaml and Haskell that are functional, statically typed, often focus on immutable data structures, require extensive meta/conceptual programming, etc. Some might, as a "stretching out" exercise. But most people and organizations consider "adjacent opportunities," not "change everything all at once" shifts.

  2. Popularity, Community, and Presumed Trajectory People are social creatures. And choosing languages/environments is also an investment. So we tend to want to shift to places that are popular, that have strong and supportive communities, where exciting changes and innovations are going on, and which seem to be "the wave of the future." It doesn't matter how much I love Smalltalk, say; it's not the wave of the future, doesn't have a large community, etc. (Sorry, Smalltalkers! I love it too!) Instead, I'd be much more likely to choose Ruby or another language that is Smalltalk-inspired, rather than Smalltlak per se. You see this "go where vibrant communities are forming" dynamic all over (favoring the likes of CoffeeScript, Go, Rust, Scala...).

  3. Approach and Capabiltiies Despite decades of aiming for this goal, there is no one language that's best at all jobs. Languages that try to span from systems and embedded computing all the way to abstracted business logic tend to end up as jumbly messes. (Looking at you PL/I, Ada, and C++! Apologies to their proponents!) So if you're trying to do embedded or systems work, you would tend to choose a C, D, Go, Rust, or similar language with features, performance, and communities that are particularly suited. You might look to "stretch" normal boundaries. There are good examples, e.g., of Java, JavaScript, and Python used in embedded work, or the likes of Python in servers. But you're not going to program the core of your next operating system in Perl, nor your next highly-threaded server in Python, Ruby, or COBOL. There's a reason that the highest level languages and systems are still, to this day, implemented in C and similar.

So, in summary, there are many, many reasons you can discard language choices, but their logical and cultural distance from your current skills; their relative popularity, community, and trajectory; and their "zone of competence" being different from the jobs on which you want to focus--those are major exclusionary forces.

Not the answer you're looking for? Browse other questions tagged or ask your own question.