30 December, 2012
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.
or the operation can be functionally independent of the object, like:
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:
24 December, 2012
In a recent article:
"At $16,000 each, the Beam isn't cheap. But Suitable Technologies says it was designed with features that make "pilots" and "locals" feel the remote worker is physically in the room: powerful speakers, highly sensitive microphones and robust wireless connectivity. The company began shipping Beams last month, mostly to tech companies with widely dispersed engineering teams, officials said. "Being there in person is really complicated—commuting there, flying there, all the different ways people have to get there. Beam allows you to be there without all that hassle," said CEO Scott Hassan, beaming in from his office at Willow Garage in nearby Menlo Park."
-- My wager, and the reason I invented Action Oriented Workflow is that systems like this are simply continuing the inefficiency of the old paradigm of stateful work processes.
This is silly, $16,000 per unit to try and simulate a social element that for many workers is not required continuously. So the payment is made for a continuous system that is used in a discontinuous fashion. It's incredible waste.
Instead, much greater value I posit can be derived per worker by providing user opt in social tools, the video chat, the audio calls, the chat and mail interaction...and then letting the work related actions route around the workers where ever they happen to be...this is what Action Oriented Workflow makes possible. People opt in, do work, the system merits them objectively and sends work to them where ever they happen to be when they opt in. No one is pressured to be any where or do anything they didn't explicitly "raise their hand" to do.
I am betting that most companies will find far more value in implementing such a system because the focus is taken off of making social interaction easy for humans who may not want it (big problem) and puts the focus on making the work actions as hyper mobile and social (across the organization) as possible.
The analysis of tele present work forces was something I started devoting serious mind time too, nearly 7 years ago as I was in the midst of implementing the code for the Action Oriented Workflow. The future I saw then and have now made possible by building...involves minimal interactions in office environments which will increasingly be restricted to the agents in business that make critical deals for the entire organization. Pointed social interaction coupled with high value deriving agents will end up being much more efficient and useful than making social the goal and spending money to achieve it just for the sake of it without any knowledge as to why that would be most beneficial in a quantified manner.