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

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?

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

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

Another good rule when practicing OOP would be "No classes without state." That helps you avoid the habit of writing pointless "namespace" classes like the "Math" class you define here. Of course, again, sometimes it is useful to wrap a bunch of related behavior in a stateless class, but that should be the exception, not the default.

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.

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 {[], []}.

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.

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!

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

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.

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

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

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

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

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

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

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.