Rumo a um software compreensível

• Programar é difícil de ler, testar e manter, e a compreensão de projetos fica concentrada em poucas pessoas; portanto, em vez de automatizar a escrita de código com LLMs, é preciso criar abstrações que reduzam o próprio escopo em que código é necessário
• LLMs se disseminaram entre desenvolvedores e não desenvolvedores, mas problemas como impacto ambiental destrutivo, base em código roubado, resultados inconsistentes e geração de dependência ainda são grandes
• O ponto de partida é inverter a prática de escrever primeiro o código e depois acrescentar documentação, migrando para a programação literária, em que se escreve a documentação primeiro e o código vem depois
• Programação visual baseada em GUI e programação determinística em linguagem natural podem fazer do código apenas uma entre várias representações, mas ambientes visuais precisam obrigatoriamente de design de acessibilidade, como integração com leitores de tela
• Tentativas anteriores como Eve e Inform, e ferramentas como Entangled e ReTangled, mostram a possibilidade de criar software de um modo compreensível tanto para iniciantes quanto para especialistas

---

LLMs não são o modelo-alvo

• LLMs se tornaram ferramentas importantes no desenvolvimento de software industrial, e até especialistas experientes usam agentes de LLM para testes, depuração e escrita de código
• Não desenvolvedores também estão usando LLMs para criar desde scripts pessoais até ferramentas de processamento de dados científicos
  • Programar tem um ponto de partida pouco claro e baixa acessibilidade para quem não quer aprender a sintaxe de uma linguagem específica nem detalhes de bibliotecas
• A disseminação dos LLMs é menos um sinal de que eles programam muito bem e mais um sinal de que programar em si é uma tarefa complexa e desagradável
  • Há stacks de software conflitantes, boilerplate sem fim e muitas bibliotecas difíceis
  • O trabalho do desenvolvedor de software médio se reduziu mais a juntar bibliotecas do que a desenvolver código interessante
• LLMs ainda têm grandes problemas
  • São ambientalmente destrutivos
  • Baseiam-se fundamentalmente em código roubado
  • Geram código inconsistente
  • Criam dependência
• O paradigma atual de programação também é insuficiente, mas os LLMs igualmente precisam de uma alternativa melhor

Abstrair em vez de automatizar

• Abrir mão de LLMs não significa abrir mão de automação, abstrações de alto nível ou interfaces amigáveis para humanos
• O objetivo não deve parar em tornar a escrita de código mais fácil, mas lidar com o stack de software abaixo do código e reduzir a própria necessidade de escrever código
• Se você sente repetidamente vontade de automatizar uma certa camada de abstração, é mais adequado abstrair essa camada para eliminá-la do que automatizá-la
• O uso amplo de LLMs em programação mostra o desejo de automatizar o processo de escrita de código, e isso é um sinal de que devemos abstrair a própria necessidade de escrever código
• Em vez de fazer humanos pensarem como computadores, precisamos de novas camadas de abstração mais próximas da forma como humanos pensam naturalmente

Programação em que a documentação vem primeiro

• O primeiro passo para um software compreensível é a documentação
  • Se você quer que outras pessoas entendam um software, precisa explicá-lo
• A abordagem comum é escrever o código primeiro e depois acrescentar doc-comments ou exemplos de uso
• A abordagem proposta inverte a ordem: escrever a documentação primeiro e anexar o código depois
  • Primeiro se explica a uma pessoa o que o programa faz; depois se diz ao computador o que ele deve fazer
  • Esse conceito é conhecido como programação literária
• Nessa abordagem, em vez de ler diretamente o código de outra pessoa e inferir a intenção, primeiro se lê a documentação para entender a intenção e depois se verifica o código
• Entangled é uma boa implementação dessa abordagem
  • É um tangler bidirecional que extrai código da documentação e o coloca nos arquivos de código-fonte apropriados
  • É possível editar blocos de código dentro da documentação, e alterações feitas em arquivos de código comuns também são propagadas de volta para os blocos de código da documentação
  • Ferramentas existentes, como testes, refatoração e formatação de código, podem continuar sendo usadas sem suporte especial a programação literária
  • O tangler acrescenta pouco overhead ao sistema de build, especialmente em comparação com o compilador
