Words to use when talking about MUSES software

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.

:star: 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.

:link: Difference Between Module, Script, Package, Library, and Framework

While this short article mentions it is “in the context of Python and JavaScript”, it is providing meaningful definitions for terminology used when discussing programming generally in any language.

There’s a lot of terminology out there when it comes to pieces of code. Modules, scripts, packages, libraries, and frameworks are some commonly encountered terms that can be confusing to keep straight. A big reason for all this is the modular programming approach, which involves breaking down a complex coding task into smaller components or modules. This article aims to explain the differences in the contexts of Python and JavaScript.


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 (*.py or *.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 __init__.py file is required to tell Python to treat the directory as a package (or subpackage). In JavaScript a package directory contains a package.json file, which contains package metadata.


Collection of packages. Libraries are generally well-tested and have a well-defined interface. The JavaScript community commonly uses the terms package and library interchangeably. The same is often true for Python, as packages like NumPy or Pandas are referred to as libraries because they encompass multiple subpackages.


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.

1 Like