This is an hot-take I've been feeling for a long time.
Almost all projects I've worked on have scripts we wrote to automate a repetitive process. Consecutively, the majority of the scripts became obsolete and unmaintainable after some weeks, because we either didn't need them anymore or they have become too complex to be looked at. Afterwards, these scripts are either refactored or they stay forever in the scripts graveyard.
I think one of the major reasons that lead to this outcome is that we wrote the scripts in Bash
or Python
. Don't get me wrong, I'm a big fan of the two, but I feel like teams can win more if they write scripts using the main language their project is developed with. From the start, time and effort required to write them is reduced since:
- The learning curve is minimal, since you already know the corners of the language
- Internal language APIs can be leveraged, which drastically changes the mental model to write the script (for the better)
- Scripts feel more natural and eventually maintainability increases. Team members are familirized with the language!
- Development machines compatibility increases. Windows users can finally run all scripts. 🤭
The downside of going on this direction is the main language runtime support. Not every language is multi-paradigm or was designed to support scripting. For example, writing scripts on JVM
languages would require additional effort to build a toolchain that compiles and runs files on the fly, with short start time. But if you work on a web frontend project (JavaScript
), the power is in your hands.
At the end of the day, it is up to teams to talk and establish an agreement on which language fits best their needs and standardize their scripting language. If they can use the main language, awesome. If they can't, an higher level scripting language with native support (e.g., Python
) should be adopted, since it provides the means to increase maintainability on the long run.
Top comments (6)
A lot of the time the scripting language might not be available on the environment needed to run the script. For example, something running provisioning actions while deploying a PHP project might be running in an environment without the PHP runtime.
But everything POSIX always has
sh
. So...This might be an issue on remote workflows and pipelines, but I actually wrote this post taking in consideration scripts that developers run on their development machines
A challenging undertaking, I should think, if the main language is C, or C++.
This is not about the language used to write the scripting language, it is critically dependent on the development environment, and the purpose for which the script is being used. For example, in modern Java projects, most developers use the scripting capabilities of Maven or Gradle to perform builds.
Agree, but my point in using the main project language is existing knowledge around it.
If you don't need them anymore, no problem. If they are too complex, the problem is not really the language. And this is fairly common, whatever the language...
I would say instead : don't let people with complex minds and/or no autonomy write or maintain the scripts ! 🤓
And for the record, ChatGPT is very good at refactoring Python, from my experience.