Eu não gastei muito tempo explicando recursão por causa daquilo que disse no começo deste curso: eu considero que quem o está seguindo são programadores experientes. Eu sei que o conceito de recursão pode ser difícil para iniciantes, mas não é aqui o lugar para entrar no b+a=ba da coisa.
O que programadores experientes podem achar estranho é o uso de recursão para quase tudo. “É que recursão consome pilha” você deve estar pensando. E está até certo. Nas linguagens procedurais e nas orientadas a calças, fazer uma recursão muito profunda pode se tornar uma grande dor de cabeça.
Python, por exemplo, tem um limite de recursão interno. Depois de umas milhares de chamadas, o interpretador sobe uma exceção (“RuntimeError: maximum recursion depth exceeded”). Em C, se você estourar a pilha, teu programa morre.
Eu cá estava pensando em pegar leve e mostrar comparações entre valores, shifts, aritmética, etc. Depois iria ver estruturas de dados. Mas, seria muito, muito chato. É melhor já entrarmos nas funções para que você possa se animar com a linguagem. :)
Mas, primeiro…
Átomos
Pois é, antes de entrarmos no reino das funções, precisamos entender o que é um átomo.
Ao contrário de Python, por exemplo, em que as coisas são, basicamente, valores ou keywords (10, “x”, while), Erlang, sendo um bom filho de Prolog, tem também átomos.
Conforme prometido, vamos ver uma implementação alternativa da função ler_arquivo/1. Para isso, vamos criar o módulo funcoes2 (“funcoes2.erl”).
-module(funcoes2).-export([ler_arquivo/1]).
ler_arquivo(Filename) -ᐳ
{ok, Fd} = file:open(Filename, [read]),
interpretar_linha(Fd).
interpretar_linha(Fd) -ᐳ
Leitura = file:read_line(Fd),
case Leitura of
{ok, Linha} -ᐳ
[PrimeiroChar|Resto] = Linha,
case PrimeiroChar of
$# -ᐳ pulando;
_ -ᐳ io:format("~s", [Linha])
end,
interpretar_linha(Fd);
eof -ᐳ file:close(Fd)
end.
Aqui a recursão permanece (vide linha 17), formando nosso “loop”, mas o tratamento dos tipos de linha é feito dentro da própria função. Para isso, usamos um case.
Vamos implementar a nossa função das aulas anteriores em Python?
Vamos!
#!/usr/bin/python
# -*- coding: utf-8 -*-
def interpretar_linhas(filename):
with open(filename) as arquivo:
for linha in arquivo:
if not linha.startswith('#'):
print linha,
if __name__ == '__main__':
import sys
interpretar_linhas(sys.argv[1])
Sim, eu sei que tem menos linhas e sei que o código aparenta ser mais claro. É quase desonesto comparar esse tipo de requisito (jogar na tela um arquivo texto com todas as linhas que não comecem com “#”) implementado em Python com qualquer outra linguagem.
(Mas, claro, um Perl monk conseguiria fazer isso tudo em uma linha só (eu acho).)
Eu estava pesquisando sobre Erlang, especialmente sobre sites em português, e, no meio da busca (que retornou, basicamente, vários sites em inglês), encontrei este excelente artigo (de 2012) do Evan Miller: Why I Program In Erlang.
Depois de lê-lo, logo me veio à mente: este é o conteúdo perfeito para o primeiro post do “Erlang de Hoje”! (Site que, agora, está morto e será migrado para cá.) Então, depois de pedir permissão ao Evan, logo comecei a traduzi-lo.
Lembrando que é uma tradução livre e não-oficial, segue o conteúdo:
Por que eu programo em Erlang
Por Evan Miller
20 de outubro de 2012
Erlang é uma linguagem com mais de 25 anos de vida que nunca ganhou um concurso de popularidade e quase certamente nunca ganhará qualquer medalha por velocidade, nem sequer uma coroa de louros por beleza sintática. A linguagem é lenta, esquisita e feia. Refatoração de código Erlang é um sofrimento.
Recentemente descobri uma particularidade interessante da linguagem Zig, que é a “extração de valores”, coisa que inicialmente eu julgava feia e esquisita mas agora consigo entender que há um bom motivo por trás da coisa toda.
Photo by https://unsplash.com/photos/BStW5kYXw4E on Unsplash
Conforme já comentei em artigos anteriores, sou um usuário de Linux
bastante cíclico. Passei um bom tempo, recentemente, deixando de lado
meus problemas “filosóficos” com o systemd e seus amigos e usando
o Linux Mint. Ultimamente, acabei encontrando o MX Linux, que é um
Debian sem systemd. Mas o MX ainda é um amontoado meio desorganizado
de software, todo empilhado de maneira a “funcionar”, distante do que eu
acredito que seria um sistema operacional ideal para mim.
Então eu tive uma ideia: eu precisava de um “sistema base” que praticamente
não mudasse nunca, e poderia rodar aplicações mais “chatas” em containers
rodando qualquer outra distro que fosse necessária. Dessa maneira, além de
ter um sistema mais são, eu evitaria o transtorno que é ficar migrando
de uma distro para outra (e isso acontece frequentemente...).
Funcional, mas sem exageros
O que é
coconut é uma espécie de “transpiler” que permite que você faça uso de algumas funcionalidades bem interessantes de linguagens funcionais, mas mantendo 100% de compatibilidade com o Python tradicional.
Basicamente, você escreve teu módulo/script/programa em arquivos .coco e depois “compila” cada um desses arquivos para um .py correspondente.
Uma rede P2P “offline first”
1- Problemas comuns que eu gostaria de resolver
Tenho percebido que sou um usuário de computador constante e extremamente insatisfeito. Há muita coisa que eu gostaria que fosse possível (e fácil) mas que, atualmente, são casos meio que sem solução. São problemas comuns que eu acredito que afligem muita gente, não somente a mim. E eu me sinto meio frustrado por não conseguir resolvê-los, seja por falta de tempo, seja por falta de capacidade, mesmo…
1.1- Dois laptops
Eu uso dois laptops distintos: um em casa e outro no trabalho. E eu gostaria que meus “archives” (as coisas que eu mantenho salvas no HD e que estão razoavelmente bem organizadas e catalogadas) ficassem perfeitamente sincronizados entre os dois. Ou seja: alterações que eu faça em um eu quero que sejam aplicadas também a outro e vice-versa.