Entrevista com Gavin Howard - O autor da linguagem bc do toybox

 

Entrevista com Gavin Howard - O autor da linguagem bc do toybox

    Recentemente eu postei em meu blog sobre o lançamento do bc 5.0 desenvolvido por Gavin Howard. Eu venho acompanhando o bc do Gavin desde de Noembro de 2018 quando foi anunciado que iria desenvolver um patch para o toybox. Também postei nom eu Instagram que estava testando a linguagem bc do Gavi mesmo que estava como pendente no  Toybox e desde então boas coisas vem aconcentendo. Uma delas é que eu conheci o próprio Gavin Howard que nos concedeu essa incrível entrevista. Espero que gostem :)

Gabriel: Antes muito obrigado por aceitar meu convite para essa entrevista.

Gavin: Muito obrigado! Muitas pessoas não ligam para a bc, então é legal que alguém ligue pelo menos uma vez. :)

Gabriel: Poderia nos contar um pouco sobre você? (Vida pessoal e profissional)

Gavin: Me formei na universidade há alguns anos em ciências da computação. Desde então, eu venho trabalhando em projetos pessoais enquanto lutava para conseguir e não conseguia manter um emprego. Minha esposa é a provedora. Tenho certeza que falhei em mantes empregos por causa de habilidades sociais, então eu sugeriria ao seu publico que eles desenvolvam essas habilidades cedo, mesmo que seja difícil.

    Desde meu emprego antigo, eu venho trabalhando na bc e em outro software, mas eu vou falar sobre esse software depois.

Gabriel: Por que decidiu desenvolver a bc?

Gavin: Só aconteceu, de verdade. Eu estava desempregado, alguém me pediu para construir um analisador para bc porque queria fazer a biblioteca matemática. Eu decidi fazer isso para experiencia de currículo.

    Bom, uma vez que eu desenvolvi o analisador, ele ainda não havia concluído, então eu decidi mergulhar e eu mesmo escrever a matemática. A essa altura, eu tinha um bc totalmente funcional. Levei coisa de um mês.

    E desde então eu venho a aperfeiçoando. Já fazem três anos e meio desde que eu concluí a implementação original. 

Gabriel: Quais são as principais diferenças entre o GNU bc e seu bc?

Gavin: Você mencionou que meu bc não possui alguns bugs que o GNU bc possui. Eu gostaria de explicar isso.

    bc é um programa que é padronizado pela POSIX. POSIX é um conjunto de padrões para sistemas operacionais que a maioria segue, incluindo Linux e Mac OSX (até certo ponto). POSIX não possui padrões somente para o sistema operacional; alguns padrões são para as ferramentas que o sistema operacional deve possuir agregadas a si. Entre estas estão o comando `ls`, o comando `mkdir`, o comando `ln` e o comando `bc`.

    O padrão bc define o que o bc tem que fazer e como deve se comportar. Se você escrever os seus scripts bc para seguir exatamente esse padrão, você pode muito bem contar com seu script executando em qualquer bc.

    O bug do GNU bc geralmente tem a ver com desvios do padrão bc. O meu bc não se desvia desse padrão de forma alguma, exceto por extensões que podem ser desabilitadas.

    Além disso, meu bc possui *muito* mais extensões que o GNU bc, que sim, possui algumas extensões. As extensões que meu bc possui e o GNU bc não inclui:

1. Um gerador de número pseudo-aleatório semeado que gerará números de tamanhos arbitrários. Isso permite os usuários gerar números pseudo-aleatórios em Bash scripts.
2. Um jeito de realizar entrada e saída de números em notações cientificas e de engenharia.
3. Atribuir de strings a variáveis, passá-las para funções, e retorná-las das funções.
4. Algumas funções extras builtin (abs(), modexp(), divmod(), asciify() e etc).
5. Alguns operadores extras para truncamento, extensão, e deslocamento decimal (não bitwise).
6. Uma biblioteca matemática estendida com um monte (94, eu acho?) de extras funções uteis de matemáticas. (Uma função não é realmente útil exceto para a biblioteca em si).
7. Uma flag de linha de comando para tornar mais fácil de cuidar de globals (ibase, obase, e scale).

Gabriel: Em uma conversa particular que tivemos, você me contou que seu bc foi adotado pela equipe do toybox para ajudar a construir o kernel Linux. Pode nos dar mais detalhes disso?