• Essa abordagem não elimina a complexidade do código em si, mas pode substituir LLMs no domínio de entender o código de outras pessoas

Eliminando código: GUI e múltiplas representações

• Código é um conceito de uma era antiga, uma forma que usamos porque precisávamos interagir com computadores por meio de terminais
• Mesmo que a computação tenha mudado nos últimos 40 anos, não há motivo para insistir que só podemos nos comunicar com computadores por meio de strings unidimensionais de símbolos e palavras-chave obscuros
• GUIs tornam conceitos complexos mais fáceis de lidar do que interfaces baseadas em texto e muitas vezes são mais acessíveis para novos usuários
• Um IDE pode ser mais do que um lugar conveniente para editar código: pode se tornar uma nova forma de interagir com o desenvolvimento de software
  • Alguns IDEs já oferecem recursos assim
  • Indo além, a programação visual pode se tornar universal e simples o bastante para que qualquer pessoa crie o que deseja sem aprender código
• Não é preciso abandonar completamente o código em si
  • Representações em GUI podem ser apenas uma entre várias representações editáveis por humanos
  • Assim como há pessoas que preferem interfaces de sistema operacional baseadas em texto, também pode continuar havendo pessoas que preferem editar software por código
  • Ainda assim, o código não precisa ser o padrão nem a única opção
• A programação visual pode ser projetada para ser mais acessível, mas ambientes centrados no visual podem levar à exclusão de pessoas cegas ou com deficiência visual
  • É necessária uma forte integração com leitores de tela
  • Também são necessárias representações alternativas que possam ser compreendidas de forma rica por meios auditivos ou táteis

Tornando a linguagem natural uma abstração determinística

• Ao contrário da afirmação de que LLMs elevam uma camada de abstração, eles se parecem mais com uma camada de automação do que com uma abstração
• Uma camada de abstração deve ser previsível e confiável, e intenções de alto nível devem ser expressas de forma precisa e consistente em um nível mais baixo
• LLMs interpretam prompts de modo probabilístico e preveem intenções, por isso se comportam de forma imprevisível
  • Automatizam o processo de aproximar aleatoriamente o resultado de uma tarefa
  • Se fossem uma abstração, seriam uma abstração com muita perda
• Avanços em processamento de linguagem natural (NLP) oferecem a possibilidade de criar um pipeline previsível de linguagem natural para linguagem de máquina
• O objetivo é criar programas previsíveis e robustos sempre, mesmo com entradas semelhantes a prompts de LLM
  • Sem destilar o trabalho de outras pessoas como uma média de código roubado, mas construindo diretamente por meio de definições
• Essa abordagem pode acoplar documentação e código de forma mais forte
  • Se a parte de código da programação literária for substituída por linguagem natural, pode sobrar apenas a documentação
  • O texto que explica a uma pessoa como o programa funciona pode ser, ao mesmo tempo, o texto que se comunica com a máquina
• Essa programação em linguagem natural precisa ser determinística
  • NLP pode ser usado para analisar gramática em significado sem a capacidade generativa de modelos transformer
  • A gramática analisada pode ser transformada diretamente em uma representação intermediária que é compilada conforme os requisitos da plataforma, como em outras linguagens de programação
• A ideia é semelhante ao Inform, mas com maior reconhecimento sintático e conectada a uma rede mais ampla de definições
• Graças à qualidade determinística, prompts se tornam código de forma confiável e consistente, o que é uma verdadeira camada de abstração fundamentalmente diferente dos LLMs

Tentativas anteriores: Eve e Inform

• Essas ideias não são novas; já houve tentativas de implementá-las antes
• Eve é uma linguagem de programação e IDE que tentou tornar a programação mais acessível para humanos
  • Usa uma abordagem de programação literária
  • Insere uma linguagem de programação orientada a dados e específica de domínio dentro de documentos que descrevem o comportamento do software
  • O código fica subordinado à documentação, e todo o ambiente de programação reflete isso
