
This just isn't functional - nicholasjbs
https://codewords.recurse.com/issues/six/this-just-isnt-functional
======
victorNicollet
> In an immutable world, the coupling of functionality and data is extremely
> difficult to use because any functionality would have to be rebuilt any time
> the facts change.

This is wrong. The problem is lack of support for immutable data in
Javascript, not with immutable data in itself. Consider the OCaml equivalent:

    
    
        class person name = object
    
          val _name = name
    
          method name = name
    
          method greet other = 
            "Hello " ^ (other # name) ^ ", my name is " ^ _name
    
          method set_name name = 
            {< _name = name >}
        
        end 
    

This creates an immutable person class. Calling 'set_name' on a person creates
a new person and the methods of that person use the new value. You can even
use inheritance :

    
    
        class whistleblower secrets name = object
           inherit person name       
           val _secrets = secrets
        end 
    
        let bradley = new whistleblower (...) "Bradley"
        let chelsea = bradley # set_name "Chelsea"
    

The new person is an instance of "whistleblower" and has the same value for
"_secrets" as the original object.

------
Dr_tldr
I found the initial example of a problem with context and this to be
incredibly contrived. If you have people who hate you dropping bind into your
code and misusing a function only meant to be used with constructor calls, why
wouldn't they do the same thing with your protocols?

By this author's logic, his own implementation is no good, because what if
someone comes along and writes Protocol = "foo" in global scope? There's a
difference between writing defensive code to prevent mistakes anyone could
easily make, and trying to push your pet implementation forward through
ridiculous hypotheticals.

Also, no mention of ES6 fat arrow functions and no mention of Immutable.js
indicate that maybe this guy isn't interested in solving problems as much as
he is in promoting his personal style.

~~~
kemayo
Yeah, an example which doesn't involve "assume the caller will deliberately
use your API wrong" would have helped me maintain my suspension of disbelief.

------
bsder
Yet another article written by someone who doesn't have enough perspective to
understand when the failure is a failure of _Javascript_ rather than a failure
of a fundamental concept.

------
nmalaguti
It's great that JavaScript is flexible enough to allow these completely
different styles without requiring any changes to the language, but I wonder
if the author wouldn't be better served by switching to a language that uses
similar patterns but with better syntax.

Introspecting into this code seems very complicated and could make future
refactors painful.

------
dietrichepp
It seems like we're using dynamic language features and metaprogramming
facilities to try and jury-rig something that would solve _exactly_ the
problem that static type systems are designed to solve. I'd rather trust
people to call new Dog() instead of Dog.bind(cat), or alternatively I might
just use TypeScript and my code will still look mostly like JavaScript.

------
dustingetz
Btw react-with-addons ships with react.addons.update which gives effcent
enough immutable updates without needing to leave plain old is data structures
like the mentioned mori and immutablejs. I don't know why react.addons.update
was released with such cripplingly bad syntax, but you can trivially use it to
implement clojure's assoc, update-in and the like, see here:
[https://github.com/dustingetz/update-
in](https://github.com/dustingetz/update-in) (this tiny library is production
quality and the basis of react-cursor). When my consulting clients are ready
to taste immutability but have all this jquery style code that they can't
leave behind and which isn't compatible with redux, I point them in this
direction. (Hi from RC batch S'12!)

------
mchahn
> When we change the name of our functional object by copying it and
> refreezing, we will not change the functions inside the object. All those
> functions will still only have access to the old version of the object
> through reference.

That is why I use deep-freeze. I also have a mutate/copy function that only
changes from the changed property up to the root. Everything that can stay
frozen as the original object will stay frozen.

------
georgefrick
There is an error in at least one example, it's small but confusing to run
into:

var sonalisTemp = get(sonali, "name"); // sonalisTemp === 22

I think you meant

var sonalisTemp = get(sonali, "temperature"); // sonalisTemp === 22

