Many IT, DevOps, or DevSecOps teams in enterprises may find themselves at a tight spot when it comes to supporting programming languages. On one hand, there’s the understandable aspiration to standardize languages to help control maintenance costs or future-proof the team’s portfolio. Conversely, many also see the advantages of writing software or applications with whatever language the team thinks will address business requirements and express themselves the best.
This tight spot has a personal touch, too. Some developers may prefer to learn and get their hands on every new language they possibly can, while others may find it better to go deeper in particular languages and become specialists.
So how should enterprises tackle this — and what’s in it for them in the first place?
Popular doesn’t mean the best (or preferred).
The TIOBE Community Index, Institute of Electrical and Electronics Engineers, RedMonk, Github, and Stack Overflow have their staples: Python, Java, JavaScript, PHP, C#, C++, and TypeScript, to name a few. There’s the occasional flavors of the month that bounce up to the top 20s, like R, Rust, and Kotlin.
Their indices can reflect many things for the global development communities. They can mean current levels of interest among developers, volume of activity in certain platforms, search popularity, and job advertisements. They’re good for pointing out current needs and projecting where technology would lead to.
So why should your business take them with a grain of salt?
Just because a programming language is currently the most “widely used” doesn’t mean it’s best suited for the job. Popularity is a misnomer and can be overrated. Your team might’ve logged the most hours working on React Native-based projects but another may have written the most lines of code in Python.
The most popular doesn’t necessarily translate to the most liked either. Rust is getting love from many developers worldwide — so much so that it even gained nods of approval from Linux and Microsoft — but it’s still nowhere near the top 10 (not yet at least). Even COBOL — a 60-year old language that built 43% of banking systems in the U.S. — is recently getting in the good graces of IT teams to address urgent business needs in the time of COVID-19. The same can be said with niche languages like R, which is increasingly finding its way to universities to help with finding a vaccine for the coronavirus.
Their surge in popularity is also driven by current demands and strategic push from vendors themselves. More and more are gravitating to Python for data analysis, artificial intelligence (AI), and machine learning projects. Kotlin’s steady increase in usage, meanwhile, can be arguably credited to Google’s endorsement.
What are the programming language preferences among Ourskyers?
We poll our developers every now and then about their preferences in programming languages, frameworks, platforms, and idioms. We see these surveys as a way for us to gauge how we can better engage our developers and bring more involvement in our projects. One of the more notable responses is their preference for certain languages and frameworks that they’ve seldom (or haven’t) worked with. An example would be functional programming languages, like Elixir, Elm, PureScript, and Haskell. I appreciate this openness, even if it’s just for satiating curiosities or using it for their pet projects.
There were also some interesting ones, like what seems to be a general indifference to Ionic and PHP. One of our developers said that it may not necessarily be due to the language or framework involved, but the bloat and performance issues that they usually straddle with when working with them. There was also some impassiveness against untyped languages or those with no compile time. Personally, he preferred languages with strong and static-typed systems that enable developers to do type inferences, metaprogramming, and Resource Acquisition Is Initialization (RAII). He explained that these help accomplish many mundane programming tasks, achieve resource safety, and give developers more freedom.
But as counterpoints, working with Ionic tends to overstretch the use of Angular (for hybrid apps), which can break its original design objective. It’s doable for some, but they become inherently bound by Angular or the web technology they use, which results in performance issues. PHP, on the other hand, is originally created for simple HTML markups, but it has since expanded to writing web apps. But in doing so, developers can mistakenly mix up control and template codes, which ends up becoming a nightmare to maintain.
I like languages with sensible defaults. They help reduce conflicts, like how Go has gofmt. Development communities are very much aligned in keeping their projects up to spec, and healthy ecosystems make it possible. For example, Python has the Zen of Python/PEP 20 that glues developers together by encouraging them to follow its guiding design principles.
Do the sentiments of these global development communities align with Ourskyers’? Trends admittedly affect our perceptions — whether updated versions of languages are rolled out to support new technologies or old ones come back to address immediate needs. But at the end of the day, what’s important is we solve our clients’ problems. At Oursky, most, if not all, of our developers are polyglots. We work with clients from different spectrums of industries, so it’s very useful to have developers who are comfortable with multiple languages.
Why does it matter to my team, or my business?
At Oursky, we believe that understanding your company’s tech stack can help with your business decision-making processes and enable you to assess the advantages and risks of using existing and budding technologies. It may be tricky, however, as it requires bringing disparate teams together from across your company that may or may not have the expertise to discuss your technology canon.
Being too unfettered can be chaotic. After all, your programmer may have written the best application in Haskell, but if he or she is the only one who knows that language in your team, they will be stuck maintaining it instead of working on new projects. And with so many systems and software written in different languages, the costs of supporting them can go through the roof.
That begs the question: How many languages are too many?
Over the years, we’ve worked with many large companies and enterprises in saving financial and maintenance costs through standardization. However, that doesn’t mean you should rule out experimentation. There are special cases when general-purpose languages aren’t enough or not suitable. In embedded and internet-of-things (IoT) systems, for example, you can opt for C, Python, Java, Lua, or Rust, all of which have their own real-world impact to your IoT software — memory management, power consumption, compatibility with other devices, upgradeability, and security, to name a few.
Here are starting points that you and your team can consider when standardizing or experimenting with programming languages:
- Expressiveness. How easy (or hard) will it be to write applications the way your team likes it to? Productivity and maintainability should figure into this. Developers, too, should be able to extend the language in ways that could let them add new constructs and expressions as libraries.
- Design. Style and elegance are practical concerns, too. Your team should be able to ensure that the codes they write are comprehensible, concise, composable, and can be easily read by others.
- Syntax and semantics. They pervade every single line of code your developers write. Poorly defined semantics can drag over everything. You need the proper syntax to compile, and you need the appropriate semantics to make it work.
- Learning curve. Will your team need to overcome a steep learning curve to use it? You should factor in the time and resources needed for your team to learn and grow.
- Costs. These don’t just involve financial resources for training your developers and maintaining the applications they write. You should also factor in writability and reliability (i.e., avoiding software failures); compiling and executing the applications; and ensuring their generality (applicability to a wide range of other applications).
Whatever you and your team decide on, you need to clearly convey how and where that language will be used. Two veteran developers can have different experiences when using a language, and a mismatch in expectations can create conflicts.
Sometimes there are functions you can express more clearly in one language that you’ll find difficult to do in another. However, too much freedom can be anarchic and expensive for your company. Be prudent with your choices and find the right balance of supporting different languages and ecosystems to address unique problems. Developers benefit, too, by using the right skills and tools at their disposal.
Programming is self-expression.
Over time, programming languages become relics of an ever-changing computing culture: functionalities and semantics evolve in response to needs and preferences. In turn, organizations create their own subcultures and vernaculars through their own best practices, style guides, and project management processes.
At Oursky, there is no one programming language to rule them all. Programming is just one of the ways we use to communicate ideas. But just as important is the aptitude to express and convey these ideas into digital products that our clients, partners, and users interact with.
Beyond practicality and personal preferences, businesses are run by people. Technologies are reinforced by an ecosystem of people, communities, and organizations that help and enable developers to use them. That’s what separates Ourskyers apart. While they have their personal tendencies, we empower them to experiment and add new languages to their repertoire. We use diverse sets of programming languages because there is a gamut of projects to do and a variety of people who work on them.
Oursky is an engineer-led and DevSecOps-enabled agency comprising a diverse and socially progressive team of experts collaborating across different parts of the world. Ourskyers are technology-oriented who value craftsmanship. Our mission is to create open-source solutions to help enterprises in digital transformation and support developers in building secure and privacy-aware software. We are self-funded, ensuring our engineering culture and excellence are built into our digital products.
Our accomplished developers have become part of the successes of the startups and enterprises we’ve partnered with. Schedule a no-commitment consultation with us and we can explore how to creatively use the right tools for the job.
