There are some businesses that support one to two programming languages while others may support any number of languages. How many languages should be supported?
For further actions, you may consider blocking this person and/or reporting abuse
There are some businesses that support one to two programming languages while others may support any number of languages. How many languages should be supported?
For further actions, you may consider blocking this person and/or reporting abuse
Michael Tharrington -
dev.to staff -
BekahHW -
mahdi -
Top comments (6)
As few as reasonably possible.
I think it really depends. A programming language is a tool to get work done to provide value to the company. Some small shops, with only like one product, should only have two or three languages, a backend lang, a frontend lang, and some scripting lang. It could also get along fine with just going the JS backend approach. Bigger shops might need to do some low level stuff so get some C, then some data processing/mining stuff so go for R or Python, but want to write a huge distributed backend in Java, while supporting a legacy system in PHP. A consulting shop needs as many languages as their clients use. I don't think there is a good one size fits all approach to this question. That said, the less languages, and the less versions, and the more proper upgrading of old versions the better. Just because your code compiles and all your tests pass when you upgrade versions, doesn't mean you didn't just introduce lots of tech debt.
Do not limit yourself to a specific language group. Instead learn the design patterns behind the languages. All OOP languages are made of conceptual objects and permit polymorphism; just different syntax. All functional languages are... take a guess, functional paradigm implementations. XML derived markup languages are... you guessed it, XML paradigm based. If you can read Java, you can read C#, PHP, ASP, etc.
The second pillar to understand languages is tooling. Every worth its salt language has a debugger w/ stepping, a stack / call tracer, and a way to measure performance. The nice to use ones have editors with these built-in / plugins available.
My personal position is one of 'right tool for the job'. Don't pigeonhole yourself. PHP is a great web app language, Golang is amazing for perf. and concurrency, JS is the only option for browser side, and Java is a solid enterprise app/desktop language.
To limit yourself based on language count is to close yourself off from many valid solutions that would make you a more effective dev. Especially the understanding of different solutions approaches based on different design patterns.
I am lucky that I work for a company that selects the right tool for the job. Our "comfort languages" are Ruby and JavaScript, but as we examine new problems we evaluate other tools.
I personally see it as a big job perk that I get to explore languages like Rust, Go, Elixir, and Haskell. We don't have much (or any) code in production using those languages, but I'm sure we will at some point.
I can't say to have an answer. I think the better consideration is that adding supported languages adds complications, also depending on the language ecosystem. Build box support, available and willingness of developers to learn, limiting creativity of developers should all be considered.
The number of languages that should be supported is: as many as it takes to get the job done.
My project uses 42 languages. Some of those are used to make shipping binary (e.g., C++) or shipped with the product (e.g., JavaScript), others are used to make the shipping binary (e.g., Make, CMD, BAT), and others are used to facilitate development (e.g., Python, Ruby).