I came here expecting an article on CrossFit!
Functional calisthenics
31–37 of 37 posts
Re: Functional calisthenics
#32I wouldn't even call these things calisthenics. These are requirements for the programming style to be called "functional." Really if you aren't following Edit > Most Edit > of these rules you are not doing functional programming. The best way to learn about functional is not to follow these rules but to use a functional language that basically enforces these rules. Javascript is not a good language to learn about fu…
You are right. If you don't follow most of those rules, you are not doing pure FP. My interest on them was because I was writing production code that felt procedural. The rules are there so you can practice with purpose. Once you go into production code, you can discard them, but with knowledge that it will not be because your OOP skills take over, but conscious decisions.
Re: Functional calisthenics
#33Earlier quoted context omitted.
The people that talked about the rules at Codurance was none of the people that defined the original rules. We had to "reverse engineer" the thinking, find reasons and then discard, change or let as they were (one of the objectives of the write up was to put down those reasons). Explicit recursion did take a while. The reasoning we came with is to learn to use map/reduce functions (do take into account that our group…
If you want an example, consider writing a simple recursive sudoku solver, where at each location you fill in one empty square with the values 1-9, and reject early if you ever have a repeated value in a row, column or box. This is easy to write in C, and I always imagined would be something functional programming would excel at, but it doesn't seem to fit with your rules.
SOLD!!!!! I will have to add this to my kata collection. That also reminds me of the 8-queen problem. The last solution that I created (C#) years ago did use recursion.
Re: Functional calisthenics
#34Earlier quoted context omitted.
In Java static methods are a particularly simple way making clear to the compiler and runtime that a given functions does not have side effects (to instances of the owning class). I can imagine that, as a pattern, they would assist escape analysis.
A static method can of course mutate an object of the same class (give the object as an argument (direct or indirect) or use a static variable of the class) I can not see how they could be used to help escape analysis more than that you have one less reference (this).
Yes, of course that's possible. I was trying to point out their usefulness to the programmer as well as potentially to the runtime/JIT. Next time I'll list the obvious exceptions!
Re: Functional calisthenics
#35Isn't this going a little overboard? I remember when OOP came up, some people made functions illegal. So instead of s = sinx(x) the OOP way was m = new Math() s = m.sin(x) And instead of switch statements you had to derive a new class for each case call a virtual function. Very "OOP" but it led to the OOP equivalent of spaghetti code. Are the functional guys also starting to leave the real world for the sake of being…
No. Almost every functional language forces you to follow these "calisthenics." These look more like guidelines to follow if you want to execute the functional style in an imperative language.
I would say that only Haskell (and derivatives) force you to follow most of these rules. Neither Clojure, nor F#, nor Elixir force you into most.
Re: Functional calisthenics
#36Isn't this going a little overboard? I remember when OOP came up, some people made functions illegal. So instead of s = sinx(x) the OOP way was m = new Math() s = m.sin(x) And instead of switch statements you had to derive a new class for each case call a virtual function. Very "OOP" but it led to the OOP equivalent of spaghetti code. Are the functional guys also starting to leave the real world for the sake of being…
The article states: These rules are constraints on how to create your code and are only intended to be applied when doing katas or exercises. These rules are an exercise to kick you out of an OOP mindset, not best practices for writing real code. By that same token, I think it is a good rule when practicing OOP to not allow bare functions. It helps train yourself to think "Is there a logical class that this method be…
I don't think that no classes without state is a good hard and fast rule. In some languages classes are the easiest way to get a new namespace, and thus in combination with static methods they are useful in producing fluent APIs (which I believe are a good design choice). You could of course achieve the same result with modules but I'd argue it's cleaner to have an inline class than a separate file when you're only adding a couple of functions.
Re: Functional calisthenics
#37Earlier quoted context omitted.
> I have seen too often these things being elevated into a religion. Yeap. I have no hard preference between sin(x) or x.sin, in an OOP context or not, as long as the language is somewhat consistent (e.g., it bothers me that Ruby has some of these functions on the numbers themselves, like 1.23.floor, but others live on Math, like Math.sin(42)).
> it bothers me that Ruby has some of these functions on the numbers themselves, like 1.23.floor, but others live on Math, like Math.sin(42)). Every time I type `len(some_list)` in Python, I die a little inside.
While I agree to an extent, the reason for this is not entirely bad. The len function is basically a contract that the result you get will be an integer. An object could easily have a `.length` property that is non-integer, like a line/interval for instance. Think of this as a clunky response to a lack of type information in the language proper.