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

21–30 of 37 posts

Re: Functional calisthenics

#21

Post by lederhosen »

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.

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).

Re: Functional calisthenics

#22

Post by dozzie »

epidemian wrote: post #4
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…

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.

> Nitpick, but why "m = new Math() s = m.sin(x)" would be "the OOP way" instead of "x.sin" ?

Because you can't do the latter post-hoc. You can't add hyperbolic functions by yourself if your standard library didn't anticipate them. Well, in Ruby you can and it's a standard practice to pollute this way classes at random, and in Python you can as well, though it's frowned upon, but certainly you cannot in C++ or Java.

Re: Functional calisthenics

#23

Post by CJefferson »

MiyamotoAkira wrote: post #14
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…

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.

Re: Functional calisthenics

#24

Post by munificent »

epidemian wrote: post #6
maxxxxx wrote: post #5

Earlier quoted context omitted.

" 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)).

> 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.

Re: Functional calisthenics

#25

Post by crimsonalucard »

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…

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.

Re: Functional calisthenics

#26

Post by crimsonalucard »

I 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 functional programming.

Re: Functional calisthenics

#27

Post by jw- »

crimsonalucard wrote: post #26

I 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…

I'm not really sure why you need the requirement of infinite sequences to do functional programming, or the restriction of no intermediate variables. Let bindings seem like a nice thing to have.

Re: Functional calisthenics

#28

Post by crimsonalucard »

jw- wrote: post #27
crimsonalucard wrote: post #26

I 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…

I'm not really sure why you need the requirement of infinite sequences to do functional programming, or the restriction of no intermediate variables. Let bindings seem like a nice thing to have.

No you're right. I missed the infinite sequences thing. I'm going to reword the post from "all" to "most"

Re: Functional calisthenics

#29

Post by pygy_ »

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…

Thanks for the article. There's a class of problems that I wouldn't know how to solve using the constrains you propose.

Given

    { a: { b: { c: 4 } }, d: 2 }
return

    { 'a.b.c': 4, d: 2 }
My go to solution uses mutable state, self-recursion, and intermediate variables:

    function flatten(source) {
      var result = {}
      _flatten(source, null, result)
      return result
    }
where `_flatten(source, prefix, result)` is self-recursive (`prefix` accumulates the keys) and populates `result[prefix]=value` when value is a string. `result` is conceptually an IO monad that's passed along.

I guess the general problem would be traverse a tree of arbitrary depth and accumulate structured data on the go. Prominent examples would be compilers.

Any hints on where to start?

Re: Functional calisthenics

#30

Post by emsy »

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…

>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.

I disagree. Switch statements are fine to react to incoming data, but terrible for everything else. If you add a value to an enum you have to change every place where the enum is used in a switch. And the code inside the switch is not reusable (Unless you make it a method, at which point you're close to the "OOP" way anyway). I agree that religiously avoiding switches lead to spaghetti code, but mindlessly using them does so too.

Post reply on HN