Um Apelo por Software Enxuto (1995)

Artigo original ↗ Discussão no Hacker News ↗

Programadores revisitamm o “Plea for Lean Software” de Niklaus Wirth, de 1995, à luz dos apps atuais lentos e famintos por memória, argumentando que ferramentas e frameworks modernos muitas vezes desperdiçam enormes avanços de hardware em troca de conveniência marginal. Muitos culpam incentivos organizacionais que recompensam a entrega de recursos em vez do desempenho, a ascensão de stacks pesadas como Electron e a dependência de bibliotecas amplas e genéricas em vez de componentes focados e bem compreendidos. Outros contrapõem que funcionalidades mais ricas, Unicode, edição remota e infraestrutura complexa de sistema inevitavelmente aumentam o peso, e que, para muitos usuários e empresas, a troca continua aceitável enquanto a velocidade percebida for “boa o suficiente”.

SO, serviços em segundo plano e controle do usuário

  • Muitos reclamam de apps comerciais que iniciam automaticamente serviços em segundo plano (VPNs, Steam, apps de chat) em grande parte para atualizações/telemetria, e não para valor ao usuário.
  • O Windows é criticado por tornar esses serviços difíceis de desativar e por reverter configurações do usuário (por exemplo, políticas de AV), enquanto o macOS é visto como mais controlável pelo usuário.
  • Alguns sugerem serviços de atualização no nível do SO com os quais os apps possam se registrar, mas duvidam que os desenvolvedores os adotariam em vez de atualizadores personalizados.

Editores, recursos e bloat percebido

  • Editores mais antigos que usam poucos MB são reinterpretados como “enxutos” em comparação com ferramentas modernas como VS Code/JetBrains.
  • Um lado argumenta que recursos modernos (Unicode, emoji, desenvolvimento remoto rico, análise LSP, pré-visualizações) justificam inerentemente maior uso de recursos.
  • Outros contrapõem que esses recursos podem ser implementados com muito menos código; frameworks grandes e mecanismos de navegador são frequentemente escolhidos por padrão, não por necessidade.
  • Responsividade e latência de entrada são enfatizadas como mais importantes do que o uso bruto de RAM.

Dependências, bibliotecas e stacks Electron/web

  • Bibliotecas compartilhadas versus empacotamento é debatido: o DLL-hell e a dificuldade de distribuição levaram muitos a empacotar tudo em um grande pacote.
  • Alguns defendem bibliotecas minúsculas e específicas para cada finalidade; outros preferem bibliotecas mainstream (por exemplo, grandes renderizadores de fontes) por confiabilidade e manutenção compartilhada.
  • Electron é um alvo frequente: visto como facilitador de iteração rápida e desenvolvimento multiplataforma, mas também como emblemático de desperdício (vários navegadores embutidos, alto uso de RAM/CPU).
  • PWAs são sugeridos como um meio-termo, embora careçam de APIs nativas sem maquinaria extra.

Incentivos organizacionais e processo

  • Diz-se que grandes organizações recompensam recursos e otimismo, não desempenho; pequenas lentidões incrementais se acumulam até que os sistemas pareçam intoleráveis.
  • Processos ágeis/empresariais, CI/CD pesado e grandes equipes são criticados por inflar esforço e LOC com pouca produção real.
  • Desempenho como recurso central existe em nichos (trading, busca/anúncios) onde o tempo é diretamente monetizado; fora deles, muitas vezes é despriorizado.

Hardware, usuários e testes

  • Alguns argumentam “hardware é barato, tempo é caro”, justificando ferramentas mais pesadas.
  • Outros observam que muitos usuários têm máquinas modestas; executar vários apps pesados (Slack/Teams, IDEs, navegadores, ferramentas Electron) deixa os sistemas lentos.
  • Testar em hardware antigo ou de baixo desempenho é proposto como disciplina para manter o software enxuto.

Responsabilidade e ethos de software enxuto

  • Vários insistem que os desenvolvedores devem assumir a performance, escolher arquiteturas rápidas por design e evitar abstração gratuita e frameworks genéricos.
  • Outros destacam forças do ecossistema e econômicas (dependências compartilhadas, incentivos de carreira, cultura de gestão) que estruturalmente favorecem o bloat.
  • Há um otimismo cauteloso em torno de um contramovimento de ferramentas focadas em desempenho, mas ceticismo de que isso reverta amplamente as tendências de bloat.