Functional calisthenics
codurance.com
Functional calisthenics
1–10 of 37 posts
Re: Functional calisthenics
#2Isn'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 "pure"?
Re: Functional calisthenics
#3Isn'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…
I think it's more of an exercise than a stringent philosophy. Looking at these rules, they're designed to be helpful for cultivating functional habits and patterns of thought if you're not used to thinking and coding that way.
I wouldn't expect anyone to follow them religiously in production code.
Re: Functional calisthenics
#4Isn'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…
Nitpick, but why
m = new Math() s = m.sin(x)
x.sin
Besides this nitpick, i concur with Veen. The post seems to be about exercises/challenges, not FP best practices.
Re: Functional calisthenics
#5Isn'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…
Nitpick, but why m = new Math() s = m.sin(x) would be "the OOP way" instead of x.sin ? Besides this nitpick, i concur with Veen. The post seems to be about exercises/challenges, not FP best practices.
" x.sin "
Good point. I guess in C++ numbers aren't objects so you can't do this.
I hope they understand that this is just an exercise. I have seen too often these things being elevated into a religion.
Re: Functional calisthenics
#6Earlier quoted context omitted.
Nitpick, but why m = new Math() s = m.sin(x) would be "the OOP way" instead of x.sin ? Besides this nitpick, i concur with Veen. The post seems to be about exercises/challenges, not FP best practices.
" x.sin " Good point. I guess in C++ numbers aren't objects so you can't do this. I hope they understand that this is just an exercise. I have seen too often these things being elevated into a religion.
> 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)).
Re: Functional calisthenics
#7I don't understand "no explicit recursion". How do you do any kind of binary tree search without recursion?
Re: Functional calisthenics
#8Isn'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.
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 belongs to?" In real code, of course, the answer is often "no". But when first learning OOP, it's good to teach yourself to ask that question in the first place.
Your code isn't a good example of "the OOP way", though. A fluent OOP solution would be:
s = x.sin()
Re: Functional calisthenics
#9Isn'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…
Nitpick, but why m = new Math() s = m.sin(x) would be "the OOP way" instead of x.sin ? Besides this nitpick, i concur with Veen. The post seems to be about exercises/challenges, not FP best practices.
it's probably doable as is in Smalltalk, the issue is OOP trying to ontologically categorize everything is impossible; one day we may need operations on numbers we don't know now and we'll have to "import CategoricalHomotopy as ch; ch.tropos(42)"
Re: Functional calisthenics
#10I don't understand "no explicit recursion". How do you do any kind of binary tree search without recursion?
This is in contrast with structural recursion. When you define a binary tree datatype you should get for free a generic fold operation on these trees, analogous to the map and reduce functions on lists. I don't know if Clojure gives you that.