If you were to ask what "the best programming language" is, you'll invariably get responses along the lines of "using the right tool for the job".
However, the notion of "the right tool for the job" is not so straightforward an idea, can we unpack this a bit?
Oldest comments (23)
I think it comes down to playing to the strengths of the tools — but anybody who gets overly granular about this is misguided.
A lot of tools are in the same "class" of utility. Ruby probably is not the right tool for the job if you're writing an operating system. If you're creating a web app, it's likely not to matter whether you go with Ruby or Python — but if you're doing academic research it probably will matter. Not because Python is inherently better at that stuff, but it's just more the default accepted by that community. You're rowing upstream already if you choose something else just for the sake of it.
A lot of people can over-index on this. The right tool is often the one you are most comfortable with using. And when you're working on legacy systems, you're not necessarily helping by trying to use the best tool for the job instead of what's already in place.
Can you tell if a web app is made using Ruby or Python or PHP? If you can't tell it really doesn't matter!
I think there is often an implicit association of an ecosystem with a tool. When someone says scala, they might be thinking about Akka and the concentration of distributed systems people around it. When someone says python, they might be thinking of machine learning libraries. So, I think "tool" is misleading because it seems to imply just the core language.
This requires a lot of nuance. There probably is a statistically correct "best tool" for optimization and performance. But there are so many other factors.
What languages do you and your team dominate. Whats the ecosystem like? Whats the budget and time constraint like?
Its a combination of using the right tech and the tech you and your team have mastery over. Of course this all has its caveats and what not as well. But the main takeaway is the most boring response of: It depends.
I will share this article bartwronski.com/2016/06/26/technic...
that talks about how to choose a technology.
Basically it resumes in:
Use boring technology that you know well the pros and cons. Maybe is not the best tool for the job, but if you can circumbent the known limitations you will be fine.
Use new technology in experiments and non critical systems if wanted. Apply it when you know their quirks and limitations and can be confident using it.
Do not rush for shining new things, specially for projects with deathlines.
Deathlines... aptly put. It's not likely to be a typo.
From a classic oreilly.com/library/view/death-mar...
At an alarming rate, companies continue to create death-march projects, repeatedly! What's worse is the amount of rational, intelligent people who sign up for a death-march projects whose schedules, estimations, budgets, and resources are so constrained or skewed that participants can hardly survive, much less succeed...
I tend to use this phrase when I describe my tech stack to emphasize that I'm not fixated on a specific framework.
Maybe I can best explain what I mean by that by first explaining what it means to me to use the wrong tool for the job.
Building entire ecommerce platforms with Wordpress, for example. Yes, there's plugins, and no, they're not nearly as well maintained, flexible or modern as Shopware. Wordpress is an amazing piece of software, don't get me wrong, there's a reason that a large part of the internet runs on Wordpress still, but it's not meant to be used as an ecommerce platform. I've also seen people using Moodle as a CMS. Works, but Wordpress or Drupal would've been a more sensible choice. Every library, framework, language and toolkit is meant to solve a certain, often very specific, set of problems. A tool is the wrong tool, if its core set of solved problems overlaps minimally with the set of problems you're trying to solve. "Solving a problem" is also by no means a boolean state, more of a spectrum. Some tools solve the same problems, but in a different quality. I often use the "hammer, screwdriver and nail" metaphor for this: You can sink a nail in a wall with a screwdriver, but the hammer works better (believe me, I tried), because it was designed to do that. Also, you can probably hammer in a screw, but the screwdriver does a much better job. If you need to fight the tool to get your problem solved, that's when you use the wrong tool.
What's the right tool, then? As per my set theory excursion above, it's the tool whose set of solved problems overlaps most with your set of problems to solve, in the best way.
Lovely! ...The best tools are the ones designed for the job...and the do that one job perfectly! No need of hacking! They just do the job
Always learning so much from your discussions ❤️
Yay!
"Right tool for the job" implies that you have a toolbox with multiple tools and you know each one's "sweet spot." In other words, going beyond "if all you have as a hammer, all things problems look like nails."
I often write Command Line scripts. Most times those use Ruby but sometimes they are Bash. Why the difference? Ruby's super easy to write, but sometimes the right tool is some simple bash logic.
My brain immediately went to using the wrong tool for the job and shoehorning something to solve a problem that it actually wasn't created to do... not sure what that says about me or my past experiences.
Languages
The right tool has more to do with ecosystem tools (ex: solid data science libs), runtime constraints (ex: low resources, device driver, embedded), etc. When your constraints are lighter, its more a matter of the what your team already knows and preference.
System components
This is probably the most obvious place for "right tool for the job". After helping team mates write multiple queries, I realized that a graph database is a good option for: "does this user have access to this resource". When there is a dynamic path between the user and resource.
And there are plenty of components with multiple options to choose from. Ex: stateless vs stateful auth. Data shipping vs function shipping. Sharding or replication (or which for what pieces).
I think its quite hard to get a general consensus about "right tool for the right job" as there's a lot of factors to chime in. Ofcourse the first one is the programming language fit? for example "can we have a high IO in PHP that is fast and efficient?".
We also need to consider our talent pool at our arsenal.
For example we need to write a chatbot, we have a majority of JS/TS savvy developers at our team. Can we justify using Elixir(Phoenix) to them? Elixir is much more performant than NodeJS no doubt but most likely we will choose NodeJS to do the job.
Another thing to consider is, future proofing too. inherting the example above, do our userbase will grew really large? Will we hit the point where Elixir will let us save lots of server money?
Things like that are hard to forsee. My stance is to find balance between the best out there versus the best we can do right now.
It means time spent/wasted on research. There will always be a set of most common usage scenarios for a particular feature of a language/framework/API and a collection of accompanying tools for that set. And then there's niche. And then you'll catch yourself wanting to use a particular tool that is not in the MVP set of tools, you'll assume from its docs that it will produce certain results you desire only to find out through practice it's not producing the outcome you expected.
This is an abstraction developers like to use to communicate complex ideas to people that require simpler terms - like management.
Ok joke aside, job often refers to a usecase, scenario or project and depending on that the tool might mean a library, Framework or whole tech stack.
If we break this down we come to the foundation of the domain with specific processes and users with functional and non functional requirements and a technological choice to realize these requirements in the context of the domain.
Phew.... I sound weird, let's stick to the tool and job definition
The best tool is the one you know that may complete the job. It doesn't matter if tech X or tech Y will make the app go faster, or make it look cleaner if you hate it or don't know it. Take a list of the things you know or things that you can easy learn and pick the best one from them that can finish the job. It's like photography - yes, a 5k dollars camera might be the best one to catch a sunset, but if the sunset is now and the camera is at home, I am 99% sure the phone will do ok.
The right tool for the job is the tool right in front of you that you know how to use! It may not be fancy! It may not be new! But it's there...for you to use it!
As a software developer you're an expense to your employer. Implying the more productive you are the more valuable you are to your employer. The more valuable you are the more safe you are, and the more likely it is that you'll be promoted. Find the tool that makes you the most productive, without compromising code quality or security in any ways ...