Gavin: No kernel Linux, há um header que precisa ser gerado durante a build. Esse header (include/generated/timeconst.h, veja https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/Kbuild#L16) possui as constantes para quantos milissegundos o kernel deve esperar antes de interromper um processo. Basicamente, esse header define o tamanho de fatias de tempo (https://en.wikipedia.org/wiki/Preemption_(computing)#Time_slice).

    Para gerar esse header, o kernel possui uma opção (CONFIG_HZ, encontrado em "Processor type and features" -> "Timer Frequency") que define o número de vezes por segundo que o kernel deve antecipar os processos. Essa frequencia precisa ser convertida numero de milissegundos por fatia. Originalmente, o script para fazer isso era em bc. Foi mudado para Perl por causa de bugs no GNU bc, mas retornaram depois que esses bugs podiam ser trabalhados ou corrigidos (veja https://github.com/torvalds/linux/commit/70730bca1331fc50c3caacaea00439de1325bd6e). O scritp é o kernel/time/timeconst.bc (https://github.com/torvalds/linux/blob/5bfc75d92/kernel/time/timeconst.bc).

    A razão que o bc é utilizado ao invés de Perl é porque bc é padrão POSIX, então o Linux pode esperar que ele exista no sistema, enquanto que Perl precisa ser explicitamente instalado. Dito isso, o script timeconst.bc  do Linux utiliza algumas extensões do GNU, que vence o propósito.

    Até aquele momento, o toybox não tinha o bc, e então, por si só, ele não era o suficiente para construir o kernel Linux, e devido o script Linux timeconst.bc utilizava extensões GNU, ele realmente precisava do GNU bc. Com essa adição do meu bc, que possui todas as extensões do  GNU bc, o toybox se tornou capas de construir o Linux sem quaisquer outras utilidades externas, um conquista memorável para o autor do toybox.

código bc dentro do Linux

Gabriel: Na minha opinião pessoal, bc é um bom jeito de aprender a programas. Você concorda?

Gavin: Eu fortemente discordo, na verdade. A razão é proque há numerosas  armadilhas e ciladas que você pode cair quando escrever código bc (veja aqui https://git.yzena.com/gavin/bc/src/branch/master/manuals/development.md#lib-bc-1). Essas armadilhas incluem:

1. Existem três variáveis globais (ibase, obase e scale) que controlam como o bc se comprota. Essas globais devem ser tratadas corretamente todo o tempo.
2. As globais (ibase, obase e scale) devem ser salvas antes de ser modificadas em uma função, e devem ser restauradas antes de retornar de uma função.
3. Se constantes são utilizadas, ibase deve ser explicitamente definida pela função (e restaurada antes de retornar) ou então as constantes serão implementadas da forma errada.
4. Se a função exibir um número na saída, obase deve se explicitamente definida pela função (e restaurada antes de retornar) antes de exibir, ou o número será exibido de um jeito inesperado.
5. Todas as variáveis  locais para a função devem estar em um auto statement no inicio da função, incluindo arrays. Se você não fizer isso, as variáveis ou arrays são presumidas ser globais e assim as versões globais serão utilizadas/modificadas. No entanto, "globais" nesse sentido *também* é errônea. Digamos que possui uma função que possui a variável `a` como uma variável local (ela aprece no auto statement). Se você chamar uma função que acessa uma "global" `a`, a `a` que ela acessa não a global verdadeira `a`, mas a versão de uma `a` na função que a chamou! Isso está no padrão, então eu não posso alterar isso, mas é algo a ser considerado.
6. A ultima cilada é somente para código que quer ser portado para qualquer bc: você não pode utilizar *quaisquer* extensões.

    Essa ultima merece uma olhada mais de perto. O bc padrão POSIX é estrutura básica; ele não tem quase nada! Essas são algumas coisas que ele não possui:

1. Nomes maiores do que um carácter.
2. Clausulas `else` para `if` statements.
3. A palavra-chave `continue` (apesar de possuir `break`).
4. Um jeito fácil de exibir strings com caracteres escape (a palavra-chavet `print` no meu bc).
5. Return statements *sem* parenteses.
6. Você não pode comparar operadores fora `if` statements ou condinções loop.
7. Você só pode somente utilizar *1* operador de comparação por `if` statement e loop, então nada de operadores `&&` ou `||`!
8. Tecnicamente, parâmetros array são de alguma forma limitados também.
9. Strings só podem ser exibidos e nada mais ser feito com ou a eles.

(Para tudo o que meu bc faz que bc padrão POSIX não, veja aqui see https://git.yzena.com/gavin/bc/src/branch/master/src/data.c#L265-L283).

    Dito isso, se você precisar escrever um script matemático em uma linguagem de números de precisão arbitrária, e Python não vai funcionar (Python possui suporte razoavelmente bom à matemática de precisão arbitrária), então bc pode ser o que você precisa.

    Além do mais, meu bc remove um monte dessas limitações. ela remove número 2 (se você utilizar a opção -g na linha de comando) e basicamente todas as limitações sob o número 6. O resto não pode ser eliminado porque eles não inerentes ao design do bc.

Gabriel: Como as pessoas podem contribuir para o seu projeto?

Gavin: Eu na verdade não recebo contribuições além de bug reports. Meu projeto atual está em https://git.yzena.com/Yzena/Yc, e eu explico minha politica em https://git.yzena.com/Yzena/Yc#open-source-not-open-contribution.

    A parte que *não* é escrita é que, Se eu mesmo escrever, eu posso garantir que o software está em tal alta qualidade que eu tenho vontade de assumir a responsabilidade por ele. Esse é o meu objetivo atual: Escrever software útil e aceitar responsabilidade por ele, por um preço. Eu acho que se eu não conseguir um emprego, eu posso gerar um emprego para mim ao vender software e aceitar responsabilidade por isso.

    (Mas mesmo se eu vender software, ele será open source! Eu só venderei proteção de responsabilidade, não o software em si).

    Dito isso, se você encontrar um bug no bc e concertá-lo, provavelmente eu ainda eu receba sua correção; eu nunca vou aceitar responsabilidade pelo bc. Você também é bem vindo em submeter bug reports para *todos* os meus programas.

Gabriel: Considerações finais?

Gavin: Atualmente estou escrevendo uma linguagem de programação, um build system e um VCS (Version Control System). Se qualquer pessoa do seu publico quiser me contatar com comentários ou perguntas sobre essas três coisas, ou sobre meu bc, eles são bem vindos. Eu vou tentar responder o mais rápido possível. Para encontrar meu endereço de e-mail, vá em https://gavinhoward.com/contact/.

Obrigado por me escutar!

Para baixar a versão 5.0 da linguagem bc, basta clicar aqui

Saiba mais sobre a linguagem bc

 QUER APRENDER A UTILIZAR LINUX DE VERDADE, ENTÃO VENHA APRENDER COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte