This week there seems to be quite a bit of video and audio content to share.  We have a dramatic depiction of the benefits of Units of Measure, Luke Hoban on F#’s feature, Ted Neward talks about F# under the hood and finally a discussion on operator type inference.

 

Video Blog – Could F# have saved the Mars Climate Orbiter?

A fantastic example of how static dimensional analysis of scalar values could prevent an entire class of bugs.   In the past, I’ve talked about what a huge fan I am of the Units of Measure package for F#.  I’m glad that others also see how revolutionary units of measure are. 

Would you want to work in a building or live in a house in which the engineers who built it did not keep track of units?  I don’t think anyone would answer yes.  Similarly, we should not entrust our lives or livelihoods to software in which these very same things are not kept track of.

 

Podcast – SER Episode 129 - F# with Luke Hoban

In this podcast Luke Hoban, the F# program manager, discusses about various aspects of F#. 

Some highlights:

• Mutability comes along with .NET Framework support.
• Statically Typed means strong guarantees and so robust systems.
• FP design in the small for concurrency
• OO design in the large for scalability
• Explorative programming via interactive window
• Influenced heavily by Haskell
• FP as a technique, not a class of languages

 

Video Blog – dnrTV Show #136: Ted Neward Introduces F#

Ted Neward gives an in-depth presentation on both how F# works under the hood and the general benefits that stem from FP in general.  The examples used are simple but Ted covers them in a very exhaustive way.

Beyond the language and concepts therein, he also has a number of insightful comments about teaching people to use F#.  In particular the idea that F# syntax will be easy to teach but functional programming technique will take years really struck home with me. 

 

Blog – Kalani Thielen’s The F# overload-o-phone

In his post Kalani points out a small but significant logical inconsistency in F#’s type inference system.  The issue seems to stem from the way type inference is handled for basic operators.  Instead of working generically, they each have default types.

From his post:

> (+);;
val it : (int -> int -> int)
> 3.2 + 5.4;;
val it : float = 8.6
> let twice x = x + x;;
> twice 9.4;;
stdin(2,5): error FS0001: This expression has type
    float but is here used with type int.

To get around this, he then goes on to build a function which takes an operator and both arguments.  However, this workaround is completely unnecessary.  You need only to annotate the function’s input and it works without issue.

> let twice (x: double) = x + x
val twice : double –> double
> twice 9.4;;
val it : double = 18.8

Now, it’s important to note that this version of the twice function won’t accept an integer.  In fact, it was a conscious design decision to disallow function overloading in F#.  In both F# and C# all kinds of overloading must be qualified by type.  That is, type methods support argument overloading but free floating functions do not.

This post is in response to Joe Armstrong’s Why OO Sucks.  While I feel that Joe’s post reads more like an sermon than a stream of rational thought, it does bring up a number of misconceptions I feel many people in the functional programming world share and which need to be discussed openly if it and the object oriented world are to come to terms and work together.

The main issue here is that, in the minds of many functional programming advocates, the concept of an object is inseparable from the amalgamation of 30 years of different, and sometimes contradictory, object oriented programming ideologies. 

Perhaps they don’t understand that when binding these ideas together for the sake of argument they are simply constructing a straw man.  Similarly, to say that we must either have all of the history of object oriented design or pure functional programming, is a false dichotomy.  We can have either, neither, both separately, or any number of combinations of ideas from both groups.

 

Now, lets address each of Joe’s objections from a somewhat more moderate perspective.

In Response to “Objection 1 – Data Structure and functions should not be bound together.”

I disagree with Joe’s logic here.  It does not follow that because functions and data structures are “different animals” that they should “not be kept in the same cage”.  Wouldn’t having functions be first class citizens be locking them in the same cage with data structures as well?  The fact that they do share some fundamental similarity is manifest in that most functional programming languages do not treat function and data structure in a fundamentally different way. 

Also, I have seen no compelling reason as to why it is wrong to couple transformations with the data structure that they are able to be applied to.  When transformations often have to be tailored specifically for a particular data structure, why would we not keep them strongly associated with said data structure.

 

In Response to “Objection 2 – Everything has to be an object.”

As I discussed in my introduction, this is simply not true in all languages which support objects.

 

In Response to “Objection 3 – In an OOPL data type definition are spread out all over the place.”

First of all, it should be immediately obvious to anyone who works on even medium sized projects that having many types defined in the same file is a very bad thing.  The core of the issue is that it makes group collaboration quite difficult.

