Apply Functional Programming Principles - Revision history

Egarson at 04:26, 27 August 2009

2009-08-27T04:26:31Z

←Older revision		Revision as of 04:26, 27 August 2009
Line 5:		Line 5:
	Referential transparency is a very desirable property: it implies that functions consistently yield the same results, given the same input, irrespective of where and when they are invoked. That is, side effects from mutable state have a diminished impact on function evaluation (ideally none!).		Referential transparency is a very desirable property: it implies that functions consistently yield the same results, given the same input, irrespective of where and when they are invoked. That is, side effects from mutable state have a diminished impact on function evaluation (ideally none!).

-	A leading cause of defects in imperative code is attributable to mutable variables: everyone reading this ~~(except perhaps my mom)~~ will have investigated why some value is not as expected in a particular circumstance. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability.	+	A leading cause of defects in imperative code is attributable to mutable variables: everyone reading this will have investigated why some value is not as expected in a particular circumstance. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability.

	And we certainly don't get much help from industry in this regard: introductions to object-orientation (for one) tacitly promote such design, because they often show examples composed of graphs of relatively long-lived objects that happily call mutators on each other, which can be dangerous. However, with good test-driven design (particularly when astutely employing a mock object framework[2]), inordinate mutability can be designed away: object graphs become composed largely of ''immutable objects'', i.e. having readonly/final instance variables (in C#/Java-speak), and constructors become a means with which to perform one-time object initialization. (An interesting emergent property is that instance variables can be made public - gasp! - as the protection afforded by accessors becomes moot: the member is immutable!). The net result is a design that typically yields more numerous, smaller classes (thus better cohesion) and more numerous, smaller functions that act on arguments passed into them, rather than to reference mutable member variables; all of which adds up to a '''much higher degree''' of referential transparency. And, positively nothing will get these ideas as deeply into your bones as to learn a functional programming language, where this model of computation is the norm.		And we certainly don't get much help from industry in this regard: introductions to object-orientation (for one) tacitly promote such design, because they often show examples composed of graphs of relatively long-lived objects that happily call mutators on each other, which can be dangerous. However, with good test-driven design (particularly when astutely employing a mock object framework[2]), inordinate mutability can be designed away: object graphs become composed largely of ''immutable objects'', i.e. having readonly/final instance variables (in C#/Java-speak), and constructors become a means with which to perform one-time object initialization. (An interesting emergent property is that instance variables can be made public - gasp! - as the protection afforded by accessors becomes moot: the member is immutable!). The net result is a design that typically yields more numerous, smaller classes (thus better cohesion) and more numerous, smaller functions that act on arguments passed into them, rather than to reference mutable member variables; all of which adds up to a '''much higher degree''' of referential transparency. And, positively nothing will get these ideas as deeply into your bones as to learn a functional programming language, where this model of computation is the norm.

Egarson at 04:25, 27 August 2009

2009-08-27T04:25:20Z

←Older revision		Revision as of 04:25, 27 August 2009
Line 14:		Line 14:

	----		----
-	[1] - Sutter, H. 2005. "The ~~free lunch is over~~: A ~~fundamental turn toward concurrency~~ in ~~software,~~" Dr. Dobb's Journal, http://www.gotw.ca/publications/concurrency-ddj.htm	+	[1] - Sutter, H. 2005. "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software", Dr. Dobb's Journal, http://www.gotw.ca/publications/concurrency-ddj.htm

-	[2] - Freeman S, Pryce N, Mackinnon T, Walnes J. "Mock Roles, not Objects" - http://www.jmock.org/oopsla2004.pdf	+	[2] - Freeman S, Pryce N, Mackinnon T, Walnes J. 2004. "Mock Roles, not Objects", OOPSLA 2004, http://www.jmock.org/oopsla2004.pdf

	By [[Edward Garson]]		By [[Edward Garson]]

Egarson at 04:23, 27 August 2009

2009-08-27T04:23:04Z

←Older revision		Revision as of 04:23, 27 August 2009
Line 15:		Line 15:
	----		----
	[1] - Sutter, H. 2005. "The free lunch is over: A fundamental turn toward concurrency in software," Dr. Dobb's Journal, http://www.gotw.ca/publications/concurrency-ddj.htm		[1] - Sutter, H. 2005. "The free lunch is over: A fundamental turn toward concurrency in software," Dr. Dobb's Journal, http://www.gotw.ca/publications/concurrency-ddj.htm
		+
	[2] - Freeman S, Pryce N, Mackinnon T, Walnes J. "Mock Roles, not Objects" - http://www.jmock.org/oopsla2004.pdf		[2] - Freeman S, Pryce N, Mackinnon T, Walnes J. "Mock Roles, not Objects" - http://www.jmock.org/oopsla2004.pdf

Egarson at 04:22, 27 August 2009

2009-08-27T04:22:43Z

←Older revision		Revision as of 04:22, 27 August 2009
Line 7:		Line 7:
	A leading cause of defects in imperative code is attributable to mutable variables: everyone reading this (except perhaps my mom) will have investigated why some value is not as expected in a particular circumstance. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability.		A leading cause of defects in imperative code is attributable to mutable variables: everyone reading this (except perhaps my mom) will have investigated why some value is not as expected in a particular circumstance. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability.

-	And we certainly don't get much help from industry in this regard: introductions to object-orientation (for one) tacitly promote such design, because they often show examples composed of graphs of relatively long-lived objects that happily call mutators on each other, which can be dangerous. However, with good test-driven design (particularly when astutely employing a mock object framework[2]), inordinate mutability can be designed away: object graphs become composed largely of ''immutable objects'', i.e. having readonly/final instance variables (in C#/Java-speak), and constructors become a means with which to perform one-time object initialization~~[3]~~. (An interesting emergent property is that instance variables can be made public - gasp! - as the protection afforded by accessors becomes moot: the member is immutable!). The net result is a design that typically yields more numerous, smaller classes (thus better cohesion) and more numerous, smaller functions that act on arguments passed into them, rather than to reference mutable member variables; all of which adds up to a '''much higher degree''' of referential transparency. And, positively nothing will get these ideas as deeply into your bones as to learn a functional programming language, where this model of computation is the norm.	+	And we certainly don't get much help from industry in this regard: introductions to object-orientation (for one) tacitly promote such design, because they often show examples composed of graphs of relatively long-lived objects that happily call mutators on each other, which can be dangerous. However, with good test-driven design (particularly when astutely employing a mock object framework[2]), inordinate mutability can be designed away: object graphs become composed largely of ''immutable objects'', i.e. having readonly/final instance variables (in C#/Java-speak), and constructors become a means with which to perform one-time object initialization. (An interesting emergent property is that instance variables can be made public - gasp! - as the protection afforded by accessors becomes moot: the member is immutable!). The net result is a design that typically yields more numerous, smaller classes (thus better cohesion) and more numerous, smaller functions that act on arguments passed into them, rather than to reference mutable member variables; all of which adds up to a '''much higher degree''' of referential transparency. And, positively nothing will get these ideas as deeply into your bones as to learn a functional programming language, where this model of computation is the norm.

	Of course, there are caveats to this approach in some contexts; for one, many virtual machine implementations become inefficient when required to manage multitudinous small objects: pragmatism still applies. In object oriented systems, this style often yields better results with domain models (i.e. collaborations and complex business rules) than with server-side processing.		Of course, there are caveats to this approach in some contexts; for one, many virtual machine implementations become inefficient when required to manage multitudinous small objects: pragmatism still applies. In object oriented systems, this style often yields better results with domain models (i.e. collaborations and complex business rules) than with server-side processing.
Line 14:		Line 14:

	----		----
-		+	[1] - Sutter, H. 2005. "The free lunch is over: A fundamental turn toward concurrency in software," Dr. Dobb's Journal, http://www.gotw.ca/publications/concurrency-ddj.htm
-	[1] - "The ~~Free Lunch~~ is ~~Over~~" - ~~DDJ, Herb Sutter~~	+	[2] - Freeman S, Pryce N, Mackinnon T, Walnes J. "Mock Roles, not Objects" - http://www.jmock.org/oopsla2004.pdf
-		+
-	[2] - "Mock Roles, ~~Not~~ Objects" - ~~Freeman et al~~	+
-		+
-	~~[3] - Another spin on Resource acquisition is initialization?~~	+

	By [[Edward Garson]]		By [[Edward Garson]]

Egarson at 04:14, 27 August 2009

2009-08-27T04:14:57Z

←Older revision		Revision as of 04:14, 27 August 2009
Line 1:		Line 1:
-	''N.B. This is still a work in progress: any and all comments and suggestions will be warmly received.''
-
-	----
-
	Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because ''emergent properties'' of the functional paradigm foster a pre-disposition for it to better address the challenges posed by our industry's shift toward multi-core[1]. However, while that is certainly an important application, it is not the reason this piece admonishes you to ''know thy functional programming''.		Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because ''emergent properties'' of the functional paradigm foster a pre-disposition for it to better address the challenges posed by our industry's shift toward multi-core[1]. However, while that is certainly an important application, it is not the reason this piece admonishes you to ''know thy functional programming''.

Line 24:		Line 20:

	[3] - Another spin on Resource acquisition is initialization?		[3] - Another spin on Resource acquisition is initialization?
		+
		+	By [[Edward Garson]]
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+	Back to the [[97 Things Every Programmer Should Know]] home page

Egarson: New page: ''N.B. This is still a work in progress: any and all comments and suggestions will be warmly received.'' ---- Functional programming has recently enjoyed renewed interest from the mainst...

2009-08-27T04:08:34Z

New page: ''N.B. This is still a work in progress: any and all comments and suggestions will be warmly received.'' ---- Functional programming has recently enjoyed renewed interest from the mainst...

New page

''N.B. This is still a work in progress: any and all comments and suggestions will be warmly received.''

----

Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because ''emergent properties'' of the functional paradigm foster a pre-disposition for it to better address the challenges posed by our industry's shift toward multi-core[1]. However, while that is certainly an important application, it is not the reason this piece admonishes you to ''know thy functional programming''.

Mastery of the functional programming paradigm can greatly augment the quality of the code you write in other contexts, because if you deeply understand and apply the functional paradigm, your designs will exhibit a much greater degree of ''referential transparency''.

Referential transparency is a very desirable property: it implies that functions consistently yield the same results, given the same input, irrespective of where and when they are invoked. That is, side effects from mutable state have a diminished impact on function evaluation (ideally none!).

A leading cause of defects in imperative code is attributable to mutable variables: everyone reading this (except perhaps my mom) will have investigated why some value is not as expected in a particular circumstance. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability.

And we certainly don't get much help from industry in this regard: introductions to object-orientation (for one) tacitly promote such design, because they often show examples composed of graphs of relatively long-lived objects that happily call mutators on each other, which can be dangerous. However, with good test-driven design (particularly when astutely employing a mock object framework[2]), inordinate mutability can be designed away: object graphs become composed largely of ''immutable objects'', i.e. having readonly/final instance variables (in C#/Java-speak), and constructors become a means with which to perform one-time object initialization[3]. (An interesting emergent property is that instance variables can be made public - gasp! - as the protection afforded by accessors becomes moot: the member is immutable!). The net result is a design that typically yields more numerous, smaller classes (thus better cohesion) and more numerous, smaller functions that act on arguments passed into them, rather than to reference mutable member variables; all of which adds up to a '''much higher degree''' of referential transparency. And, positively nothing will get these ideas as deeply into your bones as to learn a functional programming language, where this model of computation is the norm.

Of course, there are caveats to this approach in some contexts; for one, many virtual machine implementations become inefficient when required to manage multitudinous small objects: pragmatism still applies. In object oriented systems, this style often yields better results with domain models (i.e. collaborations and complex business rules) than with server-side processing.

Nevertheless, you should master the functional programming paradigm and apply these principles in other domains: you will find that your object systems (for one) are much closer to their functional counterparts than many would have you believe. In fact, some experts assert that the apex of functional programming and object orientatation are '''merely a reflection of each other''', a form of computational yin and yang.

----

[1] - "The Free Lunch is Over" - DDJ, Herb Sutter

[2] - "Mock Roles, Not Objects" - Freeman et al

[3] - Another spin on *Resource acquisition is initialization*?