Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional calisthenics

codurance.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Functional calisthenics

#11

Post by nextos »

maxxxxx wrote: post #2

Isn'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…

sinx(x) can be still object-oriented. Actually, really neat object oriented systems which implement multiple dispatch, like CLOS, tend to use this notation.

Re: Functional calisthenics

#12

Post by MiyamotoAkira »

maxxxxx wrote: post #2

Isn'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…

Author here. A few have mentioned already, but this is to practice, to force you to understand what FP brings to the table, and lead you in path of discovery. When it comes to production code, you apply what you have learned, and make the decisions that you think more convenient. As an example, if you want certain performance gains on F# you do go to mutable state (Phil Trelford did a talk about it). Doesn't matter how pretty/OO/pure is the code if your application doesn't do what is supposed to ;-)

Re: Functional calisthenics

#13

Post by michaelg7x »

munificent wrote: post #8
maxxxxx wrote: post #2

Isn'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…

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.

Re: Functional calisthenics

#14

Post by MiyamotoAkira »

CJefferson wrote: post #7

I don't understand "no explicit recursion". How do you do any kind of binary tree search without recursion?

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 has an ecletic knowdledge of FP and hybrid languages: Clojure, Haskel, Elixir, Scala, F#, ...). Can that binary search tree be converted into a linear search if you rearrange the tree into a list? Yes. Now you can use map /reduce. Is it performant? Most probably not. Are there other ways? Time to discover. Interestingly, most of the katas/exercises on which we are practicing these rules are not heavily algorithmic in nature. Maybe we do need to add some to understand better and modify the "rules" with the new knowledge.

Re: Functional calisthenics

#15

Post by danidiaz »

CJefferson wrote: post #7

I don't understand "no explicit recursion". How do you do any kind of binary tree search without recursion?

Here is an answer in the CS Theory Stack Exchange that explains how: https://cstheory.stackexchange.com/a/18399/13730 (I'm not endorsing it as a practical way of doing it, mind you.)

The idea is that the only explicit recursion is contained in generic combinators "fold_result" and "unfold_result" that are "boring" in the sense that they can be derived mechanically from the "resultF" data type and do not actually know about the binary search; they just do recursion.

In practice, folds and unfolds tend to be more useful for other things.

Re: Functional calisthenics

#16

Post by MiyamotoAkira »

danidiaz wrote: post #15
CJefferson wrote: post #7

I don't understand "no explicit recursion". How do you do any kind of binary tree search without recursion?

Here is an answer in the CS Theory Stack Exchange that explains how: https://cstheory.stackexchange.com/a/18399/13730 (I'm not endorsing it as a practical way of doing it, mind you.) The idea is that the only explicit recursion is contained in generic combinators "fold_result" and "unfold_result" that are "boring" in the sense that they can be derived mechanically from the "resultF" data type and do not actually know…

In fact, a colleague that is reading SICP at the moment is the one that basically put the idea forward, as he was going through the whole idea of fold/map/unfold on the book exercises

Re: Functional calisthenics

#17

Post by maxxxxx »

MiyamotoAkira wrote: post #12
maxxxxx wrote: post #2

Isn'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…

Author here. A few have mentioned already, but this is to practice, to force you to understand what FP brings to the table, and lead you in path of discovery. When it comes to production code, you apply what you have learned, and make the decisions that you think more convenient. As an example, if you want certain performance gains on F# you do go to mutable state (Phil Trelford did a talk about it). Doesn't matter h…

Cool. I commend you for having a team that is willing to practice new things for fun. That's pretty rare.

Re: Functional calisthenics

#18

Post by maxxxxx »

michaelg7x wrote: post #13
munificent wrote: post #8

Earlier quoted context omitted.

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…

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.

In C# you can have static classes. I often use these to group simple functions together.

Re: Functional calisthenics

#19

Post by derefr »

munificent wrote: post #8
maxxxxx wrote: post #2

Isn'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…

You know, you're talking about a very specific kind of OOP here. Elixir, for example, is a language I'd call OOP—but it doesn't have classes. It just has "bare functions" in modules, where a module's functions will usually expect values of the type the module is named after.

Also, to reverse that perspective, a "type" in Erlang/Elixir-lang is just any data formatted in a way that a given set of functions will work with it, rather than requiring an explicit tag. {1, 2} can be an instance of a type†, if you have a module Foo that spits that shape of data in response to Foo.new/0 and takes it for Foo.change/1.

† An example of such a type is Erlang's http://erlang.org/doc/man/queue.html . queue:new/0 just returns {[], []}.

Re: Functional calisthenics

#20

Post by Veen »

derefr wrote: post #19
munificent wrote: post #8

Earlier quoted context omitted.

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…

You know, you're talking about a very specific kind of OOP here. Elixir, for example, is a language I'd call OOP—but it doesn't have classes. It just has "bare functions" in modules, where a module's functions will usually expect values of the type the module is named after. Also, to reverse that perspective, a "type" in Erlang/Elixir-lang is just any data formatted in a way that a given set of functions will work wi…

The actor model that Elixir/Erlang is OOP in its "purest" form, but that's not what most people mean when they discuss OOP languages.
Post reply on HN