views:

380

answers:

7

I admit I haven't grokked F# yet. But in the 30,000 foot descriptions, they keep talking about easy to test code that doesn't have mutable state. Is that the same as static methods?

Could I get the benefit of F# by writing some of my code in classes with all static methods?

I'm just looking for the short answer, I know whole books exist on the topic.

+3  A: 

No, it's not the same as static methods. You don't have mutable state if you don't assign anything (locals, function arguments, static fields, instance fields) after it was initialized. You can get some of the benefits by designing your classes to be immutable.

Anton Tykhyy
+7  A: 

Absolutely no, immutability has nothing to do with methods being static or instance. String, being an immutable class, has plenty of instance methods, which, in a very functional manner, return a new instance of String class, rather than modifying anything.

You could try to emulate F# by using functional decomposition, but this will still be pretty imperative code.

Anton Gogolev
Hmm, that leads to another question, which I will now ask on S.O. as well-- what is functional decomposition?
MatthewMartin
It's all very simple: http://en.wikipedia.org/wiki/Decomposition_(computer_science)
Anton Gogolev
That just says using functions made of functions (etc) is a good design. Is that a feature of functional programming or do they just happen to both have function in the name?
MatthewMartin
http://stackoverflow.com/questions/947874/what-is-functional-decomposition
Rob Kam
+2  A: 

No, the two concepts are unrelated. Static methods in C# can still modify incoming objects as normal, and other variables using ref or out.

Jeromy Irvine
+7  A: 

You could certainly write C# code immutably, but that's nothing to do with static functions. Immutability are things like having a struct or object that only "changes state" by making a copy of itself and having the copy be different.

Adam Luter
+4  A: 

Apart from static, functional modules versus objects, you can attempt to get some of the benefits of F# by using C# 3 and lambdas, LINQ, etc. However, that doesn't go very far. What I find nice in F# is:

  • Inference everywhere
  • Auto-generalization (adds in type parameters so I don't have to sort it out manually)
  • Easy immutability
  • Easy mix between module and classes
  • Types like discriminated unions
  • Pattern matching
  • Nested functions (lightweight)
  • First class functions (no, C#'s named delegates don't count)
  • Everything's an expression
  • Easy function composition

So, you can try to do some of this in C#. Some of it is simply not supported and won't work. The rest gets very ugly, very fast.

So, if you go much off the beaten path of LINQ and the Enumerable extensions, you'll probably end up in a world of pain.

MichaelGG
+3  A: 

I beg to differ with all the other answers to date. Immutability and static methods may not be strictly technically related, but I have found that using F# has encouraged me to make C# methods static whenever I can.

The thinking is analogue, in that it is easier to handle an immutable object because you don't have to worry about it changing state. In the same way, you don't have to worry about state when using a static method (unless you use a global singleton or something...).

Benjol
I'm unclear why you'd want static to represent immutability.For example, why would you want: x = String.gsub( y, 'a', 'b' ) instead of x = y.gsub( 'a', 'b' ).It seems that more frequently you'd still have an actor, so you'd want a regular function.Static functions are usually when there is no clear actor, such as String.cmp( x, y ) which seems no worse than x.cmp( y ) .There are of course exception situations as you mention.
Adam Luter
The whole question is, "Can I trust this method to do what I expect?". If your method is *truly* functional, it's result will be solely a function of the arguments, and not of some other 'external' state that it references. In which case you can perform tests based solely on arguments and consider your method trustworthy. In this sense, even within a non-static class, if I can reasonably make a method static, I will do so.
Benjol
+1  A: 

IT's true. You aren't going to get the benefits of functional programming just by using more static functions in C#. Howver, if you were to look under the hood (using Reflector, for example) I understand a simple let statement is a static function. In other words,

//F#
let a = 2

is like a function in C#

//C#
static int a()
{
    return 2;
}

I can understand the confusion.

Explanation pulled from Leon Bambrick's "F# Eye for the C# Guy presentation."

Ben Griswold