Secondly, any system that has ubiquitous data structures can’t be very large otherwise the namespace would become quite cluttered.  In large systems this cannot be mitigated by simply saying “more functions, fewer data structures”.

Finally, to state that any object which operates on another must inherit from it is a completely incorrect statement.  In the modern object oriented world it is common to have objects which exist solely to build, process or interface with other objects.  Also, as I mentioned above, it’s entirely possible to have stateless objects which are simply data structures which are bundled with a collection of predefined transformations.

 

In Response to “Objection 4 – Objects have private state.”

First of all, state is not the root of all evil.  While it may be harmful to concurrency and static analysis, there are many stateful algorithms which perform much better than their stateless counterparts.

Secondly, it’s entirely possible to have immutable objects.  Perhaps in these objects some state is hidden for the sake of representing ideas in a simple manner, perhaps not.

Finally, as to information hiding in general, in large systems it’s very easy to be overwhelmed by the quantity of information.  If you can say via testing “I can trust this structure over here” it means it’s entirely possible to ignore that and focus work on another piece of the system.  It’s also important to note that functional programming languages often have information hiding systems of their own.  In the most base case, calling other precompiled functions amounts to information hiding and comes along with all of the negative things stated in this section.

 

In Response to “Conclusion – Why OO was popular.”

It seems to me here that if you removed all instances of “It was thought” this would be a somewhat correct summarization. 

In reality, the industry has been using object oriented programming for many more reasons than what has been listed here.  A particularly strong reason is that it supplies an organizational framework for data structures and functions which simply does not have an equivalent in the pure functional programming world.

 

Conclusion

I must apologize to Joe here.  I don’t intend to pick on him in particular.  However, I had never previously seen a post in which the the most common misconceptions around object oriented programming were so plainly stated.

To say that the concept of an object and that the collections of ideologies used commonly to construct programs using objects are somehow inseparable is completely false.  To further state that the only reasonable choice is to instead move to pure functional programming bears no additional truth.  Yet they are both pieces of constantly perpetuated misinformation. 

The fundamental idea that data and function can be bound for the sake of organization still holds and does not inherently violate any of the tenants of functional programming.  In terms of the organizational structure of our programs we have gained much from objects.  Why then should we abandon them without sufficient reason?  It seems to me that it would be a mistake to dismiss all of what we have gained for baseless ideological reasons alone. 

This post is in response to Joe Armstrong’s Why OO Sucks.  While I feel that Joe’s post reads more like an sermon than a stream of rational thought, it does bring up a number of misconceptions I feel many people in the functional programming world share and which need to be discussed openly if it and the object oriented world are to come to terms and work together.

The main issue here is that, in the minds of many functional programming advocates, the concept of an object is inseparable from the amalgamation of 30 years of different, and sometimes contradictory, object oriented programming ideologies. 

Perhaps they don’t understand that when binding these ideas together for the sake of argument they are simply constructing a straw man.  Similarly, to say that we must either have all of the history of object oriented design or pure functional programming, is a false dichotomy.  We can have either, neither, both separately, or any number of combinations of ideas from both groups.

 

Now, lets address each of Joe’s objections from a somewhat more moderate perspective.

In Response to “Objection 1 – Data Structure and functions should not be bound together.”

I disagree with Joe’s logic here.  It does not follow that because functions and data structures are “different animals” that they should “not be kept in the same cage”.  Wouldn’t having functions be first class citizens be locking them in the same cage with data structures as well?  The fact that they do share some fundamental similarity is manifest in that most functional programming languages do not treat function and data structure in a fundamentally different way. 

Also, I have seen no compelling reason as to why it is wrong to couple transformations with the data structure that they are able to be applied to.  When transformations often have to be tailored specifically for a particular data structure, why would we not keep them strongly associated with said data structure.

 

In Response to “Objection 2 – Everything has to be an object.”

As I discussed in my introduction, this is simply not true in all languages which support objects.

 

In Response to “Objection 3 – In an OOPL data type definition are spread out all over the place.”

First of all, it should be immediately obvious to anyone who works on even medium sized projects that having many types defined in the same file is a very bad thing.  The core of the issue is that it makes group collaboration quite difficult.

Secondly, any system that has ubiquitous data structures can’t be very large otherwise the namespace would become quite cluttered.  In large systems this cannot be mitigated by simply saying “more functions, fewer data structures”.

Finally, to state that any object which operates on another must inherit from it is a completely incorrect statement.  In the modern object oriented world it is common to have objects which exist solely to build, process or interface with other objects.  Also, as I mentioned above, it’s entirely possible to have stateless objects which are simply data structures which are bundled with a collection of predefined transformations.

 

