I feel I should also comment on this too. OO design patterns are to a significant degree influenced by Parnas’ modular design principles. Those principles manifest themselves in OO as encapsulating state within the object, and providing a minimal set of methods on the object to interact with that state. That is related state and functionality is kept together (high cohesion) and the API is kept minimal (low coupling).
Even though Elm takes a different path to OO, I still think that Parnas’ modular design principles can find valid and useful expression in Elm. Elm provides 3 levels on which this can be explored; at the functional language level, at the module level and at the package level. The package level is the one that demands it the most, since each package really is a module of re-usable software.
It would be quite interesting to explore the idea of a retraining program from OO to Elm. First understand the principles of OO in the context of Parnas, then explore all the ways that Parnas can be expressed in Elm, and out of those, which ones lead to the most productive coding patterns that allow safe and better software to be written.
To me, Parnas is the master mental model that runs through everything I do that is related to computer software.