O nascimento da Kaa — quando uma ideia vira linguagem
Quem estuda ciência da computação, num passado infantil, provavelmente já sonhou em construir máquinas incríveis com recursos limitados — igual ao Batman ou ao Homem de Ferro, escapando de enrascadas pela força do engenho.
No meu caso, foi exatamente assim. Sempre busquei domar a natureza com ciência. Um exemplo que carrego com orgulho: no ensino fundamental, criei uma pequena linha de produção semiautomática de trabalhos escolares — e com a renda gerada, contribuía com as despesas de casa. Era um sistema simples, mas funcional.
Essa memória voltou com força quando fui aprovado na UFMS para o Bacharelado em Inteligência Artificial. Eu já cursava Sistemas de Informação no IFMA, mas decidi mudar de rota — e de estado. Fiz o Enem com esse objetivo.
Ao receber a aprovação, veio a lembrança da infância: minha avó dizia que tudo o que eu fazia desde os 5 anos era "robô". Ela não estava errada. O que muda hoje é que os robôs ficaram maiores — e mais interessantes.
A base computacional como projeto pessoal
Com essa transição de vida, decidi que era hora de construir minha própria base computacional. Vivemos num tempo em que o paradigma homem-máquina permite que, por meio da simbiose com IA, possamos construir coisas muito mais sofisticadas do que antes. Por que não usar isso a favor de um projeto ambicioso?
O primeiro passo foi mergulhar em Crafting Interpreters, de Robert Nystrom — uma obra completa sobre como construir uma linguagem de programação do zero, desde o lexer até uma máquina virtual. É um daqueles livros raros que não te ensina só o como, te ensina o porquê. Cada capítulo me fazia parar para ir codar.
Em seguida, fui explorar o que a comunidade de entusiastas já havia produzido: linguagens experimentais, DSLs, projetos acadêmicos. E um detalhe curioso me marcou: muitos conceitos usados hoje em linguagens de programação têm raízes na própria IA. Isso mudou minha forma de enxergar o problema.
Foi nessa pesquisa que a ideia ganhou forma. Decidi criar a Kaa.
O que é a Kaa?
A ideia central é simples: ser uma linguagem para o meu uso cotidiano. Mas como desde criança eu projetava máquinas de estado — sistemas onde cada estado define um comportamento e transições determinam o que acontece a seguir —, quis que a Kaa refletisse esse modo de pensar.
A linguagem não tem sistema de classes. Ela opera com funções e um sistema de compartilhá-las por closures como sistemas vivos separados que trabalham em conjunto. A orientação a objetos da Kaa gira em torno do conceito de S-bots: agentes autônomos que podem ser compostos e encadeados. Cada script pode ser alocado dentro de outro, formando uma árvore de execução.
Daí o nome: Kaa significa "mata, floresta, bosque" em Nheengatu, língua indígena brasileira — e uma floresta é, afinal, uma estrutura de árvores interligadas.
Nome
Kaa
Origem do nome
Nheengatu (floresta)
Paradigma
Funcional + S-bots
Estrutura
Árvore de scripts
Extensão
.kaa
Base
Python
Kaa v2.0 — sistema de tipos leve
A versão 2.0 representou o primeiro salto importante. A Kaa evoluiu de uma linguagem puramente dinâmica para um modelo com tipagem leve e validação em tempo de execução.
Declaração de variáveis com tipo:
-i inteiro
-f float
-s string
-T true
-F false
-obj objeto
var -i x = 10;
var -f preco = 4.99;
var -s nome = "Saulo";
var -i idade;
input "Digite sua idade: " >> idade;
print "Nome: ", nome, " Idade: ", idade;
Um dos pontos mais interessantes: a linguagem tenta converter valores automaticamente, mas falha de forma explícita quando não é possível — segurança sem perder flexibilidade.
Coerção de tipos acontece em três momentos: declaração, atribuição e entrada via input.
Pipeline de execução
código .kaa → scanner → tokens → parser
→ AST → interpretador
Os S-bots na prática — OOP sem classes
A inspiração veio diretamente daqueles micro-bots do ensino fundamental. A grande dificuldade sempre foi a interconexão entre eles. Com a Kaa, isso virou um sistema formal: dois arquivos .kaa separados conversam por meio do comando add e da diretiva expor.
// Arquivo inimigo.kaa — define o S-bot
fun inimigo(nome, vida, especie) {
var -obj self = {
"nome": nome,
"vida": vida,
"vivo": -T,
"especie": especie,
};
fun perde_vida(dano) {
self.vida = self.vida - dano;
}
fun morto(morto) {
if(morto == -F) {
print "O OGRO ", self.nome, " ESTA VIVO!!";
} else {
print "O OGRO ", self.nome, " MORREU!!";
}
}
self.perde_vida = perde_vida;
self.morto = morto;
return self;
}
expor all;
// Arquivo ogro.kaa — usa o S-bot importado
add "./inimigo.kaa" all;
var -T control;
var -obj ogro1 = inimigo("jose", 110, "ogro");
var -obj ogro2 = inimigo("joao", 100, "ogro");
while(control == -T) {
ogro1.perde_vida(10);
if(ogro1.vida == 0) {
ogro1.morto(-T);
destroy_arena(ogro1);
}
}
O padrão expor all / add "./arquivo.kaa" all é o equivalente a um import modular — mas pensado como sementes de uma floresta: cada S-bot é independente, mas pode crescer dentro de outro.
Trocando o interpretador — a decisão radical
Diagrama do motor JIT da Kaa
Arquitetura do motor JIT por Peephole Optimization
Depois de estruturar os S-bots como módulos vivos, o próximo passo foi uma decisão radical: jogar fora o interpretador de árvore (tree-walk).
A versão inicial funcionava como a maioria dos interpretadores didáticos: percorria diretamente a AST nó a nó a cada execução. É elegante de entender, mas tem um custo alto — cada operação redescobre o caminho. É como ler um livro inteiro para achar uma página toda vez que você precisa dela.
A solução foi construir uma Máquina Virtual de Bytecode própria. Em vez de caminhar pela árvore, o compilador interno da Kaa agora traduz o código-fonte em instruções simples e sequenciais — semelhante ao que a JVM faz com Java ou o CPython faz com .pyc. A VM lê essas instruções em linha reta, muito mais rápido.
O motor JIT — quando a Kaa parou de pedir licença
Toda linguagem interpretada carrega um peso original: ela precisa de um intermediário. A Kaa rodava sobre o Python, que já é ele mesmo interpretado. Era como contratar um tradutor que precisa de outro tradutor.
A resposta foi o JIT por Peephole Optimization. A ideia não é reescrever tudo em C — é mais cirúrgica do que isso. O otimizador observa o bytecode gerado e identifica padrões: sequências de instruções que aparecem repetidas dentro de laços, incrementos de contadores, comparações binárias previsíveis.
Quando reconhece um desses padrões, ele funde aquele bloco inteiro numa única superinstrução — uma operação atômica executada em nível mais baixo. É o conceito de Macro-Op Fusion, o mesmo princípio que processadores modernos usam internamente para fundir pares de instruções de assembly em pipeline. A Kaa trouxe isso para o nível da VM.
Conclusão — um sonho que compila
A Kaa não nasceu de uma necessidade de mercado. Não surgiu de uma demanda corporativa. Ela nasceu da mesma coisa que me fez montar aquela linha de produção de trabalhos escolares no ensino fundamental: a vontade irresistível de construir uma máquina que pensa do jeito que eu penso.
Toda linguagem de programação é, no fundo, uma filosofia materializada em código. O C acredita que o programador deve controlar tudo. O Python acredita que legibilidade é lei. O Rust acredita que segurança de memória não pode ser opcional. A Kaa acredita que um sistema deve funcionar como uma floresta: troncos rígidos, tipados, confiáveis — e galhos que se adaptam, se compõem, crescem e morrem sem derrubar a árvore inteira.
Esse projeto é uma mistura honesta de tudo que fui acumulando: a obsessão com tipagem que aprendi no C, a leveza de scripts que o Python me ensinou, a modularidade que o JavaScript me forçou a entender. E a filosofia de que um objeto não precisa de uma classe para ter identidade — que veio da minha própria cabeça, validada pelos S-bots que antes viviam em planilhas e arquivos .bat numa tarde de escola.
Ler o Crafting Interpreters foi como encontrar o manual técnico de uma máquina que eu já tinha construído no escuro. E agora, pela primeira vez, tenho o mapa formal de tudo isso.
A floresta ainda está crescendo.