I wanted to write a few paragraphs and share an article to help MUSES members (particularly grad student and postdocs) understand some standard terminology used in software development in reference to their software products, so that when they are presenting at conferences or authoring papers, they might use the proper words about their work.
Notably, I recommend avoiding the plural word “codes”.
The MUSES software developers write code in various programming languages like C++ and Python. Sometimes the code takes the form of a script that is executed to produce some output or take some action. Sometimes the code defines reusable functions that are related to one another somehow, and collectively these functions form a module (not a “MUSES module”, but a general software module). What makes it a module is that the functions, classes, and variables defined therein can be imported for use by multiple other software components, thereby increasing the modularity of the overall software product.
To create a MUSES module (in our project jargon), a typical a MUSES developer team creates a software package (in the general sense) consisting of the modules and scripts necessary for their software to provide its functionality. The reason in our collaboration we call these software packages by the term “MUSES modules” comes from the goal of our MUSES framework: to integrate disparate physics calculation software packages by defining a standard interface that allows independently developed packages to be executed and interchanged in a modular fashion by the Calculation Engine.
A piece of code that performs some specific functionality. The code could include functions, classes, objects, or variables. Generally, the code is contained in a single file (
*.js), but not always.
A directly executable code file. Generally speaking, scripts are executed at the command line (using a command like
python module.py) while modules are imported by other pieces of code. The concept of a script is more associated with Python as executing code at the command line is much more common. Any module can also be a Python script.
Directory containing a collection of modules. In Python, a
package.jsonfile, which contains package metadata.
A collection of modules, packages, and libraries that together form a skeleton or boilerplate structure. The flow and control of data is controlled by the framework (inversion of control); in other words, the framework decides when to call the packages/libraries and abstracts away a lot of the logic and behavior. Contrast that to a library in which the developer decides when to call the packages.