>>57
Hi, after filtering out your buttrage, I extracted from your post:
"If the compiler can prove that g is pure, then it can optimize a = g(...); if(n < 3) a = f(...); to if(n < 3) a = h(...); else a = g(...)".
That's a nice and easy optimization (assuming the compiler can prove that the function is pure, which reduces to the halting problem in general, but should be easy in most cases), but I prefer to see it clearly in the code. It helps me reason about the efficiency of the program, and it helps me think about what value is actually inside of a. But, to each their own. I'll keep using it, you can choose to not use it. I don't think you have stated why you hate it though. You just say that it is shit, but the only negative thing that you've said about it is that it is unnecessary.
>>61
tail recursive calls to nested functions can be pretty self documenting representations of state change, and control transfer, and they generalize modifications to local variables. Take a step on the wild side, and code in a functional language. Modifications to local variables is not where functional languages limit you, but using immutable data structures can be painful when mutable arrays and hash tables are more suitable. Most functional languages support these though. So all I'm seeing is a failure on your part to learn a different representation for a universal technique, where you are already familiar with a different representation for the technique. If you only want to get things done, then that is fine, but if you want to discuss the trade offs of different paradigms, then you should be open to learning other things, and other ways of doing things.