O que um programador DOS sabia e vale para a Web

TL;DR

Eu programei em Clipper sobre DOS nos anos 90, quando 4 MB de RAM eram luxo e cada byte contava. Trinta anos e vários frameworks depois, os mesmos princípios ainda separam software sólido de software descartável.

• Escassez: sem RAM sobrando, cada recurso era decisão consciente.
• Domínio do problema: código ruim aparecia no mesmo dia, no telhado do cliente.
• Simplicidade como decisão: feature a mais era byte a menos no disquete.
• Tratamento honesto de erros: exception ignorada = tela travada na cara do operador.
• Performance percebida: usuário notava cada segundo de espera.
• Código legível: você voltava 6 meses depois e tinha que se virar sozinho.

Quem aprendeu a programar com pouco aplica essa disciplina em qualquer stack: .NET, Angular, SQL Server, Postgres, microsserviço ou monólito. A tecnologia nova só expõe quem nunca aprendeu os fundamentos.

A escassez que ensinava disciplina

Em 1996, quando eu comecei a programar profissionalmente em Clipper, o luxo era um 386 com 4 MB de RAM. Tela monocromática. Disco rígido de 40 MB. Cada `.EXE` precisava caber no disquete de 360 KB do cliente. Não tinha como disfarçar código ruim — o sistema ou rodava, ou não rodava. Se vazava memória, o cliente ligava no dia seguinte. Se a query era lenta, a tela travava e o operador ia te esperar na porta.

Foi isso que ensinou disciplina. Não a teoria, não o curso, não o livro. Foi a consequência direta, visível no mesmo dia, da decisão ruim. O programador DOS não tinha o luxo de esperar o framework abstrair o problema. Ele era o framework.

Hoje a abundância esconde essa consequência. Você tem 32 GB de RAM, SSDs de terabyte, container orquestrado, observabilidade de ponta. O código ruim não trava na mesma hora. Ele escala feio durante meses, vira incidente em produção, custa janela de manutenção e — pior — acostuma o time a viver apagando incêndio em vez de preveni-la.

Disciplina de escassez significava pensar antes de escrever. Pensar significa: qual é o caso que estou tratando, qual é o pior caminho de execução, o que acontece se essa rotina for chamada mil vezes por segundo, o que o usuário vê se o disco demora três segundos. Em 1996, essas perguntas eram obrigatórias. Em 2026, são opcionais — até o dia em que deixam de ser.

Compreender dados antes de criar tela

No Clipper, eu não começava um sistema pela tela. Começava pelo arquivo `.DBF`, pelos índices `CDX`, pelas relações entre as tabelas. A regra de negócio morava ali. Se eu entendesse a estrutura dos dados e o ciclo de vida de cada registro, a tela era consequência. Se eu começasse pela tela, estaria decorando sintaxe em cima de regra mal compreendida — e mais cedo ou mais tarde alguém me ligava perguntando por que o saldo do estoque estava negativo.

Em 2026, com SQL Server, Entity Framework Core e Angular, eu mantenho exatamente essa regra: modelo de dados primeiro, depois endpoint, depois componente. Já vi projeto começar pelo componente Angular com `Reactive Forms` bem desenhado, `RxJS` operators elegantes, CSS caprichado — e no fim o `SELECT` trazia 1,2 milhão de linhas porque ninguém modelou a query. Tela bonita, banco em chamas.

O programador DOS sabia disso porque o custo de errar era imediato. A diferença hoje é que o custo continua existindo — só aparece meses depois, em janela de produção, quando ninguém lembra qual decisão ruim plantou aquela bomba.

Simplicidade, erros honestos, sistemas previsíveis

Simplicidade no DOS não era estética. Era sobrevivência. Cada linha a mais era byte a mais, ciclo a mais, manutenção a mais. Não dava para ser “verbose”. O código tinha que dizer o que fazia, em poucas linhas, sem rodeio. Aquela pressão formou um hábito que eu carrego até hoje: se eu consigo resolver com dez linhas, dez linhas é o que fica.

Frameworks modernos oferecem tanta abstração que é fácil cair na armadilha oposta: resolver com cem linhas o que era dez. Camadas de indireção, decorators, factories, providers, injeção de dependência, configuradores de configurador. Às vezes é necessário. Frequentemente é fuga da decisão direta. O programador DOS não tinha essa fuga — então ele pensava antes de adicionar a camada. Em .NET eu uso essa disciplina todo dia: antes de adicionar uma abstração, eu me pergunto se ela resolve um problema real ou está só disfarçando a complexidade. Framework moderno não é desculpa para software complicado.

E o tratamento de erros? No Clipper, todo erro aparecia para o usuário como uma tela amarela com a mensagem em português claro: `Arquivo não encontrado`, `Registro bloqueado por outro usuário`, `Disco cheio`. Sem stack trace inglês, sem log escondido. O usuário sabia o que aconteceu. O programador também. Era um sistema previsível.

Hoje eu vejo sistema retornando `HTTP 500` com JSON genérico para o usuário final, log de stack trace enterrado em ferramenta que ninguém monitora, e o time descobrindo o problema quando o cliente reclama. A regra que eu aplico até hoje: erro tem que ser explícito, localizado e visível para quem opera o sistema. Stack trace em inglês no log do servidor, sim — mas a mensagem que o usuário vê tem que dizer o que aconteceu em linguagem de negócio. “Não foi possível salvar o pedido porque o cliente está inativo desde 2024” é melhor que “Error: FK violation in customer.status”.

