Luego de casi quince años de trabajar, enseñar y difundir Erlang por el mundo, recién hace unos pocos días tuve la posibilidad de leer mi primer libro sobre Erlang en castellano. Se trata del libro que da título a este artículo y está escrito por Manuel Rubio. Aquí van mis opiniones…

En Resumen

Para aquellos que no estén interesados en los detalles, comencemos con la conclusión directamente así se pueden saltear las siguientes secciones si no les interesan.

En general este libro contiene exactamente todo lo que yo suelo enseñar en cualquier curso de introducción a Erlang. Y lo mejor que tiene es que está en castellano. Así que si tú estás intentando aprender Erlang o si conoces a alguien que está dando sus primeros pasos en este lenguaje/tecnología, éste es definitivamente el libro que debes recomendarle!

Y ahora, sin un orden particular, pasemos a los detalles…

En Castellano

Desde mi punto de vista porteño, donde se considera cool usar términos directamente en inglés en lugar de traducirlos, leer un libro en el que a los scripts se les dice guiones, al soft-real-time se le dice tiempo real blando y se incluyen términos como enlace vital y otros es a tanto un desafío mental como una experiencia verdaderamente refrescante.

Ciertamente para un lenguaje no tan popular como Erlang, no sé si es estrictamente útil aprender a decir guión en lugar de script, pues lo más probable es que si tienes una duda y quieres buscar ayuda en la internet, necesites expresarte en inglés de todos modos. Pero para un libro como el de Manuel, es algo que le aporta carácter sin enturbiar la comprensión del contenido.

Erlang sin OTP

Otra cosa que Manuel se encarga de mencionar en el libro y que es algo que yo he aprendido un poco a la fuerza a lo largo de mi carrera enseñando Erlang a desarrolladores es que, si bien es muy tentador introducir OTP desde el primer momento, eso no es necesario. De hecho, que el libro sea tan completo y aún así sólo mencione OTP al pasar nos muestra a la vez la simplicidad y el poder que tiene Erlang como lenguaje y la BEAM como máquina virtual.

Es cierto que nadie (salvo quizá quienes trabajen para Ericsson) va a conseguir nunca un trabajo de desarrollador Erlang que no incluya el conocimiento de OTP, pero también es cierto que para entender OTP apropiadamente es vital tener un conocimiento de Erlang y su máquina virtual en general. Así que este libro es importantísimo y, tal como su autor se encarga de manifestar, es sólo el comienzo. Hay mucho más por aprender!

Pattern-Matching

Cuando doy cursos de Erlang, generalmente dedico varias horas a explicar en detalle cómo funciona y para qué se usa el pattern-matching. Creo que lo hago así porque generalmente asumo que mi audiencia tiene cierta experiencia en programación de lenguajes del paradigma imperativo y, por eso, el concepto es algo revolucionario y sorpresivo. Además, las veces que lo he explicado velozmente, he tenido que volver a explicarlo/repasarlo al momento de enseñar funciones recursivas.

Manuel realiza una aproximación distinta al tema en su libro. De hecho, la concordancia (que es así como la llama) es algo que casi no se detiene a explicar en ningún momento. Simplemente la vemos aparecer por todos lados directamente cuando se necesita usarla. Me resulta muy interesante ver ese enfoque que, entiendo, surge de asumir que el lector no es necesariamente alguien que ya sabe programar. El libro está apuntado incluso a aquellos para quienes Erlang es su primer lenguaje de programación y por tanto, no tienen que desaprender nada.

Más allá de Erlang

Siguiendo este mismo criterio (asumir un público no iniciado), el libro no pasa por alto ninguna explicación relevante aunque no esté directamente relacionada con el lenguaje que está explicando. Así es como en un libro introductorio a Erlang, no econtramos con lecciones sobre protocolos de red, seguridad informática, algorítmos y varias otras cosas que le brindan una robustez muy satisfactoria a lo que uno está leyendo. No se necesita abandonar el libro para googlear nada, toda la información está allí mismo.

El Órden de los Tópicos

Finalmente, creo que mi única crítica, más allá de uno o dos pequeños errores que se han filtrado en el texto, acerca del libro es que es una montaña rusa de emociones.

Quizá sea porque a lo largo del tiempo me he acostumbrado a enseñar Erlang (y otros lenguajes de programación) siguiendo un orden más o menos similar todas las veces, pero el órden elegido por Manuel me resulta, al menos, sorprendente e inesperado.

En el libro pasamos de Tipos de Datos a Tiempo Real Blando sin mediar explicación alguna de algorítmos, módulos, funciones. Pasamos luego de case e if directo a listas por comprehensión. Yo hubiese esperado un poco de recursión antes de irnos tan lejos, quizá. Lo mismo cuando pasamos de funciones anónimas (o clausuras) directo a las directivas del preprocesador. Es un libro que nunca para de sorprender al lector, eso es seguro! 😏

Conclusión

En conclusión, como lo decía al principio, Erlang/OTP: Un Mundo Concurrente es un fabuloso libro para aprender Erlang de cero, en castellano y sin necesidad de tener conocimientos previos de programación, redes, concurrencia, seguridad informática, ni nada más.

Pero claro, siempre es conveniente presentar esta advertencia:

Erlang es un viaje de ida. Una vez que hayas conocido todas las cosas maravillosas que puedes hacer con este simple lenguaje y esta potente máquina virtual, ya no verás con los mismos ojos al resto.

Te lo digo por experiencia… 😉

Erlang/OTP: Un Mundo Concurrente was originally published in Erlang Battleground on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s relatively unusual to watch me talking about the shortcomings or limitations of such an excellent tool as Dialyzer. Still, today I found some very dead code blocks that slipped through its world-famous success type analysis.

So, since Halloween is close, let’s raise some dead code from its grave!

When Dialyzer produces a Warning

So, in the past, I’ve seen code like this one…

warn(X) ->
    {just, X};
warn(6) ->
    {six, 6}.

Trigger warnings from both the compiler and Dialyzer like the following ones…

===> Compiling my_app
src/el.erl:8: Warning: this clause for warn/1 cannot match because a previous clause at line 6 always matches

===> Dialyzer starting, this may take a while...
…

src/el.erl
Line 8: The pattern 6 can never match since previous clauses completely covered the type any()

Lovely! The second clause in that function is clearly dead code (i.e., it will never be evaluated) since 6 matches X and thus falls through the first clause when provided as input. This is one of my favorite Dialyzer warnings ever. It’s clear and actionable. It provides a proper context with line numbers and what-not. It’s awesome.

When Dialyzer doesn’t produce a Warning

But… Today I found a piece of dead code that was very, very similar and yet… Dialyzer and the Compiler were both utterly silent about it. Let me show you…

warn(X, X) ->
    {just, X};
warn(6, 6) ->
    {six, 6}.

Have you spotted the difference?
Let me show you yet another example…

warn(X, Y) ->
    {just, X and Y};
warn(6, 6) ->
    {six, 6}.

This one does produce the expected warnings…

===> Compiling my_app
src/el.erl:8: Warning: this clause for warn/2 cannot match because a previous clause at line 6 always matches

===> Dialyzer starting, this may take a while...
…

src/el.erl
Line 8: The pattern <6, 6> can never match since previous clauses completely covered the type <_,_>

What’s Going on Here?

Well… It seems that not every clause that cannot match can be detected by either the compiler or Dialyzer. Sadly, those that include bounded variables (like the second X in warn/2) or guards or any other semantic constructs are outside the scope of these detection tools.

So, if you have functions like that, the compiler and Dialyzer won’t detect your dead code, and it may end up living as a ghost for a long, long time.

Well, in that case, who you’re gonna call?

