Should Bash Ever be Used as a Primary Language?
From Zanecorpwiki
While looking for a source documentation tool for bash, I ran across a post on StackOverflow, which is a site I generally find good answers on. The question was for a "Javadoc or POD" like tool for bash. There was a comment on the question: "I'd say that if your bash scripts are complex enough to need such a thing, you shouldn't be using bash. And I'm a bash fan."
This instance of "questions as platforms" embodies a common prejudice that certain tools are only for certain projects. Clearly, a given tool or tool set is going to and should be tailored to a particular kind of work. Bash would be a poor choice as a primary language for most "large scale" development projects.
However, to imply that Bash should never be used for any project of a size where the scripts would benefit from inline documentation just as clearly overreaches in the application of a generally true and useful stereotype. Porridge is an integrated network, host and services management tool that built with both development and administrators in mind. Te vast majority of the code is written in Bash.
I'd actually done similar systems in the past—the earlier versions both starting as significant extensions built around or in the spirit of make—which were written in Perl and Ruby. Having now had significant time to work with the Bash based Porridge, my experience is that despite being written in Bash, the porridge code base is much clearer and easier to manage.
Clearly both Ruby and even Perl are generally better languages for large projects. They are built with high-level usage and large code bases in mind. These are both significant factors that argue well for Perl and Ruby, and clearly there are certain aspects of the earlier applications which were superior in terms of coding clarity and maintainability.
However, on net the Bash implementation wins because it's closer to how people actually do it today. In other words, with the bash implementation, I can implement any function with the following process:
- do the process myself, manually, in the bash shell
- copy my command sequence to the script or function which is to implement the task I just did
- abstract as necessary
In other words, I can prototype the functions by just doing it. What makes Bash ideal, therefore, is the distance from prototype to production implementation is minimally short.
I also believe that, and in my corpus of work have some evidence for, the overall line count is less than had I went with another language. This is interesting because part of the point of high-level languages is code compaction. However, Bash is close to what the system is trying to do that, so there's no less to encode the differences.