Performance percebida, código legível, manutenção por outras pessoas

No DOS, performance era medida em segundos. Se o `BROWSE()` demorava três segundos para listar mil registros, o operador reclamava no mesmo turno. A correção era imediata: índice novo, query reescrita, estrutura de dados repensada. Não tinha cache distribuído para esconder o problema.

Hoje a métrica equivalente é perceived performance: o que o usuário sente enquanto interage. Não é só tempo de resposta do servidor — é feedback visual, é spinner bem posicionado, é resposta em 100 ms na interação local mesmo quando o servidor demora. Em Angular, eu aplico isso com `OnPush`, lazy loading, skeleton screens, otimistic updates. Mas o princípio é o mesmo do DOS: o usuário está esperando, e ele nota cada segundo.

E o código legível? No Clipper, a manutenibilidade era questão de sobrevivência porque o mesmo código era mantido durante anos, pelo mesmo programador ou pelo próximo da fila. Variáveis tinham nomes completos em português. Funções tinham `PROCEDURE` com cabeçalho documentando o que faziam. Comentário não era luxo — era herança para o próximo.

Hoje, com Git, code review e Copilot, parece que comentário ficou opcional. Não ficou. Código em Angular que mistura template, lógica e estilo em um único `.ts` com nomes de variável de uma letra é tão ilegível quanto Clipper mal escrito — só que tem IDE que esconde isso com autocomplete. O próximo dev que abre o arquivo vai sofrer da mesma forma que sofria em 1996. A pergunta que vale fazer antes de mandar commit não é “o código funciona?” — é “o próximo dev entende isso em cinco minutos?”

O perigo de acreditar que framework compensa decisão ruim

Esta é a maior armadilha do desenvolvedor web atual: acreditar que o framework compensa decisões ruins. Spring Boot resolve problema de arquitetura? Não, ele esconde. React resolve problema de UX? Não, ele esconde. Entity Framework resolve problema de modelagem? Não, ele esconde. Cada framework é uma ferramenta — e ferramenta mal usada produz software mal feito em escala maior.

Eu vejo projeto em .NET com 47 camadas de abstração porque “a arquitetura exige”, e o `SELECT` continua trazendo o banco inteiro. Vejo SPA em Angular que faz 200 requests porque o time não sabia qual dado precisava em qual tela. Vejo microsserviço com 12 serviços para resolver um problema que cabia em um monólito bem escrito. Tudo isso é a mesma doença: decisão ruim escondida por framework sofisticado.

O programador DOS não tinha essa fuga. Ele decidia, ele codava, ele sofria a consequência. Hoje o sofrimento é distribuído — e por isso é mais fácil de ignorar.

O que eu carrego do DOS para qualquer stack

Algumas coisas eu trouxe do DOS e aplico em 2026:

• Modelo de dados antes de tela. Sempre. Sem exceção.
• Mensagens de erro claras para o usuário. Sem stack trace em inglês.
• Variáveis com nome completo. Sem `x`, `tmp`, `data2`.
• Funções pequenas que fazem uma coisa só. O DOS ensinou isso por limitação física.
• Pensar no pior caminho antes de escrever o caminho feliz.

E algumas coisas eu trouxe e abandonei — porque eram limitação, não princípio:

• Otimização prematura de bytes (não faz sentido com SSD e 32 GB).
• Medo de abstração (abstrações certas continuam certas).
• Programação defensiva a ponto de esconder bug (validação tem limite).

O programador DOS dos anos 90 não era melhor que o dev web de hoje — era diferente. Tinha pressões diferentes e desenvolveu reflexos diferentes. Os reflexos que vieram da escassez continuam valendo. Os que vieram da limitação tecnológica, não.

Frameworks mudam. Software ruim não

A pergunta que vale fazer é direta: a abundância de recursos tornou alguns desenvolvedores menos cuidadosos? A resposta é sim — mas não por culpa da abundância. A abundância permite coisas que o programador DOS jamais sonhou: observabilidade em tempo real, deploy sem janela de manutenção, IA que escreve o boilerplate. O problema nunca foi o recurso. Foi abundância sem disciplina.

Se você começou a programar ontem e nunca passou por restrição real, vale exercitar a escassez de propósito: escreva a query que traz só o que precisa. Trate o erro com mensagem de negócio. Meça o tempo de resposta antes de otimizar. Pense no pior caso antes de empolgar com o caso feliz. Essas decisões não exigem 4 MB de RAM — exigem atenção.

Frameworks mudam. Clipper virou .NET. O prompt de comando virou terminal PowerShell. O `BROWSE()` virou Angular Material. Mas software ruim continua nascendo das mesmas decisões ruins: dados mal modelados, erros escondidos, complexidade por preguiça, performance ignorada até alguém reclamar. E software bom continua nascendo do mesmo lugar: gente que aprendeu a pensar antes de escrever, em qualquer stack, em qualquer década, com 4 MB ou com 128 GB de RAM.

Leitura relacionada

• Programar ficou mais fácil ou apenas trocamos dificuldades? — o argumento oposto pelo mesmo prisma de carreira atravessando décadas.
• DOS, Windows e Web: três maneiras diferentes de pensar uma tela — a transição dos três paradigmas pelo lado da interface, que este post complementa pelo lado dos princípios.
• Do DOS à Web: mudou tudo, menos o problema que o software precisa resolver — onde argumento que regra de negócio atravessa tecnologia; aqui eu mostro que disciplina também atravessa.