Test Coverage, of course!

If you have a good test coverage policy in place (maybe one like the Inakos had where we demanded 100% coverage everywhere, perhaps a lighter one), you should immediately see that no test can ever cover those clauses. Then, you can remove them.

As usual, if you like my blog, you can buy me a coffee and if you want to participate, we’re always looking for new writers for Erlang Battleground. Hit me up on Twitter, Facebook, Slack, etc.…

Bonus Track

While writing this article, I checked several other scenarios to see what was detectable and what was not. You can see the module I used for that below…

And these are the only warnings that I get with it…

===> Analyzing applications...
…
===> Compiling lapp
src/el.erl:8: Warning: this clause for warn/2 cannot match because a previous clause at line 6 always matches
src/el.erl:19: Warning: this clause cannot match because a previous clause at line 17 always matches
src/el.erl:25: Warning: this clause cannot match because a previous clause at line 23 always matches
src/el.erl:27: Warning: this clause cannot match because a previous clause at line 23 always matches

===> Dialyzer starting, this may take a while...
…

src/el.erl
Line 8: The pattern <6, 6> can never match since previous clauses completely covered the type <_,_>
Line 19: The pattern <> can never match since previous clauses completely covered the type <>
Line 25: The pattern 6 can never match since previous clauses completely covered the type any()
Line 27: The variable _ can never match since previous clauses completely covered the type any()

If you find more scenarios worth mentioning, please write a comment about them below.

Erlang’s Halloween 👻 was originally published in Erlang Battleground on Medium, where people are continuing the conversation by highlighting and responding to this story.

For almost ten years, I waited patiently but actively. And finally, the time has come! I was able to participate again in my all-time favorite hackathon: SpawnFest. In this article, I’ll show how Mariano, Manuel, Tetiana, and I spent the last 48 hours emojifying as many Erlang modules as possible.

Background

Let me start with a bit of personal history… 👴🏻

Back in 2011, when I was one of the youngest Inakos in Buenos Aires, Chad (or is it Chad?), Manuel, Marcos, and I spent two days locked in a house writing Erlang code for a contest. That contest was the first SpawnFest ever. It was a truly fantastic experience, particularly for people living far away from the leading developer community centers of the world.

We played again the following year. But then, after its second edition, the organizers discontinued the contest. 😢

We waited for a while… ⏲ … hoping to be able to participate again.

Five years later, in 2017, Marcos and I decided to take matters into our own hands: We started organizing the contest. We did it basically from scratch, but we were very fortunate to have many people helping us with it. We organized 2017, 2018, and 2019 editions (the last two with Juan and Darío, too).

It still is one of the most rewarding experiences of my life. I would do it again millions of times if it was only up to me. But I was still longing for the chance to play again. That, plus other circumstances, led us to seek the help of Fiqus to organize the event in 2020. Still, those same circumstances prevented me from building a team and competing in the event. I ended up helping the organizers a bit. 🤷‍♂

This year, we also started looking for other folks to take care of the organization (this time indefinitely) and luckily we found The Fellowship of the BEAM (Pablo, Paulo, Bryan, and Filipe from The Erlang Ecosystem Foundation).

Almost 10 years after the last time, I was finally able to play again! 🎉

BEAMoji 🪄

It took us quite a while to build the team, but from the get-go, we had a very clear idea of what we wanted to achieve in this contest:

We wanted to have fun, not rush

and build something just for the fun of it.

And that’s exactly what we did.
We wrote the funniest rebar3 plugin ever: BEAMoji.

What is BEAMoji? 🤌

BEAMoji is a plugin that adds the rebar3 emojify command, which allows you to turn all the boring atoms in your code into funny, creative, progressive, and (why not?) auto-localized… emojis!

Do you want an example? Say no more…

Do you want to test it yourself? Of course…

Add this to your rebar.config:

{deps, [beamoji]}
{project_plugins, [beamoji]}.

Then update your deps and run…

$ rebar3 emojify

You should see something like this as output…

===> emojifying your code with beamoji_emojilist_translator…
===> emojifying src/your_module.erl with beamoji_emojilist_translator…

Then, your module would’ve changed from… 😑

search(P, [H | T]) ->
    case P(H) of
        true ->
            {value, H};
        false ->
            search(P, T)
    end;
search(P, []) ->
    false.

…to… 😱

'🆘👀🍎🌈💿️❤️'(P, [H | T]) ->
    case P(H) of
        '🦖🌈🦄👀' ->
            {'✌️🍎🦙🦄👀', H};
        '🔥🍎🦙🆘👀' ->
            '🆘👀🍎🌈💿️❤️'(P, T)
    end;
'🆘👀🍎🌈💿️❤️'(P, []) ->
    '🔥🍎🦙🆘👀'.

…or… 🤩

'👀️'(P, [H | T]) ->
    case P(H) of
        '✔️' ->
            {'⚖️', H};
        '❌' ->
            '👀'(P, T)
    end;
'👀'(P, []) ->
    '❌'.

…depending on what translator you decide to use.

Translators 🗣

BEAMoji comes with 3 translators that you can pick using rebar emojify — translator your_favorite_translator. Each of them will turn your atoms into emojis (and back) using a different strategy:

• EmojiList: This translator is the default one. It has a dictionary of known atoms and it maps each one to a sensible emoji. You can see it in action in the last example above.
• BaseEmoji: This translator started as something like a Base64 with emojis, but we made it a bit more intuitive along the way. Check if you can find the relationship between the emojis and what they represent! 🕵️‍♂️
• MultiWords: This translator is like EmojiList, but it can handle multiple words in an atom as long as you write them using snake_case.

Parse Transformation ⏪

Just replacing the atoms with their emojified versions would likely break your code, since many atoms have specific meanings like true, false, undefined, error, ok, etc. Many of them are used as module and function names, too. We couldn’t just emojify them.

To make the emojified modules work we add attributes during the translation to run a parse transform and tell it which translator was originally used so that the parse transform can “demojify” the module before it’s sent to the compiler.

In this way emojis are for humans, the compiler sees the module as if no translation was done. It’s a little secret between you and us. 🤫

Lessons Learned 🤓

Turning words into emojis is not a trivial task. We achieved our goals during the weekend. We even published the project on hex.pm. But we had to work around a few obstacles along the way, and we learned quite a few valuable lessons with those experiences. We detailed them all in the repo. Go check them out! There’re a couple of funny bits here and there.

And we wanted to share this learning experience with everyone. So we want to invite you to keep learning with us. For that, we prepared one of the world-famous CleverBunny 🐇 quizzes. Jump in on it and check your emoji-skills!

Oh, Erlang! 🤯 was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

We all know about the most renowned Erlang/Elixir centers worldwide, like Sweden, Brazil, California, and London. But the community, even when not huge, is broadly spread. Today we want to celebrate a smaller region that’s home to many amazing contributions to our beloved ecosystem. The birthplace of my ancestors: Galicia!

So, in this unusual style (a collaborative bilingual interview-like article), we’re going to showcase 4 of the many Galicians that have had a profound impact on the language and the people around it…

Laura M. Castro

Ghuapo, ghuapo non é… pero ten uns procesos!!!

Laura got her first Erlang-related “job” (it was a summer internship in the fourth year of her career) because after having taken an elective course called “Functional Programming,” where she learned the language, all she could do was talking to her classmates about its wonders non-stop. She was fascinated with how easy it was to work with multiple processes, multiple nodes, and … reloading code without having to stop the system!!

One day, while at the student representatives’ premises (of whom she was part), someone called to offer an internship. As soon as they mentioned “functional” and “Erlang,” someone handed her the phone without saying another word.

