Modular Oriented Programming is far more essential, and important, than just Object Oriented Programming. Modular oriented programming is communicating two plug-ins or modules together, at run time or compile time. MOP is fundamental knowledge, it is not a true pure and one paradigm or a specific implementation.
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.
Buying some headphones for your mp3 player doesn't mean recompiling your mp3 player (soldering, melting the plastic, molding it), it just means plugging the headphones into the sub-mini jack at run time (or before turning it on, to avoid sparks). And after you plug in the headphones, it just works - there isn't any abstraction, inheritance, or other bull shit that we need to know about - we just need to know that the MP3 player is modular enough to use speakers, headphones, or even USB.
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.
Humans, have cells - thousands - which are all modules. Modules are essential for any large sized project. For if your cell dies, it is replaced with another and is not a big deal. A cell can die on the human skin without a human noticing. It is replaced promptly, i.e. swapped with a newly grown one.
Standard Pascal lacked modules - and it died for a good reason. It was not prepared for growth by modules - it was only prepared for growth by adding another procedure to the end of the program.
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.
People always want to relate programming to life, and supposedly OOP is more life like. Fine then. Let's talk about how plug-ins relate to life.
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?
MOP is more important than OOP, since MOP doesn't rely on OOP. MOP can be implemented by connecting an application to a database, or connecting an mp3 player to headphones, or connecting a female body to a male body, or connecting an assembly coded application to an OO application. The headphones or the database or the human body could be OO, but don't have to be OO. More importantly is a plug-in system that works at run time. If I want to change the way someone's MP3 player sounds, I change or update the speakers, and I plug in an amplifier, and I plug in an equalizer. You see, they are all plug-ins.
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.
In my opinion, the communication between plug-ins us more powerful than object orientation itself. Plug-ins are not monolithic - they are individual smaller modules that connect to other modules.
All Objects Are Modular and Reusable?
Object orientation is not very modular at all in many cases. Just ask anyone who maintains large applications without any plug-in system, and they will tell you it is one big giant monolithic beast that is hard to maintain - hence, run time plug-ins are the future for large applications, not OO itself. If the plug-in happens to be OO, that is just coincidence. In fact, this is not just my opinion - this is what I've studied and ate for breakfast for the past 7 years.
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
Of course things like Compilers and Real Time embedded systems sometimes don't need a modular design. There are some cases where modularizing code into run time plug-ins doesn't suit the job. The embedded software chip that an MP3 player uses to play MP3's is an example of when run time modularization is not needed. But the jacks on the Mp3 are modular. Most of us however are not building MP3 players or airplane controller software - most of us spend our time building software applications and websites that become monolithic beasts all chained together with a bunch of code - well actually websites don't become huge monolithic beasts in all cases, and web programming can teach us a lesson about modularization. More on that much further below, if you continue reading.
(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
We don't remain UNIX zealots and continue to develop one program for each problem - we sometimes develop one program for each problem, and we sometimes develop one plug-in for one problem.
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
Let's pretend that you create a plug-in for a web development IDE. This plug-in is written horribly with absolute shit code. That's fine - because you can uninstall the plugin. If the absolute shit code was compiled in to the IDE itself, the entire IDE may crash and you cannot uninstall that shitty code. You uninstall the entire IDE and never use it again, instead of just uninstalling the plugin that is at fault. Think about that for a minute. Why should your IDE break down because of some crappy code some twit wrote (especially on open source projects where unskilled developers contribute code). Therefore plugin architectures are important in open source!
OOP <> Modular and OOP != Modular
OO does not automatically equal modular. Whether one uses OO or not to build modular systems doesn't matter so much as people think. In fact OO can have a negative influence on modularization if folks take OO too far - as many parts of the program can break and come crashing down if there is an error in one object upline or up river. I'd rather use a good modular designed IDE even if it was written using no OO if it was better than the OO alternative. The point is to be a Modular Oriented Programmer (MOP) and not an Object Oriented Programmer (OOP). I realize that OO code can be designed so that it is modular - and I'm not against OO - I'm just against the idea that all OO code is modular. Most of it isn't - it just appears to be since you can claim you are reusing and inheriting other objects - which is all fine and dandy but I reuse my database columns and rows each day too, and I reuse several websites each day too.
Unix Philosophy - the missing link
For those folks out there who have liked the idea or notion of Unix philosophy where one program does something well, I think you will find it easy to migrate your thinking into a little bit of an extended philosophy. Modular design - one program does one thing well, and one plug-in does one thing well. In some cases modular design can be done by using multiple programs that pipe together (unix has been doing this for eons) but in other cases plug-ins that are stored in libraries are more fit for the situation.
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
The biggest advantage of modular design is that you can uninstall shitty code. If someone writes a shitty plugin you simply uninstall it. In a monolithic compiled OO system many people still think that their design is modular - because they can inherit and add new objects, piggy back on to other objects, etc. But true modular design has got nothing to do with compiled in objects - true modular design is all about run time installation/uninstallation of plugins. If someone writes a shitty piece of code, I want to be able to uninstall it at run time.
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
An example of a plug-in that could be a run time module rather than simply an "abstracted object" would be an FTP connection window for a html editor, or an advanced search dialog for an editor. Some people have absolutely no need for FTP in editor programs, while others do. Some people have no need for extremely advanced search features, while others do. Some people want to write their own search window with their own special features such as special wildcards or custom search algorithms.
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?
And other's think.. "everything will be solved once the compiler supports packages".
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;
In the host program:
var PluginProc1: procedure; stdcall;
var PluginProc2: procedure; stdcall;
var PluginProc3: procedure; stdcall;
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');
Having to constantly match up the host program VAR/TYPE declarations with the plugin's procedure declarations is a pain in the ass.
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.
That's like saying:
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.
People are too Lazy To Do That, and this is too Hard For People to do.
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
The idea that plugins are hard to debug (because DLL/DSO can't be traced as easily) is also a red herring. Why is this something we shouldn't worry about? Because we can uninstally the plugins/bugs at run time and find out what small plugin is causing the problem! One single small plugin is easier to locate and find problems with than trying to debug a huge monolithically compiled program, even if this monolithic huge program has a good debugger available!
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
Take the database, for example.
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?
The days of compiling huge programs are over. Imagine if you had to recompile a text editor or IDE program each time you wanted to add a Tools menu item into the program? Tools menu programs can usually pipe back information to the text editor or IDE, and you can uninstall the Tools at run time. Recompiling the entire host program (the one with ability to set up external tools) just to add a new external tool to your tools menu would be an example of non-MOP style programming. It doesn't matter whether or not the external tools are written in functional, procedural, assembly, or object oriented code - what matters is if you can install external tools in a modular manner at run time.
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?
Many languages focus on compile time or interpret time modularization.. such as source files being split up into several files instead of all the source being in one file. Other languages focus on source packages. This is compile time modularization but it isn't the holy grail since we need run time modularization. Even if source files are split up and even if you can use one class that taps into another class, it still doesn't mean that I can install and uninstall a tool at run time without breaking the entire program if there is an error.
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?
Many OO programmers tend to think of OOP as a completely different way of thinking. OO programmers tend to say and think "once you do OOP you will never go back to that other stuff you were using.". Skeptical of the hype?
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.
Please realize that MOP is not some "radical new way of designing programs". Just realize that MOP has been used for years - start to recognize where it has been used and where it can be used.
- 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
Slapping a quick program together that does one thing well can be easy at first - extending it to be modular can be hard. Programming isn't easy. Modular programming takes some discipline but offers rewards. For example if you design your system to be one huge compiled system, it may be easy to start out with - but when you get bugs in your system it will be hard to recompile the whole piece of software each time if you didn't modularize it. It takes discipline to create a modular system, but once the modular API is in place, it becomes an easier to maintain system and a more robust system. If there is an error in someone's module, you can uninstall it and tell them to fix it - rather than the main program breaking down and leaving you stranded.
Nice items I found many months after writing this article:
>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
Objects are not Holy Cows? This man, Wojtek, sums it up nicely.
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."
There are actually people out there on this planet who are reading my mind, or vice versa. I like Wojtek's statements a lot. "Objects are not gospel".
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
END TheProcedure; // hideous for many short procedures
Modular programming involves many small procedures.. therefore this hideous BEGIN END TheProcedure duplication just kills the language. I know it is a syntax issue and people can work with it.. but another problem with ComponentPascal is that it doesn't even have a plan for Unix/Linux/BSD, nor can the ComponentPascal IDE create console programs. Ridiculous. Academics. Quiche eaters. Useless for the real world. Not even any database libraries out there.
So ComponentPascal is out. Can't use it, shouldn't use it. Nice learning experience but no good for the real world. Sorry Niklaus Wirth, and sorry Oberon Microsystems. No offense. So what is the plan for real world modular programming?
Modular programming has been used for eons.. modularizing your database, modularizing your exe from the operating system, etc. But as for my tasks?
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.