To begin with, this isn't a question about which language one should choose :)

We're considering a language switch as our general direction is changing from content-driven web sites to data/action-driven web applications.

What sort of factors should one think about in order to successfully evaluate the various languages out there.

A few factors I've thought of so far, along with a supposed importance level:

  • Level of knowledge of language X within the company [medium/high]
  • Tooling available [medium]
  • Community size & activity [medium]
  • Availability of developers [medium]
  • Cost of developers [medium]

Frameworks are also an important consideration, however I'm just trying to focus on the language-selection question first :)

  • 4
    question doesn't look bad at the core, but importance level idea is quite slippery, could make it shift into polling / "bad subjective" / not constructive. Tooling is top! no, community is top! no all you are wrong what matters is cost! - you see?
    – gnat
    Aug 3 '12 at 8:11
  • gnat - yeah, you raise a good point there. I'll keep my fingers crossed it doesn't denigrate into such an argument...
    – otupman
    Aug 3 '12 at 10:14
  • well as far as I can tell you can just edit this part out of the question
    – gnat
    Aug 3 '12 at 11:20

I'd throw in:

  • Suitability for the problem at hand (Is the project web-centric? Does it use a lot of concurrency? Is real-time performance important? Is there a lot of number-crunching involved? Is it mainly transactional? etc.)
  • Overall quality of available tools and third-party libraries
  • Bindings for other technology (doesn't make sense to use a language that doesn't have any decent libraries for your choice DBMS)
  • Legal and licensing issues (not usually a problem, but licensing the tools can be a cost factor)
  • Platform support (even more important if you have to support multiple platforms, or want to be able to switch platforms down the road)
  • Integration with other systems (e.g., .NET works best if combined with other Microsoft technology; PHP and Apache go well together; etc.)
  • Paradigm support
  • Philosophy
  • Semantic properties (static vs. dynamic, etc.)
  • Maturity
  • Stability (Will your code break in 5 years? Will you be able to fix it?)
  • Quality of available programmers (it's easy to find a hundred PHP programmers, but about 95 of them will be incompetent; it's hard to round up 5 Lisp programmers, but those that you do find know their stuff)
  • Security - no programming language is inherently secure or insecure, but some provide more and better tools for secure programming than others; for example, avoiding XSS is much easier in Haskell (use the type system to distinguish between raw strings and HTML) than it is in PHP (remember to call htmlspecialchars appropriately)

Usually all that matters is what fad do your current programmers believe in. This is the only thing which matters and what comes after usually is rationalizing this argument.

Every webpage can be written in basically any turing complete language. I've written web services in bash, and there was a design rationale behind it.

Performance is also an issue, however, I'm yet to see a person to claim that java is just awfully slow on average sized projects sometimes (and slowness is easy: response should be around 200ms for end-user),

Ease of use and adherence to platform is also an issue, for example sometimes you feel that ASP.NET library developers have only developed libraries in their life, but never web applications.

Noone will ever claim that as they either believe in a language, and know it, or don't believe, and don't know it. I'm over with believing in technologies, and maybe the projects have moved on (I won't ever write a web application in java 1.4 again for sure, and I hope postback was killed by now)

The java community seriously believed for years that J2EE 1.4 is suitable for web application development. Today, Spring is much closer to Ruby on Rails or PHP than it is to J2EE. The .NET community seriously believed that postback is a good idea. It was a usability disaster, able to make planets extinct.

We all know that these were brain-dead ideas, the communities have moved on. We have new brain-dead ideas and a huge bunch of people claiming it's the way to do it.

It doesn't matter. Keep the cognitive time limits, ensure that the user interface is responsive, and do whatever your coders feel fine with it.


  • Have a list of what technologies your current coders know on a whiteboard,
  • Give everyone 5 sticks, and ask them to place it wherever they see it fit.
  • Grab the top two or three, form teams and ask them to create prototype
  • Walk through each prototype in a code review session
  • Make a decision.
  • I like the selection process you propose. Short and pragmatic. Aug 3 '12 at 13:44

I would consider the following order as important factors before decision:

  1. Learning curve - if your team finds it difficult to adopt and there is no good introductions and tutorial, better skip it
  2. Active Community - around this technology/framework/language is very important, this is driving force
  3. Tooling - how much productivity tools exist around it
  4. Comfort level - of developers in a team or company
  5. Availability of developer(s) who has experience and build some proto-types with this language/framework

I would also take into account the possibility of hosting your applications or deploying them in a cloud (so I would recommend checking which languages and frameworks are supported by the biggest cloud vendors). Also an important factor to consider would be non-functional requirements, the size of your applications and the number of developers working on them.

  • Tooling (very high)
  • Community (very high)
  • Learning curve (very high; if a system has a high barrier to entry it can't be good for new people)
  • Level of knowledge in the company (medium-low; if the top 3 are met, you won't have problems here)
  • Hype (medium; can be good for recruiting)
  • Availability of developers (medium-low; is usually dictated by hype & community)
  • Cost of developers (medium-low; if everything else is fine the boss will pay more for developers)

You've listed everything but the most important: which language provides features that are most necessary for the very project you will work on.

This is sometimes more important. You could find many excellent developers and make them struggle with the language of your choice to implement the features required. Or you could hire fewer developers maybe with less experience, but who would get the project done since the language they're using provides everything necessary.

My boss always says that the problem should determine the technology to use, and not vice versa. We've had a bad experience in the company I work in. We had a brilliant developer who was trusted a big piece of the project. He chose the technology he knew best, and failed. His failure cost the company about 6 months and a lot of money.

  • 1
    superM, you're right on the money there - I think I'd say we're looking for a new 'primary' language, i.e. the one we hope would fulfill 80% of projects. I stress 'hope' :)
    – otupman
    Aug 3 '12 at 10:24
  • @otupman, 'hope' is the right word in our industry. You'll never know until you try ))
    – superM
    Aug 3 '12 at 10:30

I think 3 of those factors are really the same thing. If developers aren't available, you can hire some and train them, but it adds cost. Some fields have more expensive developers - which adds cost. And training up those you have adds cost. Fundamentally, though, I think most professional developers can move from language to language without too much hassle - though picking up new frameworks can be a pain - and this cost is usually at the start of when they work with a technology. Personally, I wouldn't worry too much about these factors.

Tooling and community I think are both enablers - they make a developer much more effective over the long run. This would concern me more. I work mostly with Microsoft stuff, and I'm no fanboy - but the tooling and community size is very useful when I compare it with other things I've worked with.

One thing not mentioned there is also the human factor of such a change. For example, we had a change in direction which caused some developers to leave. They were already invested in a particular suite of technologies and that was where they saw their careers. When the company changed, they left. Worth thinking about.

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