DEV Community: Éber Freitas Dias

Announcing elm-express

Éber Freitas Dias — Tue, 18 Apr 2023 17:54:46 +0000

Not knowing it was impossible, he went there and discovered it.

Elm in the backend has always been an idea in the background. Many people have experimented with the concept with varying degrees of success, but it never really took off. In my case, I wrote about it, suggesting that Elm might not be the best language for the backend. Nevertheless, I have just released elm-express, an Elm library with a JavaScript bridge that allows the creation of (almost) pure Elm backends using Express.

Working with dynamically typed languages like Ruby and Elixir made me want something like Elm in the backend. Although I could have learned Haskell or even tried Rust, I already knew Elm, and it is such a comfortable language to work with that I was willing to take a shot at it in the backend.

However, the timing may be a little off. In some ways, it feels like the "Express" way of developing for the backend is dying. We are seeing tools that blur the line between backend and frontend, trying to unify how we develop web applications. Tools like Phoenix LiveView, StimulusReflex, Laravel Livewire, Remix, Next.js, and many others are being developed.

Moreover, in the Elm world, we have amazing tools like Lamdera and the upcoming elm-pages v3 which bring the full-stack development experience to Elm.

Additionally, there is a lot of movement around the Elm language regarding other new and interesting languages like Roc, Gren and even Elm itself which will probably reveal new and interesting ways of developing for the backend with the ergonomics of Elm that we like and love.

So, why do we need elm-express when there are so many interesting tools out there? For me, personally, there are some reasons:

I wanted an Elm-like experience for developing backends, and maybe nothing beats Elm itself right now.
I didn't want to wait for the next great way of developing for the backend with the next Elm-like language.
I wanted to use something simple with pure Elm, without extra steps or tools like custom compilers.
I didn't want to feel constrained on the types of apps I can build with the tools at hand.

While Elm in the backend may seem appealing, it may not be a wise choice due to the substantial amount of decoding/encoding that could be required and the need for "hacks" like taskport to improve FFI ergonomics.

Tools like LiveView and Lamdera are really good at removing a lot of the boilerplate and glue code you have to write to get a full-stack experience, which is valuable. My attempt with elm-express will likely result in more boilerplate and glue code. Is that a bad thing? Not necessarily. Being in control of boilerplate and glue code opens up the opportunity to explore more domains, but there is an obvious downside when you are writing lots of code for things that should "just work."

In the end, elm-express is an experiment. Will it be useful? Maybe. My intention is to write some toy projects with it and see. Maybe it will be a complete disaster, or maybe it will be a really pleasant experience. Perhaps I will come back to talk more about it once I have done something else with it.

If you use it, let me know. I would love to learn more about other experiments in the area. Thanks for reading.

About lazyness, automation, types and functional languages

Éber Freitas Dias — Sun, 08 Aug 2021 06:03:38 +0000

There is that famous quote attributed to Bill Gates that says: "I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it."

I think it is a stretch, but it makes sense, I guess. The term lazy is a little too much and could be replaced by "person that optimizes its time".

I'm not saying on the workaholic sense or productivity freak. I'm talking about the person that wants to use their time most efficiently at times. Avoiding repetitive tasks and trying not to worry about things that can be taken care of in an easier way.

Automating a task, making it easier to execute, delegating worries, all this looks like a way to value and enrich time.

Elm, for instance, is a very restrict programming language. It is strongly typed, immutable, and has controlled side effects. What it demands when you develop inside these constraints, pays off by guaranteeing the correctness of your software and the tranquility of not having runtime errors.

When I use Elm it may look like it is hard to follow its rules and limitations, but I'm choosing the path of least resistance there. After all the computer can aid me to write better software without overloading my brain. If it can perform this kind of task (by using static analysis for instance) I don't have to waste my time and mental bandwidth with it.

Elm is one example but there are other languages out there like Haskell, Rust, PureScript, and many more.

When choosing a tool you can value its popularity, expressiveness, who is funding it, etc. But for me, I will always choose to value my time when I can.

Pelmodoro - a Pomodoro app built with Elm

Éber Freitas Dias — Sun, 25 Jul 2021 21:54:23 +0000

Pelmodoro is an app that helps you use the pomodoro technique in your daily life. If you don't know about it take a look at the Wikipedia article.

There are many Pomodoro apps out there of different sizes and colors. After using some of them I tried to build my own. Pelmodoro is the result of that effort.

The app has the traditional timer and a few other features:

Personalize the number of rounds and sessions duration (work, break, and long break);
Control how the timer will behave after each session ends;
Control how you will be notified about session endings;
Themes!!! 🎨
Spotify integration to play any playlist during your work rounds;
Rate your work sessions;
App usage stats, including worked minutes, breaks, and more;
Import/export your stats data.

On top of that, Pelmodoro is an off-line first PWA, so you can install it on your mobile device or desktop. I have been using it as a stand-alone app with Edge's PWA support.

Pelmodoro running as a PWA on my desktop and some of the themes you can choose from

The project is open-source and you can check it out @ GitHub.

Yet another Pomodoro app? Why?

There isn't one reason why, and the answer could be just "because I wanted" 😁 But I also wanted to create something with Elm, a language I've been using daily for the last year and a half, but that I have never used to build something from my own.

Besides, I was using Habitica (an RPG game like that helps you achieve your goals and daily tasks) to track my productivity but I felt it was overkill. The idea was to replace Habitica building some of the features that made sense for me into the Pomodoro app, mainly the round rating system.

The calendar @ the stats screen also dubs as a graph showing your most productive days, inspired by GitHub's graph

Making it work

The main tool I used to build the app was the Elm language and its ecosystem. It is not a large ecosystem, but it offers lots of quality packages that really surprised me during development.

Elm is a functional language, strongly typed and pure (with controlled side effects) targeted at front-end development. Although it is not popular, I was impressed to see that most of the problems I needed to solve were already solved by the community.

For the timer rendering I used SVG and the excellent official package to create and handle SVG documents;
I used elm-css for the CSS, which allowed me to write safe and dynamic styles;
For dates handling I used the date package;
The calendar on the stats area was easily solved using the calendar package.

For some of the features, I had to use JavaScript, mainly the Spotify integration. Luckily Spotify has a reasonlably complete documentation for its API. After fighting the PKCE auth system, developing the integration was easy.

To persist the app's state I used both localStorage (for settings and the timer state) and IndexedDB (to persist usage stats). Instead of using the IndexedDB API directly, I used Dexie which abstracts most of the IndexedDB complexities.

To play sounds I used the howler.js lib.

Rate your work rounds and check your stats

Making it beautiful

After being satisfied with the features and the way everything looked and worked, I showed my code to some people that gave me valuable feedback, mainly about my code structure. In about two days I refactored my app's structure completely. When I was done I had a PR adding 5,934 lines and removing 3,756.

If that was a JavaScript project, that would be a very daunting PR, but I'm using Elm so refactors are safe and cheap. If it compiles it probably works as intended, so I could just merge the PR without blinking twice.

The original code structure grew very organically during development, which produced a functional code but was ill-organized. One example was that I was separating Model, Msg, and Types on different modules. The idea was to avoid import cycles, but that was just evidence that my code needed better structure.

Looking at the Real World application I could see that there were better ways to structure my modules using nested TEAs and keeping the Main module as a hub for everything in the app.

My original update function was massive, but after separating messages for each "page" I ended up with a more organized, contained, and easy to understand code.

There is a lot to talk about code patterns with Elm so I would recommend reading Elm patterns for a more in-depth study.

I also implemented a few stylistic decisions to standardize my code such as:

Avoid exposing constructors in module definitions;
Avoid exposing functions and types when importing modules;
When aliasing a module, use the module's own name, mimicking Elixir's alias. Ex.: Html.Attributes as Attributes;
In case of name conflicts a) don't alias at all or b) join module's names. Ex.: Svg.Attributes as SvgAttributes;
Prefix every view function with view 👀

The idea behind most of these was to make the code more explicit, making it clear where types and functions are coming from as well as their effects.

Monthly stats, including your most productive hours

Final thoughts

Although I did this big refactor I know my code structure and design could improve at various places, but I want to finish the project. I feel like software in general is never really done, except for a few outliers, so I need to stop investing so much time on this project that is already working very well for me. That way I can invest my time on another side project that will suck out all my free time 🤡

In general, I'm very satisfied with the final result and have been using the app daily. With some luck other people will find it useful as well and if you are one of those people I'll be extremely happy to know 😊

Elm in the server (or anywhere else) with promises

Éber Freitas Dias — Mon, 04 Jan 2021 14:20:44 +0000

Elm was created to run on the browser, but every once in a while someone will ask about how to run Elm in a server environment.

At my current job, we needed to sync several clients and persist that shared state somewhere, so we thought it would be a good idea if the server could act like another client that could persist that state in a centralized place.

For that, we created a Node/Express server to run our Elm code and at first, it was very hackish.

In a server-like environment, you mostly always have a request and a response tied together. You ask for something and you might get what you requested or an error. It doesn't matter, for every request, there is a response.

But Elm doesn't work like that if you wanna talk to the outside world. Yes, you can use ports for outside communication, but ports follow the actor model of message passing. So contrary to the request/response nature of server communication, you can only send and receive messages in Elm. That might sound like the same thing but it is not. You can receive a message without ever sending one in the first place. Or send a message without the need to wait for a message back. You can send a message and receive multiple messages back and so on. There is no coupling between sending and receiving a message and that makes Elm kinda unsuitable for a server software where request/response messages are tied.

After looking for better solutions I came across this post in the forums where the user joakin made a clever suggestion: just send the response object from the JavaScript side to a port and send it back through another port when replying to whatever it was requesting. Use the response object to send a proper response to the right client and there you go. You can see an example of that on this helpful repository.

That is something I didn't know: you can pass any JavaScript value as a Json.Decode.Value to Elm, even functions. Of course, you can't do much with them inside Elm but in this case, it helps to tie a specific function call to the message we will send back.

The idea is great and helps us to have some type of tied request/response flow. The problem is when we needed to test the integration. It was easier to bypass all the server stuff and focus on the interoperation between Node and Elm directly. Or even worse, what if the software we were writing wasn't a Node/Express server at all? That is when my boss and co-worker Nate suggested we used promises. Instead of sending the response object from Express to Elm, we could send the resolve function from a promise!

I have made a fork from the example code above with these changes. You can check it out here.

On the Elm side, nothing much has changed. I just made a few naming changes to better reflect the new nature of the interoperation with the JavaScript code. But other than that, we didn't have to change much to make this approach work as both the previous response object that was being sent from Express and the new resolve function from the promise are both just Json.Decode.Values.

The real magic is on the JavaScript code. It is a little bit more complex but it decouples the Elm code and ports from Express itself, making it possible to use that approach virtually anywhere. Here is the bit that makes everything work:

http
  .createServer((request, res) => {
    new Promise(resolve => app.ports.onRequest.send({ request, resolve }))
      .then(({ status, response }) => {
        res.statusCode = status;
        res.end(response);
      });
  })
  .listen(3000);

app.ports.resolve.subscribe(([{ resolve }, status, response]) => {
  resolve({ status, response });
});

So, it is possible to use Elm in the server, and I would argue that with that approach if you need some kind of tied request/response integration, you can use Elm anywhere where you can use Node. But is it useful? In our case, where we wanted to use most of the code from our client on the server it was a total win, but I would think twice if I wanted to build a full server with Elm as it just doesn't have all the things you will need to make it a good developing experience, although it would be possible.

Maybe Roc will be the language we will use for cases like that. Can't wait for it!

So, what do you think about this approach? Have you done something similar or vastly different to solve the same problem?

Thanks for reading!

Comparing Elm to Ember Octane and React

Éber Freitas Dias — Tue, 12 May 2020 21:08:04 +0000

Today I stumbled on this article "Comparing Ember Octane and React" on Hacker News.

The article goes to demonstrate how the same application can be built both with React and Ember, going into implementation details and drawing some conclusions from it. The app is a simple Hacker News search that you can test yourself here:

React
Ember

At the end of the article, the author (Chris Garrett, which is an Ember Core team member) writes:

In writing this post, I feel like I got to experience React with hooks much more deeply than the research I've done before, and I enjoyed learning them and working with them. It is an interesting programming model, and while I'm not entirely sold yet (I think I'd still prefer something more akin to Elm personally) I can definitely see why people like them, and what the advantanges are.

That had me wondering: what the Elm version of the same app would look like? So I tried to build it! You can see the ending result here.

Like in the original post, let's take a deeper look at what is going on here.

Getting started

port module Main exposing (main)

import Browser
import Browser.Dom as Dom
import Html exposing (Html, a, button, div, h1, hr, input, label, p, span, strong, text)
import Html.Attributes exposing (disabled, for, href, id, type_, value)
import Html.Events exposing (onClick, onInput)
import Http
import Json.Decode as Decode exposing (Decoder)
import Task


port sendQuery : String -> Cmd msg

This is how most Elm applications (and files) start. You define the file's module name and explicitly declares what you want to expose and import from other modules. Elm has it's own package manager and when you create a new project, it will install a few basic packages to get you going. We also had to install some extra packages like elm/json and elm/http.

One particular thing about our module is the fact that we start it by saying port module. In case you are not familiar with Elm, it is a purely functional language that can't have side effects. That means we can't, for instance, set things to localStorage from our Elm code. That is where ports come in, but we will talk about it later. At the end of this section, we declare a port named sendQuery that we will use later on.

type alias Story =
    { id : String
    , title : String
    , author : String
    , url : String
    , comments : Int
    , points : Int
    }


type alias Model =
    { input : String
    , lastSearch : String
    , stories : Stories
    }


type Stories
    = Loading
    | Error
    | Stories (List Story)


type Msg
    = NoOp
    | GotInput String
    | Search
    | Dismiss String
    | GotResults (Result Http.Error Stories)

Here we have our types definitions. Elm is a strong and static typed language. That means we can create our types to help model the application. First, we have two alias types: Story and Model. An alias type just gives a nickname to some other typed structure. That way we can use the compiler to help us write the correct structure every time.

Later we have some custom types: Stories and Msg. Those types will help us to keep a better understanding of our application's state and what we should do about it.

The TEA

The TEA (or The Elm Architecture) is a way to describe how most Elm applications work in terms of how the data flows through our code. It consists of a few basic concepts:

We have one global state;
That state is rendered using some view function;
The view can send messages to some kind of update function (picture a button click or form submission);
Finally, the update mutates the state that is re-rendered by the view.

That is it! So let's build those functions:

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        NoOp ->
            ( model, Cmd.none )

        GotInput i ->
            ( { model | input = i }, Cmd.none )

        Search ->
            if model.input /= model.lastSearch then
                ( { model | lastSearch = model.input, stories = Loading }
                , Cmd.batch
                    [ request model.input
                    , sendQuery model.input
                    , focusSearch
                    ]
                )

            else
                ( model, Cmd.none )

        Dismiss id_ ->
            let
                stories_ =
                    case model.stories of
                        Stories s ->
                            Stories (List.filter (.id >> (/=) id_) s)

                        _ ->
                            model.stories
            in
            ( { model | stories = stories_ }, Cmd.none )

        GotResults res ->
            case res of
                Err e ->
                    let
                        _ =
                            Debug.log "error" e
                    in
                    ( { model | stories = Error }, Cmd.none )

                Ok s ->
                    ( { model | stories = s }, Cmd.none )


view : Model -> Html Msg
view model =
    div [] <|
        h1 [] [ text "My Hacker Stories" ]
            :: searchForm model.input
            ++ stories model.stories


searchForm : String -> List (Html Msg)
searchForm input_ =
    [ label [ for "search" ] [ strong [] [ text "Search:" ] ]
    , input [ id "search", value input_, onInput GotInput, type_ "text" ] []
    , button [ disabled (input_ == ""), onClick Search ] [ text "Submit" ]
    , hr [] []
    ]


stories : Stories -> List (Html Msg)
stories stories_ =
    case stories_ of
        Loading ->
            [ p [] [ text "Loading ..." ] ]

        Error ->
            [ p [] [ text "Something went wrong ..." ] ]

        Stories [] ->
            [ p [] [ text "No results." ] ]

        Stories list ->
            List.map storyItem list


storyItem i =
    div []
        [ span [] [ a [ href i.url ] [ text i.title ] ]
        , text " "
        , span [] [ text i.author ]
        , text " "
        , span [] [ text (String.fromInt i.comments) ]
        , text " "
        , span [] [ text (String.fromInt i.points) ]
        , text " "
        , span [] [ button [ onClick (Dismiss i.id) ] [ text "Dismiss" ] ]
        ]

Here we have an update function that will receive our model and a message. Remember our types Model and Msg? We are going to use them here. We need to check which Msg we are getting and make the appropriate changes to the Model. And if you are paying attention you can see that we don't just return our Model, but a Cmd msg type (command). Remember when I said Elm can't have side effects? To solve that we have commands, which are a special type that we can handle to the Elm runtime to solve for us. It can be, for instance, an HTTP request like we are doing when Msg is Search. More on that later...

After that, we have a few different functions that will return the type Html. That is different from returning actual HTML, but that is how we implement templates and components with Elm. Using plain functions! The Elm runtime will take care of things and render proper HTML from that.

Now, let's wire it all together:

main : Program String Model Msg
main =
    Browser.element
        { init =
            \query ->
                ( { input = query, lastSearch = query, stories = Loading }
                , Cmd.batch [ request query, focusSearch ]
                )
        , view = view
        , update = update
        , subscriptions = always Sub.none
        }

The main function is the entry point of our application. It is what the Elm runtime will look for and run once it kicks in. Here we are explicitly saying which functions our application will use for each stage of TEA. The init key is a function that should set up the initial model. Keys view and update are pretty self-explanatory by now. Finally, we have subscriptions that we won't use for this app but if you are interested, take a look at the elm guide.

The missing stuff

Finally we have a few extra functions that will make our interaction with the application more dynamic:

focusSearch : Cmd Msg
focusSearch =
    Task.attempt (\_ -> NoOp) (Dom.focus "search")


request : String -> Cmd Msg
request query =
    Http.get
        { url = "https://hn.algolia.com/api/v1/search?query=" ++ query
        , expect = Http.expectJson GotResults resultsDecoder
        }


resultsDecoder : Decoder Stories
resultsDecoder =
    Decode.field "hits" (Decode.list storyDecoder)
        |> Decode.andThen (Decode.succeed << Stories)


storyDecoder : Decoder Story
storyDecoder =
    Decode.map6 Story
        (Decode.field "objectID" Decode.string)
        (Decode.field "title" Decode.string)
        (Decode.field "author" Decode.string)
        (Decode.field "url" Decode.string)
        (Decode.field "num_comments" Decode.int)
        (Decode.field "points" Decode.int)

The function focusSearch is just a helper function that returns a command to inform the Elm runtime to focus on an element with a specific id and that is it. That one I straight copied from the Elm guide.

The real important function comes next: request. It receives a query string and creates a command that runs an HTTP request. This is where Elm shines for me. After making a request the runtime will send a new message for the application with some data. In our case we are telling the runtime to return the data with the GotResults message, expecting a JSON that can be successfully decoded with the resultsDecoder function. See, everything in Elm is typed and we can't just receive arbitrary data from the server. How would the compiler know which type of data are we dealing with? That is why we have to decode the JSON that we get, making it fit at a specific type. In our case, we need the JSON to return a valid Stories type.

If you take a look at the way we handle the GotResults message on our update function, you will see that the returning data can either be Ok ... or an Err .... An Err may occur if the HTTP request fails or if the JSON decoding fails.

We still need JS after all...

<html>
<head>
  <style>
    /* you can style your program here */
  </style>
</head>
<body>
  <main></main>
  <script>
    var app = Elm.Main.init({
      node: document.querySelector('main'),
      flags: localStorage.getItem('searchTerm') || 'Elm'
    });

    app.ports.sendQuery.subscribe(query => localStorage.setItem('searchTerm', query));
  </script>
</body>
</html>

The important bit about the HTML/JS part of our app is how we start it. On the init function call we can pass the value of the current data stored at the localStorage to our application. Take a look at the init function on the Elm side to see how we handle that.

After that, we use the sendQuery port to save the search query every time a new search occurs. Take a look at the Search message handling we do on the update function to see the use to the sendQuery port we defined right at the beginning of our module.

Takeaways

I have no real experience with React or Ember so this section won't be as well informed or in-depth as in the original article is. But let's take a look at how Elm solves some of our problems in a very efficient and easy way.

Custom types are a game-changer

The React implementation on the storiesReducer function will do something like what our update function does. The real problem here is that it uses plain strings as keys for the possible actions it can execute. That is fine until you need more messages/actions.

Because we are using an actual custom type as our message (we could be using strings but that wouldn't help), we need to handle every possible message that there is. If we need more messages we can just add them to our Msg type and the compiler will politely tell us about all the places where we need to handle that new message if we miss something.

Custom types are a game-changer ²

Both on the React and Ember apps you will see that the "model" has a few flags like isLoading or isError. All that those flags are doing is informing the state of the stories we are trying to load. See how we always need to worry about resetting the values of those flags so we don't end up with a view that says that we have an error and we are loading at the same time. Nothing is preventing that from happening...

We can solve that by using a custom type that can represent the state of those stories only once at a time. It can't be Loading and Error at the same time, so we have certainty that our view will always render the right thing no matter what.

JSON decoding

We have a bug in this app. See... A story title or author can be a null value coming back from the API call. If you open up the React or Ember apps and search for "elmish" for instance, you will get a few funny looking lines. That is because JavaScript won't stop you from accessing data that don't exist on a given object, rendering a pretty confusing and uninformative list of... things.

That can't happen with Elm. Besides the fact that we can use alias types to inform our compiler about the shape of some structures, when receiving data from the outside world it has to pass through a decoding process and that decoding can either work or fail: Elm will force us to handle both situations or it won't compile our program. Search for "elmish" on the Elm version of the app and you will see the message "Something went wrong ...". That is because our decoder only decodes strings for the title key, and if that key is null on the JSON side, it won't decode at all.

We could then update our decoder to handle those situations, maybe making the title key a Maybe String, and that would force us to handle the fact the title can either be Just ... something or Nothing in our view function. We could never reproduce those silly and confusing lines you get from using "plain" JavaScript.

A simple take

Hooks, components, tracked properties, actions, and so on... JS-land apps can have a lot of concepts that require time to learn and master. Elm, on the other hand, is pretty simple. Despite its somewhat cryptic syntax, if you never dealt with anything like it, Elm introduces very few concepts: everything is a function, and the way you make your application work is through the iteration of TEA, just like that.

I fell like I'm having a very superficial take on top of such a well informed and well-written article like the one this is based on, but hopefully, I succeeded at showing how Elm would solve similar problems pointing at the exciting things it brings to the table.

What am I missing from my list of takeaways? Is there any place where the React/Ember solutions are better? Please, let me know in the comments section. Cheers!

Elixir for PHP developers - Programming paradigm

Éber Freitas Dias — Tue, 01 Oct 2019 03:04:16 +0000

When I want to learn something new I try to find some kind of material comparing it to something that I already know so I can see the pros and cons and decide if I should invest my time on it.

I come from the PHP world and fell in love with Elixir so my idea here is to compare some aspects of those languages and show how they are different (or similar) and maybe help you make a decision to learn more about it. I hope you will find that Elixir is a super fun language to work with!

By the way, I'm a beginner in the Elixir world. This is the perspective from someone learning it as we go so take that into account.

Elixir is a functional programming language

The first big difference between PHP and Elixir is that Elixir is a pure FP (functional programming) language. PHP, on the other hand, is a multi-paradigm language, where you can solve problems using different paradigms even though OOP (object-oriented programming) is pretty dominant these days.

And what does FP means? The theory can get really dense, and you might wanna check the Wikipedia article for a more elaborated description, but in a nutshell and for the purposes of this comparison, it means there are no objects.

An object in OOP is (among other things) when you bundle data and functionality together: on the same object, you have the state and the methods to affect that state.

But in functional programming, those are separated things and all you get are functions that manipulate data. Let's take a look at how that looks like:

<?php

class User extends DataLayer
{
  private $name;
  private $email;

  public function __construct(string $name, string $email)
  {
    $this->name = $name;
    $this->email = $email;
  }
}

$user = new User('John Doe', 'john.doe@example.com');

$user->save();

The somewhat equivalent of that code in Elixir looks like this:

defmodule User do
  defstruct name: nil, email: nil

  def save(%User{} = user) do
    Repo.insert(user)
  end
end

%User{name: "John Doe", email: "john.doe@example.com"}
|> User.save()

There is a lot going on here. The syntax is kinda alien compared to the PHP counterpart. No brackets, and what is that assignment on the function definition? Well, we will get there but just to clarify, that is not an assignment.

What we did here was to create a struct which is a glorified map. A map is similar to an associative array in PHP where you have keys and values. The difference between a map and a struct is that with the struct you can structure how the data will look like, defining keys and even default values (you might be thinking "uhm, that looks like an object" but it is not, it is just data).

Another thing you might have noticed is that we don't have any kind of inheritance. In the PHP code, it is assumed that the save method comes from the DataLayer class from which the User class extends but in the Elixir code the save function is just calling another function from another module (Repo being the module) to persist the data to the database.

In FP you have data and functions all the way down and your work is to compose those things to make bigger things that can also be composed onto other things.

But PHP also has functions...

The Elixir code could be roughly translated to PHP like:

<?php

function save(array $user): bool
{
  DataLayer::persist($user);
}

$user = ['name' => 'John Doe', 'email' => 'john.doe@example.com'];
save($user);

So PHP can do FP right? Well, right... I guess? Like I said at the beginning, Elixir is a pure FP language. That means that there are no "escape hatches" from the FP world when using Elixir.

In PHP you can certainly try to use a "functional style" of code but it will never be real FP. You might get "lazy" and just take advantage of the multi-paradigm nature of the language to solve some problems in other ways and in fact, that would be easier in PHP because it is not an FP language.

Also, FP is not only defined by the lack of objects. If you were curious enough to take a look at that Wikipedia article you might have seen that the FP paradigm includes other things like:

First-class functions
Total functions
Pure functions
Data immutability
Recursion
Heavy use of ~~drugs~~ mathematical theory

Among many other things...

Some of that you might even have in PHP. First-class functions entered the language with closures on version 5.3. Other things you definitely won't have like data immutability which is a huge aspect of FP.

And how is it any better?

Now you have a rough idea of what FP is and how it is different from OOP but is it any better than OOP? Yes and no. Some people might claim that each paradigm has its place in the programming world trying to solve different problems but at the end of the day, FP is just a different way to look at programming.

Instead of thinking about objects and their attributes and methods, you only think about data and how to transform that data with functions. It is a simpler outlook but a very powerful one.

Without strong patterns and consistency OO programs can quickly become unmaintainable. With FP you can avoid a lot of those pitfalls writing simpler code that is easier to write and refactor. Don't get me wrong, you can still screw up writing FP but some common problems in the way you architect programs with OOP are non-existent in FP.

There are a lot of articles out there that will show you how FP can be a strong paradigm and I suggest you take a look. I know there are a lot of loose ends in this article but I'm just trying to make an interesting introduction. The idea is to dive deeper on some of these concepts in future articles.

Let me know if you are interested in a specific subject and how that compares to PHP. I might talk about it in my next article.

Thanks for reading!