DEV Community

Write Better Code With [Functional Programming & Elixir]

Anthony Gonzalez on March 23, 2021

The Beauty Of Functional Programming With Elixir Writing code can get messy, especially when you are a beginner, sometimes you focus so ...

Read full post

hidden_dude • Mar 25 '21

Prolog solution is better:

legal_message(Age, "Nope!") :- Age < 18.
legal_message(Age, "Not in the US") :- Age < 21, Age >= 18.
legal_message(Age, "YES!!!") :- Age >= 21.

The nil message is not even necessary it's implicit.

My paradigm is better than yours I win. ;)

I can even have several results for a single case in Prolog. And it's more truly declarative than most FP languages.

hidden_dude • Mar 25 '21

But in all seriousness real OO is directly against case statements like these.

It intends to group decisions about the kind of thing you have in a single place.

So an OO way of doing this would be to compute an Age class on a person and then have all Age rules apply to that age class.

So you could ask a person what age classification they have like Senior, Adult, Child, etc.. and all things related to being an Adult or Child would center there.

This is overkill of course, but that would be the OO spirit.

In Java this can be approximated with the very non-OO enum operator that can make these sorts of minimal type classes quite easy to build.

But the idea of removing if-elses is so that your program isn't riddled with the same if-else all over the place but maybe in only on place.

Of course often a simple if-else is just simpler then some complex idiom like subscribing age values to behavior via callbacks or listeners.

hidden_dude • Mar 26 '21 • Edited

But here's a modern Java example:

var legalMessage = new ImmutableRangeMap.<Integer, String>builder()
   .put(null, "You're not a Person")
   .put(lessThan(18), "Nope!!")
   .put(closedOpen(18,21), "Not in the US!!")
   .put(atLeast(21), "YES!!!")
   .build();

System.out.println(legalMessage.get(age));

In OO it's all about whether you're using the right objects or not. Many times people get sloppy. (This data structure comes from the Guava library)

Anthony Gonzalez • Mar 26 '21

Nice one! Hard to believe that's Java. I agree, you can get sloppy with any language, even with Elixir, check this example:

def handle_event("upvote", %{"p_id" => post_id, "u_id" => user_id}, socket) do
    if user_id == "false" do
      {:noreply, redirect(socket, to: Routes.pow_session_path(socket, :new), replace: true)}
    else
      user = Repo.get!(User, user_id)
      post = Community.get_post!(post_id)
      vote = %Vote{}

      case current_user_voted?(user_id, post_id) do
        "" ->
          case Votes.create_vote(user, post, vote) do
            {:ok, _vote} ->
              User.karma_update(user_id, 1)
              post = Community.get_post!(post_id)
              if post.votes_count == -1 do
                Community.votes_count_update(post_id, 2)
              else
                Community.votes_count_update(post_id, 1)
              end
              post = Community.get_post!(post_id)
              socket =
                assign(socket,
                p_votes_count: post.votes_count,
                active?: "active",
                p_id: post_id,
                u_id: user_id)

              {:noreply, socket}
            {:error, %Ecto.Changeset{} = changeset} ->
              socket = assign(socket, changeset: changeset)
              {:noreply, socket}
          end
        "active" ->
            Votes.delete_vote(Votes.find_vote(user_id, post_id))
            User.karma_update(user_id, -1)
            Community.votes_count_update(post_id, -1)
            post = Community.get_post!(post_id)
            socket =
            assign(socket,
            p_votes_count: post.votes_count,
            active?: "",
            p_id: post_id,
            u_id: user_id)
          {:noreply, socket}
        nil ->
          vote = Votes.find_vote(user_id, post_id)
          case Votes.update_vote(vote, %{downvote: false}) do
            {:ok, _vote} ->
              User.karma_update(user_id, 1)
              post = Community.get_post!(post_id)
              if post.votes_count == -1 do
                Community.votes_count_update(post_id, 2)
              else
                Community.votes_count_update(post_id, 1)
              end
              post = Community.get_post!(post_id)
              socket =
              assign(socket,
              p_votes_count: post.votes_count,
              active?: "active",
              active_dislike?: "",
              p_id: post_id,
              u_id: user_id)

              {:noreply, socket}

            {:error, %Ecto.Changeset{} = changeset} ->
              socket = assign(socket, changeset: changeset)
              {:noreply, socket}
        end
      end
    end
  end

defp current_user_voted?(user_id, post_id) do
    if user_id == false or user_id == "false" do
      ""
    else
      voted? = Votes.find_vote(user_id, post_id)
      if voted? == nil do
        ""
      else
        if voted?.downvote == true do
          nil
        else
          "active"
        end
      end
    end
end

hidden_dude • Mar 26 '21 • Edited

Yeah that needs refactoring.

Also overuse of if/else and case is not helped with FP popular error handling these days.

A nice thing about exceptions is that you can essentially ignore errors in most places rather than having and if/else everywhere or an error handler everywhere.

That style seems to be devolving into old styles where error handling is mixed in with the happy path making the code harder to read.

Classic OO (Smalltalk) and classic FP (if you consider Common Lisp FP) didn't even really have "if statements" or "case statements".

These were handled in the libraries.

I think modern OO languages biggest flaw is there over reliance on statements and keywords that make them much less extendable than Smalltalk or Lisp where you could literally change everything by extending the libraries.

Really no "modern" OO language really has that flexibility and clean design. Not Java, not C++, not C#, not Ruby, not Python, not JavaScript.

Andrei Dascalu • Mar 25 '21

Well, thing is OOP by its 4 pillars nudges you towards shooting yourself in the foot in the long run. All the attempts to fix the paradigm are actually borrowing from FP.

Ever since I dove into DDD and saw its reliance on immutability I've been failing to see any inherent merit of OOP (aside from having become historically dominant for a long time, mostly due to functional paradigms being fairly compute inneficient)

Anthony Gonzalez • Mar 23 '21

I agree, I'm not saying that is better by any means, it's just another tool to get the job done. We all think differently, we can solve the same problems in multiple ways, it is always going to depend on what makes us feel comfortable in our brains.

Anthony Gonzalez • Mar 23 '21

Sure, that would be a really interesting series, I'm down!

Luke Hafermann • Jul 8 '21

I appreciate seeing two people dig through their opinions to find some common ground. Then agreeing to build from there. Thanks for the constructive info- finding! 👍

Comment deleted

Anthony Gonzalez • Apr 4 '21

I guess you mean to remove the can_drink() function and rename legal() to can_drink() like the example below:

defmodule Person do
  def can_drink(age) when is_nil(age), do: "You're not a Person"
  def can_drink(age) when age < 18, do: "Nope!"
  def can_drink(age) when age < 21, do: "Not in the US!"
  def can_drink(age) when age >= 21, do: "YES!!!"
end

IO.puts Person.can_drink(age)

You're right, but I thought that would've make more sense, more readable, and a little bit less confusing for people coming from other languages, the way I did it.

Nikola Begedin • Apr 1 '21

While pattern matching / function clause overloading is great, and one of the many advantages elixir offers, AFAIK, it's not a trait exclusive to functional languages.

Anthony Gonzalez • Apr 1 '21

That's correct!

Anthony Gonzalez • Mar 23 '21

You're absolutely right, but with functional programming, it's not as easy, you need a completely different mindset and the principles force you to not be so careless or not so procedural.