Popular posts

Jason Knight True, for recustion to be really useful in replacing loops, you need to be able to be sure that tail call optimization happens. There should at least be an annotation or something that breaks the build if tail call optimization was not done. Otherwise a trivial algorithm suddenly overflows the stack.

(In the strict sense, 'side effects' are any effects other than computing return values, so not IO, or changing global state, etc. Since in many functional languages everything is immutable it's easier to do. In JS you'd have changing of arguments or changing outer values from closures. Guess we've come a long way from 'out'-parameters in Fortran).

@Jason: Just an FYI about Side effects. In general, a function is supposed to do only what it is intended to do. Technically, a function should behave the same everytime you invoke it for a set of function parameters. The usual victim is the state of an object being modified based on implicit criteria unknown to the caller of the function. This is where Immutablilty comes into picture as an approach to prevent object modification.

There are something called as Pure functions which operates solely on the parameters passed to that function but no other data. People often confuse Pure functions as the only of writing Functional programming and clutter the code with unnecessary amount of functions.

Vishwa Bhat That's the part I don't get -- to me thats a desirable behavior; they're passed by reference for a reason so LET me change the values. Otherwise why would I be passing it?

@Jason: Exactly. You pass an object reference as a function parameter and that function modifies a property of an object. This approach might lead to a side effect unless the function actually defines that modification.

For ex:

You have an object order which has a property grossAmount and a property totalAmount whose value is grossAmount x taxPercentage. Basically, totalAmount should be in sync with grossAmount all the time. Now, suppose your teammate being unaware of the above relation, writes a function validateOrderItems(order) where he finds an anomaly in grossAmount and hence modifies it. No one wouldn't expect this behavior by looking at the name of the function. This leads to a side effect. While testing the code, your test validating totalAmount would always fail.

So, the way to avoid the above situation across the team is to make the function paramters Unmodifiable or Immutable so that the function is forced to return new grossAmount value instead of changing it within itself. Currently, we are passing around primitive data types as function parameters to avoid this as they're Immutable by default but this has a con - hard to test when no of parameters increase more than two which forces us to pass around objects (this leads to above mentioned side effect). This is where FP enforces Immutablity on any parameter being passed to a function regardless of the type, be it primitive or an object.

Excuse the brevity, hard to explain it on phone.

Vishwa Bhat So it's EXACTLY what I thought -- what's being called a "side effect" is the behavior I automatically EXPECT and even WANT from passing an object to a function.

Leaving me still scratching my head as to why it's called a side effect or why it is bad; much less how making it immutable (aka basically having to either make another copy in an interpreted language, or add the overhead of checks in an interpreted language, at least with compiled you can just not allow it) is going to result in any of the claims of said programming technique being true.

Much like the claims of frameworks being "easier" (which is most always BS in my experience) I don't "get" how this methodology actually does anything but ADD overhead and make things harder to do, harder to follow, harder to understand, etc, etc, etc.

Vishwa Bhat a reference IS as sideffect and does not lead to one.

Jason Knight OOP and FP can have the same compiled code. Because compiler optimizations and substitutions. For example -> tail recursive functions will get translated to a normal loop without calling the stack over and over again.

The overhead you mention is a true fact but it's easier to argue about state, which as the application grows and gets more distributed has it's advantages.