Another List-Related Asymmetry
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…
…or is it to Erlang Pattern-Matching?
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.
Or how to use Pattern-Matching for Tests
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…
So, I just watched Michał Muskała’s talk at CodeBEAMSF, and I have something to say…
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…
Particularly for Erlang
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. …
Let’s go back to the origins of this blog with a bit of unexpected code behavior. This time, let’s try removing elements from a list…
Let’s Subtract!
The beauty of this trick is that the code examples work in both Erlang and Elixir, with barely any changes at all… I’ll do it in Elixir, feel free to try them out in Erlang or efene if you like.
Now, this is a list…
iex(1)> [1, 2, 3]
[1, 2, 3]And now, we can subtract a few elements from it…
iex(2)> [1, 2, 3] -- [1, 2]
[3]Let’s now subtract that last…
…or Why you should use specs if you use opaque types
Following the steps from Devon and Stavros, I wanted to write this article to highlight a not so obvious dialyzer lesson about opaque types and specs…
TL;DR
For the impatient ones…
If you define an opaque type, you have to add specs to all the exported functions that use it (i.e. your module’s API).
Opaque Types
Since this article is about opaque types, I will do a quick intro first…
In Elixir, there are 3 ways to specify a user-defined type:
@type t1 :: boolean | atom # this type is exported
@typep t2 :: String.t ……for Erlang & Elixir
A few months ago, Fred gave me a copy of his latest book (Property-Based Testing with PropEr, Erlang, and Elixir) so I could review it. So, here I am, returning the favor. But I’ll also use this chance to express some of my feelings and opinions about Property-Based Testing in general, since reading the book elicited quite a few of them. This will not be one of the usual articles on this blog, but I hope you’ll enjoy it anyway.
The Book
In a nutshell, this book is a very extensive and detailed manual/hands-on-tutorial with which you’ll first learn the general concepts…
A while back this question popped up in one of the many places where the Erlang community gathers, I think it was IRC:
How many functions do you have in your Erlang node?
As an answer, Craig posted this beauty:
1> length([{M,F,A} || {M,_} <- code:all_loaded(), {exports,Fs} <- M:module_info(), {F,A} <- Fs]).
2531
2> length([{M,F,A} || {M,_} <- code:all_loaded(), {exports,Fs} <- M:module_info(), {F,A} <- Fs]).
2539
3> {ok,2}.
{ok,2}
4> length([{M,F,A} || {M,_} <- code:all_loaded(), {exports,Fs} <- M:module_info(), {F,A} <- Fs]).
2628
What’s going on here?
As usual, it’s better if you try understanding this by yourself. If you are up for the challenge…
The year was 2008. I had a steady job as a .NET developer. Then I read an ad from a company that was looking for developers with knowledge of Erlang… or functional programming in general and I applied.
I had learned a bit of Haskell in college and I loved it but I was not even remotely close to having experience in functional programming. Nevertheless, something told me that it was the right path.
Totally unprepared but ready to just improvise and see, I arrived at Novamens for an interview. I met Juanjo there but, more importantly, I met Erlang!
…
