C compilers have .C files and modern pascal compilers have units or modules. These are essential plugin units or plugin files at compile time. i.e. standard pascal didn't have these and this is why it is not (or should not be) used today for very serious work.

A good IDE has a plugin system which is modular. Components can be added to the IDE. Even Emacs/Vim have plugin systems.

This is all modular programming. It does not have to be implemented through objects, but it can. This is the important distinction to make and study. I.e. modular design is more important, because it is a lower level idea to learn than OOP. It is a more important lower level idea to learn. Not lower level as in assembly code, but lower level as in education and base knowledge before becoming an excellent programmer.

Objects are not gospel nor are they holy cows (thanks Wojtek for these phrases). Objects are useful, and they can be used in modular programming. But modular programming is more important. It is the ground to breed objects if you want, but you don't have to. An object can be in a module, but a module also doesn't have to OOP inside it. Nesting modules into OOP and OOP into modules can sometimes over complicate architectures where just a module is needed.

Many operating systems are extremely modular. An executable such as ELF, EXE, a.out are all modules. Operating systems are based on modular design.

Analogy

Whether USB, headphones, or speakers are implemented in assembly code, functional code, Object oriented code, binary, ASCII, doesn't really matter. If the headphones break, you unplug them and plug another pair in. The headphones are easy to debug. They are a module. They are a plugin.

Modular Cells

Dead Cell

Although I do not agree with Java Engineer Guy Steele about only objects being the true way to the future, I agree with his statements about GROWTH and why Standard Pascal failed, along with APL and other "hard to extend" languages. A language where no one can feel part of the community and extend it.. is a failed language. Steele has a video that you should see.. just don't pay attention to his Object obsession. Pay attention to the part where he discusses what a language needs to succeed... room for growth, community for growth.

Lifelike Stupidity

Sex is based on plug-in technology, and therefore is more life like than OOP, but I won't get into that in too gross details. Someone will just bring up children and inheritance, as the result of sex. But if sex is more important than the children, since the act of sex is required to obtain children, isn't the plug-in (two humans plugging in to each other) more fundamental than the children? No one is saying plug-ins and children cannot be implemented using OOP.

Besides, computers are slaves, they are not life like at all. I tell my computer to do something, and it does it in a very un-life like manner. So let's stop all the "oop is lifelike" nonsense please. But since that is how everyone wants it, I will continue to make silly analogies like the MP3 player one so you get the hint about what MOP is all about.

Objects Required for Reuse?

Whether the amplifier is OO, functional, procedural, machine code, or even food based, doesn't effing matter - what matters is the plugin system and the communications between plugins (or modules).

Headphones aren't children of an MP3 player nor are they abstracted from an mp3 player. The headphones are just a plug-in, that is all.

MOP (modular oriented programming) is the fundamental knowledge and basis of a plugin system. OOP is only one choice of implementation for a plugin.

Best example of MOP: An operating system that runs EXEs or ELFs (executables). The executables talk to the operating system. This isn't OOP, this is modular oriented design. One does not have to recompile the operating system kernel to get a new program working.

HTTP protocol is the same. The sockets don't have to be OOP, nor does Morse code, or a telephone line.

Communication

All Objects Are Modular and Reusable?

I personally have looked through millions of lines of code and seen several software applications that could not be extended without recompiling the whole application, even if it was object oriented - and I've seen several applications that have broken down and stopped functioning when one little thing was changed in the main source code.

Bugs can easily be introduced when the original source code has to be modified instead of a plugin being added.

Consider HTML templates versus hardcoding all the html into a binary program. The html templates are like plugins.

Consider INI files that allow a program to behave slightly differently without the program having to be recompiled. An INI file is actually just a modular plugin.

Consider a perfectly working application that can no longer be compiled because compiler version 3.X.X is no longer available for download. If it had a plugin system there would be no problem - some compiler issue doesn't cause the day to end for you - since the plugin could be compiled with a different compiler.

