Hacker News Reader

Comment by Thaxll | Hacker News Reader

Do people actually enjoy FP on the long run? Most devs are used to OO.

Yep, FP is really nice. A lot of what people think is going to be different is actually not that different from OO. Elixir especially ends up looking a lot like OO with its pipe operator ("string" |> String.split() vs "string".split(), for eg). Some of the major wins are immutability (which is actually very easy to grasp and a lot of people write in an immutable style in OO) and the fact you can every functions dependencies right there. The latter is actually huge for me as I always hated jumping around files, trying to see where things are coming from. FP minimizes this. There are lots of other niceties (some language-specific) but those are some of my faves.

Sometimes things take a little longer to write as you have to be slightly more verbose, but it's so much quicker to understand when coming back to it.

What's better (and more flexible) than Object Oriented is Polymorphism.

The pipe operator |> that you mention is great example because it does something in OO that is typically done using a 'fluent interface'[0] often used in 'Builder' classes (i.e., the class methods return the object so that it can be chained together). The great thing about the pipe operator is that it's much more simple and flexible, it simply passes the result of the prior function as the first argument to the second. This means, unlike with a fluent API, you can pipe together functions from completely different modules:

    :crypto.hash(:md5, some_binary)
      |> :base64.encode_to_string()

Elixir also has protocols[1], which allow a function to be used across a variety of types (similar to obj-c/Swift). Which again is more flexible, as the functionality can extend a 'class' that you don't control.

Elixir also has behaviors[2], which just guarantee that a module contains a number of functions, something akin to interfaces Java.

Dialyzer can take advantage of behaviors and protocols to enforce typing constraints.

[0] https://en.wikipedia.org/wiki/Fluent_interface [1] https://hexdocs.pm/elixir/1.12/Protocol.html [2] https://hexdocs.pm/elixir/1.12/Behaviour.html

Yes! Another thing I love about FP is the simplicity of terms. So like how you mention a return value can flow through different modules, if you wanted to do something like that in OO, you’d have to come up with a concept for what the new object is (ie, Service or what have you) which in turn has to take an object, breaking the whole “data and behaviour combined” idea. In FP, you just have modules. You don’t have think much past that a module is a group of functions that work on a certain data structure and other modules might also work on that data structure and that is fine (though of course you’ll want to hide those behind another module and delegate if you are dealing with a complex model, but that is a whole other problem that also exists in OO).

Yes - far more than the opposite IME, it's pretty rare for someone who's good at FP to switch permanently to OO, whereas even successful, experienced OO people often switch permanently to FP.

My OO definitely has a much more functional feel to it. Pretty much use OO to connect the parts so that the functions are connected from inputs through to outputs in a pipeline-y way. Monadic data, aspects, and error handling is also commonplace. I recently figured out that I can chain (value, error) in Go with different value types and not deal with input x output explosion of flatmappers--trick is to bind with closures to make zero-arg functions so only the output type varies.

Sounds interesting, can you share a snippet?

I assume you mean the Go part. I meant to write a mini-blog post but can summarize here. Lets say we want to use an Either<ok, error> and chain computations. In Go naively without generics this needs the product no-of-input-types x no-of-output-types forms of result mappers/chainers. Instead we make functions that bind all it's inputs so only has an output-type. Now we only need linearly as many mappers/chainers (and_then's). e.g.

  x, err := computeAThing(1, 1)
  y, err := and_then.Int(err, makeComputeAThingFn(x, 1))
  z, err := and_then.Int(err, makeComputeAthingFn(x, y))
  another, err := and_then.AnotherType(err, makeComputeAnotherTypeFn(z))

where makeComputeAThingFn(...) returns a function with the body `return computeAThing(...)`. `err` will end up with the first non-nil error and the following and_then.X's will be no-ops.

Java/Python/C# were my first languages, and worked in them for over a decade.

I learned F# in a ~year, and then found a Clojure job. I _never_ want to go back to OO.

I started using OOP with Turbo Pascal and C++ a long time ago, and Elixir 5 years ago roughly.

Yes, I do enjoy FP on the long run, not only to write it but more importantly to maintain it (much easier in my opinion, including refactoring & tech debt reduction).

I still use OO too (e.g. with Ruby), but my Ruby style has gotten more FP-oriented as a result (e.g. ETL components which looks a lot like Elixir modules).

After 15+ years of OO (C++, Ruby, Python, JS) I will never go back, with allowances for some relatively high bar for "if you pay me enough i will".

I do, for some reason it fits my brain more than OO.

I think many people haven't realized that different paradigms fit different people's brains in different ways; there are better paradigms for a specific person and task but it's impossible to generalize.

Yes, I love it!

Reply on news.ycombinator.com