In Response to “Objection 4 – Objects have private state.”

First of all, state is not the root of all evil.  While it may be harmful to concurrency and static analysis, there are many stateful algorithms which perform much better than their stateless counterparts.

Secondly, it’s entirely possible to have immutable objects.  Perhaps in these objects some state is hidden for the sake of representing ideas in a simple manner, perhaps not.

Finally, as to information hiding in general, in large systems it’s very easy to be overwhelmed by the quantity of information.  If you can say via testing “I can trust this structure over here” it means it’s entirely possible to ignore that and focus work on another piece of the system.  It’s also important to note that functional programming languages often have information hiding systems of their own.  In the most base case, calling other precompiled functions amounts to information hiding and comes along with all of the negative things stated in this section.

 

In Response to “Conclusion – Why OO was popular.”

It seems to me here that if you removed all instances of “It was thought” this would be a somewhat correct summarization. 

In reality, the industry has been using object oriented programming for many more reasons than what has been listed here.  A particularly strong reason is that it supplies an organizational framework for data structures and functions which simply does not have an equivalent in the pure functional programming world.

 

Conclusion

I must apologize to Joe here.  I don’t intend to pick on him in particular.  However, I had never previously seen a post in which the the most common misconceptions around object oriented programming were so plainly stated.

To say that the concept of an object and that the collections of ideologies used commonly to construct programs using objects are somehow inseparable is completely false.  To further state that the only reasonable choice is to instead move to pure functional programming bears no additional truth.  Yet they are both pieces of constantly perpetuated misinformation. 

The fundamental idea that data and function can be bound for the sake of organization still holds and does not inherently violate any of the tenants of functional programming.  In terms of the organizational structure of our programs we have gained much from objects.  Why then should we abandon them without sufficient reason?  It seems to me that it would be a mistake to dismiss all of what we have gained for baseless ideological reasons alone. 

This week there seems to be quite a bit of video and audio content to share.  We have a dramatic depiction of the benefits of Units of Measure, Luke Hoban on F#’s feature, Ted Neward talks about F# under the hood and finally a discussion on operator type inference.

 

Video Blog – Could F# have saved the Mars Climate Orbiter?

A fantastic example of how static dimensional analysis of scalar values could prevent an entire class of bugs.   In the past, I’ve talked about what a huge fan I am of the Units of Measure package for F#.  I’m glad that others also see how revolutionary units of measure are. 

Would you want to work in a building or live in a house in which the engineers who built it did not keep track of units?  I don’t think anyone would answer yes.  Similarly, we should not entrust our lives or livelihoods to software in which these very same things are not kept track of.

 

Podcast – SER Episode 129 - F# with Luke Hoban

In this podcast Luke Hoban, the F# program manager, discusses about various aspects of F#. 

Some highlights:

• Mutability comes along with .NET Framework support.
• Statically Typed means strong guarantees and so robust systems.
• FP design in the small for concurrency
• OO design in the large for scalability
• Explorative programming via interactive window
• Influenced heavily by Haskell
• FP as a technique, not a class of languages

 

Video Blog – dnrTV Show #136: Ted Neward Introduces F#

Ted Neward gives an in-depth presentation on both how F# works under the hood and the general benefits that stem from FP in general.  The examples used are simple but Ted covers them in a very exhaustive way.

Beyond the language and concepts therein, he also has a number of insightful comments about teaching people to use F#.  In particular the idea that F# syntax will be easy to teach but functional programming technique will take years really struck home with me. 

 

Blog – Kalani Thielen’s The F# overload-o-phone

In his post Kalani points out a small but significant logical inconsistency in F#’s type inference system.  The issue seems to stem from the way type inference is handled for basic operators.  Instead of working generically, they each have default types.

From his post:

> (+);;
val it : (int -> int -> int)
> 3.2 + 5.4;;
val it : float = 8.6
> let twice x = x + x;;
> twice 9.4;;
stdin(2,5): error FS0001: This expression has type
    float but is here used with type int.

To get around this, he then goes on to build a function which takes an operator and both arguments.  However, this workaround is completely unnecessary.  You need only to annotate the function’s input and it works without issue.

> let twice (x: double) = x + x
val twice : double –> double
> twice 9.4;;
val it : double = 18.8

Now, it’s important to note that this version of the twice function won’t accept an integer.  In fact, it was a conscious design decision to disallow function overloading in F#.  In both F# and C# all kinds of overloading must be qualified by type.  That is, type methods support argument overloading but free floating functions do not.