Print

Code Watch: At the function junction, have you a compunction?



Larry O Brien
Email
October 11, 2011 —  (Page 1 of 3)
Writing code is the primary activity of software development. Writing the right code, code that delivers customer value, is the hard part. But right or wrong, the main thing that developers do is work in an editor, transforming inputs to outputs.

For more than a decade, most mainstream developers have done their work guided by the concepts of object orientation, which says that programs should be structured in a way that mirrors real-world objects. The fundamental concept of an "object" is a software module that combines the functions that operate on data and the data itself an object instance for a customer. For instance, it could store the data of a particular person's name, account number and so forth.

This is so ingrained that it may seem natural to those who have known no other way, but 25 years ago, it seemed an academic theory with dubious benefits. As an alternative to the behavior-oriented "structural programming" model and the data-oriented world of "fourth-generation languages," object orientation sometimes seemed like so much mumbo-jumbo, and other times it seemed like it was belaboring well-known principles.

But, over time, object orientation has become the norm. Its dominance is, in my opinion, as much a matter of happy coincidences as any inherent virtue; I utterly believe in the virtues of object orientation, but its uptake in the industry was largely driven by promises of code reuse that were never achieved, and an accidental association with GUI programming, which caused a wholesale reset of development techniques.

Today, we are in a similar situation with functional programming. It will not replace object-oriented programming in the way that OOP replaced structural programming; the concepts of "class" and "object" are clearly attractive for structuring software modules. Rather, functional programming techniques will become ever more common, and programming languages will evolve to have more and more functional features.

It's always easy to predict what has already happened; in truth, functional programming approaches have quietly become commonplace. I say "functional programming approaches" because what I'm talking about is not at all the "pure functional" theory-driven model. Rather, from a strictly pragmatic point of view, if you compare code written at the turn of the millennium with code written today, you'll see today's code has less internal state and more context-carrying arguments, and you'll see yesterday's code uses object-structural techniques where today’s developers would use first-class functions (that is, where an OOP developer might define a single-method interface to capture the idea of a sorting strategy, the functional programmer would simply pass around a particular function as the implementation).



Related Search Term(s): functions

Pages 1 2 3 


Share this link: http://sdt.bz/36003
 
Most Read  Latest News  Resources

close
NEXT ARTICLE
PostGIS 2.0 brings new vector functions to mapping data
Open-source geographic database based on PostgreSQL now works with Windows Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?