• Eve também tentou expandir essa ideia substituindo sua própria linguagem por consultas em NLP
  • Não estava preparada para lidar com a complexidade do processamento de linguagem natural
  • Em 2016, NLP mais avançado não era facilmente acessível para uma empresa que não fosse centrada em machine learning
  • Também experimentou uma abordagem orientada a GUI
• Um ex-colaborador do Eve também aborda preocupações semelhantes sobre a complexidade do projeto e as limitações dos LLMs
• Eve terminou porque era um projeto ambicioso financiado por VC que não conseguiu monetizar, e não houve oportunidade de ver essas ideias darem frutos
• Inform é uma linguagem declarativa para criar ficção interativa e mostra que esse conceito pode ser aplicado de forma mais ampla
• Embora exista a possibilidade de a linguagem natural ser uma abstração inerentemente vazada, seu potencial de permitir que uma pessoa comum controle diretamente seu computador merece mais atenção

Próximos passos e trabalhos propostos

• ReTangled está sendo desenvolvido como um projeto para criar software compreensível
  • É um tangler bidirecional compatível com Entangled, escrito em Rust
  • O objetivo é expandir a programação literária tanto quanto possível e integrá-la estreitamente, em um nível razoável, com toolchains existentes
  • Atualmente está em estágio inicial de desenvolvimento e contribuições são bem-vindas
• Há planos de escrever textos mais completos sobre programação visual, programação literária e programação em linguagem natural, respectivamente
• No nível da comunidade, propõe-se seguir os passos do Eve, mas adotando uma abordagem um pouco diferente
• O objetivo é criar um ambiente de programação visual ou em linguagem natural bem documentado e acessível, útil desde iniciantes até especialistas
• O ponto de partida é documentar melhor o software, e o objetivo final é inverter o próprio conceito de programação

[GN⁺]

Comentários no Lobste.rs

• Não tenho certeza de que jogar fora o código ou subordiná-lo à prosa em linguagem natural seja uma solução eficaz para o problema de acessibilidade da programação.
  Linguagens de programação são uma interface de usuário que equilibra as exigências do computador e das pessoas. Uma notação formal clara e bem-feita pode se tornar uma ferramenta de pensamento que ajuda tanto a compreensão individual quanto a transmissão de ideias entre pessoas e máquinas.
  Aprender linguagens da família APL me influenciou muito; levou tempo para pegar, mas, depois que aprendi, passei a conseguir manter problemas maiores na cabeça e pensar com mais precisão. K permite resolver problemas só com a cabeça, papel e um REPL simples, sem uma IDE complexa.
  Projetos bem documentados e programação literária têm valor, mas documentação também consome tempo para ler, escrever e corrigir. Assim como testes, mais documentação não é automaticamente melhor; prefiro explicações concisas e estruturadas, e programas concisos que sejam fáceis de explicar. Código pode ser poesia, mas a maior parte da poesia não é programa.

  • Gosto de programação formal, mas não acredito que o usuário médio deva precisar virar programador para usar o poder dos computadores.
    A maioria das pessoas não vai aprender esse funcionamento interno, então quero reduzir a barreira de entrada para que mais gente possa participar.
    É por isso que acho que LLMs são populares. Vejo com frequência não programadores usando LLMs para escrever código a fim de realizar tarefas, mas, como o texto diz, LLMs têm grandes falhas que eu gostaria de evitar. As pessoas deveriam poder modificar jogos, criar scripts e estender programas usando linguagem natural ou uma interface de usuário confortável.
    A expressão “vamos abolir o código” pode ter sido um pouco exagerada, mas muita gente não quer pensar em código, e nem deveria precisar.

