Question

I have two questions, stemming from observed behavior of C# static methods (which I may be misinterpretting):

First:
Would a recursive static method be tail call optimized in a sense by the way the static method is implemented under the covers?

Second:
Would it be equivalent to functional programming to write an entire application with static methods and no variables beyond local scope? I am wondering because I still haven’t wrapped my head around this “no side effects” term I keep hearing about functional programming..

Edit:
Let me mention, I do use and understand why and when to use static methods in the normal C# OO methodology, and I do understand tail call optimization will not be explicitly done to a recursive static method. That said, I understand tail call optimization to be an attempt at stopping the creation of a new stack frame with each pass, and I had at a couple points observed what appeared to be a static method executing within the frame of it’s calling method, though I may have misinterpreted my observation.

Answer 1

Would a recursive static method be tail call optimized in a sense by the way the static method is implemented under the covers?

Static methods have nothing to do with tail recursion optimization. All the rules equally apply to instance and static methods, but personally I would never rely on JIT optimizing away my tail calls. Moreover, C# compiler doesn’t emit tail call instruction but sometimes it is performed anyway. In short, you never know.

F# compiler supports tail recursion optimization and, when possible, compiles recursion to loops.
See more details on C# vs F# behavior in this question.

Would it be equivalent to functional programming to write an entire application with static methods and no variables beyond local scope?

It’s both no and yes.

Technically, nothing prevents you from calling Console.WriteLine from a static method (which is a static method itself!) which obviously has side-effects. Nothing also prevents you from writing a class (with instance methods) that does not change any state (i.e. instance methods don’t access instance fields). However from the design point of view, such methods don’t really make sense as instance methods, right?

If you Add an item to .NET Framework List<T> (which has side effects), you will modify its state.
If you append an item to an F# list, you will get another list, and the original will not be modified.

Note that append indeed is a static method on List module. Writing “transformation” methods in separate modules encourages side-effect free design, as no internal storage is available by definition, even if the language allows it (F# does, LISP doesn’t). However nothing really prevents you from writing a side-effect free non-static method.

Finally, if you want to grok functional language concepts, use one! It’s so much more natural to write F# modules that operate immutable F# data structures than imitate the same in C# with or without static methods.