Mop Advocate

Renamed "mopMind" to MopAdvocate so it is less confusing (don't want to be mixed up with TopMind)

Note that this term shouldn't be confused with advocates for the MetaObjectProtocol...

Mop stands for modular oriented programming.

MopAdvocate doesn't consider all the information out there about Mop to be correct.. for example the wikipedia and this wiki contain false information about modular programming not being able to encapsulate and such nonsense. An example page:

HeInventedTheTerm

Some websites declare mop as some programming paradigm that some company developed or such things. I consider it more of a concept and an open idea to be discussed by modular experts.. not a specific technology as I once saw it described on wikipedia pages.

How is Mop distinct from ModularProgramming as defined on that page?

Does a mop advocate have a mop of uncontrollable hair that needs to be modularized?

"modular" is not very well defined yet, at least not in a consensus way. (Then again, some say that TableOrientedProgramming is not well-defined.)

True, this page will work on defining it, along with providing more references.

Modular programming is not as well defined as it could be an unfortunately a lot of pages on the internet are incomplete about it.

Examples of modular concepts is seen

an Exe/Elf/a.out where a module loads itself into an operating system (and reuses the OS api without it being recompiled into the kernel each time).
Oberon, Modula, and ComponentPascal's Module system, along with turbopascal's "unit" system

The dictionary's view on module:

"a detachable unit with a specific function"

In other words a module is a unit with specialization.

A moduel contains specific functions, procedures, variables, types. It organizes. One should try to segregate programs into modules instead of allowing the program to grow into a large monolithic beast. One should not obsess over perfect separation of modules, ,as sometimes it is hard to decide what exactly belongs in which module - but we can try hard to make extremely elegant compromises.

A module as in source files, can contain code that does or does not use OOP, meaning it is a lower level concept that OOP itself (and I think it is a more important concept to learn before going crazy with OOP since modules come first).

Minix shows signs of a more modular kernel.

Unix and Windows have always had a modular API to connect to and use.

Apache uses a module system.

Databases that are normalized are modularized into more relvars (tables) so the data can be queried (what is the data related to.. a module (relvar) that defines its relation!)

It seems almost any important large system today uses a form of modularization. It has been proven to work.

In really small systems such as an embedded MP3 player, modularization isn't needed in the software - but the mp3 player has modular files that can be deleted and copied without destroying the MP3 player. The MP3 player also has modular headphones that aren't permanently soldered into the MP3 player (hopefully).

Examples of Anti-Modularization

one gigantic Standard Pascal program thrown together in one file
one gigantic CeeLanguage program thrown together with dumb include files melted in place.
CeeLanguage has a problem underscores_used as fake module namespaces since include files and .C and .H files are poor forms of modules that carry somewhat of a global namespace mix matched together.
ErlangLanguage has the same problem as CeeLanguage

mopMind knows that normalizing tables (relvars) is a form of modularization. For example, consider we are selling widgets to a bunch of home owners. When we later need to query the data, the data is better modularized than crammed into some global huge wide table. When we modularize the data into tables or relvars that relate to the module in question (homes, widgets, people.. instead of big global wide table with all data in it), we can access or data, manage our data, and remain flexible and sane. It takes some work to modularize, but it is worth it when you need to access these modules sanely!

mopMind knows that creating more pages on a wiki and more sections (with horizontal rules) is much more sane than creating a long spanning ThreadMess. Pages should be kept well organized (modularized!) instead of globally humongous.

Not all classes or types belong in a separate file of their own. Nor does a procedure or function belong in its own separate file. That is what a module is for. Nor does one single object belong in one single file. (Although, if you wanted to, you could put one item in a module of its own). A module allows one to choose what goes in the module - sounds like common sense - but the computer industry lacks common sense!

Modules can never be perfectly separated and we must make compromises and tough decisions about what belongs in what module. Sound bad? Not really. What is the alternative? The alternative is worse: one huge module (a gigantic Standard Pascal program. Just say no.).

Similarly, in databases... what is worse: one big unqueryable unrelated table - or a few tables (modules) that are separated by what the data relates to? Can the modules still be viewed and used as one - sure. When one puts his modules in his import or uses section, he can utilize all those modules that he needs as if they were all available as one. Similarly, one can join several tables (relvars) together if he needs to - but the data is still stored modular form for sanity. The view of the modules can be different than how it is stored.

If a mopMind has a scatterbrain at birth - modularization is the cure. Modules utilizes modules to assist organizing his scatterbrain. All programmers are overwhelmed and scattered.

In a large complicated world, with only 24 hours in the day, a scatterbrain (verging A.D.D) must find a cure for his disease. The cure is modularization, obviously. Organize problems (and data) into modules - instead of attacking them all as one global program in one huge global namespace. Focus!