30 December, 2012

Functionality stuffed into procedures...


The funny thing about "functional programming" to me is that when you compartmentalize the structure of your code in any language and do it very well...you will naturally embrace a modular paradigm that combines functional and procedural pockets.

In OO code for example, you often write procedural chunks inside atomic methods which you then invoke in a functional way against the method that one writes the code in and attaches to a given class. This is at the class programming stage.

The functional aspect to the development of OO code then comes into place when the client programmers then take the created classes and put their methods and external program attributes together to create a highly (hopefully) function frame work for the solution of a general problem scope for the  given problem at hand.

For example, if you want to write a class that allows you to perform a transformation of a geometrical object of the screen, you'd first create functional encapsulated representations of the "how to draw any object" , "how to draw *this* object" and "how to move any object" and "how to move *this* object"  problems.

Once encoded into the necessary classes you are then just invoking functionally those procedural bits of code against an input data set that represents the desired object.

Object.move(fromlocation,tolocation);

or the operation can be functionally independent of the object, like:

Move(object,fromlocation,tolocation);

Ones choice of design in solving the functional problems described previously will constrain which approach of the two above is most useful in the functional domain. For example....if a general decoupling of what it means to "Move" can be made for all objects in a given draw space (say rectangular grid of pixels) then the second form makes sense for all types of geometries that "object" can define.

One the other hand if "move" is contextually polymorphic against the type of "object" then the first form above is more appropriate. It's the developers art to know which one would be most useful to the client programmers uses BEFORE releasing this functionality to them. Hence underscoring the importance of UNIT TESTING to a) test out the solution scope spans a large enough region of the problem scope . b) does it efficiently (not with spaghetti or non performant solution) c) does not harbor any execution pathologies that may be fatal (race conditions induced by concurrency bugs or by bad data values).

Programming...nay Engineering is part Art and part Science for this reason. It's FAR more than just knowing how to write an efficient sorting algorithm in programming language X or Y or Z....when dealing with code that runs on distributed systems (and often using different programming languages) a whole new world of architecture problems need to be confronted by the class programmer. One has to develop this vision for "the right" solution over time...it can't be taught in any rigorous text on how to solve problems in a given language.

A carpenter is not limited in most cases by the tools he has, his hammer and nails, his wood, saws and levels. He's limited by his ability to USE those tools to construct a gabled roof, or a triple level home or a patio deck. The tools are the mechanics, the Science of the profession of being a carpenter the knowledge of how to put them together to solve a given problem...well that's pure art.

I've covered aspects of these ideas in similar posts over the last few years:

http://sent2null.blogspot.com/2008/02/considerations-during-design.html

http://sent2null.blogspot.com/2008/04/avoiding-de-spaghettification-in-client.html

http://sent2null.blogspot.com/2008/04/another-bug-in-eternity-bin.html

No comments: