O tio Crébis escrevendo sobre Software

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.

Read more...

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.

Read more...

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.

Read more...

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).)

Read more...

Eu lembro de ter feito algo assim em Prolog.

De fato, para alguém TÃO acostumado a programação procedural e a paradigmas “comuns”, é um tanto complicado começar a entender programação funcional. Eu, por exemplo, admito que a experiência anterior com Prolog me ajuda muito a conseguir pensar em Erlang.

Sim, Prolog é um paradigma diferente (programação lógica), mas a sintaxe do código que eu fiz, sinceramente, é praticamente Prolog. Vide:

    -module(join_lists).
    -export([join/2]).

    join([Head|Tail], [Head2|Tail2]) -ᐳ
        [Head|join(Tail, [Head2|Tail2])];
    join([], [Head2|Tail2]) -ᐳ
        [Head2|Tail2].
Read more...

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.

Read more...

zig.webp

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.

Read more...

black illuminated keyboard

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...).

Read more...

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.

Read more...

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.

Read more...