I have also found it extremely hard to debug large applications that are compiled from one source base, yet I've found it easy to debug small plug-ins that just plug into a main application. Whether a program is modular or not does not depend on whether it is object oriented or not! Whether a program is reusable and maintainable or not does not depend solely on objects!

Not All Architectures Require Plugin

(Side note: by the way, although the MP3 player may have embedded software that is written in assembly code not geared toward modular plugins, it kind of does have a plugin technology on it. The MP3 files it reads are modular at run time. You can load new MP3 files onto the player. You can add headphones on to the player. Imagine if you had to recompile the MP3 player and remelt the plastic each time you wanted to add some more music onto the player?

This has nothing to do with inheritance or abstraction. You should be able to see that OOP isn't always life like, and this is one analogy to use when thinking about modules and plug-ins. The MP3 player may have a chip in it that has been embedded with assembly code or machine code - it doesn't have to be OOP objects connecting to other OOP Objects.

The MP3 player can connect to other assembly code implementations (USB to USB), other OOP implementations (programs that connect through USB using objects or not, doesn't matter), other simple blackbox hardware devices without any code like headphones and speakers.

You can't abstract a headphone set to be a large speaker system in real life. Speakers and headphones are two different plug-ins that you have to buy for your mp3 player, and they are very different things. They just happen to have a cord that can plug in to the same jack. They do have in common magnets and paper, albeit completely different sized magnets and paper. They are two different things though.

Plug-ins are more life like than OOP, because people buy plug ins for their widgets at stores each day! Developers don't have time for abstracting their headphone set into a speaker set - most developers go to the store and buy the speaker plugin and buy the headphone plug in. Got me?

Developers have time to go and download plug ins from someone else's web site that work at run time, but they don't have time to recompile and remelt the plastic to get their MP3 player working (along with casting, putting screws in, soldering, etc). Buying some headphones for your mp3 player does not mean recompiling your mp3 player, it just means plugging the headphones into the submini jack at run time. You can even unplug the headphones and plug in a stereo speaker set or an amplifier into the submini jack.

So who said OOP was life like in all cases? I know for sure plug-ins are sometimes life like.. and even if they are, this doesn't automagically make plug in programming the holy grail in every case.

What it takes to be a Modular Oriented Programmer

My philosophy is that one plug-in should do something well and in some cases one program should do something well. Sometimes one program has to do many things - such as a file manager. A file manager does not just copy files - it deletes files too. But if you start making the file manager a text editor - this text editor should be an optional plug-in and not compiled into the file manager itself.

Unix folks would go mad if they saw you creating a text editor out of your file manager - because one program is supposed to do something well. But for those cases where you do need your file manager to also be a text editor (take Total Commander for instance which can view files, or Midnight Commander) then a run time plug-in is a much better solution than a compiled-in solution.

Plug-ins or single programs that do one thing well, are easier to debug than huge monolithic swiss army knives.

We all write shitty code some times

OOP <> Modular and OOP != Modular

Unix Philosophy - the missing link

Run time plug-ins bring back some of the UNIX philosophy that one program does something well. This UNIX philosophy became somewhat flawed as computers hosted much larger hard drives and more memory - but still not 100 percent flawed - because as an application becomes larger and larger (a swiss multiknife) it becomes harder to maintain! So how do we solve the problem? Create plug-ins - each plug-in does something well, and can piggy back itself on to a main program.

Advantages of modular design

Large applications become like operating systems - they must be modular. You don't install linux or windows with FIXED compiled in applications! You install plug-ins, ELF files or EXE files, or scripts on top of your operating system. These ELF and EXE files and scripts can all be uninstalled from your operating system. The same must be done with large applications such as IDE's, File Managers, Web Browsers. Modularization is the future, not OO! Modularization can be done with or without OO, and if a modular plug-in happens to be written in OO, that is just coincidence. It isn't mandatory.

Prioritize Modular Oriented Programming over Object Oriented Programming... PLEASE!

Can a database be used separately from a web program? Yes. Therefore a database is reusable and modular. Can an INI or CONFIG file be used separately from a program? Yes, therefore it is reusable and modular. Can a template be reused separately from a program that uses the template? Yes. The template is reusable and modular.

Reuse and modularization are demonstrated when one module can be uninstalled and reinstalled without ruining the main system. Many object oriented programs offer absolutely no easy we to separate or uninstall one object or function or procedure from the program.

Examples of our desperate need for run time modules

Some users wish to download additional extensions from the internet that can plug into their application, and the user should not have to recompile the application since the user doesn't have version XYZ of ABC compiler.

Many programs today have hard-coded and compiled in "objects" and "components" which cannot be unloaded at run time (i.e. delphi components, vb components, visual C++ files, etc).

Many programmers are simply too lazy to write good API's for run time plug in systems on large projects in the middle stages. After the project becomes large in middle stages of development (say 2-3 years of development) the developer continue to compile in more and more components or abstracted objects into the application.

Since humans are not perfect, all these compiled in components and source files contain many undiscovered bugs. If these compiled in components were instead modularized into plug-ins, the bugs would be much easier to trace. The typical delphi/vb developer for example will download some prewritten component from a package available on the internet (say JEDI) that will magically fix their application and add hundreds of new features, and solve all their world problems in 10 seconds.. These lazy folks compile in the magical draggy droppy clicky dicky components, and continue to add more and more. Each of these compiled in components have bugs in them (even good coders create hundreds of bugs), and each of these compiled in components may not work in 6 months down the road when the IDE changes its component system (say Delphi 3 to Delphi 5, or multiple developers using diferent IDE's or different languages).

Each time the program gets a new feature it must be recompiled and reshipped to hundreds or thousands of users. If a bug is found in one component, the whole application needs to be shipped rather than just the component.

The application has grown bigger than a giant bean stalk, has more bugs than an ant hill, and has lost its reputation.

I could go on and on about the disadvantages of this silly "object oriented RAD" approach folks are using today. RAD and compile time OOP abstraction is fine for small projects.

Some think: just enable Packages in your IDE?

This isn't a compiler thing or an IDE thing. It is a developer thing, a discipline thing, and API thing, an engineering thing.

We have the package systems which magically are supposed to create run time packages for us, such as Borlands run time checkbox that turns all compile time components in to BPL style DLL's (or Visual Basic's equivalent, or Lazarus LPK system).

Above LPK/BPL/VB "compile to run time magic" checkbox doesn't solve our problem - it just puts the components into DLL's and makes them look like modules. But they aren't modular design using LoadPackage and UnLoadPackage. The dynamic plugins would need to be engineered.

The computer saves memory if more than one application is using the same DLL, but that is really all. This compile to run time package magic implemented at the compiler level doesn't magically create "modular" programs where one can ship components separately from the main application.

No IDE can create a good run time API for a developer magically. Some manual intervention and a well thought out plug in API needs to be created. It isn't as simple as just going into an IDE dialog window and clicking "create run time packages" I'm afraid.

The compiler can definitely help in making the plugins easier to develop though. For example it is a real pain in the butt to have to maintain Import and Export declarations when utilizing DLL/SO libraries on unix/windows.

In the plugin:

  procedure PluginProc1; stdcall;
  procedure PluginProc2; stdcall;
  procedure PluginProc3; stdcall;

  var  PluginProc1: procedure; stdcall;
  var  PluginProc2: procedure; stdcall;
  var  PluginProc3: procedure; stdcall;
begin
  PluginProc1:= LoadLibrary('plugin.dll', 'PluginProc1');
  if PluginProc1 = nil then writeln('whole bunch of error crap');
  PluginProc2:= LoadLibrary('plugin.dll', 'PluginProc2');
  if PluginProc2 = nil then writeln('whole bunch of error crap');
  PluginProc3:= LoadLibrary('plugin.dll', 'PluginProc3');
  if PluginProc3 = nil then writeln('whole bunch of error crap');
end.

So the compiler package system helps us there. But the compiler package system does not teach people the fundamentals of why modular oriented programming is important. Most of the open source lazarus/fpc crowd completely misses the point of packages, for example. They always comeback with the same line:

  Packages and plugins are useless when the source code is open! Just recompile
  your program with the modifications that you need to make, and we'll ship the
  program with source code changes.

MySQL database is missing a feature? No problem, just change the MySQL source code on your local hard drive since it is released under the GPL. And tell MySQL to patch the sources and release a new version of MySQL! MySQL missing a feature that Oracle has? Implement it on your hard drive and submit it to the MySQL team! It's that simple.

If I want to modify a program it is very hard to modify the actual source code without introducing new bugs. Now a database like mysql does not need a plugin system and that was a bad analogy. But programs like text editors, file managers, lazarus, and an IDE need plugin systems. Plugin systems allow the program to be changed without the risk of new bugs, because if there are any new bugs you simply say goodbye to the plugin.

Debugging DLL/DSO is hard

What this means is that if a plug-in is written with shitty code, you can simply uninstall the plugin in a split second.

No plugin system available? You're screwed. You cannot modify and recompile and hack the original source code in a split second. You have to sift through the sources and step all over someone else's code.

The task of changing the original source code of the program to add a feature to the program is like recompiling the kernel of your operating system to add a new program onto your OS. Fortunately, operating system developers have a clue. Each time you add a new program to your OS you don't have to recompile the kernel and the operating system.

Modularization isn't new

If a database or a plug-in can be detached from a program and accessed separately from some other program, this is a form of modularization - not object orientation. Knowing about modularization and how to use it is much more important than the specific rules or ideas of object orientation. Schools should be teaching Modular Oriented Programming, not Object Oriented Programming.

One can implement a Module with object oriented code if they want - this is why modular oriented programming is more essential to know than object oriented programming. Modular oriented programming is ground knowledge or base knowledge. How you implement the modularization can vary. A database can be modular from a program without the database being an object or an inherited class.

Monolithic Compilation Process and One True Paradigm?

It's especially excellent if you can install external modules, plug-ins, or extensions without embracing one true paradigm, since everyone has different paradigms they love (except me, who doesn't love any paradigm - I'm a hybrid guy). MOP is not a "true one and pure" way to compile a program, or interpret a program. MOP is simply a philosophy or discovery to use with any sort of programming language or programming system. MOP allows people to install modules written in any paradigm, even assembly or machine code if they want.

Do all languages have modular run time capabilities?

In the case of plug-ins, some languages may not be able to create modules such as DLL's, and if this is the case sockets communication or piping may need to be used. In fact the internet is very modular, since each time the internet changes we do not have to recompile the whole internet or reinterpret the whole internet. If one website breaks on the internet, it doesn't bring the entire internet crashing down - other websites and servers are still alive. This has nothing to do with OOP and everything to do with modular oriented programming or modular oriented design. I hate to over use acronyms but you could call it MOP and MOD if you like.

MOP over OOP?

MOP is not a completely different way of thinking and it is not a cult or religion. In fact MOP has been used for years - people just haven't coined a phrase to describe MOP yet.

MOP can be seen in history.

• Operating systems are modular.
• a database is modular from the program that connects to it.
• the internet is modular
• sockets communication and clients and servers are modular

The reason I came up with the term "modular oriented" is so that we have a term or phrase to address and point out this pattern in programming or this design style in programming.

If we see an applicaiton that is developed in a modular manner, we may try and say "that is a good design like an operating system that uses several executable programs that can be compiled separately, and that is a good design like the internet where if one site crashes the whole internet doesn't come crashing down". However, instead of trying to say that each time, it is easier to call this MOD or MOP since it is shorter and much easier. Once people have a definition of MOD and MOP, we can use MOD and MOP so that our lives are easier. I've tried to explain to people that well designed large programs are like the internet or like an operating system kernel - but it is too hard to explain to people each time. Phrases or terminology such as MOP and MOD are just short-form ways of describing a situation or pattern.

Modular programming isn't always easy

>In sum, operating systems have ALWAYS been OO up to a point, and the
>ideas for progressing beyond that point are ones that are coming INTO
>and not OUT OF the OO community.

Before OO was hip, we called this "modular programming" and it
was a sign of competence, not trendiness.

Operating systems tend to be modular if they are designed by
anyone with any kind of a clue. Yes, an operating system can be said
to be "object oriented", but let's not be any more faddish than we have
to be. 

Bob Frankston of Microsoft was speaking at a conference..

"Bob provided a variety of observations and insights into the construction of large, complex software systems. he started with several caveats; he didn't claim that they were actually implementing anything, and he wasn't sure what the relationship will be between what he described and what will actually get built.

Bob observed that operating systems (like databases) were developed as solutions to specific problems. People discovered that they were doing the same thing over and over, solving the same problems and coding up similar solutions to them. THe result was a body of code that dealt with these common cases.

Bob also pointed out that the only reason that the web works is that the internet is unreliable. If the internet were as reliable as a LAN, applications (such as the web) that were built on top of it would become too brittle, and a single failure would bring the whole thing crashing down. But because everyone expects failure in the internet, there are very few real dependencies. Different pages may point to each other, but they are, in fact, independent of each other.

Moving on the the construction of large systems, Bob posited that programs, especially large ones, shouldn't be written. Instead, the should evolve. As a metaphor for this process, he described the process of adding small bits of code to a system as being like throwing small balls at a larger collection of similar balls the represent the system being modified. Ideally, we would like these balls to be covered with velcro, so that they stick together easily. Unfortunately, with most current software, the balls are like oranges. Throwing one orange at a pile of oranges is likely to send oranges flying all over the room.

Bob claimed that object-oriented programming is the not the silver bullet that will solve this problem. The problem with OOPS is that once an interface is designed it becomes very difficult to change it. This makes it difficult to evolve large systems."

Modular Languages

But there is one problem. ComponentPascal is not the tool to use for web programming, unix programming, or even MS Windows programming.. as it lacks any real world tools to implement web programs, unix programs, and distributable applications. You can ship the environment with your app, but it is a pain in the ass and really isn't viable. It reminds me of Smalltalk's "squeak" where people try and peddle you into their "environment". Smalltalk isn't popular either.. any reasons? Hmm.

Modular programming is a concept and a practice.. one does not need to use ComponentPascal or Modula or Ruby Modules in order to practice modular programming. ComponentPascal also has one serious problem - CAPS LOCK reserved words such as BEGIN and END, along with verbose Ada style

PROCEDURE TheProcedure
BEGIN 
END TheProcedure; // hideous for many short procedures

Language Missing?

Lars has decided to implement modular programming practices into real world tools, languages, and utilties - such as fpc and delphi, powtils, and IDE's like PowDev. I also implement modular programming practices and engineering into the Qompute language. I also push for and make public statements about modular programming.. encouraging Borland/Codegear and FPC and other language designers to implement Unit Aliases and other modular programming concepts (unit aliases allow easier swapping of units, and is not available in FPC/Delphi right now, but has been available in ComponentPascal and is really handy).

It's nice to see that Ruby has Modules (and not just objects or source files) too. Namespaces are a hackish attempt at modular programming too.. and can be used to emulate modules.

Modular languages like ComponentPascal are just languages to learn from - and corporations or open source teams with real world products must study it for the learning experience, if not the real world usage experience.