• Programadores, de certa forma, abandonaram os não programadores.
  Visual Basic morreu, PHP sem framework também não parece muito ativo, e Access está praticamente morto. Restaram ferramentas parecidas com bancos de dados, como Notion ou Airtable.
  Programadores amam tanto escrever código que muitos se afastaram de soluções simples para problemas simples.
  Python em certo momento varreu o mundo dos não programadores porque parecia simples, e ferramentas como Pandas também pareciam fáceis de usar. Curiosamente, muitos programadores acham Python ou Pandas ruins. Por exemplo, é bem desanimador ver código que usa Pandas para fazer coisas que seriam fáceis com a biblioteca padrão.
  Antigamente, não programadores também criavam páginas HTML e colocavam cores e imagens nelas. Hoje, se você pedir a um programador para criar um site estático, vem junto uma complexidade absurda. Parte dela é necessária, mas a maior parte não é nem um pouco. Se você entregasse a não programadores o processo que programadores usam para criar um site simples, até as pessoas que há 20 anos teriam se divertido editando HTML sairiam correndo aos gritos.
  É profundamente irônico e inquietante que algumas coisas tenham ficado, na verdade, muito mais difíceis hoje.

  • Isso não faz sentido nenhum. Hoje qualquer pessoa ainda pode escrever HTML e, na verdade, está mais fácil do que antes.
    CSS ficou mais poderoso, os navegadores estão menos quebrados, e há assistentes pessoais de programação para ajudar em tudo. Com Python puro é a mesma coisa: é só usar. Programar está mais fácil do que nunca.
    A complexidade das stacks modernas geralmente tem motivo, mas deve ser usada depois que esse motivo aparece; iniciantes não precisam usá-la de jeito nenhum.
    Se as pessoas não criam sites em HTML ou programas básicos, é porque não querem. Achávamos que, no futuro, todo mundo saberia programação básica, mas o que se revelou é que as pessoas simplesmente não querem fazer isso. Também dá para argumentar que todos deveriam saber fazer manutenção básica em carros ou bicicletas, mas as pessoas recusam. Isso não quer dizer que a tarefa seja difícil ou impossível; quer dizer, mais provavelmente, que falta vontade de fazê-la.
    Acho que a alfabetização digital do público em geral quase não avançou, e isso não tem relação com a complexidade da programação. Há até quem diga, no meio educacional, que a alfabetização digital parece estar regredindo, mas é difícil atribuir isso a frameworks complexos de front-end.

• Concordo com boa parte do texto. Por exemplo, gosto de programação literária, mas não acho que programação em si seja ruim.
  Algumas formas de programação são ruins, e a programação feita em empresas de Big Tech muitas vezes tende a ser ruim. Mas ainda é prazeroso escrever programas para mim ou para pessoas de quem gosto.
  Eu não conhecia o Entangled, mas parece uma boa ideia, e aborda o maior sofrimento da programação literária: o problema de LSP e ferramentas existentes não reconhecerem o código. Por isso, até agora usei programação literária principalmente com linguagens declarativas, como configurações do NixOS.
  Se for programação literária bidirecional, talvez torne a vida mais fácil ao usar linguagens não declarativas. Pretendo experimentar o ReTangled.

  • Programação não é ruim. Concordei com o autor até essa frase, mas, quando apareceu “vamos aceitar a GUI”, perdi o interesse.
    GUIs parecem existir principalmente para fazer executivos e níveis acima acreditarem que os funcionários estão fazendo algo que eles entendem e conseguem fazer.
    Fiz uma aula sobre uma ferramenta visual de ETL com arrastar e soltar, e só fiquei com a impressão de que seria difícil recriar algo quase igual ao primeiro sistema e difícil versionar tudo. Em 2010, o sistema visual de arrastar e soltar que a empresa onde eu trabalhava usava como substituto do cron era parecido.
    Para executivos, arrastar e soltar é fácil; para quem executa o trabalho, fica mais difícil encontrar erros, manter versões e backups, e reutilizar coisas.
  • Se esse recurso é o objetivo principal, recomendo usar Entangled até que o stitching funcione no ReTangled.
  • Há um trecho realmente árduo no processo de transformar algo que é divertido de usar momento a momento em algo que o usuário provavelmente vai gostar.
    Para transformar um protótipo divertido em algo pronto para operação, entram muita coisa como tratamento de erros, serialização, desserialização e projeção de tipos. Uma das minhas regras é que uma ótima experiência de usuário quase sempre vem acompanhada de uma estrutura interna bagunçada.
    Pessoalmente, não gosto da maior parte disso, e no passado já peguei atalhos ou simplesmente deixei de fazer esse trabalho.

• Concordo com bastante força. Olhando para editores WYSIWYG, eles não substituíram completamente o desenvolvimento web, mas reduziram um nicho considerável de pessoas que só querem um site básico ou vender produtos simples.
  Ainda há uma grande área de software que poderia ser simplificada com boas interfaces GUI.
  Se hoje você está só juntando código ou acionando LLMs de qualquer jeito, talvez programação com GUI fosse, na prática, melhor. Muito do código que uso com frequência também é um servidor REST, e não há motivo para não criarmos algo para esse tipo de coisa.

• Compartilho o mesmo objetivo e venho pensando há anos em uma stack tecnológica que ofereça exatamente a solução que eu gostaria de usar.
  Cheguei a publicar um projeto chamado Curv, mas ele é só uma pequena parte de um sistema muito mais bonito que existe apenas na minha cabeça.
  Milhares de outras pessoas também vêm se dedicando a esse problema. Pelo tamanho do problema, parece exigir trabalho em equipe, mas, na prática, a maioria são pequenos projetos de uma pessoa só. Muitas vezes, quem tem a visão mais forte não quer comprometer sua própria visão em nome de metas de equipe. Não sei como resolver isso.
  Entre os projetos inspiradores estão a visão do Dynabook de Alan Kay, o Smalltalk que veio na sequência, o projeto posterior de Alan Kay, STEPS Toward the Reinvention of Programming, o trabalho de Bret Victor e, em especial, sua realização impressionante, o Dynamicland.
  Uma comunidade interessada nesse tema é a Feeling of Computing, antes chamada Future of Coding. Se houver mais algo a acrescentar, seria bom saber.

• A ideia de “criar um programa completo digitando instruções como se fossem prompts para uma LLM, mas fazendo com que ele funcione de forma previsível e robusta todas as vezes” parte da enorme suposição de que é possível analisar, a partir da linguagem natural, uma semântica determinística e consistente.
  Mas, para começo de conversa, não acho que isso seja verdade. Mesmo deixando de lado o fato de que ainda ninguém fez isso funcionar direito, também duvido que seja possível.
  A linguagem tem contexto demais. Você pode dizer a mesma frase uma dúzia de vezes, e cada uma ganha um significado sutilmente diferente dependendo da entonação, do público, da localização física, do meio de enunciação e do horário. Técnicas tradicionais de processamento de linguagem natural fundamentalmente não conseguem lidar com essa flexibilidade.
  É justamente por isso que LLMs existem. Em vez de tentar definir regras rígidas de contexto que provavelmente nem existem, a abordagem é treinar um modelo capaz de codificar a detecção de contexto nos pesos. E isso se mostrou surpreendentemente eficaz.
  É também por isso que as pessoas usam LLMs. Porque elas conseguem levar o contexto em conta muito melhor do que qualquer interface de linguagem natural já criada até agora e produzir a resposta esperada. Desse ponto de vista, elas realmente funcionam. O processamento de linguagem natural fora das LLMs não demonstrou o mesmo nível de sucesso.

• Se você tem interesse em ambientes ricos de programação visual, o Glamorous Toolkit é um bom exemplo de uma direção possível: https://gtoolkit.com/
  Ainda não o vejo como uma forma finalizada, mas é uma ferramenta que leva mais adiante coisas que já foram construídas. Na era do código gerado por LLMs, também há espaço para falar de ambientes baseados em imagens.

  • Dei uma olhada no site do Glamorous Toolkit e não entendi nada do que é. Dá para resumir em algumas frases?

• O que falta são abstrações previsíveis que vão além dos elementos primitivos que programadores costumam usar hoje, ou seja, linhas de código organizadas em funções e módulos.
  Especialmente quando requisitos que modelam sistemas externos complexos, e não simples transformações de dados, são traduzidos apenas para esses elementos, o resultado vira uma bola de lama cada vez maior, mesmo quando feita por programadores humanos. As LLMs também estão imitando esse padrão.