Thanks to that opportunity, the following course, she wrote her Final Thesis exploring how objects could be “simulated” (OOP was starting to take over at the time) in Erlang (using structures, using processes). That Thesis led her to participate in developing a risk assessment system for a large multinational company, which backend was entirely written in Erlang. The first articles arrived at the Erlang Workshop recounting the experience, and the academic world bug bit her. It started with her thesis, then becoming an assistant professor, getting a doctorate … the rest is history!

When / How did you take your first steps in the Erlang ecosystem?

Beyond using the language and reading the mailing lists, my diving into the community coincided with my predoctoral visits to Sweden, hosted by Thomas Arts (now Quviq AB). Being in Gothenburg, it was easy to get to Stockholm, the center where it all started! The Erlang User Conferences helped me put faces together with names, one thing led to another, you know…

What motivated you the most to contribute to the community?

I have always been (even before I met Erlang!) a heartfelt advocate of free software, so contributing, for me, is at the core of software development work.

Prowess

One of the multiple contributions from Laura to the community is her participation in the Prowess Project. A three-year innitiative that got companies and universities from several European countries researching together on methods and tools to improve the quality of web services. Their output was a swath of Erlang open-source libraries.

What’s that thing that stands out about Prowess?

The work that was done, side by side, between companies and universities together trying to design useful tools for the community.

How can people participate, help, or just learn more about it?

Follow the code! There are articles, presentations at Erlang Factories, Erlang User Conferences, Erlang Workshops …

What’s your advice for the next generation of Galician BEAMers?

(this one in Spanish, considering the target audience)

Yo no empecé a programar con 10 años. Llegué a la universidad sabiendo escribir en un procesador de textos y poco más. Tenía la sensación de que todo el mundo me llevaba mucha ventaja.
Pero la programación funcional era desconocida para la gran mayoría (y lo sigue siendo, aunque cada vez menos). Además de gustarme, sentí que si me especializaba en ella, sería más fácil destacar. Sería más fácil conectar con otras personas con una sensibilidad parecida.
No me equivoqué.
Mi madre siempre ha dicho: “¡Vale más ser cabeza de ratón, que cola de león!”

Pablo Costas Sanchez

Se ten que errar, que erre!

For Pablo, everything started back in college. Most of their courses were focused on Java and other imperative languages, which he liked but never to this point; thankfully, they were also taught the basics of functional programming and later on in the Concurrency & Parallelism course had an assignment in Erlang. He found this language so intriguing and interesting that he ended up asking the professor for a book to learn more about it. Javier Paris, the professor, recommended Programming in Erlang by Joe Armstrong. Pablo binge-read it, and that moment defined his love for the language.

Then he had a course by Laura, although this one was in Elixir, which was so damn fun and practical that he tagged along with a friend and participated in that year’s SpawnFest. After that, he knew for sure that he wanted Laura to be his dissertation supervisor. A year later, she proposed the idea of parallelizing PropEr, and he liked it. Jump a few months of hard work and a few talks with Kostis Sagonas into the future, and there it is: PropEr now has parallel and distributed executions!

When / How did you take your first steps in the Erlang ecosystem?

I got into the community because I had an amazing experience during Lambda Days 2020 in Kraków, where I met wonderful peers (pun intended, I owe you all a dinner) and decided I wanted to help grow the community and for it to continue being as awesome as it is. I got my chance at this when Brujo Benavides asked for help organising SpawnFest, to which my fellow members Bryan Paxton, Paulo and Filipe chimed in.

What motivated you the most to contribute to the community?

Being part of a community means giving back to it when possible. I consider that true both for the open-source software we all depend on and for ecosystems themselves, such as the BEAM community. Given that, the next logical step was actually helping out :)

SpawnFest

SpawnFest is an annual 48-hour online software development contest in which teams from around the world get exactly one weekend to create the best BEAM-based applications they can. Participation in SpawnFest is 100% Free of Charge, and all BEAM languages are welcome!

This year, it’s organized by The Fellowship of the Beam (which, of course, includes Pablo).

What’s that thing that stands out about SpawnFest?

Seeing folks from all over the community come together to build these amazing ideas is really inspiring ❤

How can people participate, help, or just learn more about it?

Sign up for the event if you have not already! You can either register your own team of friends or fill in another form to have us hook you up with a team; we can’t wait to see you there!

What’s your advice for the next generation of Galician BEAMers?

(this one in Galician, considering the target audience)

Antes de nada, benvid@s ao clube da xente guai ;)
Agora en serio, se vos gusta a BEAM, xa sexa por Erlang ou por Elixir, tendes empresas de sobra e traballos dabondo: hai unha empresa en A Coruña mesmamente e se non, hoxe en día, a gran maioría aceptan traballo remoto, así podedes ver mundo se queredes ou seguir disfrutando das terras galegas.
En calqueira caso, se tendes dúbidas, poñédevos en contacto :)

Brujo Benavides

(yes, me… deal with it 😎)

Fai que funcione, logo faino bonito e, se realmente o necesitas, faino rápido. O 90 por cento das veces, se o fas fermoso, xa será rápido. Entón, realmente, simplemente faino bonito!

Brujo started writing code when he was 10, on a Commodore, at school. From then on, he never stopped. He moved from BASIC to QBasic, to Visual Basic, to .NET… until he found Haskell and Smalltalk at the University.
Then, Novamens was looking for someone willing to learn Erlang to develop a VoIP server with it. Brujo immediately fell in love with the language. A few years later, after joining Inaka, he was already giving his first talk at the Erlang Factory SF in 2012 and answering questions from no other than Joe Armstrong himself. 🤯

When / How did you take your first steps in the Erlang ecosystem?

Inakos’ culture was tightly bound to open-source and, as such, we contributed many many projects, tools and libraries that we are still maintaining today, even when the company was dissolved in 2017.
After joining Erlang Solutions, I became a trainer, too and I had the honor to deliver some lessons with Robert Virding, among others.

I started writing this blog back in 2016, mostly to collect the funny bits of my experience with the language, but it grew so much beyond that. So, when the Erlang Ecosystem Foundation became a thing… I knew I had to join!

Now, I work at NextRoll (previously known as AdRoll), a company that also has an amazing culture and gives me and my colleagues lots of chances to keep contributing back to the community, particularly building development tools and mentoring people.

What motivated you the most to contribute to the community?

I’m a big fan of open-source, in general. We use tons of open-source software every day, every second… If we have the chance to contribute back to the people who developed it and forward to more people that may use our tools, I think we must.
Now, particularly for the Erlang Ecosystem, this is a community that welcomed me with open-arms even when I was just some totally unknown mate-drinker from the far south. At the time, that was totally unusual for me and I valued it a lot. It made my desire to contribute even stronger and it still does to this day. Lately, I’ve been developing tools for Erlang (like the formatter, hank, elvis, etc.) mostly because I felt that was one of the things Erlang devs needed the most.

Hank

rebar3_hank is an oxbow code detector for Erlang. It helps you remove dead code that pollutes your projects, like unused macros, unused record fields, and other nasty stuff…

It is developed by Pablo Brud, Diego Calero, and Brujo… and it will soon have an associated paper published by Laura and Brujo for the Erlang Workshop at the upcoming ICFP2021.

What’s that thing that stands out about Hank?

The best thing about Hank is that it’s a tool that other languages don’t have! It might as well be the first time in a long long time that you can do something with your Erlang code, that you can’t do in your Elixir projects. 😎
From a personal perspective, as well, it opened up the doors of the scientific community for me. We were able to write an academic paper about it and give this small hackweek project a certain class and elegance that others don’t have. It can now sit at the grown-ups table, with dialyzer, RefactorErl, and others.

How can people participate, help, or just learn more about it?

Use it! Find bugs and report them.
And, of course, send all the PRs to https://github.com/AdRoll/rebar3_hank

What’s your advice for the next generation of Galician BEAMers?

(this one in Spanish, considering the target audience)

El mundo de la BEAM no es sencillo para los recién llegados, eso es cierto.
No hay escasez de buenos trabajos, pero la mayoría de ellos requiere cierto nivel de experiencia y conocimiento que impide que los estudiantes o recién graduados ingresen fácilmente.
Se están realizando esfuerzos para superar esta brecha. Empresas como Erlang Solutions o LambdaClass tienen programas de capacitación que pueden ayudarlos a obtener la experiencia deseada, y no están solas. Pero es cierto que las oportunidades laborales no surgen en todos los rincones, como ocurre con otros lenguages.
Por otro lado, una vez que se consigue un trabajo en un proyecto basado en la BEAM, no hay vuelta atrás. Nada se sentirá igual después de esa experiencia. No necesitan confiar en mi palabra, simplemente observen cuántos lenguajes están agregando soporte para modelo de actores, pattern-matching, árboles de supervisión, deep tracing… Todas cosas que Erlang ya proveía cuando yo lo conocí hace más de una década… Les garantizo que, una vez que tengan todas esas herramientas a su disposición, van a querer usarlas donde quiera que vayan.
En pocas palabras: conseguir su primer trabajo con Erlang o Elixir puede ser un desafío, ¡pero es uno que realmente vale la pena!
Y una forma realmente genial y divertida de comenzar ese proceso es participar de SpawnFest y/o solicitar una beca de estudios de la EEF.

Miriam Pena

“nunca choveu que non escanpara”

(repetir para si cando as cousas rompen en produción)

Miriam Pena is a computer engineer, graduated from the University of A Coruña who is passionate about building computer systems distributed over several continents that work for millions of simultaneous users. She has worked as an Erlang specialist worldwide, including Sweden, Egypt, the USA, Ireland, and Spain.

Two years ago, she founded, along with other community leaders from Erlang and Elixir, a non-profit foundation called the Erlang Ecosystem Foundation, based in California. Miriam is a member of the board of directors and also leads its Education working group. This non-profit foundation is dedicated to promoting technologies and languages ​​such as Erlang and Elixir, based on the Erlang virtual machine.

She got the Ada Byron Award in 2018 from the Galician College of Computer Engineers and was listed as one of the Inspiring Female Staff Engineers to Watch that same year. This recognition leads her to commit to being more visible and encouraging other women to get into technology.

Since 2015 she works at the marketing company NextRoll, in San Francisco, where she is in charge of designing and implementing critical parts of the real-time data collection used in their Marketing solutions.

When / How did you take your first steps in the Erlang ecosystem?

My first internship was at Igalia, developing a V-LAN switch in Erlang. Then I did my final degree project extending that to make it work with better performance. Little by little, I fell in love with the ecosystem. Later, at Nomasystems, I developed my first highly concurrent systems in production, working on renewable energy, social networks and telecommunications systems … and I simply could not stop…

What motivated you the most to contribute to the community?

I deeply believe in the potential of the Erlang & Elixir ecosystem and the community of developers that are part of it.

The Erlang Ecosystem Foundation

The EEF has a clear goal: to grow and support a diverse community around the Erlang and Elixir ecosystem by helping to develop open-source technologies and projects based on their languages and runtime.

What’s that thing that stands out about the EEF?

From my perspective, it’s the hard work that I’m doing to increase the diversity of the community and for this reason (with the collaboration of the Education group) we are promoting initiatives that increase the number of language users around the world. Lately we are working in collaboration with conferences and workshops to be able to send students and underrepresented people in tech to conferences for free.

How can people participate, help, or just learn more about it?

Perhaps the best thing to do is to just join the foundation’s slack workspace and start talking with us.

What’s your advice for the next generation of Galician BEAMers?

(this one in Spanish, considering the target audience)

Les animaría a probar a programar en Elixir porque tiene una gran comunidad, buena documentación, y gran demanda de trabajo bien pagado (especialmente en remoto). Las aplicaciones escritas en la BEAM escalan muy fácilmente y son fiables. Además, aprender a programar en la BEAM te va a hacer programar mejor en otros lenguajes.

But Miriam, Pablo, Brujo, and Laura are certainly not alone. There are many more Galician folks in the Erlang Ecosystem. So, stay tuned because like our grandmothers used to say…

Quedaches con fame? Fágoche algunha entrevista máis?

Galicia ❤️ The BEAM was originally published in Erlang Battleground on Medium, where people are continuing the conversation by highlighting and responding to this story.

DISCLAIMER
This article is not meant to be an instructive one. It’s written just for fun! 🙃

Erlang is famous for its introspecting powers. You can get a lot of information about the processes running in your nodes without any external tool. One of the functions that provide that information is erlang:process_info/1,2.

Well, this article is not about it. It’s just about this unintuitive but understandable situation we found with Manuel Rubio and Mário Luís Guimarães on the Erlang Slack a long time ago…

1> Pid = spawn(fun() -> receive stop -> ok end end).
<0.85.0>
2> erlang:process_info(Pid) == erlang:process_info(Pid).
false

Where are the Differences?

That situation might not seem strange to some folks. As Manuel pointed out…

Keep in mind that between the first erlang:process_info/1 running and the second one, the World™️ is moving around 😄

But I wanted to know exactly what was moving around there…

3> erlang:process_info(Pid) -- erlang:process_info(Pid).
[{reductions,4009}]

OK. Clearly, the number of reductions is what’s changing…

4> {erlang:process_info(Pid, reductions), erlang:process_info(Pid, reductions)}.
{{reductions,4011},{reductions,4011}}

Let’s try in a different way…

5> {I1, I2} = {erlang:process_info(Pid), erlang:process_info(Pid)},
5> {I1, I2}.
{[{current_function,{prim_eval,'receive',2}},
  …
  {reductions,4011},
  …
  {suspending,[]}],
 [{current_function,{prim_eval,'receive',2}},
  …
  {reductions,4012},
  …
  {suspending,[]}]}
6> f(I1), f(I2),
6> {I1, I2} = {erlang:process_info(Pid, reductions), erlang:process_info(Pid, reductions)},
6> {I1, I2}.
{{reductions,4013},{reductions,4013}}

Alright, so… reductions are increased by one, but only when you get certain pieces of information from the process. Interesting.

What’s going on here?

But then… What are those reductions anyway?

According to the docs…

{reductions, Number}

Number is the number of reductions executed by the process.

This explanation might seem silly at first, but it does contain a vital piece of data: “executed by the process”. We’ll see what a reduction actually is in a second, but we already have something unexpected here. Counterintuitively, it seems that to retrieve some items from a particular process, Erlang needs to execute something in that process.

Let’s first understand what a reduction is in this context. Luckily, the same docs from above provide the explanation, though in a rather unlikely place…

In the Beam emulator, the reduction counter is normally incremented by one for each function and BIF call. A context switch is forced when the counter reaches the maximum number of reductions for a process (4000 reductions in Erlang/OTP 19.2 and later).

With this in mind, it now seems that to retrieve some information from a process, the Erlang VM needs to evaluate a function or run a BIF on that process. Interesting… Let’s dig a bit deeper!

The Costly Bits

First of all, as usual, I wanted to check if this behavior is also seen with compiled code. You know, the Erlang shell is tricky sometimes. But I also wanted to figure out exactly which information items were the costly ones.

I started with this simple module…

The results were the expected ones…

1> c(pi), pi:check().
#{diff => [{reductions,8}],
  pi1 =>
      [{current_function,{pi,wait,0}},
       …
       {reductions,7},
       …
       {suspending,[]}],
  pi2 =>
      [{current_function,{pi,wait,0}},
       …
       {reductions,8},
       …
       {suspending,[]}]}

Notice how the number of reductions matches much more closely what we would expect from a simple process that doesn't do anything.

And now for the more exciting part…

And the Costly Bits of Information are…

2> c(pi), pi:check().
[backtrace,binary,current_function,current_location,
 current_stacktrace,dictionary,links,memory,messages,
 monitored_by,monitors,suspending,total_heap_size]

So, now you know…

Every time you check, for instance, the list of links of a process, the Erlang VM evaluates something (consuming precisely one reduction) in that process.

And that also happens when using erlang:process_info/1 because the default list of items includes current_function, dictionary, links, suspending and total_heap_size.

Even More…

That leads us to the final mystery… If, to return each of the items listed above, the Erlang VM evaluates a thing (that adds a reduction) to the process, how many reductions do you think it should add if we request all those items?

And the result is…

3> c(pi), pi:check().
1

Let’s close this with the usual reminders…

• 💪 SpawnFest is coming!!
• ✍️ Erlang Battleground (this blog) is looking for writers. Please talk to Brujo Benavides if you want to become part of it.
• ☕️ If you like what I write, you can always buy me a coffee.

Spot the Difference was originally published in Erlang Battleground on Medium, where people are continuing the conversation by highlighting and responding to this story.

A long time ago, I wrote an article about The Asymmetry of ++, thanks to Fede Bergero’s findings. Let’s add a few more asymmetries to that list…

Note: This article is based on OTP23. Many things have been improved since that version already.

Introduction

Initially, I thought about writing this article as a story (like I usually do), but I suddenly had too much information on my hands. So, I chose to start with a table/cheatsheet instead.

The goal of the table is to show how the different high-order functions in the lists module react when they’re given bad input, particularly in the argument where they expect a function. This bad input can be either…

• something that’s not a function (e.g. lists:map(not_fun, [1,2,3]) ); or…
• a function with the wrong arity (e.g. lists:map(fun() -> wat end, [a]) ).

Empty Lists

Before we start and to reveal about half of the issue here, let me present you the first asymmetry:

1> lists:map(something_wrong, [1,2,3]). % A non-empty list
** exception error: bad function something_wrong
     in function  lists:map/2 (lists.erl, line 1243)
2> lists:map(something_wrong, []). % An empty list
** exception error: no function clause matching lists:map(something_wrong,[]) (lists.erl, line 1242)

And this happens in all the functions you’ll see below: If you call these functions with a bad first argument and an empty list, you’ll get a function_clause error. The same happens if you call them with something that’s not a list at all. If you call them with a non-empty list, well… keep reading ;)

At least, the lists module is consistently raising function_clauseerrors when the list argument is empty. That’s good.

Non-Empty Lists

What happens when the lists are not empty? To figure that out, I used this:

And these are the results I got…

Findings

So, as you can see, while most of the functions will raise a badfun error if you don’t use a function at all, and a badarity error if you use the wrong function arity, some of them will instead raise a function_clause error in both scenarios.

For context, this is how each of those errors looks as described by the shell…

10> lists:foldl(not_fun, 1, [a,b,c]).
** exception error: bad function not_fun
     in function  lists:foldl/3 (lists.erl, line 1267)
11> lists:foldl(fun() -> {wrong, arity} end, 1, [a,b,c]).
** exception error: interpreted function with arity 0 called with two arguments
     in function  lists:foldl/3 (lists.erl, line 1267)
