In a recent CIO Magazine article, Esther Schindler asks if, and to what extent, the popularity of a programming language is a factor in choosing that language for enterprise development projects.
While most enterprise managers, as well as developers, would agree about the importance of choosing the best tool for a job, deciding on the best programming language for a given task, or for an organization, is a complex process, writes Esther Schindler in a recent CIO Magazine article, Is Computer Language Popularity Important?
Schindler focuses on whether, and to what degree, the perceived popularity of a programming language influences decision makers in choosing that language for projects and as a basis for enterprise systems:
How do you decide which languages are "acceptable" in your shop? Is it because your favored development environment (such as Eclipse or .NET) builds in support for one language suite? (Thus shops choosing Visual Studio would bless C#, VB.NET, and occasionally C++, with a smattering of IronPython accepted.) Or do you look for what programming languages are "in" and thus it's easy to hire developers affordably?
A key point Schindler notes is that developers and business managers have different, and sometimes divergent, criteria in settling on a language:
At the developer level, language choice is completely personal. Like picking a brand of hammer or carving knife, the tool should fit well in your hand. Some people think better in Python than in PHP, and God help anyone who thinks in LISP...
In business and managerial terms, however, the choice of a programming language is a much larger issue. A corporate standard language (or at least set of languages) ensures that the entire staff can read any in-house code, if not adequately maintain it. Predictability is a good thing, even if it's boring, though I've seen some mighty strange internal standards. In the mid 1980s, Ramada Inns let developers work on PCs in only Assembly language and interpreted BASIC, which meant that otherwise trivial apps were written in Assembly because none of the developers could stand BASIC. Turbo Pascal was smuggled in like booze at the office potluck.
Do you think language popularity is important in picking a language for a project or an enterprise? What factors do you, and your company, consider when deciding on an language?
If by popularity we mean what languages are most often used, then, yeah, sure it's important.
Popular languages have the tool support, talent base, taught in schools - all worthy attributes. Sadly, the features (or lack of) of the popular languages are suboptimal for wide range of problems. Some things never change.
The study cited in the article (http://www.langpop.com/) on language popularity seems to point to C being (still) very popular. I'm speechless.....
Language popularity is important, but maybe not the way a CIO simpleton might imagine.
For example, if Java is popular, then everyone and their dog is learning it to get a "job". Sure, your pool is larger, but it's also more diluted with people who are totally not motivated for technical excellence and who just want a "job". That's exactly the kind of people that equate hard work with working overtime. And these people fit the simpleton CIO like a glove. Frankly, the CIOs that make decisions based on popularity in a very naive way deserve what they get -- something between abject failure and mediocrity.
Popularity is not an all-plus quality at any level, be it a developer or a CIO level.
Popular languages tends to have more libraries and components available for them. They are not always better, but statistically, there is a chance of a better library that does something for a popular language than a library that does the same task on a less popular platform.
Less popular languages can offer unique advantages in productivity, safety, memory footprint, ease of parallelism and execution speed (and I'm probably missing many other good qualities). If you hire a person who knows one of these, chances are they also know how to build an interface between the language of choice and the more popular language with better libraries.
It's also possible that some less popular language has the best library in the world for the exact task you need to perform.
Maybe the most popular platform ties you uncomfortably to the whims of a single vendor? Is that an acceptable business risk for you?
There are so many things and angles that can and should be considered.
Popularity should not entirely dismissed, but it does not give a straightforward benefit. Popularity has drawbacks. The CIO who cannot see the drawbacks of popularity is simply dumb. An intelligent person doesn't see anything in simple black and white or 0/1 terms.
In general a CIO is poorly equipped to make any kind of language choice decisions all by himself/herself. CIO, if he/she has any brains at all, should consult his/her team, as well as any smart people they can find (not necessarily consultants, but do try well known and well respected open source developers), and, without any kind of hurry, build some consensus in the course of a thorough examination.
I also agree with that. But I wouldn't choose Lisp for a very important big project, because you have to build nearly everything by yourself. That's (sadly) a very big benefit of a popular language: More tool support, more librarys, more standard solutions,...
At the level of large projects that have subcontractors and tight controls over what libraries are used, popularity is not the biggest issue.
Instead, what is in the language proper and supported by the compiler proper is important. Many government jobs do not allow the use of the C++ Boost libraries. In part, this is an environmental factor that results from developers shifting careers to the ranks of middle management prior to fully understanding the importance of a library. After a while, the managers lose touch with what the developers need to do quality work. The result is that the middle management blocks decisions from going upstream, because they do not understand these new technologies in the same terms programmers do.
The ability to do things like "template metaprogramming" is practically forbade on many projects, forcing developers to create alternative solutions that would be more simply expressed using Boost::MPL. These alternative solutions are generally more inflexible, because they usually necessitate static configuration in the source code. Metaprogramming is supposed to solve by the static configuration problem by providing dynamic configuration of source code through notions like gradual typing and concepts.
In forcing developers to use less than their full creative abilities, opportunity costs occur. These opportunity costs are not apparent to most managers and executives until the mature revenue stream has been exhausted and the company is only earning a normal profit. At this point, the company must explore new revenue streams, but their underlying code-base is not agile enough to adapt to new market areas, because everything is based upon static configuration that was engineered based on the developers' view of the external problem domain. However, the external problem domain has switched to something else incongruent to that view. The end result is disaster.