DEV Community: P. Schreiber 🧙🏻‍♂️🔮🐐

Prolog first steps: predicates, metapredicates, lambdas

P. Schreiber 🧙🏻‍♂️🔮🐐 — Sun, 30 Jun 2024 00:11:24 +0000

I first became interested in Prolog after I watched a talk by Joe Armstrong, creator of Erlang, in which he mentioned this small, niche language twice. The first time, he explains how he took inspiration from the Prolog syntax to write Erlang's. The second, he mentions that if he were to choose only 4 languages to learn, Prolog would be among them.

I have always found it super instructive to learn languages that are very distinct from one another. There isn't much to learn from a third dynamically-typed imperative language. But coming from, say, imperative to fuctional or, in this case, logical paradigm is quite the mind-bending experience. It makes us see things we think we know from a different angle, and provides new ways of expressing ideas and operations.

This is my first contact with logical programming, so everything here is basic and rudimentary. It is a first step in learning how logical programming works and why it is interesting.

Deductions: logical results

Prolog provides a very interesting functionality, one that I haven't seen in other languages. While all languages provide results for problems such as,

Let X = A, Y = B, what is the result R of X + Y ?

Prolog provides a way to find all possible values of variables that make a problem true. For example,

Let X + Y = R, what are the possible values of X and Y for which R = C

Predicates: defining our data set

In Prolog, we define relations between terms. These relations are called predicates, statements that evaluate to true. Let us define some.

% astrology.pl 

ruler(aries, mars). 
ruler(taurus, venus). 
ruler(gemini, mercury). 
ruler(cancer, moon). 
ruler(leo, sun). 
ruler(virgo, mercury). 
ruler(libra, venus). 
ruler(scorpio, mars). 
ruler(sagittarius, jupiter). 
ruler(capricorn, saturn). 
ruler(aquarius, saturn). 
ruler(pisces, jupiter). 

element(taurus, earth).
element(virgo, earth).
element(capricorn, earth).
element(aquarius, air).
element(libra, air).
element(gemini, air).
element(pisces, water).
element(cancer, water).
element(scorpio, water).
element(aries, fire).
element(sagittarius, fire).
element(leo, fire).

Undefined possible relations such as ruler(aries, pluto) evaluate to false.

Queries: deducting results from the data set

Let us generate some new information from the data we have, using logical deduction.

Get a value from relations

Suppose we have two friends whose star sign we do not know, but for whom we can imagine, from their personality, their ruler planets and elements. We can deduce their signs based on those traits.

To extract values from queries, we use variables, terms starting with an uppercase letter.

?- element(Sign, fire), ruler(Sign, sun).
Sign = Leo.

Alfred is has a fiery spirit and a sunny personality. By deduction, his sign is no other than Leo.

?- element(Sign, water), ruler(Sign, mars).
Sign = scorpio.

Beth loves the ocean, and is very combative, like the god Ares. By deduction, her sign has to be scorpio.

?- element(Sign, water), ruler(Sign, venus) .
false.

Charles also loves the ocean, and is beautiful like Aphrodite. But there is no sign that fits this combination. Our assumptions about him must be wrong.

Get multiple valid results from relations

In our premises, we have not defined any direct relation between planets and elements. However, planets rule signs, therefore we can establish indirect relations. For example, we can ask for planets that have the earth element; in other words, "what is the planet X that rules some sign Y of the earth element?"

?- element(Y, earth), ruler(Y, X).
Y = taurus,
X = venus ;
Y = virgo,
X = mercury ;
Y = capricorn,
X = saturn.

Prolog is telling us that Venus, Mercury, and Saturn are ruled by earth signs (taurus, virgo, capricorn). It is noteworthy in our dataset, while a single sign has a single element (1-n), a single planet may have multiple elements (n-n).

?- element(Y, air), ruler(Y, X).
Y = aquarius,
X = saturn ;
Y = libra,
X = venus ;
Y = gemini,
X = mercury.

We see that Saturn and Mercury are also air planets in this world.

Get a list of valid results

As we saw, a planet may have multiple elements based on its ruled signs. Let us try now to get the elements of a certain planet. This time, we will wrap those in a list, using the buit-in predicate findall/3.

elem(El, Planet) :-
    element(Sign, El), ruler(Sign, Planet).

?- findall(El, elem(El, mercury), Elements).
    Elements = [earth, air].

First, we wrap the same query for elements of some planet from the previous topic in a function (more precisely, in a conditional predicate). Functions in Prolog are Horn clauses, a form of implication that reverses the position of p -> q to q <- p, or "q if p", in natural language.

Our Horn clause states that, "E is the element of a planet P if E is the element of a sign S, and the sign S is the ruler of the planet P".

Then we find the elements of the planet Mercury, and throw those in a list. The built-in predicate findall/3 evaluates all elements for which P(El, ...) is true, and appends them to a list of valid elements.

One amazing feature of Prolog is that, because it deals with values that evaluate to two, the elem/2 serves not only to find elements of a planet, but also planets of an element! In other words, we can query both elem(E, mercury) and elem(earth, P), and both return the valid results that we look for. It is a feature I have never seen in a language.

Metapredicates

Metapredicates are the logical programming equivalents of higher-order functions in functional programming. They are predicates that have predicates as arguments. The predicate findall/3 mentioned earlier is such an example.

Metapredicates are very useful generalizations on common operations. We may go beyond the metapredicates already predefined in the standard library, and define our own.

For example, suppose we want to judge whether all planets in a list of planets are rulers of some sign. We may define a predicate all_rulers, such as:

all_rulers([]).
all_rulers([P|Ps] :-
    ruler(_, P),
    all_rulers(Ps). ?- all_rulers([mercury, sun]).
true

?- all_rulers([mercury, pluto, sun]).
false

The predicate is defined recursively, and states that all planets are rulers if the first element of the list is a ruler, and all other elements are also rulers.

Judging whether all elements in a list are true according to some condition is so useful that we would be wise to define a general operation that accepts not just ruler/2, but any condition.

ruler(P) :- ruler(_, P)

all([], _).
all([E|Es], Pred) :-
    call(Pred, E),
    all(Es, Pred).

?- all([mercury, sun], ruler).
true

Lambdas

We have an inconvenient limitation in our program: all/2/ only accepts as arguments predicates with arity 1 (i.e. that take one argument). That is becase we make use of call(Pred, E), which applies the current element to the predicate.

To further generalize our metapredicate, we can make use of lambdas, anonymous predicates that allow us not only to apply predicates of different arities, but also to define predicates on runtime.

Let's define another metapredicate any, which judges whether any element in a list is valid according to a condition.

any([], _) :- false.
any([E|Es], Pred) :-
    call(Pred, E);
    any(Es, Pred).

?- pack_install(lambda).
true.

?- use_module(library(lambda)).
true.

?- any([pluto, mercury, uranus], \X^ruler(_,X)).
true

?- any([pluto, uranus], \X^ruler(_,X)).
false.

The metapredicate any/2 is very similar to all/2, except that instead of using AND operators (,), it uses OR operators (;); in other words, any/2 is true if the predicate for the first element of the list is true, or if it is true for some other subsequent element.

This time, we are not passing a predicate previously defined in compilation, but rather a dynamic predicate with a lambda (we install and require the lambda package first). Lambdas empower us to call a 2-arity predicate such as ruler/2 by wrapping it in an anonymous 1-arity anonymous predicate.

Conclusion

Prolog is an interesting language, with a mind-bending paradigm. In this article, we have explore some of its features, such as:

getting bidirectional results;
finding multiple solutions to a problem using variables;
defining functions as Horn clauses;
generalizing particular predicates into metapredicates;
stating anonymous predicates with lambdas.

I hope you liked this article, and I look forward to exploring Prolog further. I have just started using this language, so I apologize for any incorrect terminology or explanations. If you have any comments or suggestions, I'll be happy to read them.

12 great music records for programers

P. Schreiber 🧙🏻‍♂️🔮🐐 — Fri, 23 Feb 2024 14:57:59 +0000

Our senses can really influence our mood, actions, and ideas. Great art is inspirational, and it is a wholesome companion to our day to day work.

Many programmers I know are music geeks, or at least have some interest in music. So, I want to give my recommendations for 12 music albums that I think are great to listen while programming. I have put these albums in three categories:

Inspirational: for when we want to discover, explore and come up with great ideas
Energetic: for when we need a boost of energy to power through the work
Chill: for when we just want to enjoy our happy lives

Searching for inspiration

These are albuns for when we know what we need to do, but still need to discover how to do it. We want inspiration, and this is exactly what they provide.

"Stone Flower", Antônio Carlos Jobim

Widely recognized as the greatest composer of Brazilian music, every album of Antônio Carlos Jobim's discography is worth the listen, as an exploration of the wide range of his musical creativity and influence in the most varied genres: samba, bossa nova, jazz, classical music, and more.

"Stone Flower", released in 1970, features some of Jobim's classic songs in orchestral arrangements that elevate even higher the already esteemed sounds of bossa nova and jazz. It is a mostly instrumental, elegant, and joyful record.

Highlights: Sabiá, Brazil

"Peer Gynt", Edvard Grieg

It is a little scary to talk about classical music, as its aura produces such awe and the fear of blasphemy. But let me try, if only to inspire readers to try this great record.

"Peer Gynt" was composed around 1870's by Edvard Grieg as a musical accompaniment (a soundtrack, so to speak) to the play by Henrik Ibsen, and later worked into a standalone musical suite. The music has a distinct dramatic and narrative sound, and the listener can really feel immersed in the different settings of the story that is being told: a story of dangerous adventures in distant lands.

Each track in the suite paints a distinct picture, and it is very album-like in this sense. Some give the vibe of the idyllic Norwegian countryside village, while others present the otherworldly setting of fairy tales, magical woods and eerie dungeons.

While this is not my favourite work by Grieg (that would be the magnificent Piano Concerto in A Minor), it is a truly pleasant and fun listen.

Highlights: Morning Mood, In The Hall of the Mountain King

"The Inner Mounting Flame", The Mahavishnu Orchestra

The 1971 debut record of John McLaughlin's Mahavishnu Orchestra is a turning point in modern music, stretching the limits of the avant-garde music explorations initiated by Miles Davis' jazz fusion classic Bitches Brew. The band applies unparalleled technical prowess to the most different sounds, with influences from Eastern and Western music, to create a truly spiritual experience.

Take, for example, "A Lotus on the Irish Streams". Luckily for us, the name of the track gives us a hint of what to expect: it is a mix of celtic folk, beautifully led by the melody of the violin, with some Indian-sounding guitar reminiscent of a sitar. I have to admit that it can be hard to grasp what is happening sometimes, when everything in this record is so fast and crazy. But there are beautiful moments, such as the aforementioned track or the contemplative "You Know, You Know".

To some people, this record may sound self-indulgent. But if you like to hear some crazy guitar shredding, insane drums, that kind of stuff, give this one a try.

Highlights: Meeting of the Spirits, Vital Transformation, You Know, You Know

Powering though

When programming, sometimes what we need is a boost of energy, some nurturing of our will to exist, in order to power through challenging tasks.

This is a list of albums for when you want to code while headbanging, playing air drums and singing (or growling) loudly.

"Blackwater Park", Opeth

The sheer brutality of this record is almost unmatched, even when we talk about metal music. Even in the first moments of "The Leper Affinity", this album throws the listener into an absolute maelstrom of dark matter.

This is the prime example of progressive death metal, taking inspiration in the inventiveness of progressive rock giants such as King Crimson or Genesis, and applying that to the technically challenging and insanely fast sound of death metal. By using a mix of weird scales and odd tempos, the band achieves such face-melting riffs unheard since the times of the first Black Sabbath albums.

Highlights: The Leper Affinity, The Drapery Falls

"Saosin", Saosin

Arguably one of the best albums in the post-hardcore genre, this album is an unbroken string of bangers from start to finish.

The guitar work is beautiful, with thick riffs and fast arpeggios, tastefully mixed to sound not like pretentious guitar metal, but balanced, impressive, and super cool.

The singing does away with the violent growls that are a staple of the screamo genre, which can sound too harsh or tiresome for some people, and rather focuses on high-pitch screams on the livelier passages. The lyrics are much clearer than the arcane verses of previous iterations of this band, making them super catchy and making the listener feel in a concert, screaming, "We speak in different voices!" while banging keys on the code editor.

Highlights: It's Better to Learn, Come Close, Voices

"Inspiration is DEAD", Ling Tosite Sigure

Ling Tosite Sigure plays a mix of post-hardcore and shoegaze that features all the characteristics of both genres, while also presenting a unique and immediately recognizable sound.

You can expect to find shoegaze walls of sound, intensely distorted, delayed and reverbed guitars; also, post-hardcore screaming high vocals, fast-tempo guitar arpeggios and insane drum rolls. But what makes this band special is that it has so much character.

First, the band is a power trio, i.e. drum, bass, guitar. This is a perfect band formation because you can hear each instrument very distinctly. Not having two guitars makes the bass really slap: think Black Sabbath, Rush, The Jimi Hendrix Experience.

Second, the vocals are so weird that it may take some time to get used to. At first listen it may even sound bad. But at the same time, they are super cool. TK and 345 both sing, and the boy-girl dynamic makes a colourful mix of sweet, aggresive, soft and harsh sounds.

Highlights: Disco Flight, am 3:45, I Not Crazy Am You Are

Chilling

Different moods are good for different tasks. Sometimes, what we need is to just chill and do what we are confident in.

These are records for when you want to code while vibing and enjoying life, thinking about the weekend that is coming.

"No. 4", Serge Gainsbourg

Last year I decided to dive deep in Serge Gainsbourg's discography, and while there is much to talk about many of his records, I believe this the masterpiece. No. 4 is a mix of many artistic expressions: poetry, jazz, rock, bossa nova, samba, pop.

Though time has made records made in the 60's sound old or vintage, this record is incredibly modern and forward-driven in its artistic explorations: For example, "Baudelaire" sets the lyrics of XIXth century poetry to the sounds of bossa nova and samba, offering a sunny, tropical and sensual take on the words of a poet whose work is commonly associated to a sinister aesthetic of dark rooms, smoke and absinthe. Also worthy of note are the sick electric organ solos that sound like a weird French precursor to The Doors.

Highlights: Black Trombone, Baudelaire, Intoxicated Man

"At Home", Paddy Reilly

"The voice of Ireland", wrote some wise YouTube commenter.

Paddy Reilly, the great guitarist, singer, and one could even say at one point frontman of the legendary band The Dubliners, dropped this killer record in 1972. There is no mix of styles here, no avant-garde sound explorations, just the purest, most beautiful sound of Irish balladry.

Paddy's voice is powerful and heartwarming, and while marked by a strong and beautiful Irish accent, his words are clear, and wrap the listener in the most varied stories, from heroic war songs of rebellion to the love stories of whiskey-filled drunks. This is a record that just makes me want to take arms against the British and die in the arms of a golden-haired maiden.

Highlights: The Foggy Dew, Come Out Ye Black and Tans, The Limerick Rake

"Canta en Español Con Los Panchos", Eydie Gormé

I first heard this record when searching for the original Spanish version of the Dalida song "Histoire d'un amour". The Frech version is beautiful in its own term, providing a mix of the Latin rhythm of bolero with the melodramatic charm of the chanson française. But Eydie Gormé's version is superior to my ears for being livelier, more cheerful, showing, even if the lyrics are sad, the inherent beauty of a love story.

The 1964 record is a collaboration between the American singer and the Mexican trio, and is a beautiful display of the warm and colourful charm of Latin American music. Eydie Gormé's voice is soft, sweet, and elegant, with the perfect dose of drama (a character that can sometimes be excessive in such a genre as bolero), and a clear and charming accent. Los Panchos' guitars are expressive, sharp, and act like singers themselves.

This is definitely a record to put us in a good mood, reminding us of warmth, sunshine, dancing, love, and other joys of life.

Highlights: Historia de un Amor, Quando Vuelva a Tu Lado, Sabor a Mí

Pretty writing in Emacs: exporting Org files to PDF

P. Schreiber 🧙🏻‍♂️🔮🐐 — Thu, 15 Jun 2023 14:58:39 +0000

Introduction: Org to LaTeX to PDF

There are two types of Emacs users: those who give up and go back to vscode, and those who get full citizenship and move permanently to Emacs town. This article is for those masochists who don't care if Google provides an easier tool for writing pretty texts and code notebooks.

Org-mode is an awesome tool for writing multi-purpose text in Emacs. It can be used for literate programming (like Jupyter Notebooks) in any languages we want, for todo-lists and schedules, for articles and much more.

We have been using Org files for our own notetaking for a few months now, but until yesterday we didn't really explore the export and publish functionalities, which allow us to transform org texts into formats used in the world outside of Emacs, and package a collection of texts into a cohesive unit. (we will not explore publish in this article, as we have not yet used it).

We want to configure Emacs to export an Org text to a pretty PDF. Let's use this article, which we are currently writing in org-mode (inception!) as an example. Our objective is to use org-export-dispatch (C-c C-e) to export to LaTeX as PDF file and open.

LaTeX: what is it, installation, exporting PDF

The first step in our pipeline from Emacs Org to PDF is exporting our document to LaTeX. Emacs can't do that if the program is not installed. So, before we try to export our Org file, let us make sure that we can correctly produce a PDF from LaTeX code.

What is LaTeX?

From the LaTeX documentation:

LaTeX is a high-quality typesetting system; it includes features designed for the production of technical and scientific documentation. LaTeX is the de facto standard for the communication and publication of scientific documents.

In this sense, LaTeX is a hierarchical text definition language, like markup or html, which allow us to describe the role of each section in the context of the whole text. This is an example of LaTeX code, taken from the docs.

    \documentclass{article}
    \title{Cartesian closed categories and the price of eggs}
    \author{Jane Doe}
    \date{September 1994}
    \begin{document}
       \maketitle
       Hello world!
    \end{document}

The documentclass section describes the template for the output document; in other words, the style, which is defined in the LaTeX document template.

In summary, LaTeX is a language and a program for:

hierarchical text definition language (like markup, html)
format and style definition language (like css)
text processing program

Installation

If we open the LaTeX Project GET page, we will find the recommended distributions for the most popular operating systems. We are configuring this on our MacBook Air, so we should get MacTeX. However, the complete MacTeX bundle is 5GB, which is absurdly huge for our humble project. Rather, let us go for the much smaller 90MB BasicTeX.

The BasicTeX .pkg file is very much plug and play, as it installs the binaries to folders already supported in the terminal PATH. For generating a PDF from LaTeX code, will use XeLaTeX, an improved version of LaTeX with support for unicode and special fonts.

Fixing problems and exporting the PDF

Even the minimal BasicTeX comes with the necessary tools to generate a PDF. Therefore, we should be ready to export our PDF after the installation. Let's save the the LaTeX code example provided earlier as article.tex and try exporting it to PDF by using the xelatex article.tex command.

In our machine we have encountered some problems, registered in a .log file. Let us see what they are and how to solve them.

    $ xelatex article.tex
    ...
    (/usr/local/texlive/2023basic/texmf-dist/tex/latex/amsmath/amsopn.sty))
    (/usr/local/texlive/2023basic/texmf-dist/tex/latex/amsfonts/amssymb.sty
     (/usr/local/texlive/2023basic/texmf-dist/tex/latex/amsfonts/amsfonts.sty))

    ! LaTeX Error: File 'wrapfig.sty' not found.

The error is very clear. LaTeX cannot find the wrapfig package. Our distribution must have come without it. The good thing is that the error message even shows us where to put it. The fix is easy, we just download the file and store it where the error pointed us, maybe in the graphics/ folder:

    $ wget http://mirrors.ctan.org/macros/latex/contrib/wrapfig/wrapfig.sty
    $ sudo mv wrapfig.sty /usr/local/texlive/2023basic/texmf-dist/tex/latex/graphics/wrapfig.sty

If we run xelatex article.tex again, we get a different error, and that is progress; it means the first problem
was solved. Here is the second error:

    $ xelatex article.tex
    ...
    (/usr/local/texlive/2023basic/texmf-dist/tex/latex/amsmath/amsopn.sty))
    (/usr/local/texlive/2023basic/texmf-dist/tex/latex/amsfonts/amssymb.sty
    (/usr/local/texlive/2023basic/texmf-dist/tex/latex/amsfonts/amsfonts.sty))

    ! LaTeX Error: File 'capt-of.sty' not found.

This is almost the same error as before. LaTeX cannot find the capt-of package. The solution here is a bit more challenging, because the source does not provide the .sty file (don't ask us why). We have to compile it ourselves.

    $ wget http://mirrors.ctan.org/macros/latex/contrib/capt-of/capt-of.dtx
    $ wget http://mirrors.ctan.org/macros/latex/contrib/capt-of/capt-of.ins

    $ xelatex capt-of.ins

    $ sudo mv capt-of.sty /usr/local/texlive/2023basic/texmf-dist/tex/latex/caption/capt-of.sty

Now, if we run xelatex article.tex, we get a beautiful article.pdf exported by LaTeX. Awesome.

Running on Emacs

The essential part is basically done. All we have to do now in order to export our org files to PDF is telling Emacs what LaTeX compiler and command to use. For that, just add to the elisp configuration file (e.g. init.el):

    (setq org-latex-compiler "xelatex")
    (setq org-latex-pdf-process '("xelatex %f"))

We can now run M-x org-export-dispatch (C-c C-e) to export to LaTeX as PDF file and open (options l-o), just like we wanted. In fact, we have done it in just the org file for this article, and it worked beautifully.

This concludes our explanation of how to export an Org text to a pretty PDF. One thing to add is that we are not academics who produce papers frequently, so our knowledge of LaTeX is very limited. Feel free to leave any suggestions and corrections in the commentaries.

Transparent execution of Fortran code from the Erlang machine using ports

P. Schreiber 🧙🏻‍♂️🔮🐐 — Fri, 10 Mar 2023 00:31:14 +0000

Transparent execution of Fortran code from the Erlang machine using ports
1. The plan
2. The Fortran program
3. The Erlang program
4. Conclusion

Joe Armstrong, creator of the Erlang programming language, said a couple of times that, though the Erlang system is the perfect tool for writing programs designed for concurrent execution, it is not the best tool for compute-intensive tasks, such as numerical calculations. Those tasks, he said, would be best served by calling an external program written in Fortran.

The problem, however, is that he never told us how to run such a program from inside the Erlang machine.

Code for this article is available on my Github

The plan

We are going to write a Fortran program that receives input and does some calculations with the values provided by the user. Because our problem here is not how to write Fortran, but rather how to run the program from inside the Erlang runtime, a simple program will do just fine. For this exercise, we will write a program that calculates the force according to Newton's 2nd law.

In order to interface with the Fortran program, we use a genserver process that manages an Erlang port. Ports are Erlang processes that allow running external programs and interact with them in the same way we interact with processes in the Erlang machine, by sending and receiving messages.

Our objective is to call the genserver API in Erlang, have the function transparently execute in the Fortran program (that is, as if it had been called locally), and return the correct result.

    Eshell V13.1.2  (abort with ^G)
    1> f90:start_link("./newton").
    {ok,<0.84.0>}
    2> f90:force(90,80).
    7200

The Fortran program

First, we focus on the Fortran program that will effectively perform the calculations. As we said, we are going to calculate the force using newton's formula, which is, as we all know, defined as: f = m * a.

Let's start with the simplest program possible:

    ! newton0.f90
    program newton
      implicit none
      integer mass, accel

      mass = 90
      accel = 80

      write (*,'(10i0)') force(mass, accel)

    contains
      function force(m, a) result (f)
        implicit none
        integer m, a, f

        f = m * a
      end function force
    end program newton

The program consists of a simple function definition for the Newtonian formula, a couple of variable declarations and assignments, and a write statement that prints the result of applying the function to the variables as arguments.

We compile the program with gfortran newton0.f90 -o newton. Running it in the terminal produces the correct result.

For the next step, we need to process user input:

    ! newton.f90
    program newton

      implicit none
      integer rstat
      integer mass, accel
      character(20) :: input

      do while(.true.)
         do while(.true.)
        read(*,'(A)',iostat=rstat) input

        if (rstat /= 0) then
           stop
        else
           if (input(1:4) == 'mass') then
              call maybe_read_int(mass, 4 + 2) 
           else if (input(1:5) == 'accel') then
              call maybe_read_int(accel, 5 + 2)
           else if (input(1:6) == 'return') then
              exit
           else
              write(*,*) 'bad input' 
           end if
        end if
         end do

         write (*,'(10i0)') force(mass, accel)

         mass = 0
         accel = 0
      end do

    contains
      subroutine maybe_read_int(field, index)
        implicit none
        integer field, index

        read(input(index:), *, iostat=rstat) field
        if (rstat == 0) then
           write(*,'(10i0)') field
        else
           write(*,*) 'bad input'
        endif
      end subroutine maybe_read_int

      function force(m, a) result (f)
        implicit none
        integer m, a, f

        f = m * a
      end function force
    end program newton

The program starts with a loop, which reads the standard input, and assigns its value to a string. The input is matched to the expected patterns:

mass [value]: stores the value in the mass variable
accel [value]: stores the value in the accel variable
return: exits the loop and proceeds to the next step

Next, the program prints the result of the force function over the variables, just like in the previous snippet. Let's compile the program and run it in the terminal to see it in action.

    > ./newton
    > mass 90
    90
    > accel 80
    80
    > return
    7200

Great, we have successfully written a Fortran program that calculates the force using the Newtonian formula. Now, we need to write an Erlang program that is able to run it.

The Erlang program

As we said, we want to be able to call an Erlang function that produces the result from the Fortran program's execution. The appropriate way to do this in Erlang is using ports. Acording to the documentation:

Ports provide the basic mechanism for communication with the external world, from Erlang's point of view. The ports provide a byte-oriented interface to an external program. When a port is created, Erlang can communicate with it by sending and receiving lists of bytes (not Erlang terms). This means that the programmer might have to invent a suitable encoding and decoding scheme.

When to use: Ports can be used for all kinds of interoperability situations where the Erlang program and the other program runs on the same machine. Programming is fairly straight-forward.

Most things in the Erlang system are processes, and ports are no exception. A port is a processes that sends and receives messages from other processes in the Erlang runtime, and sends and receives messages from the external program.

One key difference of message passing from ports to the external program, compared with message passing between processes inside the Erlang runtime, is that internal processes understand Erlang terms (e.g. atoms, tuples, records, maps), while the external program absolutely does not. Everything we can do is send and receive binaries.

This is very similar to what happens in the distributed architecture of microservices implemented in different programming languages. For example, three services running Node, JVM, and Python cannot share objects native to their respective languages. They must instead resort to a common binary (string) protocol (e.g. JSON) for the API, and implement encoding/decoding internally.

Luckily for us, our Fortran program is designed to expect very simple binary patterns. Let's see how we create a port and send and receive messages.

    Eshell V13.1.2  (abort with ^G)
    1> Port = open_port({spawn, "./newton"}, [use_stdio, exit_status]). 
    #Port<0.5>
    2> Port ! {self(), {command, "mass 90\n"}}.
    {<0.82.0>,{command,"mass 90\n"}}
    3> flush().
    Shell got {#Port<0.5>,{data,"90\n"}}
    ok
    4> Port ! {self(), {command, "accel 90\n"}}.
    {<0.82.0>,{command,"accel 90\n"}}
    5> flush().
    Shell got {#Port<0.5>,{data,"90\n"}}
    ok
    6> Port ! {self(), {command, "return\n"}}.  
    {<0.82.0>,{command,"return\n"}}
    6> flush().
    Shell got {#Port<0.5>,{data,"8100\n"}}
    ok

We create a port with the Erlang library function open_port/2, which receives the command to the external program and some options, and returns the port Pid. We use the Pid to send messages to the port, which it will relay to the external program using the stdin.

Here, we are creating a port to the Fortran program "./newton", and sending it three messages. The flush() call reads the messages received by the Erlang shell process. Notice the third message: it is the result of the force() function, executed by the Fortran program!

We are very close to wrapping this up. All that is left is to put this functionality in a genserver that manages the port and provides a clear interface in accordance with the OTP standards.

    %% f90.erl
    -module(f90).
    -behaviour(gen_server).

    -export([start_link/1, force/2, stop/0]).
    -export([init/1, handle_call/3, handle_cast/2]).

    %% API
    start_link(Filename) ->
        gen_server:start_link({local, ?MODULE}, ?MODULE, Filename, []).

    stop() ->
        gen_server:cast(?MODULE, stop).

    force(Mass, Accel) ->
        gen_server:call(?MODULE, {force, Mass, Accel}).

    %% callbacks
    init(Filename) ->
        process_flag(trap_exit, true),
        Port = open_port({spawn, Filename}, [use_stdio, exit_status]),
        {ok, {port, Port}}.

    handle_call({force, Mass, Accel}, _From, {port, Port} = State) ->
        call_port(mass(Mass), Port),
        call_port(accel(Accel), Port),
        Res = call_port(result(), Port),
        {reply, Res, State}.

    handle_cast(stop, {port, Port}) ->
        port_close(Port),
        {stop, normal, []}.

    call_port(X, Port) ->
        port_command(Port, X),
        receive
        {_, {data, Data}} ->
            TrimmedData = string:trim(Data),
            list_to_integer(TrimmedData)
        after 500 -> nil
        end.

    accel(X) -> "accel " ++ integer_to_list(X) ++ "\n".
    mass(X) -> "mass " ++ integer_to_list(X) ++ "\n".
    result() -> "return\n".

We start the genserver with start_link/1 by providing the external program command as argument. The init/1 function runs as a callback, spawns the port, and stores the port Pid in the genserver state.

The force/2 function takes two integers, mass and acceleration, and will callback a handler that sends messages to the port and receives the response from the external program.

With this, we have implemented exactly the functionality we wanted in the beginning: a server that provides a simple Erlang function and produces the result of a calculation done in an external Fortran program.

Conclusion

The computer is an awesome machine, and it provides so many different tools and patterns with which we can create programs. It is a waste of intelligence to be confined to a single programming language.

In this exercise, we showed that with a simple construct, the Erlang port, we can interface with external programs in other languages. Once we set up a common binary protocol between the two programs, we can send and receive messages just like we do inside the Erlang machine, requesting execution and getting back results.

Notes on Russel's Introduction to Mathematical Philosophy

P. Schreiber 🧙🏻‍♂️🔮🐐 — Mon, 08 Aug 2022 22:18:23 +0000

In the Introduction to Mathematical Philosophy, Bertrand Russell describes a philosophical ethos in relation to mathematics, that stands in contrast with the standard practice of mathematicians. Rather than progressing from a set of established principles into complex operations -- from the arithmetics of natural numbers to the algebra of real numbers, and from that to the differentiation and integration calculus -- Russel describes the philosophical ethos as the research of the essence of mathematics, and the logical operations by which we can deduce these foundational principles, such as numbers, sequences, sets and functions.

As mathematics undergoes a process of arithmetisation, in a divergence from formal logic, it follows that, in order to take on the investigation of its principles, it is necessary to define first the fundamental concept of number. As Russell describes it, though the number is an ubiquitous concept in the hundreds of years of the history of mathematics, a clear and correct definition was only formalised and published in recent years, by Frege (Foundations of Arithmetics, 1884). Frege's definition is different to that of Peano, who defines numbers in terms of sequences or progressions, and also subtly different to the philosophers who defined numbers simply in terms of plurality -- one apple, two apples, three apples.
The problems in defining numbers in terms of progressions or plurality are:

Progressions, while they provide a correct knowledge about the relationships of numbers -- according to the function f(x) that determines the successor of x -- they do not provide any knowledge about the number itself and what it represents; if we change the reference to the first element of the sequence, the reference to all elements in the sequence is lost.
Plurality, on the other hand, while it does provide knowledge of a single number in terms of the quantity of objects, it tells us nothing about the number as a number -- and, more importantly, about what numbers are; in other words, it provides a sense of what "three" is, but not of what "number" is.

A precise definition of what a number is requires that we abstract a single quantity into the general concept of all quantities, therefore putting forward the concept of groups -- or, more precisely, classes. Just as we can define a class a with three apples, and a class b with three bananas, we can define a class of all classes with three elements (i.e. all classes similar to a class with three elements, in terms of quantity of elements). Similarly, we can describe a class of all classes with thirty elements, or a class of all classes with three hundred elements.

The number of a class, then, will be the class of all classes similar to it. A number is any entity that is the number of a class.

The definition of numbers in terms of classes is interesting to the student of computer sciences, because of the importance that term has gained since the advent of object-oriented programming. Though I want to tread carefully and avoid the sin of anachronism (we are talking about a text written in 1919, when modern computation by electronic machines was a distant dream), it is worthy of note how Russell describes classes as "logical fictions" -- not real things in and of themselves, but rather a sort of imaginary line traced around objects, grouping them together in terms of some arbitrary common description (generative function; e.g. the class of men, the class of cars).

Am I then accusable of being too hasty and unconsidered in seeing a similarity between this definition of classes with the concept of abstract data types, which is so cherished in the field of object-oriented programming? Of course classes in OOP languages are much more complex structures -- with attributes, behaviours, contracts, interfaces -- than the simple abstractions of classes as "logical fictions" described by Russell; but I do see how we could interpret the latter as the former's source and inspiration.

We could, for example, describe the type specification of a class constructor as its intentional definition, and the instances of a class as its extensional definition. As Russell writes, classes can be defined in two ways: extensionally, in terms of its members, or intentionally, in terms of an abstract description; so, a class A could be defined as:

A = {Jack, Jim}
A = "men in this room now"

As for methods, they describe the relations between objects of this class with other objects in the world.

This approximation was brought to my mind because of a tweet someone posted some other day, about the weirdness of writing numbers as class objects in OOP languages, which leads to constructs such as 10.is_pair(). As we see in Russell's writing, the idea of describing numbers as abstract classes capable of having properties is not an invention of object-oriented programming.

Map, Filter, Reduce in C: recursive high-order functions using pointers

P. Schreiber 🧙🏻‍♂️🔮🐐 — Mon, 04 Apr 2022 20:42:42 +0000

The functional programming journey has a dual aspect: understanding the paradigm conceptually, and applying it in practice on the daily work. When working with the current common tools for programmer, however, we are usually far removed from the arcane knowledge of Haskell and functional Lisp. Sometimes, what we have to do is to find ways to program in a functional style in the languages we use day to day, like Python or Javascript.

Usually, this starts with three techniques which, though simple for someone whose mind is used to functional programming fundamentals, like recursion and higher-order functions, can prove challenging for someone used to the imperative style, for loops and mutable variable assignment. These techniques, which feature in most "functional programming in [blank]" tutorials, are:

map(function, list): produces a new list where the elements are the result of the application of the function to the elements of list in the argument;
filter(function, list): produces a new list where the elements are those where the application of the elements to the function returns true;
reduce: produces the result of the application of the function to all elements over an accumulator.

They are higher-order functions: functions that receive other functions as arguments.

list = 1 2 3 4 5 6

f(x) = x + 2    
map(f, list) = 3 4 5 6 7 8

g(x) = x > 3
filter(g, list) = 4 5 6

h(x,y) = x + y
reduce(h, list) = 21

In this article, we are attempting to implement this functionality in the C programming language. Please note that this is just an exercise, not a recommendation for a serious style of programming in this language.

Considerations for implementing functional tools in C

There are a few things we must consider before we try to implement these functional tools in C.

First, we must remember that, in functional programming, data is meant to be immutable. Therefore, we must make sure that our functions do not alter the values of our variables and data structures, but rather create new variables and data structures, whose values are derived com computations applied to a source.

Second, we must consider that, in C, functions are not first class objects: they cannot be defined inside functions, returned from functions, or passed to functions as arguments. We need to find a way provide our functions with a function to be applied to the values in a data structure.

Implementing a linked list

It is a general rule that recursive algorithms work best with recursively defined data structures: data structures defined by making reference to themselves, such as a linked list or a binary tree.

A linked list is a chain of nodes, each of which contains a value and a reference to the next node (and therefore to the rest of the list).

In functional programming lingo borrowed from Lisp, we can define a linked list in terms of a cons cell, a pair of elements (a, b), where the head is the first element, and the tail is a recursive sequence of cons cells ending on an empty cell.

Our tools -- map, filter, reduce -- are recursive high-order-functions, so it is natural that the lists they iterate over are recursively defined. Our first step should be to define the data type.

We define each element of our linked list as a struct Node containing two values: int data, the value of the node itself; Node *next, a pointer to the next node in the chain. Every node points to a next node, up to the final element in the chain, with points to nothing (nil pointer, or zero).

Also, we define a cons function, which allows us to create a linked list. It receives an integer value and a list to add it to, allocates space in memory for a node, assigns the value as its data, and plugs the node into a list by pointing next to the head of the list.

/* functional.h */
typedef struct Node {
  int data;
  struct Node* next;
} Node;

Node *cons(int, Node *);

/* linkedlist.c */
#include "functional.h"
#include <stdlib.h>

Node *cons(int el, Node *n){
  Node *node = (Node *) (malloc(sizeof(Node)));
  node->data = el;
  node->next = n;

  return node;
 }

It is worth mentioning that the linked list is defined as a pointer to the first node_, not as the first node itself. To make that explicit, we could have written a type definition typedef *Node Linkedlist, where Linkedlist is a pointer to the first node of a linked list.

Using pointers to pass functions as arguments

Lambda functions are essential for functional programming, because they provide a clear syntax to create function objects that can be passed to and returned from functions. In Haskell, for example, we can write \x -> x + 3 to create a function, without having to name it or write it separately from our main program.

Unfortunately, we don't have that luxury in C. The language does not allow us to write functions inside of other functions, to pass them as arguments, or return them as results of functions. So, we have to find another way to pass functions to our higher-order functions map, filter, and reduce.

One awesome thing that C does provide is the function pointer, a pointer to the memory address of a function. This allows us to pass the address of a function as an argument. For example, we can create a function apply that takes a function (or rather, a pointer to a function) and a value, and returns the result of applying that function to the value.

/* functional.h */
typedef int (*fp) (int);
typedef int (*gp) (int, int);

int apply(fp, int);

/* apply.c */
#include "functional.h"    
int apply(fp fp, int x){
  return (*fp)(x)
}

With this device, we can do different operations on a variable, depending on which function we pass an argument to apply.

Implementing recursive iterators

We have addressed our two considerations, and are now able to define the three high-order functions: map, filter and reduce. They are very simple to implement, if we remember to compute recursively-defined data structures with recursion.

Our three functions take the first element of the list (the head), apply a function to it, and proceed to compute the next elements (the tail) according to the result, recursively, until it reaches a nil pointer, at which point the list is exhausted and the computation stops.

Let us implement and explore them in further detail.

map

Map takes a function and a linked list, and produces a new linked list by applying the function to each element of the list.

/* functional.h */
Node *map(fp, Node *);

/* iterators.c */
Node *map(fp fp, Node *n){
  if (n == 0) return 0;
  int val = (*fp)(n->data);
  return cons(val, map(fp, n->next));
}

We take the value of the head of the list, apply the function specified in the arguments, pointed to by fp, and cons the result into a new list build by the recursive application of map to the next elements.

Let us define a few different functions that can be passed to map, and create a transformed linked list.

/* functional.h */
int addThree(int);
int doDouble(int);
int toFour(int);

/* main.c */
int main(){
  Node *src = seq(1, 5, NULL);
  Node *li = map(&addThree, source);
  Node *lj = map(&doDouble, source);
  Node *lk = map(&toFour, source);

printlist(li); // prints 4 5 6 7 8
printlist(lj); // prints 2 4 6 8 10
printlist(lk); // prints 4 4 4 4 4

  return 0;
}

int addThree(int x) {
  return x + 3;
}
int doDouble(int x){ 
  return x * 2;
}
int toFour(int x){
  return 4;
}

filter

Filter takes a function and a linked list, and produces a new linked list by applying the function to each element of the argument, conserving or discarding it, depending on whether the function returns true or false.

/* functional.h */
Node *filter(fp, Node *);

/* iterators.c */
Node *filter(fp fp, Node *n){
  if (n == 0) return 0;
  if ((*fp)(n->data))
    return cons(n->data, filter(fp, n->next));
  else
    return filter(fp, n->next);
}

We pass to the filter what is called a predicate: a function that returns a boolean value. We take the value of the head of the list, and apply the predicate to it. If it returns true, we cons that value into a new list built by the recursive application of filter to the next elements. If it returns false, we discard it, and proceed with the recursion of the tail.

Let us define a few different functions that can be passed to filter, and create a filtered list.

/* functional.h */
int isEven(int);
int greaterThanTwo(int);

/* main.c */
int main(){
  Node *src = seq(1, 5, NULL);
  Node *li = filter(&isEven, source);
  Node *lj = filter(&greaterThanTwo, source);

  printlist(li); // prints 2 4
  printlist(lj); // prints 3 4 5

  return 0;
}

int isEven(int x) {
  return (x % 2 == 0);
}
int greaterThanTwo(int x){ 
  return x > 2;
}

reduce

Reduce takes a function, a linked list, and an accumulator, and returns the result of applying the function to the accumulator and to every element of the list.

/* functional.h */
Node *filter(fp, Node *);

/* iterators.c */
int reduce(gp gp, int acc, Node *n){
  if (n == 0) return acc;
  int val = (*gp)(n->data, acc);
  return reduce(gp, val, n->next);
}

The reduce function receives a binary operator: a function with two arguments, just like the basic arithmetic operators. We take the head of the list and apply the binary operator to it, together with the accumulator. Then, we set the result as the new value of the accumulator, and recursively repeat the operation on the next elements of the list.

Let us define a few different functions that can be passed to reduce, and compute the value of a reduced list.

/* functional.h */
int sum(int, int);
int sumTimesTen(int, int);

/* main.c */
int main(){
  Node *src = seq(1, 5, NULL);
  int i = reduce(&sum, source);
  int j = filter(&greaterThanTwo, source);

printf("%d\n", i); // prints 15
printf("%d\n", j); // prints 150

  return 0;
}

int sum(int x) {
  sum;
}
int sumTimesTen(int x, int y){ 
  return (x * 10) + y;
}

Conclusion

We have developed a way to implement the popular tools for a functional programmer -- map, filter, reduce -- in C, a language that does not really support lambda functions.

To recap, the first thing we had to consider was the data structure on which we wanted to operate. We chose the linked list, the standard data structure for collecting items in functional programming languages like Scheme, Haskell and Erlang. We defined or linked list as pointers to nodes, every node being a structure that stores some data (an integer) and points to the next item of the list. The end of the list is marked by a nil pointer (a zero value). We have also define a cons function that allows us to construct a list by plugging elements to an existing list (or to an empty list, represented by a nil pointer).

One thing to keep in mind is that this is meant to be merely a study on recursive data structures and function pointers, and not a proposal for functional programming in C. One major problem with our approach is that, in order to achieve the immutability of data structures, we are allocating new data to memory, but we haven't provided any way to clean the unnecessary or unused data. That would require a garbage collector, something that is not provided in C, and is beyond the scope of this exercise.

Another thing worth mentioning is that our functions are limited to working with integer types int. It would have been nice to implement some sort of parametric polymorphism, that is, defining of function types to accept any types of arguments.

I would appreciate any comments, corrections, critiques or suggestions.

Functions used but not explained in the article:

Node *seq(int fst, int lst, Node *acc){
  if (fst <= lst) {
    acc = cons(lst, acc);
    return seq(fst, lst - 1, acc);
  }
  else {
    return acc;
  }
}

int length(Node *n){
  if (n == 0) return 0;
  return 1 + length(n->next);
}

void printlist(Node *n){
  if (n != 0) {
    printf("%d ", n->data);
    printlist(n->next);
  }
  else printf("\n");
}

Abstraction, Composition as Software Development Fundamentals: Reading List 1-3/2022

P. Schreiber 🧙🏻‍♂️🔮🐐 — Tue, 15 Mar 2022 20:27:05 +0000

I have decided to organise my studies of computer science based on trimestral reading lists. For the first trimester, I am taking the advice of Joe Armstrong, from his talk "Computer Science: A Guide for the Perplexed". Between January and March, I set myself to reading:

Algorithms + Data Structures = Programs, Niklaus Wirth;
The Mythical Man-Month, Frederick Brooks;
Category Theory for Programmers, Bartosz Milewski.

The three texts discuss computer science on a fundamental level, but from three different aspects: the elements and operations of computer programs, the human process of writing software systems and products, and the algebra of high-level abstractions that on a lower level manifest themselves as data and algorithms.

Abstraction and Composition

Despite these differences in perspective, there are points of convergence between the three texts. The first is the role of abstraction as a way of conceiving programs, making the understanding easier and the architecture leaner. The second is the idea that composition is the fundamental operation in the architecture and building of programs and software systems.

Abstraction in computer science can be described as the action of zooming out, blurring details and providing a wide view. By abstracting, we hide the particular qualities of something and treat it simply as a named object; we hide the individual operations in a program and treat it as a named function.

{red, wheels: 4, fuel: .8, ignition: off} → car
{1 * 2 * 3 * 4 * ... n} → factorial(n)

Composition, on the other hand, is the action of joining parts of a program to solve a complex problem.

Both operations, composition and abstraction, can be applied iteratively. Consider the biosphere: it is a humongous quantity of atoms, related to each other or not based on the laws of physics, forming molecules. That is a ridiculously complex system to understand in terms of their interactions as living beings, so we abstract the complex structures of molecules into objects, and call these cells, which interact with each other by forming tissues and organs. But these systems are still far too complex; therefore, we iterate the same process, abstracting organisms into living beings, living beings into species, species into classes, kingdoms, and so on.

The same can be applied to computer systems, to great effect. We join elements to each other to create data structures, and can compose data structures themselves. We join functions acting on data, and create programs. We join programs to create systems.

Algorithms + Data Structures = Programs

"A systematic and scientific approach to program construction is bound to include all aspects of data structuring. Programs, after all, are concrete formulations of abstract algorithms based on particular representations and structures of data."

The progress of almost all sciences can be traced back to a few fundamental principles from which they develop. In the study of Metaphysics, for example, we are required to understand the concepts of substance and attributes, the intellect and the extension, the entities and the phenomena. All further development and the branching of newer disciplines depends on these principles. The same goes for the science of computation by machines.

This book, in the spirit of modern philosophers, concerns itself with the first principles of computer science: primitive data, basic operators, composition of data (fundamental and recursive data structures), composition of operations (procedures and functions), the building blocks of computer programs, from which we can build all sorts of complex systems.

The book is divided into 5 subjects. Each step is necessary for the next; just like we design programs by composition of functions and data types, we understand the science itself by composing ideas. They are:

Basic data structures;
Algorithms;
Recursion;
Advances data types;
Compilers.

Concerning data, the main problem is how we represent the abstract objects, structures and operations we have conceptually designed (i.e. the product), in a form that fits and executes in the physical constraints of the machine.
For this, we require a readable abstraction for the binary operations done by the machine, allowing us to represent the data structures and operations that compose the system in a human language. This is the finality of the programming language. The author explains:

"The essence of the use of abstractions in programming is that a program may be conceived, understood, and verified on the basis of laws governing the abstractions, and that it is not necessary to have further insight about how the abstractions are implemented and represented in a physical computer."

The programming language allows us not only to represent the simple elements, but also to abstract functions and procedures as named objects, therefore allowing us to reference them, and implement repetitive operations through recursion.

fact 0 = 1
fact n = n * fact(n - 1)

By applying the idea of recursive referencing to data, we can also create repetitive, complex, and potentially infinite data structures, such as lists and n-ary trees. In a lower level, these abstract structures are implemented as pairs or tuples of elements, containing the element itself and references (pointers) to the next elements in the structure. But in a high level abstraction, these can be defined very simply in programming language notation.

list(a) = [] | [a | list(a)]

These are called dynamic structures, due to the fact that their structure and size change during the execution of the program. We can see that there are similarities between the definitions of algorithms and data.

The Mythical Man-Month

“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.”

Recognising that the human aspect -- communication, leadership and subordination, decision making -- is a major part of software development is a hard pill to swallow. What we want is to explore new technologies, to write algorithms that produce expected results, and to create programs that solve real problems. But the reality is that problems are rarely understood, and conceptual schematics are rarely precise, leading to great difficulties in the ideally simple task of writing programs -- after all, how do we write stuff when we don't know what it is we have to write?

Joe Armstrong describes software development, in physics' terms, as an entropy-increasing process. It is an essential and inescapable problem that, as a project grows, so does the complexity of functions, procedures, and data structures: more attributes, more states to keep track, more secondary effects, more dependencies, more errors to handle.

The main virtue of software systems and products is described by Brooks as conceptual integrity: removing unnecessary components, therefore reducing potential bugs and making the system more easily understood. The task of the product developer is therefore to make the product grow, while containing the spread of complexity.

The project, as described by Brooks, has two requirements:

conceptual design, the logical abstract structure of how the parts of the system interact implementation;
representation (implementation) of the abstract structures as programming language code and compiled machine language code.

Both these aspects force us to face the problem of growing complexity. The main takeaway is that software development is an art that allows us to create great things, but it comes with a challenge for which there is no magical solution. We cannot wait for a wonderful programming language, machine or project management framework to make complexity disappear or communication to flow flawlessly. All we can do is, through diligence, apply proven experiences and try new things.

From the first programs in machine code to our current state of the art, several techniques have been developed and proven to work, both in terms of architecture and implementation:

centralised architecture and decision-making, which improves conceptual integrity;
rapid prototyping and incremental growth, which allows feedback iteration;
high-level languages, which remove accidental flaws;
improved tooling, which speeds up development and tests;
object-oriented programming, with abstract data types and inheritance
interactive programming;

We could add to the list the more recent trend of functional programming, which reduces bugs by eliminating side effects, and providing the ideal conditions for concurrent programming.

Category Theory for Programmers

"I hope future generations will be as admiring of the programming skills we've been displaying in building complex operating systems, web servers, and the internet infrastructure [as we admire the builders of old gothic cathedrals]. And they should be, because we've done all this based on flimsy theoretical foundations. We have to fix those foundations if we want to move forward."

There is a standard method of solving problems which seems to be common in a wide range of intellectual activities: it is the method of dividing a complex problem into smaller chunks, solving them separately, and composing the solutions. For example: when we try to understand a complex historical event, such as a revolution or a war, we cannot fully grasp the entire situation all at once; rather, we divide the narrative by different aspects: the economy, the political relationships of leaders, the cultural, philosophical and artistic spirit of the time. These aspects interact with one another, producing the results we call events.

Similarly, we use decomposition and composition in all sciences: mathematics, physics, music, computer science. The author of the book poses the question of whether this method is the way our species evolved to think.

Category theory is the science of abstraction par excellence. It allows us to understand the structure of complex systems, and how the elements interact with each other, without making reference to their qualities. It takes information and stripes down to the bare essentials, until all we have left are objects and arrows between them.

Categories are described in terms of objects and morphisms, where morphisms are arrows that go from one object to the next, and compose with one another. In the realm of programming, for example, we are mostly working with the category Type, where objects are types and morphisms are functions.

f :: a → b
g :: b → c
g . f :: a → b → c

But abstractions, as we described earlier, can be employed iteratively. Just as we have described functions as morphisms between objects in the category Type, we can wrap this structure in an object, and throw it as an object in a new category. This is the category Cat, where objects are small categories and morphisms are functors.

A functor is a mapping of objects and morphisms between two categories. Given a category C, a functor F maps its objects and morphisms to a category D, preserving identity and composition.

For C (a, b), where f :: a → b
Functor F gives D (Fa, Fb), where Ff :: Fa → Fb
For h = g . f in C
Fh = Fg . Fh in D

The mapping of morphisms is implemented as a higher order function fmap:

(a → b) → (Fa → Fb)

In programming, functors can be understood as parametric type constructors: equations that, given a type, produce a new type. We can, for example, take a type int and map it to types such as maybe_int or list_of_ints. Or, we can take the types int and boolean, and construct a list_of_ints_and_bools applying a bifunctor.

We can continue abstracting these structures to higher degrees. Just as we wrapped the objects and morphisms of small categories, forming Cat, we can wrap its objects and morphisms (functors) and throw these in a new category. This is the category Fun, where objects are functors and morphisms are natural transformations (mappings of functors).

As we can see, category theory is a powerful exercise in abstraction and composition, which, as was mentioned before, are often described as the essentials of programming. This ultra abstract science reveals to us a top-down approach to thinking. It consists of the declaration of general, abstract principles, that are then developed into material entities, just like the platonic idea of a chair is materialised into wooden or metal chairs. Brooks calls this the top-down approach for software development, where the work is divided between architecture (or design) and representation (or implementation).

Fantasy-Oriented Programming

P. Schreiber 🧙🏻‍♂️🔮🐐 — Wed, 12 Jan 2022 15:56:31 +0000

Fantasy is the realm of imagination, magic, and dreaming about endless possibilities, even the seemingly or truly impossible. It allows us not just to question "what would it be if...", but actively express and create possible worlds, even if they do not make sense in reality. Sure, giant reptiles cannot fly and spit fire: there is no muscle mass and energy source that would allow that; but what if they did?

Programming is a fantastic activity, even if we lose sight of that aspect. It creates reasoning -- a spiritual thing -- from sand and metal; that is something not even the most audacious magicians and alchemists could dream. It is no joke when Sussman compares sorcery and computation, which harnesses the demon in the machine to produce magic results.

"You, the Spirit of Earth, are nearer:
Already, I feel my power is greater,
Already, I glow, as with fresh wine.
I feel the courage to engage the world,
Into the pain and joy of Earth be hurled
And though the storm wind is unfurled,
Fearless, in the shipwreck’s teeth, be whirled."
Faust conjures the Earth Spirit, Goethe, pt. I, sc. I

Fantasy-oriented programming is not a paradigm. Rather, it is an ethos, a reflective understanding of ourselves as programmers. By contemplating the abstract, philosophical, and almost mystic aspects of programming, we allow ourselves to feel awe -- a double affection of being at the same time terrified and fascinated by greatness -- in face of the vast universe of possibilities offered by computation by machines.

Art and science: identity and difference

There is in programming a tension between science and art, which is common to all human activity.

By science, I mean the work of the human mind, the abstraction of real entities into symbolic representations, and the logical operations of the intellect on these symbols. Think geometry, computer algorithms, musical composition.

By art, I mean the work of the human hand, the hypostasis of spiritual entities into real substance by transforming the physical matter. Think building a house, manufacturing computer hardware, playing the guitar.

Programming has these two contradictory aspects at once, coexisting in a harmony. They cannot exist one without the other. We cannot compute equations without giving instructions to the processor, which transforms them into the physical reality of electrical pulses; conversely, it is in the symbolic representation of these physical realities that we find meaning through equations.

The pragmatic ethos

There is a pragmatic approach to programming that is akin to the work of the artist. The Artist does not care about the alignment of doors and windows to the stars and constellations; he does not need to understand the principles of trigonometry in order to build walls and a roof. He has built many houses, and knows how it is done, by experience.

The spirit of the Artist lives in the pragmatic programmer. His job is not to make systems that correctly implement mathematical equations; he does not care about the abstraction of types and sets into categories; the word monad to him is a distraction, nothing more.

The scientific ethos

Similarly, there is a scientific approach to programming. The Philosopher spends his days pondering questions his kindred, the Artist, rejects, marveling at how objects in the world can be represented in a language of mathematical symbols, and how even these symbols can be expressed by even more abstract representations.

The virtue of balance

There is a reason why the book "The Pragmatic Programmer" is considered a classic in this field. Pragmatism is a major virtue in programming. As developers, our job is not to prove mathematical theorems, but to create systems that are useful, that add value to the lives of users, whether in daily work, study or leisure.

Pragmatism is also a major asset in the professional career of a programmer. As a Philosophy major, I have often heard people say: "that is so fascinating; but what do you do with it, for a job?". This is a legitimate concern. Companies are not concerned with understanding the mysteries of the universe and the human experience, but rather with developing, launching and selling products. So, what matters is the skills and tools you can effectively use. For example, if you're a marketer, it does not matter whether you have any insights about communication in abstract, but only whether you can communicate the advantages of a product over the competition in 50 words or less. The same goes for programming.

If no employer is ever going to ask us "how to express computation with lambda calculus", or for a comprehensive intuition about monads, what is the purpose of learning these things? Rather than spending time and mental energy with that, is it not more beneficial to apply these resources to learn something practical like how to operate the Amazon cloud or build apps with Flutter?

"More useful", yes, definitely. But I would argue that there is a virtue in harnessing the philosophical spirit, even to the most pragmatic programmer. It challenges us to unravel an arcane knowledge through the power of spirit; it reveals to us that the universe is wider than our comprehension, and that our practical action of constructing things using tools is the expression of timeless principles; it shows us that there are people out there who have attained higher wisdom, which beckons us to keep moving forward.

I remember the first time I watched a class about Haskell. The explanation of how we can represent complex logical and mathematical operations with the simple notation of lambda calculus is something I will never forget. I felt like the young Artie listening to Merlin, fascinated by the wizard's wisdom and his wonderful tales of the achievements of art and science.

That fascination, which fuels passion and curiosity, is the source of my belief in the virtue of contemplating the philosophical aspects of computer science. That is fantasy-oriented programming.

In summary, there is nothing I can say that Byron has not said better, in these words:

"I love not Man the less, but Nature more,
From these our interviews, in which I steal
From all I may be, or have been before,
To mingle with the Universe, and feel
What I can ne'er express, yet cannot all conceal."

Compreendendo tipos de dados algébricos com exemplos em Elixir

P. Schreiber 🧙🏻‍♂️🔮🐐 — Mon, 20 Dec 2021 17:55:00 +0000

"Il est des jours de brume et de lumière vague,
Où l'homme, que la vie à chaque instant confond,
Étudiant la plante, ou l'étoile, ou la vague,
S'accoude au bord croulant du problème sans fond."
Victor Hugo

Introdução

Números, no mundo real, raramente são apenas números. Pelo contrário, quase sempre apresentam-se como valores relativos a um certo atributo, categoria, unidade de medida. Se alguém dissesse: "este prédio tem 48", nossa resposta imediata seria, "48 o que?"

Imaginemos um prédio com 48 metros de altura. Isso é tudo que podemos dizer sobre este prédio? É claro que não. Podemos enumerar uma série de valores e atributos que descrevem esse prédio e compõem sua existência. Por exemplo:

prédio = %{
    altura: 48,
    unidades: 64,
    cores: [:branco, :laranja],
    categoria: :comercial,
    completo: true 
}

Essa descrição é bastante inteligível, e nos permite imaginar um prédio real. Levando esse exercício mais longe, poderíamos abstrair os valores específicos, descrevendo um prédio platônico, uma ideia de todos os prédios possíveis. Construiríamos, assim, um tipo de dados prédio, composto pelos diferentes tipos de dados que descrevem os prédios (altura, unidades, cores, categorias, estágio de construção).

Neste artigo, explicaremos os tipos de dados algébricos, isto é, como definir tipos de dados compostos de tipos singulares e as regras que governam sua composição. Mostraremos os exemplos mais comuns de tipos de dados algébricos, como tipo multiplicação e soma de tipos, tipos de funções ou exponenciação de tipos, e tipos recursivos, utilizando exemplos na linguagem Elixir.

Tipos de dados

Toda computação é uma operação sobre valores de determinados tipos. Para explicar os tipos de dados, a ciência da computação costuma referir-se ao tamanho e à disposição dos números binários que expressam os elementos de diferentes tipos: desta maneira é formalizada a distinção entre Integers e Longs, Floats e Doubles -- quanto maior o espaço em memória reservado aos valores, maior a precisão ou o limite de valores representáveis. A mesma explicação vale para coleções de tipos, como arrays de tamanho fixo: o tamanho da coleção é o tamanho do dado multiplicado pelo numero de entradas na coleção

Entretanto, essa explicação é limitada quando queremos nos referir a certos valores computáveis. Por exemplo, como podemos expressar em termos de quantidade de bits uma coleção com um número indeterminado de valores; ou, em outras palavras: qual é o tamanho de uma coisa da qual não sabemos o tamanho?

@spec tamanho(list()) :: integer()
def tamanho([]), do: 0
def tamanho([h|t]), do: 1 + tamanho(t)

É claro, neste exemplo, que o tipo list() não pode ser definido em termos de quantidade de bits, porque a quantidade varia de acordo com o tamanho da lista. Vamos, então, usar outra explicação: tipos são representações abstratas de valores possíveis de operações computacionais. Em uma analogia com a teoria matemática dos conjuntos, um tipo é um conjunto de valores.

Tipos de dados algébricos

Da mesma maneira como somos capazes de criar funções que operam sobre números e produzem determinados valores, podemos definir operações sobre tipos de dados, que produzam tipos compostos de outros tipos.

Entretanto, tipos de dados são muito diferentes de números. Antes de realizar operações com tipos de dados, precisamos descrever uma certa álgebra que governe as regras de composição dos tipos. Para isso, recorremos à matemática, especificamente à teoria dos conjuntos.

Tipos de dados algébricos nos permitem definir coisas como:

#apelidos
@type palavras_magicas :: charlist()
@type resultado :: boolean()
#tipos compostos
@type elemento() :: :fogo | :terra | :agua | :ar
@type mistura() :: {elemento(), elemento()}
@type transformacao(a, b) :: (a -> b)
#tipos recursivos
@type lista(a) :: {} | {a, lista(a)}
@type arvore(a) :: {} | a | {arvore(a), arvore(a)}

Entendidos de forma matemática, tipos de dados algébricos podem ser definidos em termos de três operações básicas: soma, multiplicação e potenciação. Assim como entendemos um tipo de dados como o conjunto dos seus valores possíveis, um tipo composto é o conjunto dos valores possíveis resultante da composição.

Soma de tipos

O que significa falar sobre a soma de dois tipos de dados, como "inteiro mais booleano"? A idéia parece estranha a princípio. Para entender, vamos primeiro pensar sobre a soma de números, que já conhecemos: dois mais três são cinco, quatro mais cinco são nove, e assim por diante.

A soma de tipos é semelhante. Se descrevermos um tipo como o conjunto dos valores possíveis, a soma de tipos é a soma do número desses valores. Por exemplo, imaginemos um tipo "certeza", com dois valores: verdadeiro e falso; imaginemos um tipo que tem apenas um valor possível, e vamos chamá-lo de "dúvida". Somando os dois tipos, compomos um tipo com três valores possíveis: ou é verdadeiro, ou é falso, ou é duvidoso. Vamos chamar esse tipo de "hipótese":

@type duvida() :: :undefined
@type certeza() :: boolean()

@type hipotese() :: duvida | certeza

valores_possiveis = [
    true,
    false,
    :undefined
]

É fácil entender que somamos tipos com 1 e 2 valores, e obtivemos um tipo com 3 valores. Em matemática, na teoria dos conjuntos, essa composição é chamada de disjunção: "A ou B".

Funções que aceitam tipos compostos dessa maneira apresentam comportamentos diferentes dependendo do tipo de dado utilizado (o que nos levaria a um outro tópico, polimorfismo, que não trataremos neste artigo). Para isso, é necessário utilizar estruturas condicionais, como if, guards ou pattern match:

@type t() :: boolean() | integer()

@spec f(t()) :: atom()
def f(x) when is_boolean(x), do: :bool
def f(x) when is_integer(x), do: :int

Representamos a soma de tipos como a + b.

Multiplicação de tipos

A multiplicação de tipos segue uma lógica semelhante. Para entender, vamos primeiro pensar sobre a multiplicacão de números, que já conhecemos: dois vezes três são seis, três vezes três são nove, e assim por diante.

A multiplicação de tipos é semelhante. Se descrevermos um tipo como o conjunto dos valores possíveis, a multiplicação de tipos é a multiplicação do número de valores desses tipos. Por exemplo, imaginemos um tipo "materiais", com dois valores: "madeira" e "pedra"; imaginemos um tipo "cores", com três valores, "branco", "amarelo" e "azul". Multiplicando os dois tipos, compomos um tipo com seis valores possíveis. Vamos chamar esse tipo de "casa":

@type material() :: :madeira | :pedra
@type cor() :: :branco | :amarelo | :azul
@type casa() :: {material(), cor()}

valores_possíveis = [
    {:madeira, :branco},
    {:madeira, :amarelo},
    {:madeira, :azul},
    {:pedra, :branco},  
    {:pedra, :amarelo},
    {:pedra, :azul}
]

É fácil entender que multiplicamos tipos com 2 e 3 valores, e obtivemos um tipo com 6 valores. Em matemática, na teoria dos conjuntos, o número de valores do produto de dois tipos corresponde ao produto cartesiano de dois conjuntos, e o valor composto a uma intersecção, "A e B".

Para nossa surpresa, esse tipo de dado algébrico não é uma novidade, mas um velho conhecido: uma tupla de n valores. Esta é a razão por que os records em Erlang (nome dado para structs ou hash tables, coleções de valores de tipos distintos) são implementados simplesmente como tuplas normais.

-record(casa, {material, cor}).

#casa{material=madeira, cor=branco}.
% é o mesmo que
{casa, madeira, branco}

Representamos a multiplicação de tipos como a * b.

E quando o número de valores for infinito?

Quando entendemos a composição de tipos de valores finitos, fica fácil entender a composição de tipos de valores infinitos. Lembremos que na matemática, na teoria dos conjuntos, nem todos os infinitos são iguais: o conjunto dos números reais é infinito; o conjunto de números divisíveis por 999 também é infinito, mas eles são infinitos muito diferentes.

Vamos definir um tipo "booleano inteiro"; em outras palavras, um número que pode ser verdadeiro ou falso. Para isso, multiplicamos o tipo booleano pelo tipo inteiro. Nosso novo tipo tem um número de valores possíveis que é o número de valores possíveis do tipo booleano vezes o número de valores possíveis do tipo inteiro:

type booleano() :: :verdadeiro | :falso
type inteiro() :: 1 | 2 | 3 | 4 | 5 | ... 
type bool_int() :: {booleano(), inteiro()}

valores possíveis = [
    {:verdadeiro, 1}, {:verdadeiro, 2}, {:verdadeiro, 3}, ...,
    {:falso, 1}, {:falso, 2}, {:falso, 3}, ...
]

Tipos de funções

Em muitas linguagens de programação, funções são objetos de primeira classe, ou seja são entidades em si próprias, e podem ser registradas em variáveis, passadas como argumentos de funções ou retornadas como resultados de uma função. A exponenciação de tipos é a composição de tipos em tipos de funções, isto é, corresponde ao conjunto de funções que mapeiam valores de um tipo a outro.

Por exemplo, podemos definir um tipo de função "validação numérica" que aceita um valor inteiro e retorna um valor booleano. Utilizamos funções do tipo "validação" como funções de alta ordem, aplicando à função "validar" para garantir que um valor é válido ou não para determinada aplicação:

@type validacao() :: 
  (integer() -> boolean())
@type resultado() :: 
  {atom(), integer()} | {atom(), charlist()}

@spec validar(integer(), validacao()) :: atom()
def validar(x, regra) do 
    if regra.(x) do
        {:ok, x}
    else 
        {:erro, "valor inválido"}
end

Tipos de dados algébricos nos proporcionam propriedades interessantes para pensar a lógica e a matemática das funcões em programas computacionais. Por exemplo, sabemos que na álgebra do conjunto de números reais, a seguinte propriedade é válida: a^(b+c) = a^b * a^c. Ora, esta propriedade também é válida para tipos algébricos:

@type elemento() :: :agua | :ar | :fogo | :terra
@type espirito() :: :trevas | :luz 
@type efeito() :: :boom | :kablam

# a^(b+c)
@spec magia(elemento() | espírito()) :: efeito()
def magia(poder) do
    cond do
        elemento?(poder) -> :boom
        espirito?(poder) -> :kablam
    end
end

# a^b * a^c`
@spec feitico(elemento()) :: efeito()
def feitico(poder) when elemento?(poder), do: :boom

@spec bruxaria(espirito()) :: efeito()
def bruxaria(poder) when espirito?(poder), do: :kablam


defp elemento?(x), do: x in [:agua, :ar, :fogo, :terra]
defp espirito?(x), do: x in [:trevas, :luz]

O que a propriedade descreve é que o mesmo cálculo pode ser representado de duas maneiras distintas: como duas funções que aceitam tipos a e b, ou como uma só função que aceita um tipo composto a + b.

Tipos recursivos

Vimos como representar tipos compostos de um número definido de elementos: pares, tuplas, variantes. Estes tipos, embora nos proporcionem um grande poder expressivo para estruturar os dados de um programa, ainda não respondem uma questão que colocamos no início: como podemos representar um conjunto com um número indefinido de elementos?

Para isso, precisamos recorrer a um dispositivo que nos permita trabalhar com repetições. Em programação funcional, esse dispositivo é a recursão. Da mesma maneira como podemos definir funções recursivas que expressam-se em termos de si mesmas, podemos definir tipos que expressam-se em termos de si mesmos, recursivamente. Podemos, por exemplo, definir uma lista como a junção de um elemento a uma lista.

Vamos definir uma lista de animais. Para isso, vamos usar a conjunção que vimos antes na multiplicação de tipos, e expressar nossa lista como uma tupla recursiva:

@type animal() :: :gato | :cachorro | :hamster | :peixe | :galinha
@type lista_de_animais() :: {} | {animal(), lista_de_animais()}

meus_bichos = {:gato, {:hamster, {:peixe, {:peixe, {:peixe, {:peixe, {}}}}}}}

Vejamos que não precisamos nos restringir ao tipo list() nativo do Elixir para definir nosso tipo. Não é o tipo de coisa que utilizaríamos em um projeto em produção, é claro: para isso, é sempre recomendado utilizar o padrão estabelecido pela comunidade. Mesmo assim, o que esses tipos representam é fundamentalmente a mesma coisa -- um tipo algébrico recursivo definido pela conjunção de um elemento a uma lista de elementos.

[:gato, :hamster, :peixe, :peixe, :peixe, :peixe]
#é o mesmo que
[:gato | [:hamster | [:peixe, [:peixe | [:peixe | :peixe | []]]]]]
#que não é muito diferente de
{:gato, {:hamster, {:peixe, {:peixe, {:peixe, {:peixe, {}}}}}}}

Outro exemplo de um tipo recursivo é a árvore binária, que pode ser definida como:

@type planta() :: {} | :folha | {planta(), planta()} 

grama = :folha
muda = {:folha, :folha}
arbusto = {
    {
        :folha, {
            :folha, {
            :folha, 
            {}
            }
        }
    },
    :folha
}

No exemplo, nosso tipo planta() não é muito útil, porque não nos permite registrar nada além de folhas. Mas o poder expressivo desse tipo fica claro se percebermos que o tipo folha poderia ser qualquer outro tipo, simples ou complexo.

Observação sobre os exemplos em Elixir

Antes de concluir, vale adicionar uma nota sobre a relevância deste assunto no contexto da linguagem de programação Elixir e do ecossistema Erlang. Ambas as linguagens são dinamicamente tipadas e, desta forma, a verificação de tipos de dados ocorre em tempo de execução. Isso significa que, em geral, as especificações de tipos servem mais para documentar o código do que efetivamente restringir a execução, garantir a correção e acusar erros. Desta forma, o entendimento de tipos de dados algébricos não é tão indispensável para a programação como no caso de linguagens estaticamente tipadas. Mesmo assim, optamos por utilizar o Elixir para os exemplos pela familiaridade e gosto pelo linguagem.

Precisamos ainda dar os devidos créditos. Este artigo é inspirado na apresentação do programador e matemático Bartosz Milewski, a propósito de tipos algébricos e sua representação na linguagem C++. A apresentação é de 2018, e pode ser vista clicando aqui.

Neste artigo, vimos como é possível expandir nossa capacidade de representar informações por meio da compreensão dos tipos de dados algébricos, que nos permitem compor tipos singulares em tipos mais complexos e expressivos. Vimos, ainda, como certas estruturas que já conhecemos são, fundamentalmente, expressões dessa álgebra de tipos de dados.

Implementando estados mutáveis e arquitetura cliente-servidor com funções recursivas e troca de mensagens entre processos

P. Schreiber 🧙🏻‍♂️🔮🐐 — Mon, 20 Dec 2021 17:41:57 +0000

O objetivo deste artigo é apresentar como é possível implementar estados mutáveis em uma linguagem funcional sem variáveis globais, utilizando funções recursivas. Para ilustrar, utilizaremos como exemplo os processos e troca de mensagens no sistema Elixir. A abstração dessas operações nos permite implementar uma arquitetura cliente-servidor com uma clara separação entre requisições de consulta e atualização dos dados por parte do usuário, e a computação dos dados por parte da máquina.

Estados mutáveis

Computadores, como implementações da máquina de Turing, são essencialmente máquinas de estado mutável. Um tocador de música, por exemplo, embora não tenha todas os atributos de uma máquina de Turing, também é uma máquina de estado mutável: ele registra uma música atual e, de acordo com o tempo ou o input de um usuário, aciona funções de tocar, pausar ou trocar de música. A música que está tocando é registrada na chamada variável global.

Esta é a base da computação imperativa, e pode ser exemplificada pelo código:

let song = {title: "Rainbow - Stargazer"}
function select(title){ song.title = title }
function listen() { console.log("Now playing: " + song.title) }

listen()
// Now playing: Rainbow - Stargazer
select("Rainbow - Self Portrait")
listen()
// Now playing: Rainbow - Self Portrait

A programação funcional, implementação do cálculo lambda para sistemas computacionais, opera basicamente com funções puras para a computação de dados. Por definição, é um paradigma no qual não existem variáveis globais. Mas se o que dissemos é verdade, e computadores são implementações da máquina de Turing, uma máquina de estados mutáveis, como é possível a computação sem variáveis globais? Ou, perguntando de outra forma: como seria possível, sem variáveis globais, implementar uma máquina de estados mutáveis, capaz se registrar e, mais importante, alterar os dados registrados após a computação?

Processos e troca de mensagens

Antes de apresentar a solução para este problema, precisamos esclarecer duas ideias fundamentais para nossa implementação: processos e troca de mensagens.

Um processo em Elixir é uma thread de execução que roda na BEAM, máquina virtual Erlang. Processos são concorrenciais, leves (com baixo consumo de memória), e isolados uns dos outros. Invocamos processos por meio da funçao spawn/1, que retorna um PID, endereço do processo na máquina virtual.

Podemos, por exemplo, invocar um processo que roda uma função anônima:

spawn fn -> true end
#PID<0.109.0>

Processos, embora independentes, são capazes de mandar e receber mensagens uns para os outros. Mensagens enviadas a um processo são registradas em sua caixa de mensagens, que ele lê e responde de acordo com as especificações determinadas.

Enviamos mensagens a qualquer processo ativo na máquina virtual por meio da função send/2, que recebe como argumentos um PID, endereço do destinatário, e a mensagem (geralmente um atom ou tuple). Os processos recebem mensagens por meio do bloco receive, que especifica as mensagens que pode receber e como responder.

O código a seguir ilustra como processos podem enviar e receber mensagens. No exemplo, self() retorna o PID do processo que está rodando atualmente, e que receberá a mensagem:

restaurante = self()
send restaurante, {:pedido, "pizza"}

receive do
    {:pedido, item} -> IO.puts "Cozinhando: #{item}"
end
# Cozinhando: pizza

É importante ressaltar que, tal qual em uma comunicação entre pessoas, a comunicação entre processos só pode ocorrer por meio de mensagens que são capazes de entender, interpretar e responder. No exemplo acima, o processo restaurante só entende uma mensagem: {:pedido, item}. Poderíamos enviar outras mensagens para o processo, como :cancelar_pedido ou {:reclamacao, "a comida não estava boa"}, mas ele é incapaz de responder, porque não entende, isto é, não está devidamente configurado para essas mensagens.

Implementação de estados mutáveis

Com essas duas ferramentas à nossa disposição, podemos enfrentar o nosso problema anterior: implementar estados mutáveis sem recorrer a variáveis globais. Para resolvê-lo, vamos dividi-lo em duas etapas: como registrar dados e como atualizar dados.

Processos instanciados na VM executam a ação para que foram criados, e extinguem-se. Isso não ocorre, porém, com funções recursivas, que chamam a si mesmas em sua execução. Podemos, portanto, utilizá-las para registrar dados como parâmetros.

Retornemos ao nosso exemplo do tocador de música. Podemos registrar a música que está tocando em um processo:

def player(%{song: title}), do: player(%{song: title})

player = spawn fn -> player(%{song: "Rainbow - Stargazer"}) end
#PID<0.109.0>

O processo player vai rodar infinitamente, registrando o valor passado como argumento da função. Entretanto, ainda é incapaz de trocar de música, e não é muito útil. O exemplo ilustra como registrar um dado, mas não explica como ele pode ser mudado.

Processos são isolados uns dos outros, e uma vez chamados não podem ser redefindos no meio de sua execução. O que precisamos é dum efinir processo que registre os dados como argumentos, e tenha em si próprio a capacidade chamar-se recursivamente com dados passados do exterior. A forma como passamos dados a um processo é por meio de mensagens.

Implementamos nosso tocador de música utilizando o que aprendemos até aqui:

def player(%{song: title}) do
    receive do
        {:select, new_song} -> 
            player(%{song: new_song})
        :listen -> 
            IO.puts "Now playing: #{title}"
            player(%{song: title})
    end
end

player = spawn fn -> player(%{song: "Rainbow - Stargazer"}) end

send player, :listen
# Now playing: Rainbow - Stargazer
send player, {:select, "Rainbow - Self Portrait"}
send player, :listen
# Now playing: Rainbow - Self Portrait

Agora, nosso tocador de música não apenas registra a música que está tocando, mas também recebe comandos e responde condicionalmente, podendo trocar de música ou tocá-la. As chamadas recursivas no final de cada função (tail recursion) mantêm os processos ativos.

Vimos até aqui, então, exatamente o que procurávamos no problema inicial: uma maneira de implementar estados mutáveis em um sistema de programação funcional sem variáveis globais. Pode ser interessante, para continuar essa discussão, comparar a solução implementada em Elixir com a de outras linguagens funcionais

Agora que temos o conhecimento e as ferramentas necessárias para implementar uma máquina de estados mutáveis, somos capazes de desenvolver sistemas mais complexos e úteis. Pense nos exemplos de máquinas que você conhece: um semáforo de trânsito, um termostato, um videogame; todos esses sistemas, do mais simples ao mais complexo, gravam estados atuais e o atualizam de acordo com eventos e operações pré-programados.

Arquitetura cliente-servidor

Vamos voltar ao nosso exemplo do tocador de música. Imaginemos um sistema que permite a vários usuários consultarem a temperatura atual em diferentes lugares do mundo: o usuário descreve em uma interface o lugar desejado, e o sistema aciona uma estação meteorológica remota, que mede a temperatura e devolve ao usuário como resposta. Esse modelo, que separa a interface de usuário do núcleo de processamento, é chamado arquitetura cliente-servidor.

Entendida desta maneira, a arquitetura cliente-servidor não está restrita ao domínio das redes de Internet; é um modelo conceitual, uma abstração da máquina de estados, para implementar o sistema de forma clara e organizada. Para ilustrar, continuaremos o desenvolvimento do mesmo sistema, nosso tocador de música.

A forma ideal de implementar um sistema com modelo cliente-servidor em Elixir é usando o GenServer. É um sistema construído sobre os fundamentos que apresentamos anteriormente -- processos e troca de mensagens -- que encapsula e proporciona um padrão (behaviour) para a implementação, em que separamos as funções de interface e de processamento dos dados (callbacks).

Podemos reescrever nosso tocador de música utilizando o GenServer:

defmodule Blackmore.GenserverPlayer do
  use GenServer

  ## Client API
  def start_link(opts) do
    GenServer.start_link(__MODULE__, :ok, opts)
  end

  def select_song(pid, title) do
    GenServer.cast(pid, {:select_song, title})
  end

  def listen(pid) do
    GenServer.call(pid, {:listen})
  end

  ## Server callbacks
  @impl true
  def init(:ok) do
    {:ok, %{song: nil}}
  end

  @impl true
  def handle_cast({:select, title}, song) do
    {:noreply, %{song | song: title}}
  end

  @impl true
  def handle_call({:listen}, _from, %{song: title}) do
    {:reply, title, %{song: title}}
  end
end

Apesar de utilizar mais linhas para cumprir um propósito semelhante, percebemos agora uma clara organização, separando as operações realizadas pelo cliente e pelo servidor. Nossos comandos -- as mensagens passadas para o processo -- não estão soltas, mas encapsuladas em funções com finalidades distintas e claras.

Entre os recursos proporcionados pelo GenServer, vale a pena observar a possibilidade de designar callbacks síncronos, isto é, que aguardam o retorno de uma resposta, e assíncronos, que devolvem apenas a promessa de execução do comando requisitado. O GenServer também proporciona um gerenciamento de erros e uma integração eficaz com outros componentes de um sistema Elixir, como Supervisors e Application. Este é um tópico que merece um artigo dedicado inteiramente a ele, então ficará para uma próxima oportunidade.

Conclusão

O controle de estados mutáveis é a base da computação, tanto em um sentido teorético como físico. Para computar, é necessário registrar valores e atualizá-los segundo determinadas operações. Tal fato nos impõe um problema quando pensamos em implementar uma sistema computacional segundo o paradigma funcional, isto é, baseado em funções puras e sem variáveis de escopo global.

Vimos, porém, que lançando mão de funcões recursivas e troca de mensagens entre processos, é possível implementar uma máquina de estados mutáveis, gravando dados nos argumentos das funções, e atualizando-os por meio de mensagens aos processos.

Tais fundamentos nos permitem o desenvolvimento de um sistema no modelo cliente-servidor, em que o usuário é capaz de realizar requisições a um processo por meio de uma interface clara e isolada das funções de processamento.

React Mastermind

P. Schreiber 🧙🏻‍♂️🔮🐐 — Tue, 05 Jan 2021 16:47:14 +0000

O jogo começa com um segredo de quatro cores. Ao todo existem seis cores diferentes que podem ser combinadas de qualquer forma: azul, amarelo, rosa, verde; azul, azul, amarelo, amarelo; azul, azul, azul e azul. Não há limite para cores repetidas.

Para descobrir o segredo, o jogador faz testes, escolhendo cores que o computador compara com o segredo. Se as combinações forem iguais, o jogador ganha; se forem diferentes, joga outro turno. Em 10 turnos, o jogador perde.

Mas é preciso algo a mais para descobrir o segredo em menos que 1296 tentativas aleatórias. Cada teste retorna pontos: a cada ponto preto, há uma cor certa no lugar certo; a cada ponto branco, há uma cor certa no lugar errado.

Agora, vamos criar esse jogo. Para entender como funciona, experimente aqui a versão pronta.

As ferramentas utilizadas

Para criar esse jogo, vamos utilizar duas ferramentas principais. Com o React, vamos criar a interface, gerenciar os estados da aplicação por meio da Context API e operar os inputs do jogador.

Com o Lodash — conjunto de funções que expande[1] as possibilidades de manipulação de estruturas de dados em Javascript, vamos manipular os arrays e objetos para montar testes, comparar testes ao segredo e calcular pontos. Escolhi o Lodash porque a inspiração para recriar esse jogo veio do Mastermind in Haskell[2], uma implementação feita com funções puras que roda no terminal.

Gerando o segredo

Vamos começar pelo mais fácil. O segredo não é nada mais do que uma combinação aleatória de 4 das 6 cores disponíveis. As funções shuffle e take do Lodash nos permitem resolver isso em uma quatro linhas.

Sample colhe elementos aleatórios de arr, que são então mapeados em um novo array, e a partir dele take gera um novo array com os primeiros n elementos. É importante ressaltar que as funções são puras e não alteram a fonte arr. Um beijo para o time lambda 🧙.[3]

Assim, para começar um novo jogo, basta gerar um novo segredo com algo como let secret = genSecret(cores, 4).
Gerando os testes
Gerar o segredo é a parte mais fácil. Agora vamos ver como gerar o teste com as cores escolhidas pelo jogador. Para isso, vamos usar o hook useReducer do React para adicionar, remover e resetar cores no teste, que aqui será chamado de state.

No componente, iniciamos o teste (state) como um array vazio. A cada evento que dispara uma ação do dispatch, um novo objeto teste é emitido de acordo com o tipo da ação (“add”, “remove”, “reset”): adicionando a cor escolhida (action.payload) ao teste, removendo-a ou resetando tudo.

Mais uma vez, as ações não alteram o objeto do teste, mas sim criam um novo objeto que o substitui, a cada ação.

Gerando a pontuação

Essa é a parte mais interessante. Se você leu até aqui, aí vai um desafio: dados um conjunto teste e um conjunto segredo, ambos de quatro elementos, como descobrir quantos são os elementos iguais na posição correta e os elementos iguais na posição errada?
Descobrir as cores certas na posição certa (pontos pretos) é fácil, é claro. Comparamos os arrays lado a lado: se na posição 0 as cores forem iguais, 1; se forem diferentes, 0; e somamos os pontos. Mas e os pontos brancos, isto é, as cores certas na posição errada?

Mais uma vez, o Lodash nos dá uma série de ferramentas para juntar, filtrar e comparar os arrays. solução para o desafio: os pontos brancos são o numero de cores do segredo, menos as cores que o teste não acertou, menos os pontos pretos.

Condições de vitória e derrota

Falamos sobre como começar o jogo — gerar o segredo — e como fazer cada turno — criar um teste, calcular os pontos. Agora, preciso falar sobre o funcionamento geral do jogo, isto é, como registrar os testes realizados e quais são as condições de vitória e derrota.

Para o jogo funcionar, eu preciso de acesso a uma informação em todos os componentes (tabuleiro, header, mão do jogador, app). Essa informação é a lista de todos os testes já realizados.
No React, essa necessidade nos leva diretamente à ideia de uma ferramenta de gerenciamento de estado global da aplicação, como o Redux. Para criar este jogo, optei pela ferramenta nativa do React, a Context API.

A lista de testes (“guesses”) agora pode estar disponível por meio do uso do custom hook useGuesses. A variável guesses lista todos os testes já realizados, e a função setGuesses é usada para incluir novos testes à lista.[4]
Para terminar, precisamos falar sobre como ganhar o jogo, e também como perder. O jogador ganha quando o teste é igual ao segredo, e perde quando já lançou 10 testes errados. Agora que temos a lista completa e constantemente atualizada dos testes, fica fácil implementar essas condições. Para isso, utilizaremos o hook useEffect, um método que roda a cada atualização do componente.

Se o último teste tiver 4 pontos pretos, o jogador ganhou. Se o número de testes for maior que 9, o jogador perdeu.

Conclusão

Desde que eu comecei a programar, meu mentor sempre me disse que criar jogos é uma das maneiras mais eficazes de estudar, treinar, aprender. Isso porque é ao mesmo tempo divertido e complexo.
Neste exercício, recriei o jogo de Mastermind que pode ser jogado pelo browser, no computador ou no celular. Ainda teria muita coisa para falar, como a organização dos componentes do React ou a estilização responsiva com Material UI. Mas acho que nesse artigo consegui explicar o que eu queria: como o jogo funciona logicamente, e como usar funções puras para manipular estruturas de dados para obter os resultados desejados.
Se você gostou, pode conferir o código no meu github, jogar o jogo pelo browser ou deixar o like no artigo. Obrigado e um abraço!

1.Talvez a expressão correta seja “facilita”; afinal, não há razão para as operações feitas com o Lodash não poderem ser feitas com o Javascript puro. Mas “expandir” é mais bonito, vamos concordar.

Mastermind in Haskell, por Christophe Delord. Acesse aqui.
Na primeira versão, eu utilizei a função shuffle do Lodash, que gera um array de elementos embaralhados. Como um colega apontou, dessa maneira o jogo não conseguia gerar segredos com elementos repetidos, e alterei para usar a função sample.
Para criar esse Context, foi indispensável o tutorial do Guilherme Rodz. Obrigado, meu caro! Acesse aqui.

O robô entusiasta de poesia

P. Schreiber 🧙🏻‍♂️🔮🐐 — Tue, 05 Jan 2021 16:23:13 +0000

Um fantasma de mil anos habita o Twitter: o fantasma do poeta japonês Ki no Tsurayuki (紀貫之, ca.872 — ca. 945). Na verdade, não é fantasma nenhum; trata-se de um bot que a cada duas horas posta poemas aleatórios extraídos da coleção Kokin Wakashū.

A ideia é tão legal que eu resolvi programar meu próprio robô entusiasta de poesia, só que em vez de poemas japoneses, meu Charles Robaudelaire seria um robô de poesia francesa, extraída do acervo poetica.fr.

A versatilidade — diversidade de tarefas às quais a ferramenta pode servir — é um dos maiores atrativos da linguagem Python. A riqueza de bibliotecas open source é igualmente grande no Javascript, é verdade. Mas esta linguagem sempre me pareceu ligada muito fortemente à manipulação do DOM do navegador. Ser general-purpose desde o princípio, e não por expansão, me fez confiar muito mais em Python.

Construindo o scraper

O Robaudelaire precisava ter sua biblioteca, isto é, um banco de dados de poemas que serviriam de conteúdo para cada tweet. Para criá-la, havia duas opções: buscar uma API que providenciasse os dados dos poemas em formato JSON, ou extrair essa informação de sites que a contém, mas não providenciam uma API, por meio de um scraper.

Scrapers e crawlers não são exatamente a mesma coisa, mas são parecidos — como um prego e um parafuso. Deixo aqui uma definição rasa, só para esclarecer e seguir com a história:

Scrapers são scripts que visitam uma página da web e traduzem (parse) o código de forma a deixá-lo interpretável e navegável pela linguagem de programação. Desta forma, é possível buscar, listar, filtrar e manipular os elementos do html como quaisquer objetos. Crawlers são scripts que navegam as várias páginas de um site repetidamente, como um aventureiro que explora as áreas novas de um mapa. Como as duas atividades são fundamentais para o nosso programa, chamarei simplesmente de scraper.

O scraper foi desenvolvido utilizando a biblioteca Beautiful Soup 4, que faz exatamente o que está escrito na definição acima, portanto não é necessário repetir. Consiste em três funções: get_poem_list() acessa a página de um autor e retorna a lista de todos os seus poemas; get_poem_detail() acessa um poema individual e retorna o texto completo e o nome do autor devidamente formatado para o tweet (get_poem_detail() não será usada para construir a biblioteca); scrape_site() acessa o acervo e, utilizando get_poem_list() em cada um dos autores, retorna a lista total de poemas, com nome do autor, título e link.

A função get_poem_list() opera como um procedimento interno da função principal scrape_site(), que além fazer o scrape da página inicial para montar a lista “library” de autores e urls, funciona como um crawler que navega a página de cada autor, por meio da função map(…).
Rodando o scraper, preenchemos a biblioteca com 3.000 poemas de 150 autores. Restava apenas salvá-la no banco de dados como o arquivo .csv a ser consultado para criar os tweets. Em caso de dúvida sobre como salvar o objeto em .csv, segue o snippet.

Construindo o objeto Poem

Tendo a biblioteca em mãos, era hora de fazer os tweets — primeiro em texto, antes de postar no Twitter. Após algumas tentativas, decidi que a melhor abordagem seria criar instâncias/objetos de uma classe Poem, que teria em si não apenas os atributos obtidos da biblioteca, mas também dois métodos importantes: get_poem() e get_tweet().

Você deve ter percebido que a biblioteca que salvamos no banco de dados não contém os texto dos poemas. É claro que o Robaudelaire precisa desses textos para citar nos tweets. Para isso, cada instância do objeto Poem possui o método get_poem(), que chama a função get_poem_details() dos scrapers e retorna o poema completo.

Postando no twitter por meio da API

O Robaudelaire já tinha uma biblioteca cheia e o método para criar seus tweets. O último passo era postá-los no Twitter.
Para isso, era necessário criar uma conta na plataforma para developers do Twitter, vinculá-la à conta, registrar o app (i.e., o robô) e adquirir as quatro chaves para autenticação, api key, api secret key, access token, access token secret. (Esta parte é um desafio que vou deixar você enfrentar sozinho, porque a explicação seria longa, fácil e desinteressante).
Com as quatro chaves, é possível autenticar na API e postar o tweet com o método api.update_status(). Utilizei a biblioteca pandas para ler o arquivo .csv e extrair um poema aleatório com o método data.sample().

Com o arquivo main.py rodando, o loop infinito while True: posta um tweet a cada intervalo configurado no método time.sleep(). Na hora de configurar o intervalo de tweets, lembre-se que a API impõe um limite de acessos para evitar spam.

Conclusão

O Robaudelaire foi um programa fácil de se criar, mas um bom exercício para aprender a desenvolver scrapers e crawlers, ler e escrever arquivos, desenhar classes, interagir com APIs.
Por enquanto, ele só posta citações com links para o site que generosamente disponibiliza o acervo de poemas (espero que não se incomodem por eu pegá-lo emprestado). Mas há outras funcionalidades que podem ser desenvolvidas no futuro; por exemplo: retweetar conteúdos relevantes, responder automaticamente a mensagens e citações, entre outras.

Mas essa é outra história. Agradeço ao site poetica.fr por fornecer gratuitamente na internet um acervo de poesia tão impressionante. Se você gostou deste projeto e quer tirar dúvidas ou conversar, me mande um alô pelo Instagram ou me adicione no Github.

DEV Community: P. Schreiber 🧙🏻‍♂️🔮🐐

Prolog first steps: predicates, metapredicates, lambdas

Deductions: logical results

Predicates: defining our data set

Queries: deducting results from the data set

Get a value from relations

Get multiple valid results from relations

Get a list of valid results

Metapredicates

Lambdas

Conclusion

12 great music records for programers

Searching for inspiration

"Stone Flower", Antônio Carlos Jobim

"Peer Gynt", Edvard Grieg

"The Inner Mounting Flame", The Mahavishnu Orchestra

Powering though

"Blackwater Park", Opeth

"Saosin", Saosin

"Inspiration is DEAD", Ling Tosite Sigure

Chilling

"No. 4", Serge Gainsbourg

"At Home", Paddy Reilly

"Canta en Español Con Los Panchos", Eydie Gormé

Pretty writing in Emacs: exporting Org files to PDF

Introduction: Org to LaTeX to PDF

LaTeX: what is it, installation, exporting PDF

What is LaTeX?

Installation

Fixing problems and exporting the PDF

Running on Emacs

Transparent execution of Fortran code from the Erlang machine using ports

Table of Contents

The plan

The Fortran program

The Erlang program

Conclusion

Notes on Russel's Introduction to Mathematical Philosophy

Map, Filter, Reduce in C: recursive high-order functions using pointers

Considerations for implementing functional tools in C

Implementing a linked list

Using pointers to pass functions as arguments

Implementing recursive iterators

map

filter

reduce

Conclusion

Abstraction, Composition as Software Development Fundamentals: Reading List 1-3/2022

Abstraction and Composition

Algorithms + Data Structures = Programs

The Mythical Man-Month

Category Theory for Programmers

Fantasy-Oriented Programming

Art and science: identity and difference

The pragmatic ethos

The scientific ethos

The virtue of balance

Compreendendo tipos de dados algébricos com exemplos em Elixir

Introdução

Tipos de dados

Tipos de dados algébricos

Soma de tipos

Multiplicação de tipos

E quando o número de valores for infinito?

Tipos de funções

Tipos recursivos

Observação sobre os exemplos em Elixir

Implementando estados mutáveis e arquitetura cliente-servidor com funções recursivas e troca de mensagens entre processos

Estados mutáveis

Processos e troca de mensagens

Implementação de estados mutáveis

Arquitetura cliente-servidor

Conclusão

React Mastermind

As ferramentas utilizadas

Gerando o segredo

Gerando a pontuação

Condições de vitória e derrota

Conclusão

O robô entusiasta de poesia