Friday, November 09, 2012

Modular Paradigm

Welcome to my blog on my design decisions for my programming language. I haven't decided a name for it yet since most of the good ones are taken. ☺

Decision: To Use the Modular Paradigm.

Now that OO has been in use for a while, some of its flaws have become apparent. Which is why I chose the modular paradigm over OO. Some of my reasons are:

Which classes to use is not easily apparent.

Unless the app is simulating a model, the choice of which classes to create is fuzzy. I suppose this is common among all apps; if we knew how to do it, it's because we did something similar before. That means we could reuse the code and most of the work is already done. But in OO, there seems to be a reluctance to throw out classes. I think this is because, once completed, the developer has a hard time forgetting the class.

With modular design, on the other hand, there is seldom the sense that the module is complete. There is less reluctance to tinker with it. It may not be correct but that's easily changed.

Inheritance does not encourage code reuse.

In most projects, class inheritance forms a wide and shallow tree. Code reuse through inheritance is not common. In fact, if a class is not inherited and has only the root class for its ancestors, then it is no more than a module.

Objects have states.

This is the biggest reason I chose modular design; objects have states. The attributes of each objects are state variables. The problem with them is that the developer has to remember its value and the more classes with attributes, the more likely he won't remember. And when a developer doesn't remember, bugs appear.

Advantages of Modular Design.

Modules are name spaces.

Subroutines in modules need only have a unique name within its module. Different modules can reuse the same name.

Modules can be reused.

Reusing code is a result of good library practises. Modules lend themselves to this better than OO.

Modules less like to have state variables.

Modules are thought of a set of subroutines. Unlike OO, they do not insist on storage within them. They are less likely to have state variables.