If you’re looking for your next software development role, or you’re looking to hire into a new development position in your company, one of the primary features of any CV or job description is which programming languages have been chosen.
People often wonder, why is a company looking for such detailed experience with language X? Or, why has this person or this team gained such extensive experience with language Y? Why indeed choose any one language over any other?
There are a lot of potential reasons for these choices, but interestingly, only one or two usually (and sometimes misleadingly) springs to people’s minds as key factors.
Suitability for the task at hand. If someone is asked why any given language was chosen, this is often the key if not the only motivation that occurs to people, though in truth there are usually many other factors. It is strongly believed, in some cases with great foundation, that certain languages are particularly suited to certain tasks. This has many axes: a language may offer precise low level control, be particular good for low-level tasks on modern cache-heavy out of order CPUs, or have particularly strong libraries available to bootstrap certain kinds of project. Its code may be quick and easy to write, or offer great performance, or use very little memory. In theory all Turing-complete languages are in a sense equivalent and theoretically interchangeable, but this is rarely comforting “at the coalface”.
Cumulative expertise. The longer one has been using a particular language, the more intimately familiar one is with its benefits, pitfalls, libraries and tools. Whilst it is possible to become productive (even extremely so) in a new language in a relatively short space of time, becoming expert in anything takes a much greater commitment. This is particularly true of framework-heavy languages and domains. On the other hand, far more emphasis is placed on existing expertise than seems truly reflective of most people’s capacity to learn and evolve.
Existing codebases. Especially from a company’s point of view, it can seem unwise to build products from too divergent a selection of languages, or to effectively dilute the focus of one’s engineers across too many languages. Rewriting an existing product in a new language is also no small endeavour.
Time and money. This overreaching duo are responsible for a lot of decisions, some of them good.
Active development. For the longest time, this was not considered a key point, as many mainstream languages were mature and only updated every few years (or decades); however much emphasis is often now placed on whether a language is being actively developed and is considered to be evolving to meet new demands and new applications. This is driving a lot of change in previously steadfast languages.
Community. This word is overloaded, however in this instance we refer to an existing community of developers and users to offer support to those working with the language; help from outside both on troubleshooting and around new libraries and tools.
Open source. If the language is itself open source, not only does this have perceived (and arguably actual) social value, and not only can it help a language to evolve more quickly, but there is a benefit to being able to customise a language should the need arise. In addition there are valuable open source projects and tools for many languages.
Proven track record. Particularly for companies, there is great value placed on a language having proven itself, especially in a relevant field, and the more instances of this the more reassuring it is. There can be a reticence and even wariness around being an early adopter, from companies.
Skill base. Whether a person is committing to learn a language, or a company is committing to producing a product with a potentially substantial code base, it can be reassuring to know that there are many other developers with the same skills, so that as a person one can find work and as a company one can hire future developers without issue.
Public image. It is not only important what an individual or particular company can see in a language, but the way it is perceived by others can readily drive people toward or away from it, potentially without full regard to the foundations for these perceptions.
Syntax. The style and formatting of the language, how verbose it is, and how familiar or esoteric it is compared to other familiar or comparable languages are all factors, especially to individual programmers. Many languages are general purpose, but some will be better at expressing certain concepts or solutions than others. Coders naturally want the minimum impedence between a thought and its expression. Sometimes this goes too far. Companies usually have style guides or house rules to ensure everyone can easily read everyone else's code, and to avoid the "holy wars" that have arisen over where the curly braces should go or indeed whether they should be there at all.
Paradigm. Some languages are so different that they require an entirely different way of thinking about a problem: compare an imperative language (like Python, C, C# or Java) with a functional language (like Haskell, F# or Ocaml) with a logical language (like Prolog) or a Lisp (like Scheme or Clojure). Some of these approaches are better suited to some kinds of problems than others, and many coders find it easier to "think" in certain languages (and from a company's point of view, this affects hiring).
Refactorability. Some languages' code may be quick to write but is hard to rewrite, and on large projects this can become significant, especially commercially.
Culture, fashion and trends. The software industry may or may not see itself as above the sort of thing, but it can be a much stronger indicator than is often credited. Some very viable languages have just gone out of style.
Technological shifts. Hardware architectures and instruction sets used to be very diverse; now 32 and 64 bit x86 and ARM chipsets dominate. It goes without saying that the kinds of software being built and used have changed dramatically in recent decades. However, this is perhaps given more credence than is necessarily deserved – a nuclear rewrite is still rarely necessary – you can still run COBOL (even on AWS) and 1972 C code can still compile on pretty much anything (albeit with switches and warnings, and potentially a few tweaks, and you might spend a while hunting for the right compiler). On the other hand, just because you can do something…
Creator’s profile and involvement. People may take language much more seriously if its creators are high-profile (perhaps even having created other works of note) and are still actively involved.
Personal identity. People and companies have been known to at least in part select a language based on the statement that choice makes in and of itself, and of the culture with which one is identifying in so doing.
Inertia. It is no small commitment to become an expert in a new language, its libraries and ecosystem; it is an even bigger commitment for a company to base its products, and potentially its future, around a language. If a commitment has been already made it one direction, it can be considered a “courageous” move to deviate from this course.
Accessibility. Not all languages are as accessible to programmers new to language or to people new to programming, and this is sometimes a key consideration.
Do you have a different view? Whether you’re looking to hire, or looking for your next job, you’re welcome to contact ECM to discuss your perspective.
