 |
| Bellacosa Mainframe e a caixa preta do automatos |
☕ Um Café no Bellacosa Mainframe
🌑 CID KAGENOU E A CAIXA-PRETA DOS AUTÔMATOS — QUANDO O COBOL DESCOBRIU QUE TAMBÉM ERA UMA MÁQUINA DE ESTADOS
Autômatos finitos, máquinas de estados, linguagens regulares, regex, engenharia reversa, CPU, COBOL, testes, protocolos, segurança — e o dia em que Shadow descobriu que não precisava abrir a caixa-preta para descobrir o segredo escondido dentro dela.
🎬 PRÓLOGO — HÁ ALGUMA COISA ESCONDIDA NESSA CAIXA
Imagine Cid Kagenou entrando em uma dungeon.
Nenhum monstro.
Nenhum artefato mágico.
Nenhuma princesa sequestrada.
Alpha olha desconfiada para o centro da sala.
Ali existe apenas uma pequena caixa preta.
Na frente dela:
um terminal de entrada;
uma pequena lâmpada;
um botão escrito RESET.
Beta examina o equipamento.
— Shadow-sama, devemos desmontá-lo?
Cid cruza os braços.
— Não.
Silêncio dramático.
Naturalmente, todos imaginam que Shadow descobriu algum segredo ancestral.
Na realidade, ele simplesmente não sabe como abrir a caixa.
Mas, como frequentemente acontece em The Eminence in Shadow, uma frase improvisada acaba contendo uma ideia surpreendentemente profunda:
Não precisamos conhecer o interior de uma máquina para estudar seu comportamento.
E é justamente assim que começa nossa excursão pela Teoria dos Autômatos.
Pegue seu café.
Aperte o cinto.
Nosso ônibus vai balançar um pouco.
🚌 CAPÍTULO 1 — O ÔNIBUS DE TURING CHEGA À DUNGEON
A inspiração desta viagem vem de A. K. Dewdney, autor de The Turing Omnibus, livro concebido como uma série de excursões por diferentes territórios da Ciência da Computação.
A metáfora é maravilhosa.
Em vez de imaginar Ciência da Computação como um gigantesco manual técnico, imagine um ônibus.
Em cada parada visitamos alguma região:
AUTÔMATOS
↓
LINGUAGENS FORMAIS
↓
ALGORITMOS
↓
LÓGICA
↓
COMPLEXIDADE
↓
COMPUTABILIDADE
↓
INTELIGÊNCIA ARTIFICIAL
↓
...
Na primeira excursão encontramos justamente uma criatura aparentemente humilde:
o autômato finito.
Não deixe o nome assustar.
Vamos desmontar o conceito — sem desmontar nossa caixa.
📦 CAPÍTULO 2 — SHADOW ENCONTRA UMA CAIXA-PRETA
Nossa máquina possui uma entrada capaz de receber dois sinais:
0
1
Também possui uma lâmpada.
Quando determinada sequência é fornecida, a lâmpada eventualmente acende.
Podemos representar a máquina assim:
┌──────────────────────┐
0 ou 1 ─────►│ │
│ CAIXA-PRETA │────► 💡
RESET ──────►│ │
└──────────────────────┘
Não sabemos o que existe dentro.
Pode haver:
transistores
circuitos
flip-flops
microcontrolador
relés
magia negra
um COBOL de 1978
Para nossa análise, isso não importa.
Estamos interessados em:
ENTRADA → COMPORTAMENTO → SAÍDA
Essa é uma abstração extremamente importante na computação.
Um programa COBOL pode executar:
CALL 'PAGTO001'
Você não precisa necessariamente conhecer cada instrução existente em PAGTO001 para utilizar sua interface corretamente.
Da mesma maneira, quando consumimos uma API:
POST /pagamento
podemos trabalhar com o contrato da API sem conhecer toda sua implementação.
A primeira lição da dungeon é, portanto:
Implementação e comportamento são coisas diferentes.
🧪 CAPÍTULO 3 — ALPHA COMEÇA OS EXPERIMENTOS
Vamos alimentar nossa máquina.
Depois de pressionar RESET:
0
Nada.
1
Nada.
0
Nada.
1
💡
A lâmpada acendeu.
Descobrimos:
0101
parece ser uma sequência aceita.
Alpha repete imediatamente:
0101
Nada.
Beta começa a escrever um relatório de 847 páginas explicando que provavelmente se trata de um artefato demoníaco.
Até alguém lembrar:
RESET.
Pressionamos RESET.
Executamos novamente:
0101
💡
Funciona.
Isso revela uma informação gigantesca.
A máquina lembra alguma coisa do que aconteceu anteriormente.
🧠 CAPÍTULO 4 — O SEGREDO CHAMA-SE ESTADO
Se a saída dependesse somente do último símbolo recebido, bastaria analisar:
entrada atual
Mas nossa experiência demonstra que o comportamento depende também da história anterior.
Existe alguma espécie de memória.
Na teoria dos autômatos chamamos essa informação de:
ESTADO
Estado não significa necessariamente uma variável armazenada em RAM.
Uma definição muito melhor seria:
Estado é a informação relevante sobre o passado necessária para decidir o comportamento futuro.
Essa frase vale ouro.
Imagine uma porta eletrônica.
Ela poderia possuir:
LOCKED
UNLOCKED
Quando recebe:
CARD_VALID
pode fazer:
LOCKED → UNLOCKED
Quando alguém abre a porta:
UNLOCKED → LOCKED
Não precisamos registrar toda a biografia da pessoa:
acordou às 07:00
tomou café
pegou o carro
chegou ao escritório
tirou o cartão do bolso
...
Nada disso interessa à porta.
A informação relevante é:
LOCKED
ou:
UNLOCKED
O estado é, portanto, uma espécie de compressão do passado.
🌑 CAPÍTULO 5 — SHADOW GARDEN DESCOBRE A MÁQUINA DE ESTADOS
Imagine uma catraca.
Estados:
Q0 = LOCKED
Q1 = UNLOCKED
Entradas:
COIN
PUSH
Podemos definir:
LOCKED + COIN → UNLOCKED
LOCKED + PUSH → LOCKED
UNLOCKED + PUSH → LOCKED
UNLOCKED + COIN → UNLOCKED
Isso pode ser colocado numa tabela:
| Estado atual | Entrada | Novo estado |
|---|---|---|
| LOCKED | COIN | UNLOCKED |
| LOCKED | PUSH | LOCKED |
| UNLOCKED | PUSH | LOCKED |
| UNLOCKED | COIN | UNLOCKED |
Temos uma máquina de estados.
E provavelmente você já programou alguma sem saber.
🧙 CAPÍTULO 6 — A DEFINIÇÃO MATEMÁTICA
Um autômato finito determinístico costuma ser definido pela quíntupla:
M = (Q, Σ, δ, q0, F)
Calma.
Não invoque ainda o compilador COBOL.
Vamos traduzir.
Q — conjunto de estados
Por exemplo:
Q = {q0,q1,q2,q3,q4,q5}
Σ — alfabeto
São os símbolos aceitos como entrada.
No nosso exemplo:
Σ = {0,1}
δ — função de transição
A famosa letra grega delta determina:
estado atual + entrada → próximo estado
Formalmente:
δ : Q × Σ → Q
Por exemplo:
δ(q3,0)=q5
δ(q3,1)=q4
q0 — estado inicial
É onde começamos depois do RESET.
F — estados finais
São os estados considerados de aceitação.
Quando terminamos de processar a entrada em algum deles:
💡
A sequência foi aceita.
💾 CAPÍTULO 7 — DELTA DESCOBRE QUE DELTA NÃO É APENAS UMA PERSONAGEM
Imagine a surpresa da própria Delta ao descobrir que existe uma função matemática chamada δ.
Se estivermos em:
q3
e recebermos:
1
podemos ter:
δ(q3,1)=q4
Isso significa simplesmente:
ESTADO ATUAL = Q3
ENTRADA = 1
NOVO ESTADO = Q4
Não existe mistério.
Na prática, poderíamos implementar isso em COBOL.
💻 CAPÍTULO 8 — O AUTÔMATO ENTRA NO COBOL
Considere:
01 WS-STATE PIC X(02).
01 WS-INPUT PIC X.
MOVE 'Q0' TO WS-STATE.
EVALUATE TRUE
WHEN WS-STATE = 'Q0'
AND WS-INPUT = '0'
MOVE 'Q1' TO WS-STATE
WHEN WS-STATE = 'Q0'
AND WS-INPUT = '1'
MOVE 'Q0' TO WS-STATE
WHEN WS-STATE = 'Q1'
AND WS-INPUT = '0'
MOVE 'Q1' TO WS-STATE
WHEN WS-STATE = 'Q1'
AND WS-INPUT = '1'
MOVE 'Q2' TO WS-STATE
END-EVALUATE.
Parabéns.
Acabamos de implementar parte de um autômato finito.
Uma implementação mais organizada poderia separar:
READ-INPUT
PROCESS-TRANSITION
CHECK-FINAL-STATE
Observe como conceitos aparentemente matemáticos começam a aparecer naturalmente no COBOL.
🔄 CAPÍTULO 9 — O RESET É O INITIALIZE DA DUNGEON
O botão RESET possui uma importância enorme.
Ele coloca a máquina novamente em:
q0
Imagine testar:
0101
e depois:
0100101
sem RESET.
O segundo teste não começa realmente do zero.
A máquina pode estar carregando o estado produzido pelo primeiro.
Na prática estamos testando algo parecido com:
01010100101
Isso possui uma conexão direta com testes de software.
Um teste confiável deve começar de condições conhecidas.
Algo como:
GIVEN estado conhecido
WHEN evento acontece
THEN resultado esperado
Em COBOL isso poderia significar:
INITIALIZE WS-AREA
MOVE ZERO TO WS-COUNTER
MOVE '00' TO WS-STATUS
Estado residual é uma fonte clássica de bugs.
🔬 CAPÍTULO 10 — SHADOW COMEÇA A ENGENHARIA REVERSA
Executamos vários experimentos.
Descobrimos que a caixa aceita:
0101
0100101
0100100101
0100100100101
Vamos reorganizar:
01 01
01 001 01
01 001 001 01
01 001 001 001 01
Há claramente um padrão:
01 (001)* 01
O símbolo:
*
é chamado estrela de Kleene.
Significa:
zero ou mais repetições.
Portanto:
(001)*
pode produzir:
ε
001
001001
001001001
001001001001
...
ε representa a palavra vazia.
Consequentemente:
01(001)*01
produz:
0101
0100101
0100100101
0100100100101
...
Acabamos de entrar no território das linguagens regulares.
📜 CAPÍTULO 11 — REGEX NÃO NASCEU PARA VALIDAR E-MAIL
Quando alguém fala em expressão regular, muitos programadores imediatamente pensam:
^[0-9]{5}-[0-9]{3}$
CEP.
Ou alguma criatura monstruosa utilizada para validar endereço de e-mail.
Mas existe uma teoria matemática muito mais profunda por trás disso.
A relação fundamental é:
┌─────────────────────┐
│ EXPRESSÃO REGULAR │
└──────────┬──────────┘
│
⇅
┌─────────────────────┐
│ AUTÔMATO FINITO │
└──────────┬──────────┘
│
⇅
┌─────────────────────┐
│ LINGUAGEM REGULAR │
└─────────────────────┘
Essas são diferentes maneiras de descrever a mesma classe fundamental de linguagens.
Uma regex pode ser transformada em um autômato.
Um autômato pode ser utilizado para reconhecer uma linguagem regular.
Essa relação aparece na implementação de scanners, parsers simples, ferramentas de busca e compiladores.
⚠️ CAPÍTULO 12 — CID PERCEBE O PROBLEMA DA INDUÇÃO
Agora surge uma questão maravilhosa.
Testamos:
0101
0100101
0100100101
0100100100101
Todas funcionaram.
Podemos afirmar que:
01(001)*01
é realmente a linguagem completa da máquina?
Não.
Talvez a máquina aceite apenas:
n <= 4
Talvez rejeite a quinta repetição.
Ou a número 847.
Ou talvez exista algum comportamento especial depois de 65.535 símbolos.
Experimentar alguns casos não demonstra automaticamente uma regra infinita.
Esse é um princípio extremamente importante também para testes.
🧪 CAPÍTULO 13 — “FUNCIONOU NO MEU TESTE”
O programador executa:
100 → OK
200 → OK
300 → OK
400 → OK
e declara:
— Funciona.
Shadow aparece atrás dele.
— Você testou 32767?
Silêncio.
— E 32768?
Mais silêncio.
— 99999999?
O programador começa a suar.
Testes demonstram comportamento para os casos efetivamente observados.
Não provam automaticamente comportamento universal.
É exatamente o problema encontrado na caixa-preta.
🕵️ CAPÍTULO 14 — MAS E SE SOUBERMOS QUANTOS ESTADOS EXISTEM?
Agora alguém nos fornece uma informação adicional:
A máquina possui seis estados.
Isso muda profundamente o problema.
Imagine:
q0
q1
q2
q3
q4
q5
Depois de transições suficientes, algum estado inevitavelmente precisará reaparecer.
Por quê?
Porque só existem seis possibilidades.
Se continuarmos andando:
q0 → q1 → q2 → q3 → q4 → q5 → ?
o próximo estado necessariamente será algum estado já existente.
Surge então um ciclo:
┌──────────────┐
↓ │
q2 → q3 → q4 → q5 ────┘
E ciclos explicam repetições.
Como:
(001)*
Aqui começamos a enxergar a intuição que posteriormente aparece em resultados como o Pumping Lemma.
🏰 CAPÍTULO 15 — EXISTEM MONSTROS QUE O AUTÔMATO NÃO CONSEGUE DERROTAR
Considere:
ab
aabb
aaabbb
aaaabbbb
A regra é:
aⁿbⁿ
Precisamos garantir:
quantidade de a = quantidade de b
Agora imagine:
aaaaaaaaaaaaaaaa....
Para saber quantos b deverão aparecer posteriormente, precisamos lembrar quantos a foram encontrados.
Mas nosso autômato possui memória finita.
Se existem apenas:
q0 q1 q2 q3 q4 q5
como representar:
1
2
3
4
...
1.000.000
quantidades diferentes?
Não consegue.
Encontramos uma fronteira computacional.
🪜 CAPÍTULO 16 — A ESCADA DAS MÁQUINAS
Quando precisamos de memória adicional, utilizamos modelos mais poderosos.
De forma simplificada:
AUTÔMATO FINITO
↓
AUTÔMATO COM PILHA
↓
MODELOS MAIS PODEROSOS
↓
MÁQUINA DE TURING
O autômato com pilha pode trabalhar com estruturas como:
((()))
Cada abertura:
(
pode empilhar alguma informação.
Cada fechamento:
)
remove algo da pilha.
Isso permite reconhecer estruturas que um simples autômato finito não consegue reconhecer.
E estamos nos aproximando da Hierarquia de Chomsky e da teoria das linguagens formais.
A pequena lâmpada começou a ficar perigosamente interessante.
🖥️ CAPÍTULO 17 — ESTÁVAMOS ESTUDANDO UMA CPU?
Existe uma bela provocação no texto original adaptado:
estivemos estudando o funcionamento de uma CPU simples.
Precisamos colocar uma pequena ressalva técnica.
Uma CPU moderna não é simplesmente aquele pequeno DFA.
Entretanto, componentes de hardware e circuitos sequenciais podem ser modelados por máquinas de estados.
Imagine:
FETCH
↓
DECODE
↓
EXECUTE
↓
MEMORY
↓
WRITEBACK
↓
FETCH
O processador possui estados internos.
Sinais e resultados influenciam as próximas transições.
Assim, a teoria dos autômatos possui ligação genuína com projeto de hardware.
🏧 CAPÍTULO 18 — VOCÊ ESTÁ CERCADO POR MÁQUINAS DE ESTADOS
Olhe ao redor.
Um elevador:
STOPPED
MOVING_UP
MOVING_DOWN
DOOR_OPEN
DOOR_CLOSING
Um caixa eletrônico:
IDLE
↓
CARD_INSERTED
↓
PIN_VALIDATED
↓
AUTHENTICATED
↓
TRANSACTION
↓
EJECT_CARD
Uma aplicação:
LOGGED_OUT
↓
AUTHENTICATING
↓
LOGGED_IN
↓
SESSION_EXPIRED
Um pedido:
CREATED
↓
PAID
↓
PROCESSING
↓
SHIPPED
↓
DELIVERED
Até muitos protocolos de rede podem ser entendidos como máquinas de estados.
💳 CAPÍTULO 19 — O AUTÔMATO ENTRA NO MAINFRAME
Agora imagine processamento de cartões.
Uma transação poderia atravessar:
RECEIVED
↓
VALIDATED
↓
AUTHORIZED
↓
CAPTURED
↓
SETTLED
Ou:
RECEIVED
↓
VALIDATED
↓
DECLINED
Isso poderia estar espalhado por:
COBOL
CICS
Db2
VSAM
IBM MQ
batch
APIs
Mas conceitualmente temos uma máquina de estados.
Um programa poderia fazer:
EVALUATE WS-STATUS
WHEN 'RECEIVED'
PERFORM 2000-VALIDATE
WHEN 'VALIDATED'
PERFORM 3000-AUTHORIZE
WHEN 'AUTHORIZED'
PERFORM 4000-CAPTURE
WHEN 'CAPTURED'
PERFORM 5000-SETTLEMENT
END-EVALUATE.
O programador COBOL está implementando teoria dos autômatos sem necessariamente perceber.
⚔️ CAPÍTULO 20 — A TRANSIÇÃO PROIBIDA
Aqui aparece uma aplicação extremamente útil para manutenção de sistemas legados.
A documentação diz:
CREATED → PAID → SHIPPED
Mas encontramos:
CREATED → SHIPPED
Pergunta:
essa transição é válida?
Talvez tenhamos encontrado o bug.
Em vez de olhar apenas para milhares de linhas COBOL, podemos tentar descobrir:
ESTADOS
EVENTOS
TRANSIÇÕES
ESTADOS FINAIS
Um programa de 12.000 linhas talvez possa ser resumido como:
14 estados
43 transições
11 eventos
5 estados finais
Isso é ouro para engenharia reversa.
🔥 CAPÍTULO 21 — WAR ROOM ÀS 03:17
03:17.
Naturalmente.
O telefone toca.
Produção caiu.
No log:
03:17:00 RECEIVED
03:17:01 VALIDATED
03:17:02 AUTHORIZED
03:17:03 CAPTURED
03:17:04 ERROR
O programador procura:
IF
EVALUATE
GO TO
PERFORM
O DBA examina Db2.
O especialista CICS olha dumps.
O pessoal de infraestrutura examina CPU.
Shadow permanece no fundo da sala.
Até fazer uma pergunta:
CAPTURED → ERROR é uma transição permitida?
Silêncio.
Talvez o problema não esteja em uma instrução individual.
Talvez exista uma transição de negócio impossível.
E aí está nosso easter egg das 03:17.
🛡️ CAPÍTULO 22 — O AUTÔMATO VIRA RED TEAM
Máquinas de estados também ajudam a pensar segurança.
Imagine:
DISCONNECTED
↓ LOGIN
AUTHENTICATING
↓ SUCCESS
AUTHENTICATED
Mas alguém descobre:
DISCONNECTED
↓ EVENTO-X
ADMIN
Isso é interessantíssimo.
O atacante encontrou uma transição que não deveria existir.
Problemas semelhantes aparecem em:
protocolos
autenticação
workflows
APIs
sistemas distribuídos
model-based testing
fuzzing
engenharia reversa
Uma excelente estratégia de segurança é perguntar:
Quais estados existem e quais transições deveriam ser impossíveis?
🤖 CAPÍTULO 23 — A CAIXA-PRETA ENCONTRA A INTELIGÊNCIA ARTIFICIAL
Existe ainda uma conexão conceitual com IA.
Nosso experimento faz:
ENTRADAS
↓
OBSERVAÇÕES
↓
HIPÓTESE
↓
MODELO
Em aprendizado de máquina fazemos, em sentido muito amplo:
DADOS
↓
PADRÕES
↓
MODELO
Naturalmente um LLM moderno não deve ser confundido com o pequeno autômato da nossa dungeon.
Mas existe uma pergunta epistemológica comum:
Quanto podemos descobrir sobre um sistema observando somente seu comportamento externo?
Essa questão reaparece quando trabalhamos com sistemas proprietários, serviços remotos e modelos aos quais não temos acesso interno.
A caixa-preta continua conosco.
🔧 CAPÍTULO 24 — COMO USAR ESSA IDEIA NUM COBOL LEGADO
Agora uma dica extremamente prática.
Você recebe um programa desconhecido.
Não comece tentando entender todas as linhas simultaneamente.
PASSO 1 — descubra as entradas
Procure:
arquivos
COMMAREA
MQ
parâmetros
Db2
VSAM
SYSIN
PASSO 2 — identifique os estados
Procure campos como:
STATUS
STATE
SITUATION
TYPE
PHASE
STAGE
FLAG
PASSO 3 — encontre onde mudam
Pesquise:
MOVE 'XX' TO WS-STATUS
ou:
SET STATUS-APPROVED TO TRUE
PASSO 4 — construa uma tabela
Por exemplo:
| Estado | Evento | Próximo estado |
|---|---|---|
| RECEIVED | VALID | VALIDATED |
| RECEIVED | INVALID | REJECTED |
| VALIDATED | APPROVE | AUTHORIZED |
| VALIDATED | DENY | DECLINED |
PASSO 5 — desenhe o diagrama
Você pode descobrir uma arquitetura lógica que ninguém documentou.
PASSO 6 — procure transições impossíveis
Pergunte:
REJECTED → SETTLED ?
CANCELLED → AUTHORIZED ?
SHIPPED → CREATED ?
Esses caminhos merecem investigação.
🧠 CAPÍTULO 25 — O VERDADEIRO PODER DA ABSTRAÇÃO
Observe tudo que removemos da caixa:
voltagem
resistores
transistores
temperatura
fiação
material
clock
fabricante
E preservamos:
Q
Σ
δ
q0
F
Esse processo chama-se abstração.
Não estamos dizendo que detalhes físicos não existem.
Estamos dizendo:
para responder determinada pergunta, eles não são necessários.
Isso aparece em toda a computação.
Quando trabalhamos com COBOL:
arquivo lógico
podemos não precisar conhecer imediatamente a geometria física do disco.
Quando usamos Db2:
SELECT ...
não precisamos controlar manualmente cada bloco armazenado.
Quando utilizamos MQ:
PUT
GET
trabalhamos sobre uma abstração.
Camadas de abstração são uma das razões pelas quais conseguimos construir sistemas gigantescos.
☕ EPÍLOGO — SHADOW DESCOBRE O QUE SIGNIFICA COMPUTAR
Nossa excursão começou com:
0
1
RESET
💡
Parecia quase infantil.
Mas então descobrimos:
caixa-preta
↓
estado
↓
transição
↓
autômato
↓
linguagem
↓
expressão regular
↓
limites de memória
↓
linguagens formais
↓
computabilidade
Essa é a beleza da Ciência da Computação.
COBOL é importante.
Python é importante.
Java é importante.
Assembler é importante.
Mas existe um universo abaixo das linguagens:
LÓGICA
AUTÔMATOS
ALGORITMOS
LINGUAGENS FORMAIS
COMPLEXIDADE
COMPUTABILIDADE
INFORMAÇÃO
Um programador pode passar décadas escrevendo programas sem visitar profundamente esse território.
Mas quando começa a estudá-lo, algo muda.
Ele deixa de enxergar apenas:
IF
MOVE
PERFORM
EVALUATE
e começa a enxergar:
ESTADOS
TRANSIÇÕES
LINGUAGENS
MODELOS
INVARIANTES
LIMITES
E isso muda inclusive a maneira de investigar um COBOL legado.
Aquele monstro de 15.000 linhas talvez não seja simplesmente um amontoado de PERFORM, IF, copybooks e tabelas Db2.
Talvez escondido lá dentro exista algo muito mais elegante:
┌─────────────┐
│ RECEIVED │
└──────┬──────┘
↓
┌─────────────┐
│ VALIDATED │
└──────┬──────┘
┌───┴───┐
↓ ↓
AUTHORIZED DECLINED
↓
CAPTURED
↓
SETTLED
Uma máquina de estados.
Uma descendente conceitual daquela pequena caixa-preta.
E talvez essa seja a grande lição deixada pela primeira parada do ônibus de Dewdney.
Não precisamos começar abrindo a máquina.
Primeiro podemos observar.
Experimentar.
Modelar.
Formular hipóteses.
Descobrir estados.
Mapear transições.
Procurar ciclos.
Encontrar exceções.
E somente depois descer às entranhas da implementação.
Alpha observa o diagrama.
Beta termina o volume 37 de As Crônicas Secretas da Máquina de Estados de Shadow-sama.
Delta continua indignada porque roubaram seu nome para uma função matemática.
Cid olha para a caixa-preta.
A lâmpada acende.
0100100101
Ele sorri.
— Exatamente como eu havia previsto.
Não havia previsto coisa nenhuma.
Mas desta vez estava correto.
☕ Um Café no Bellacosa Mainframe
Porque algumas vezes compreender 15.000 linhas de COBOL começa desenhando seis círculos e algumas flechas em um pedaço de papel.