12> lists:foldr(fun() -> {wrong, arity} end, 1, [a,b,c]).
** exception error: no function clause matching lists:foldr(#Fun<erl_eval.45.79398840>,1,[]) (lists.erl, line 1279)
     in function  lists:foldr/3 (lists.erl, line 1280)

At least from my perspective, the descriptions for the errors are clearer for lists:foldl/3 than they are for lists:foldr/3. And as I told you before, when the list is empty, all of the functions will look like lists:foldr/3(i.e., they'll raise function_clause in every bad scenario).

Is this a Problem?

Semantically, no. All of these functions are not defined for the scenarios I’m presenting so far. Therefore we shouldn’t rely on the errors that they produce when they’re called with improper values.

But, if you are new to Erlang and/or you’re trying some stuff on the console, it’s not unlikely that you call one of the functions above incorrectly. In that case, function_clause can be really confusing, while badfun or badarity ones can more easily guide you towards a solution for your problem.

Furthermore, if, for whatever reason, you need to write code that catches those errors and you don’t want to catch any error (only the specific ones you need), you’ll have to be careful always to handle function_clause in case your input is an empty list.

In other words, this is wrong…

%% @doc similar to lists:all/2 but if the function has the wrong
%%      arity it just returns false.
-spec my_all(fun((...) -> boolean()), [X]) -> boolean().
my_all(Pred, List) ->
    try lists:all(Pred, List)
    catch
        error:{badarity, _} -> false
    end.

because…

45> a_module:my_all(fun(X) -> true end, [a,b,c]).
true
46> a_module:my_all(fun() -> true end, [a,b,c]).
false
47> a_module:my_all(fun() -> true end, []).
** exception error: no function clause matching lists:all(#Fun<erl_eval.45.79398840>,[]) (lists.erl, line 1216)
     in function  a_module:my_all/2

So, you have to write something like…

%% @doc similar to lists:all/2 but if the function has the wrong
%%      arity it just returns false.
-spec my_all(fun((...) -> boolean()), [X]) -> boolean().
my_all(Pred, List) ->
    try lists:all(Pred, List)
    catch
        error:{badarity, _} -> false
        error:function_clause when List == [] -> false
    end.

What would I like to see?

I think the ideal scenario would be for all functions in the table above to have the same error behavior:

• If they receive something that’s not a function where they expect a function, raise badfun, regardless of list length.
• If they receive a function with the wrong arity, raise badarity, regardless of list length.
• If the list or any of the other parameters is wrong (e.g., not a list), raise function_clause.

Basically, behave like lists:foldl/3 but don’t treat empty lists as a special case.

Is this possible?

Yeah! The changes in the list module are actually not that complex. Using lists:map/2 as an example, we “just” need to add these 2 clauses here:

map(F, [H|T]) ->
    [F(H)|map(F, T)];
map(F, []) when is_function(F, 1) -> [];
map(F, []) when is_function(F) -> error({badarity, {F, []}});
map(_, []) -> error(badfun).

Is it worth it?

I don’t know… Maybe? Maybe it’s a good plan for a SpawnFest project? 🙃

Thanks for reading! If you like what I write and you want to encourage me to write more, you can buy me a coffee or just hit me up on the Erlang Slack 😊

How do List Functions Fail in Erlang? was originally published in Erlang Battleground on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working as a mentor in the Education Working Group at The EEF, there are several tiny simple lessons that I’ve delivered over and over again. The one in this article is so common that I already gave it a name: The Robot Butt Rule.

The rule goes like this…

To find if a list is not empty, don’t check its length. Use the robot butt instead.

TL;DR

Thanks to Filipe Varjão on Twitter, you can just skip this whole article.

The Problem

The situation usually arises when some exercise or problem requires the developer to do something with a list only if it is not empty. For instance, return its first or last element. To exemplify this scenario, let’s write a generic function for that scenario: it either returns an error if the list is empty or runs another function on the list if it’s not.

-spec if_not_empty(FunctionType, ListType) -> ErrorType | OKType
    when FunctionType :: fun(([AnyType,...]) -> AnotherType)
       , ListType :: [AnyType]
       , ErrorType :: {error, empty}
       , OKType :: {ok, AnotherType}.

That spec might be a bit too crowded, let’s unpack it:

This is the spec of a function called if_not_empty, with 2 arguments of types FunctionType and ListType, respectively. It can return elements of one of two possible types: ErrorType or OkType.

Elements of type FunctionType are functions that receive a non-empty list of elements of type AnyType ([AnyType,…]) and return an element of another type (AnotherType).

ListType, in turn, is a possibly empty list of elements of type AnyType ([AnyType]).

The result of a function is either ErrorType (that is the tuple {error, empty}) or OKType (a tuple of type {ok, AnotherType}, as in AnotherType, the result of the application of FunctionType).

It’s safe to assume that if_not_empty/2 will return {error, empty} if the list it receives is empty and {ok, Function(List)} otherwise.

Initial Solution

Faced with that specification, developers (particularly folks coming from an object-oriented background) tend to implement their solution like this…

if_not_empty(Function, List) ->
    if length(List) > 0 ->
           {ok, Function(List)};
       true ->
           {error, empty}
    end.

It’s a correct solution, but not the most elegant nor the most performant one.

Before we tackle the performance issue, let’s deal with that nasty nasty if…

Without If

As I’ve said in the past, in Erlang (and sometimes, in general) it is better to stay away from the if statement. So, I generally recommend changing that code and (following another guideline) use function clauses, instead.

That generally ends up in something similar to…

if_not_empty(Function, List) when length(List) > 0 ->
    {ok, Function(List)};
if_not_empty(_, _) ->
    {error, empty}.

Much better! We’re almost there. But, let’s tackle the performance issue: Let’s benchmark this code in a totally unscientific way, just for the sake of exemplifying the situation…

% First, let's create a really long list…
9> LongList = [rand:uniform() || _ <- lists:seq(1, 100000)].
[0.420515222637019,0.8779006956486717,0.8478602700250025,
 0.1570291508306687,0.9922807451124196,0.7020290584226024,
 0.22356701178759975,0.5231326543184913,0.8368749225021561,
 0.6239065648187836,0.4439549897507573,0.7351771695343225,
 0.5519649363326614,0.049439759267886574,0.7885233763802781,
 0.3857834407777109,0.7297454606625307,0.5908430855802675,
 0.2654111104532171,0.7267499922471473,0.3542637164641538,
 0.8517958528371183,0.4310782304329325,0.6897478919755892,
 0.13163761878786606,0.01160366378331068,0.9391918781985158,
 0.9608111320278309,0.9974567206076438|...]

% Then, a function that does nothing…
10> DoNothing = fun(_) -> nothing end.
#Fun<erl_eval.44.79398840>

% And then run some benchmarks…
11> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{182,{ok,nothing}}
12> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{163,{ok,nothing}}
13> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{208,{ok,nothing}}
14> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{232,{ok,nothing}}
15> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{190,{ok,nothing}}

Perfection

At this point, I generally tell the developer three things:

1. You’re not using the whole power of pattern-matching
2. Even when length/1 is written in C, the code still traverses the whole list to compute it.
3. You should use the robot butt!

And what is the robot butt?

Well… This is the robot butt…

if_not_empty(Function, [_|_] = List) ->
    {ok, Function(List)};
if_not_empty(_, _) ->
    {error, empty}.

That expression ([_|_]) will match on any non-empty list because it’s matching on a list with a head and a tail. They’re both disregarded since we used underscores (_) in their positions, but they must exist. And therefore, if the list has a head, it can not be empty.

And you can bet that this implementation is faster than the previous one…

19> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{4,{ok,nothing}}
20> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{4,{ok,nothing}}
21> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{9,{ok,nothing}}
22> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{5,{ok,nothing}}
23> timer:tc(s, if_not_empty, [DoNothing, LongList]).
{3,{ok,nothing}}

So, next time you need to match on a non-empty list, remember to use the robot butt instead of checking its length. 🧐

Of course, you can also reverse the function clause order and match with an empty list in the first clause… but where is the fun in that? 😜

As a matter of fact, if you run this code through the formatter, it will promptly tell you that it should be written as…

if_not_empty(Function, [_ | _] = List) ->
    {ok, Function(List)};
if_not_empty(_, _) ->
    {error, empty}.

Because, of course…

Oh, and don’t forget to register for the upcoming 2021 edition of Spawnfest, organized by The Fellowship of the BEAM!

Ode to the Robot Butt was originally published in Erlang Battleground on Medium, where people are continuing the conversation by highlighting and responding to this story.

While acting as a mentor on the FutureLearn MOOC about Erlang I presented an idea that folks like Adolfo Neto loved (he even tweeted about it 🧡). It is, in fact, the way I introduce people to pattern-matching when I’m teaching them Erlang. It’s a way to write tests that let you naturally work your code out from them… Sounds familiar? Yes! It’s Test-Driven Development!

The Process

I learned TDD when I learned Smalltalk. It was such a life-changing lesson! And Smalltalk was the best environment to learn it since it’s built for it. In Smalltalk, I believe it’s actually harder to write code with a different process. If you didn’t try it already, you definitely should! Follow Hernan Wilkinson, his company (10pines) delivers Smalltalk courses where you can learn this from the experts, among several other great things.

Anyway, for the uninitiated, the general process for TDD is…

What’s not described in the graph (particularly for compiled languages, like Erlang) is that after adding a test, in order to see that test fail, you first need the code to compile. And that, at first hand, may seem difficult. But it’s actually possible, using a nice hot-code-loading related feature of Erlang.

Let’s dive in with an example…

Do we have an extra day?

So, let’s say you have to write a module year with a single function: is_leap/1 . As you might guess, the idea is for that function to receive an integer and return a boolean telling you if it’s a leap year or not.

Add Tests

For the first step, we will already use the magic trick I mentioned above. Look at the module we’ll write…

-module year.
-export [test/0].

test() ->
  false = year:is_leap(1),
  ok.

Let’s dissect this thing…

The first two lines should be pretty obvious. We define the module and export test/0, which is the function we’ll use to run the tests.

Then we write the test/0 function. That function will just contain a series of assertions like most test functions do, specifying the expected results of our function is_leap/1.

The first assertion says that 1 is not a leap year. But pay attention to the fact that even when we’re going to eventually define is_leap/1 in this same module, we’re using the fully-qualified version of it (year:is_leap(…)) instead of just writing is_leap(1). Why? Hot-Code Reloading, of course!

The Erlang compiler will fail if it finds a call to an internal function that is not defined, it won’t compile your module and therefore it won’t run the test. Except… if you use a fully-qualified call. Because thanks to the logic behind hot code loading, you can totally define that function in a later version of the module.

That is super-useful for us since now we can…

See Tests Fail

1> c(year).
{ok, year}
2> year:test().
** exception error: undefined function year:is_leap/1
     in function  year:test/0 (year.erl, line 5)

Write Code

Great! Now our test tells us that we need to define is_leap/1 … So we do!

-module year.
-export [test/0].
-export [is_leap/1].

test() ->
  false = year:is_leap(1),
  ok.

is_leap(_) -> false.

Run Tests

We try compiling and running our tests in a more succinct way so we can use up arrow each time we go to the console… oh, lazy lazy developers!

3> c(year), year:test().
ok.

Rinse and Repeat…

Well… this is good! Now let’s add more assertions to our tests…

-module year.
-export [test/0].
-export [is_leap/1].

test() ->
  % regular years are not leap
  false = year:is_leap(1),
  false = year:is_leap(1995),
  false = year:is_leap(1997),
  % multiples of 4 are leap…
  true = year:is_leap(1996),
  true = year:is_leap(2004),
  true = year:is_leap(2008),
  % …except if they're multiples of 100…
  false = year:is_leap(1800),
  false = year:is_leap(1900),
  false = year:is_leap(2100),
  % …except if they're also multiples of 400…
  true = year:is_leap(1600),
  true = year:is_leap(2000),
  true = year:is_leap(2400),
  ok.

is_leap(_) -> false.

…aaand…

5> c(year), year:test().
** exception error: no match of right hand side value false
     in function  year:test/0 (year.erl, line 11)

Line 11 is the one for 1996 (as expected)… We now fix our code for that case, run the tests again… Many iterations go by… etc…

I’ll jump to the final version for brevity…

-module year.
-export [test/0].
-export [is_leap/1].

test() ->
  % regular years are not leap
  false = year:is_leap(1),
  false = year:is_leap(1995),
  false = year:is_leap(1997),
  % multiples of 4 are leap…
  true = year:is_leap(1996),
  true = year:is_leap(2004),
  true = year:is_leap(2008),
  % …except if they're multiples of 100…
  false = year:is_leap(1800),
  false = year:is_leap(1900),
  false = year:is_leap(2100),
  % …except if they're also multiples of 400…
  true = year:is_leap(1600),
  true = year:is_leap(2000),
  true = year:is_leap(2400),
  ok.

is_leap(Year) ->
  is_leap(Year rem 4, Year rem 100, Year rem 400).

is_leap(_, _, 0) -> true;
is_leap(_, 0, _) -> false;
is_leap(0, _, _) -> true;
is_leap(_, _, _) -> false.

et voilà…

7> c(year), year:test().
ok

More Complex Stuff

Of course, this technique only works for very small pieces of code that should not reach production. You don’t want that test code messing up your releases!

But if you choose Common Test as your testing framework, a suite for this module will look eerily familiar…

-module year_SUITE.

-export [all/0].
-export [is_leap/1].

all() -> [is_leap].

is_leap(_) ->
  % regular years are not leap
  false = year:is_leap(1),
  false = year:is_leap(1995),
  false = year:is_leap(1997),
  % multiples of 4 are leap…
  true = year:is_leap(1996),
  true = year:is_leap(2004),
  true = year:is_leap(2008),
  % …except if they're multiples of 100…
  false = year:is_leap(1800),
  false = year:is_leap(1900),
  false = year:is_leap(2100),
  % …except if they're also multiples of 400…
  true = year:is_leap(1600),
  true = year:is_leap(2000),
  true = year:is_leap(2400),
  {comment, ""}.

What do you think? Did I convince you to use Test-Driven Development for Erlang? 😉

Simple TDD in Erlang was originally published in Erlang Battleground on Medium, where people are continuing the conversation by highlighting and responding to this story.

As you might know, I’m also working with Juan Bono, Diego Calero, Facundo Olano, and others on our own formatter for Erlang (just like Daniel Tipping is working on steamroller). I could write an article on how our formatter differs from Michał’s but this time I want to focus our attention on a different topic.

Particularly I want to look at the following slide…

Are Formatters “Linters on Steroids”?

Michał presents a concept in his talk that is somewhat widespread and I don’t think it’s correct: The idea that if linters can tell you where you need to improve your code, formatters are better because they can just fix it.

Having worked on both Elvis (a linter) and rebar3_format (a formatter), I do believe that they are complementary but independent tools. They do have some intersection, but the really interesting parts are the ones where they don’t intersect with each other. And I believe this happens as well in other languages, for instance with Credo and mix format for Elixir.

There are things that linters can detect, but formatters can’t fix. To name a few Elvis rules like that:

• Nesting Level: The linter can detect that your code is nested too deeply, but what will the formatter do to fix that? It could theoretically move some lines out to a different function but I don’t think that’s something you would expect your formatter to do, right?
• No debug calls: The linter can tell you that you left some io:format’s in your production code, which is not good. I don’t think the formatter should just remove them. Leaving aside the fact that sometimes it’s not as easy as just removing the calls.
• DRY: My favorite Elvis rule of all time: The linter can identify pieces of code that are repeated. What will the formatter do here? A tool that would actually refactor your code to extract them to a separate function would be amazing but I don’t think the formatter should be that tool.

If only we had a tool to automatically perform all those tasks… Maybe SimonThompson knows one? 🙄

On the other hand, there are things that a formatter can fix and a linter shouldn’t deal with, like:

• Consistent indentation of clauses. The linter can warn you on whether you’re using tabs or spaces for indentation but figuring out if you properly indented all your code using the right number of spaces/tabs is not worth the effort, particularly if you have a tool like a formatter that just fixes that for you.
• Personalization. As I mentioned in my article linked above, I believe that formatters should have room for personalization, so I can read the code in the way I understand it best and you can read the same code in the way that you like it best. We don’t need to fight over comma-first ROK-style, indentation levels, tabs-vs-spaces… As long as we share a format for the code once its pushed, each one of us can work using his/her own style. That’s something that the linter can’t allow since the idea is that the rules enforced by the linter are respected by all of us.

Conclusion

The linter and the formatter are different tools that serve different purposes. The linter will make sure your code is well written and follows the best practices defined by the community or your team. The formatter will make sure that your code is nicely written and easy to understand by any other developer.

A formatter will happily make some linter rules obsolete (which is great!) but it won’t remove the need for it, at all.

In other words…

Don’t stop using a linter when you start using a formatter!

So, I Gusti Ngurah Oka Prinarjaya was reading Joe’s Book and he found one of the most amazing examples of List Comprehensions I’ve ever seen…

perms([]) -> [[]];
perms(List) -> [ [H|T] || H <- List, T <- perms(List--[H]) ].

Output:

1> lib_misc:perms("123").
["123","132","213","231","312","321"]

And, of course… he couldn’t understand it. And, as a seasoned Erlang trainer, I got to tell you: He’s not alone… by any means. After a session of the BeamBA Meetup where I casually tried to explain something even simpler than this, we had to schedule another meetup talk just to explain how recursion works and how to think recursively.

So, let me try to explain how recursion and list comprehensions work together in perms/1, how can one end up with a function like that and how to read it. Let’s see how far I can get in a blog post… and Robert Virding (I know you’re a fan of perms/1) please point out the mistakes I’ll surely make ;)

How to write a function like that?

So, let’s first think of how will we come up with such a beautiful function.

The requirement here is pretty simple:

The function perms/1 should receive a single argument (a list) and return the list of all possible permutations of it.

To understand what it does, let’s write a test for it, shall we? (I’ll use strings, since that’s what Joe used in his book, but any list will do)

Cool, if we try to run that test it will tell us that we need to implement the function…

1> c(joe), joe:test().
** exception error: undefined function joe:perms/1
     in function  joe:test/0 (joe.erl, line 6)
2>

We can start with the base case then… The only permutation of an empty list is itself.

That moved us one step ahead. Cool!

2> c(joe), joe:test().
** exception error: no function clause matching joe:perms("a") (joe.erl, line 13)
     in function  joe:test/0 (joe.erl, line 7)
3>

Now, for the recursive step…

When writing recursive functions, we must assume that we know how to apply the function to a smaller input. In our case, we’re working with lists, so a smaller input can be the tail of the list (since it’s a smaller list). That’s why my first step when writing this code would be something like this…

perms([H|T]) -> … perms(T) ….

In other words, I take the head of the list (H) and apply the function recursively to its tail (T). Now we have to figure out how to move from the list of permutations for T to the list of permutations for [H|T] .

So, let’s say H=a, T=[b,c], then perms(T) == [[b,c], [c,b]] and we want to get to [[a,b,c], [a,c,b], [b,a,c], [c,a,b], [b,c,a], [c,b,a]]. 🤔

The first two are easy to build: [ [H|P] || P <- perms(T) ]. So far, so good. Let’s try it and see what the tests have to say about it.

3> c(joe), joe:test().
** exception error: no match of right hand side value ["ab"]
     in function  joe:test/0 (joe.erl, line 8)
4>

Right… perms("ab") is not equal to ["ab", "ba"] , it’s just ["ab"]. We’re just adding the permutations that have the elements in order, since we’re traversing the list from left to right. We need a different way to reduce our list.

So far we had perms(T) be the list of permutations of the elements in the tail of the list. What if we had access to the list of all permutations of any sublist of the original list ([H|T]) with one element less (i.e. what if for [a,b,c] we could build the list of all permutations for [a,b], the list of all permutations for [b,c], and the one for [a,c]). In that case, to build the final result we will only need to add the missing element to their heads.

Too complex? Well… let’s go step by step… First let’s build all the sublists…

perms(List) -> [List -- [H] || H <- List].

Let’s test that on the shell for a second…

4> c(joe), joe:perms("ab").
["b","a"]
5> c(joe), joe:perms("abc").
["bc","ac","ab"]
6> c(joe), joe:perms("abcd").
["bcd","acd","abd","abc"]
7>

Nice! So… this following code won’t work, but if we could compute the permutations for each of those sublists like this…

perms(List) -> [perms(List -- [H]) || H <- List].

…we would end up with something like…

4> c(joe), joe:perms("ab").
[["b"],["a"]]
5> c(joe), joe:perms("abc").
[["bc","cb"], ["ac","ca"], ["ab","ba"]]
6>

Let me first apply a neat trick here to flatten the list. Something we can easily do in List Comprehensions by just using multiple generators.

perms(List) -> [T || H <- List, T <- perms(List -- [H])].

Again, using a built-up example since the code won’t actually work like this…

4> c(joe), joe:perms("ab").
["b","a"]
5> c(joe), joe:perms("abc").
["bc","cb", "ac","ca", "ab","ba"]
6>

We’re really close there. To get from ["b","a"] to the actual result we want (["ab", "ba"]) we just need to prepend each list with the element we originally removed (which is H in our code). Let’s try that!

7> c(joe), joe:test().
ok
8>

Well… that’s Joe’s code, isn’t it? What did you expect? 😉

How to read a function like that?

Well, that was fun, but what if you are faced with a function like that and your job is to understand it, not to write it. Well, a neat technique you can use it to compute the reductions manually or using the debugger. I’ll do it manually here.

What we’ll be doing is basically emulating the VM work by hand, one step at a time. So, let’s start with a sample expression and let’s see what the VM would do. To be clear: these are not the actual reductions in the VM. I took some liberties, mostly because LCs are just syntactic sugar. But I hope you understand what I’m showing here…

perms("123").
% Second clause of perms/1
[ [H|T] || H <- "123", T <- joe:perms("123" -- [H])].
% Expansion of the first generator
[ [$1|T] || T <- joe:perms("123" -- "1") ] ++
[ [$2|T] || T <- joe:perms("123" -- "2") ] ++
[ [$3|T] || T <- joe:perms("123" -- "3") ].
% Reduction of --
[ [$1|T] || T <- joe:perms("23") ] ++
[ [$2|T] || T <- joe:perms("13") ] ++
[ [$3|T] || T <- joe:perms("12") ].
% Multiple second clauses of perms/1
[ [$1|T]
  || T <- [ [H|T1] || H <- "23", T1 <- joe:perms("23" -- [H])]] ++
[ [$2|T]
  || T <- [ [H|T1] || H <- "13", T1 <- joe:perms("13" -- [H])] ] ++
[ [$3|T]
  || T <- [ [H|T1] || H <- "12", T1 <- joe:perms("12" -- [H])] ].
% Multiple expansion of first generators and --
[ [$1|T]
  || T <- [ [$2|T1] || T1 <- joe:perms("3")] ++
          [ [$3|T1] || T1 <- joe:perms("2")] ] ++
[ [$2|T]
  || T <- [ [$1|T1] || T1 <- joe:perms("3")] ++
          [ [$3|T1] || T1 <- joe:perms("1")] ] ++
[ [$3|T]
  || T <- [ [$1|T1] || T1 <- joe:perms("2")] ++
          [ [$2|T1] || T1 <- joe:perms("1")] ].

Let’s work on perms(“3”) alone for a second…

perms("3").
% Second clause of perms/1
[ [H|T] || H <- "3", T <- joe:perms("3" -- [H])].
% Expansion of the first generator
[ [$3|T] || T <- joe:perms("3" -- "3")].
% Reduction of --
[ [$3|T] || T <- joe:perms("")].
% First clause of perms/1
[ [$3|T] || T <- [[]]].
% Expansion of the generator
[ [$3|[]] ].
% List reduction (and some syntax sugar)
["3"].

And you can work with the other small lists in an analogous manner. So, going back to the original example…

% Multiple expansion of all simple perm/1's
[ [$1|T]
  || T <- [ [$2|T1] || T1 <- ["3"]] ++
          [ [$3|T1] || T1 <- ["2"]] ] ++
[ [$2|T]
  || T <- [ [$1|T1] || T1 <- ["3"]] ++
          [ [$3|T1] || T1 <- ["1"]] ] ++
[ [$3|T]
  || T <- [ [$1|T1] || T1 <- ["2"]] ++
          [ [$2|T1] || T1 <- ["1"]] ].
% Expansion of all simple generators
[ [$1|T] || T <- [[$2|"3"]] ++ [[$3|"2"]] ] ++
[ [$2|T] || T <- [[$1|"3"]] ++ [[$3|"1"]] ] ++
[ [$3|T] || T <- [[$1|"2"]] ++ [[$2|"1"]] ].
% Reduction of cons operator
[ [$1|T] || T <- ["23"] ++ ["32"] ] ++
[ [$2|T] || T <- ["13"] ++ ["31"] ] ++
[ [$3|T] || T <- ["12"] ++ ["21"] ].
% Reduction of ++
[ [$1|T] || T <- ["23", "32"] ] ++
[ [$2|T] || T <- ["13", "31"] ] ++
[ [$3|T] || T <- ["12", "21"] ].
% Expansion of generators
[[$1|"23"]] ++ [[$1|"32"]] ++
[[$2|"13"]] ++ [[$2|"31"]] ++
[[$3|"12"]] ++ [[$3|"21"]].
% Reduction of ++ and cons
["123", "132", "213", "231", "312", "321"].

Et voilà! 🎉

What you see here is kind of the same algorithm I described above:

For each element in the original list, find all the permutations for the sublist that results from removing it, then attach the element to the head of each permutation.

It’s quite a simple algorithm to describe (and thus the resulting function is also quite simple and descriptive) but it might be hard to understand how such an algorithm actually solves the problem. I hope this article brings some light on the subject. 😃

In Other News…

SpawnFest

We’re less than a month away from SpawnFest!
This year it will happen on September 21st & 22nd.
Register your team and join us for FREE to win several amazing prizes provided by our great sponsors!

ElixirConfLA

ElixirConf is coming to Latin America for the first time!
Thanks to our friends from PlayUS Media, we’ll meet in Medellín, Colombia for ElixirConfLA on October 24th & 25th.
It will be an awesome event, you don’t want to miss it :)

Erlang Battleground

We’re still looking for writers. If you want to write on Erlang Battleground, just let us know! ✍️

How to Comprehend Comprehensions was originally published in Erlang Battleground on Medium, where people are continuing the conversation by highlighting and responding to this story.