#modular oriented programming

Modular Oriented Programming and Communications

I would describe Modular Oriented Programming as programming with the intent on having reusable and interchangeable compiled code. The term used to describe their design is “Loose Coupling”. Modules interacting with other modules is a communications problem. Its Machine-to-Machine communication.

Language allows us to communicate with complete strangers or people we’ve never met. The same situation exists with modules. Modules are meant to be designed by different developers. Hence, when working with modules, there will be a lot of foreign code. The term “foreign code” is a term I use to describe code that is completely outside of your control. Code that was given to you but you had no part in its design. This means that there needs to be a set of agreements that you can rely on, that allows you to use foreign code safely and efficiently. Such set of agreements is a language. People might use the term protocol or standard but I like to use the term language. This is code interacting with other code. The term language implies flexibility and interoperability. The terms protocol and standard imply rigidity, restrain or limitation.

Modules can be represented graphically. Exhibit A is a graphical representation of two modules. The tentacles and spikes coming out of them are called end-points. These are the inputs and outputs of a module. End-points used for input are receivers (abbreviated RX). End-points used for output are transmitters (abbreviated TX). Modules work with each other by connecting these end-points. Hence no programming is necessary. All an application developer needs to do is connect these end-points together.

To enable modules to work together we have to agree on the data that comes out of the transmitters. Lets look at exhibit B. We have two aspects of data that we have to look into. Data format and data semantics. Lets look at an integer. Data format would be the integer is 32bits or 64bits. Big endian or little endian. Data semantics is basically what does this integer represent. It could be temperature, length, age, strength, voltage, etc. Modules can be blindly connected together by matching data formats but matching data semantics is also necessary. Because this is where hacks and bugs come into play. Say that a receiver accepts an integer and expects it to represent temperature. There has to be an upper and lower limit. Its theoretically impossible to have temperatures lower then -273 degrees Celsius. But hackers will attempt to hack and try to send temperatures lower then -273 to the receiving module.

When you are in control of both the transmitters and receivers you don’t have to formally define data semantics because you know how your code will behave. If its behaviour is to your satisfaction then everything is fine. BUT when you are dealing with foreign code you will have to worry about data semantics. You will want a set of agreements and expectations about the nature of the data you are getting from foreign code.

Exhibit C. I propose that we start standardizing machine-to-machine vocabulary. Basically we need to develop a worldwide dictionary of data semantics. Hence when you publish your modules you can declare that they conform to specs such and such. And everyone who understands that spec can work with your modules. As a note: SavageGardens will concern itself with machine vocabulary.

Modular Oriented Programming and DevOps

The idea is as follows.

If you were an application developer, you would go into a market place and shop for parts. For example (see figure above). You would get some buttons, an LCD display, a back panel and a control circuit. Then you would wire the components together to create an application. Even thou you would be a software developer you would not need to do any programming what so ever. For example the calculator can be put together with a simple bash script or even simpler. An XML file.

This is possible with Modular Oriented Programming. It would change DevOps for software developers to operate similar to the automobile industry. The engine is made in one country. The tires in another. The dashboards and bumpers in another and so on. All the automobile manufacturers really focus on is the outter body. The chassis that glues all the parts together.

Software DevOps would have three distinct industries:

1. - Module developer focused on a specific situation or problem.

2. - Application developer who brings together different modules and creates an application

Modular Oriented Programming (MOP) is a natural progression upwards from Object Oriented Programming (OOP). I would describe MOP as writing code with the intent on having reusable and interchangeable compiled code. Note the emphasis on compiled code. A module is basically an object stored as a DLL (or dynamically linked library).

Its not a new thing. The earliest example I can think of is with Microsoft’s ActiveX components on the browser. ActiveX was introduced almost 30 years ago but it failed. I ask why? From what I recall its because it was difficult to use. I would say it was difficult to use because Microsoft did not understand or had a vague idea about communications.

What ended up happening was that at the time Sun Microsystems had JAVA. Netscape worked with them and brought in JavaScript to the browser. The combo where able to keep Microsoft off balance long enough. Microsoft did develop a technology called dot-net but by that time it was too late.

Anyways, this post is to promote MOP (Modular Oriented Programming). Because its a rather powerful concept. I am approaching it from a communications point of view because I believe in doing so we would understand how to make better use of it.

In a development environment, importing libraries is easy and straight forward. ActiveX was easy to use inside VisualBasic or Delphi. Inside a browser however, ActiveX was outside its element and did not inherit that ease of use. Hence it failed. This situation is about communications because its about presumptions. Inside a development environment, a developer is free to make certain presumptions. In VisualBasic all you had to do was drag and drop an ActiveX component and you where free to presume your code inherited new capabilities. This level of support was not available inside a browser. To make ActiveX work inside a browser you had to do a lot of things manually. Hence ActiveX was difficult.

It turns out the success of good communication has a lot to do with making valid presumptions. When we talk to someone we presume they understand. When the presumptions are valid, that's when the magic happens. When you learn JavaScript you are learning the rules of the trade. You are learning about valid presumptions you will be able to make with your code. Hence, when you use the import statement you are under the impression that your code will magically inherit new capabilities. These rules of the trade is language. JavaScript is a language. A language basically represents a set of rules and agreements. These rules and agreements allow for presumptions. These presumptions allow us to talk to someone without worrying about the details. ActiveX failed because a developer could not rely on a set of presumptions that would allow him to use it easily and quickly.

see also: (1) about the mind and presumptions

I say if Microsoft had a better understanding of communications, they could have had their way in the mid 90s. It is very much possible for compiled code to talk to other compiled code comfortably and safely if communications between the code entities is standardized. Some people would bring the term protocol. I don’t like that term because its gives off vibes of being rigid and limited. I would prefer to use the term language because of flexibility.

Some other date I will post about machine-to-machine communication for a better understanding on how modules would talk to each other with ease.