Desencanto com o software
(tonsky.me)- O software moderno, em vez de retribuir os avanços do hardware com eficiência, simplicidade e acabamento, passou a normalizar a ineficiência apoiado na premissa de que “o computador é rápido o suficiente”
- Até tarefas básicas como rolagem na web, abrir um e-mail no Google Inbox em 13 segundos, uma atualização do Windows 10 de 30 minutos ou a latência de digitação em editores de texto parecem mais lentas do que deveriam
- Um sistema Android com 6 GB, o Windows 10 com 4 GB, o Google Keyboard com 150 MB e os casos de apps em Electron e do Slack mostram como o inchaço de apps e plataformas gera custos em desempenho, complexidade e confiabilidade
- Assim como atualizações de SO, apps e navegador, e o fim do suporte a apps de 32 bits no iOS 11, até softwares que antes funcionavam bem podem ficar lentos ou quebrar com o tempo
- Para fazer software melhor, engenheiros precisam entender o desempenho, a estrutura e os limites dos sistemas que constroem, entregando resultados rápidos e previsíveis com menos recursos
Software que desperdiça desempenho
- No software moderno, muitas vezes se aceita que algo rode usando apenas 1% ou 0,01% do desempenho possível
- Enquanto carros, edifícios e aviões se aproximam de limites físicos ou de formas otimizadas, o software justifica ineficiências com a frase “o computador é rápido o suficiente”
- O ditado “o tempo do programador é mais caro que o tempo do computador” pode esconder uma realidade em que o tempo de computador é desperdiçado em escala sem precedentes
- Um tuíte sobre reescrever em Rust um programa em Python usado diariamente, reduzindo o tempo de 1,5 s para 0,06 s, mas ainda assim levando mais de 41 anos para compensar 6 horas de trabalho, virou um caso representativo nas discussões sobre eficiência
Experiências básicas insuportavelmente lentas
- Computadores portáteis atuais são milhares de vezes mais poderosos que os da era do pouso na Lua, mas até num MacBook Pro recente é difícil rolar páginas da web com fluidez a 60fps
- O Inbox, feito pelo Google, levava 13 segundos para abrir um único e-mail no Google Chrome
- Animar uma caixa branca vazia em vez do conteúdo é quase um compromisso ditado pelos limites de desempenho que uma página web consegue entregar
- Mesmo numa época em que telas de 120 Hz viraram padrão, considera-se que nem 60 Hz está garantido para visualizar uma única resposta em uma comunidade na web
- Uma atualização do Windows 10 leva 30 minutos, e compara-se esse tempo com a possibilidade de formatar um SSD, baixar uma nova build e instalá-la várias vezes
- Editores de texto modernos têm mais latência de digitação do que o Emacs de 42 anos atrás
- Aponta-se que uma tarefa que só precisa atualizar uma pequena área retangular da tela a cada tecla nem consegue ser concluída em 16ms
- Um jogo 3D, nos mesmos 16 ms, renderiza a tela inteira, processa entrada, calcula o mundo e gerencia recursos
- Hardware mais rápido acabou sendo usado menos para rodar software melhor e mais para rodar software que faz a mesma coisa de forma mais lenta
Apps e plataformas inchados
- Apps web podem ficar 10 vezes mais rápidos só de bloquear anúncios, e o AMP seria menos uma nova tecnologia e mais uma solução de bom senso para remover partes inchadas
- O sistema Android ocupa 6 GB mesmo sem apps, o Windows 95 tinha 30 MB e o Windows 10 tem 4 GB
- Considera-se que o Windows 10 é 133 vezes maior que o Windows 95 sem ter funções básicas tão diferentes assim
- O Android é 1,5 vez maior que o próprio Windows 10
- O Google Keyboard costuma ocupar 150 MB, o app do Google 350 MB e o Google Play Services 300 MB
- A crítica pergunta se o Google Keyboard, sendo um app que desenha umas trinta teclas na tela, é mesmo 5 vezes mais complexo que o Windows 95 inteiro
- O Google Play Services não pode ser removido mesmo sem uso
- A situação em que sobra só cerca de 1 GB para salvar fotos depois de instalar apps básicos é contrastada com a época em que SO, apps e dados cabiam todos em disquetes
- Um app de tarefas baseado em Electron pode incluir até driver de controle de Xbox 360, renderização gráfica 3D, reprodução de música e captura por webcam
- O Slack, apesar de ser próximo de um app de chat com editor de texto simples, é classificado como pesado por causa do tempo de carregamento e do uso de memória
- Quanto maiores os apps, maiores ficam a perda de controle, o custo da complexidade, a perda de desempenho e a dívida de confiabilidade, e apps excessivamente pesados não deveriam ser tratados como normais
Software que apodrece com o tempo
- Há 3 anos, um celular Android de 16 GB era suficiente, mas na era do Android 8.1 os apps passaram a dobrar de tamanho sem motivo especial, tornando o uso difícil
- O iPhone 4s foi lançado com o iOS 5, mas sofre para rodar o iOS 9, que também não seria fundamentalmente muito melhor
- O iOS 11 encerrou o suporte a apps de 32 bits, então apps sem desenvolvedor ativo ou sem atualização podem nunca mais ser vistos
- Cita-se um tuíte dizendo que programas DOS rodam sem modificação em vários computadores desde os anos 1980, enquanto um app em JavaScript pode quebrar na próxima atualização do Chrome
- Até uma página web que funciona hoje pode, em menos de 10 anos, deixar de rodar direito em qualquer navegador
- Compra-se um celular novo e um novo MacBook para fazer a mesma coisa, mas no fim os mesmos apps só passam a rodar mais devagar
Expectativas de qualidade rebaixadas
- Quando uma página web apresenta problema, ela pede para recarregar em vez de investigar a causa
- Apps web podem despejar erros “aleatórios” de JavaScript até em navegadores compatíveis
- Critica-se que páginas web e o projeto de bancos SQL parecem baseados na esperança de que os dados não mudem enquanto se olha para a página renderizada
- Recursos de colaboração muitas vezes ficam no nível de “melhor esforço”, incorporando cenários cotidianos em que dados podem ser perdidos
- Diálogos como “Qual versão devemos manter?” significam quase escolher qual trabalho será destruído
- O Linux é o sistema operacional mais popular em servidores mesmo tendo um projeto que mata processos arbitrariamente
- Os casos de monitores Dell, AirDrop e Bluetooth mostram que o software dentro dos dispositivos e especificações complexas criam experiências que dependem de reset periódico ou de sorte
- Para entregar algo que funcione de forma estável, é preciso entender por dentro e por fora aquilo que foi construído, mas isso fica difícil em sistemas excessivamente inflados
A confusão das ferramentas de programação e das práticas de desenvolvimento
- Mesmo em elementos básicos como gerenciamento de pacotes, sistemas de build, compiladores, design de linguagem e IDEs, é difícil ver acabamento rápido, eficiente e duradouro
- Sistemas de build, apesar de terem toda a informação sobre as mudanças, periodicamente exigem apagar tudo e refazer do zero
- Considera-se que não há motivo para isso não ser confiável, previsível e reproduzível
- O NPM é descrito como tendo passado anos num estado de “às vezes funciona”
- Cita-se um tuíte em que
rm -rf node_modulesparece inevitável no desenvolvimento com Node.js/JavaScript
- A aceitação de compiladores e etapas de pré e pós-processamento que levam minutos ou horas entra em choque com a ideia de que “o tempo do programador importa”
- Casos em que se escolhe Hadoop mesmo sendo mais lento do que rodar numa única máquina mostram que programadores nem sempre tomam decisões racionais
- Critica-se que machine learning e “inteligência artificial” levaram o software a uma era de palpites pouco confiáveis
- Cita-se um tuíte segundo o qual apps e serviços que usam “inteligência artificial” ou “machine learning” devem ser lidos como não confiáveis, imprevisíveis e difíceis de explicar nos resultados
- Rodar uma VM sobre Linux e colocar Docker dentro da VM é interpretado como sinal de que não se sabe limpar de forma organizada programas, linguagens e ambientes de execução
- O fato de um executável único em Go ser visto como grande vantagem revela uma situação em que basta não ser um caos para já ser considerado sucesso
- Dependências entram tentando resolver problemas simples com uma “solução completa de pacotes”, trazendo junto custo de adoção e mais dependências
- Aponta-se que é difícil usar um programa por anos sem reiniciar, e às vezes até por poucos dias
- Reiniciar processos, religar banco de dados, watchdogs que reiniciam o app a cada 20 minutos, inclusão de recursos duplicados e envio comprimido são formas de seguir em frente rápido em vez de corrigir
- Essas práticas não seriam engenharia, mas programação preguiçosa; engenharia é entender profundamente o desempenho, a estrutura e os limites do que foi construído
Complexidade acumulada e indiferença do mercado
- O software atual é descrito como uma pilha de código que mal funciona sobre mais código que mal funciona, crescendo continuamente em tamanho e complexidade e reduzindo as chances de mudança
- Um ecossistema saudável precisa às vezes recuar para depois avançar, mas aponta-se que não se vê um novo kernel de SO há 25 anos e que agora tudo ficou complexo demais para reescrever
- O mesmo vale para navegadores, cujos casos extremos e problemas históricos dificultam reescrever o motor de layout do zero
- O progresso atual parece jogar mais combustível no fogo: usa-se microsserviços para resolver problemas de monólitos, Docker para resolver problemas de microsserviços e Kubernetes para resolver problemas do Docker
- Cita-se um tuíte dizendo que saímos de configuração declarativa baseada em XML para configuração de microsserviços baseada em YAML, mas que pelo menos o XML tinha schema
- Usuários acabam obrigados a aceitar o que os engenheiros oferecem, com poucas alternativas diante de apps Android de 350 MB, rolagem travando e a lógica de “se não funcionar, reinicie”
- Se todos os concorrentes também são lentos, grandes e de baixa qualidade, fica difícil surgir pressão competitiva
- Às vezes aparecem produtos que criam tensão, como iPhone/iOS frente a outros smartphones ou Chrome frente a outros navegadores, mas isso não costuma durar
- A missão dos engenheiros deveria ser mostrar o que é possível, em desempenho, confiabilidade, qualidade e disponibilidade, com os computadores modernos
Ainda assim, há alternativas visíveis
- O LMAX Disruptor, o SBE e o Aeron, de Martin Thompson, são citados como exemplos impressionantes, simples e eficientes
- O Xi editor, de Raph Levien, é avaliado como algo construído com os princípios corretos em mente
- Jonathan Blow criou uma linguagem para seu próprio jogo e consegue recompilar do zero 500 mil linhas de código em 1 segundo no notebook dele
- Trata-se do resultado de uma compilação limpa completa, não de build incremental nem de cache intermediário
- Não é preciso ser gênio nem usar magia para escrever programas rápidos; basta não construir em cima de montanhas de lixo como as toolchains da moda
Exigências para um software melhor
- A engenharia de software precisa melhorar em vez de permanecer no estado atual, e não há necessidade de continuar fazendo a mesma coisa em formas mais lentas e maiores
- O desenvolvimento atual é descrito como algo que, mais do que progresso, mal consegue cumprir objetivos de negócio sobre ferramentas desgastadas
- Afirma-se que, por ficarmos presos a otimizações locais, nos acostumamos com um estado inchado e ineficiente
- Engenheiros podem — e devem — criar apps melhores com ferramentas melhores, usando várias vezes menos recursos, de forma rápida, previsível e confiável
- Para entregar produtos confiáveis, previsíveis e de alta qualidade, é preciso entender completamente o que se está fazendo e por quê; a desculpa de “é assim que veio” não é aceitável
2 comentários
Este texto já teve uma tradução para o coreano publicada antes, então basta consultar aquela.
https://tonsky.me/blog/disenchantment/ko/
Deixei até mesmo como um link direto para a tradução.
Opiniões no Hacker News
Código menor, mais limpo, com menos bugs, seguro, rápido e duradouro é obviamente possível. Se conseguimos fazer isso no início da era da informação, não há motivo para não conseguirmos agora, com décadas de experiência e ferramentas poderosas
O motivo de não fazermos isso é que não há dinheiro nisso; na verdade, é quase o contrário. Startups financiadas por VC precisam chegar primeiro ao mercado para sobreviver e, mesmo em organizações maduras, custo e inchaço não são problemas, mas funcionam como recursos que aumentam o prestígio dos gestores. No fim, o custo é repassado aos clientes
O motivo pelo qual os “princípios implacáveis do mercado” não corrigem esse desperdício parece ser que, embora uma base de código melhor possa um dia obter as chaves do reino, o ambiente competitivo real é vulnerável demais a patologias e modismos
Ainda assim, algo que é mais fácil fazer do que em empresas financiadas por VC é reservar tempo para refatoração e tratamento de dívida técnica. Na prática, agora estamos pisando forte no freio no desenvolvimento de novos recursos por 45 dias para lidar com problemas técnicos importantes. Se você espera ser adquirido no ano que vem, é difícil fazer esse tipo de investimento, e a dívida técnica vira problema de outra pessoa
Enquanto o produto continuar sendo desenvolvido, novos bugs e problemas continuarão surgindo. “Código perfeito” só é possível em um contexto fechado no qual novos recursos não são mais adicionados
Acho que o modelo de investimento de VC empurrou o setor para esse ponto. Startups recebem milhões de dólares e precisam ganhar dinheiro rápido o suficiente para devolver aos investidores, então precisam extrair dinheiro do app o mais rápido possível. Trabalhos aos quais não se pode associar uma métrica de ROI não recebem a atenção de ninguém
Basicamente havia acesso aberto por padrão, ausência de senhas ou senhas curtas, armazenamento inseguro de senhas, tudo em texto puro, desprezo pela sanitização de entradas, coisas como telnet
Há outro motivo para o software ter ficado mais inchado. Começamos a enxergar as interações e os riscos, e, depois que você vê, não dá para fingir que não viu. As condições de contorno que precisam ser tratadas não diminuem, só aumentam, e também há mais hardware a ser suportado
O processo de escrever código performático pode melhorar, mas, ao mesmo tempo, a linha de base está subindo mais rápido do que conseguimos alcançá-la. Também é interessante que agora estejamos caminhando aos poucos de volta para uma direção sem senhas
Alta cobertura de testes unitários que torna a refatoração dolorosa muitas vezes atrapalha o lançamento de funcionalidades, e acho que isso acontece com muito mais frequência do que os fanáticos por desenvolvimento orientado a testes querem admitir. Muitas “boas práticas” do setor estão mais para dogmas irreais criados por pessoas em empresas que já encontraram product-market fit e imprimem dinheiro sozinhas
Tenho um HP MS200 all-in-one que ainda dá para usar por pouco. Comprei barato em uma venda de garagem em 2017 e, instalando Linux nele, depois que o Chrome carregava, dava para fazer chamada de vídeo em tela cheia pelo Skype na web ou assistir ao YouTube em tela cheia
Recebi a máquina de volta recentemente e, antes de transformá-la em um computador para criança, instalei o FC38 e o Chrome mais recente; os vídeos do YouTube viraram uma apresentação de slides. Mexi em todas as configurações e nada resolveu, então aumentei a RAM de 2 GB para 3 GB, e ela voltou ao mesmo nível de reprodução em 720p em tela cheia de seis anos atrás
Ou seja, para fazer a mesma coisa, passou a precisar de 1,5 vez mais memória, 1 GB a mais. Sei que há quem diga que 16 GB é o mínimo, mas mesmo nessa máquina horrorosa, com o Chrome quase ocioso como navegador web, ele mostra uma pegada de memória de cerca de 30 GB. A maior parte deve ser arquivos mmapados, mas ainda assim são 30 GB
Por outro lado, na maioria dos dispositivos, maior duração de bateria, menor temperatura e menores requisitos de RAM e disco são melhorias claras. O YouTube poderia manter duplicadas no servidor as versões com codificação antiga, mas, numa situação em que a maioria dos usuários acessa a partir de dispositivos modernos, isso vira desperdício de espaço
A maior parte do aumento no uso de RAM do Chrome veio da evolução da arquitetura de sandbox. Memória compartilhada e espaço de processo podem ser usados em ataques para escapar do sandbox, então mais isolamento foi adicionado, e o fato de o Chrome iniciar um novo processo independente para cada aba e extensão também é uma grande causa
Hoje em dia, bloqueadores de anúncios também têm grande impacto. À medida que a web piorou, bloqueadores de anúncios eficazes ficaram mais difíceis de criar e passaram a exigir mais recursos. Software lento não ficou lento só para irritar as pessoas; muitas vezes é resultado de transformar hacks perigosos em boas implementações e de mudanças nos requisitos. FLV já não é suficiente, e h264 também parece ter dificuldade para resistir por mais cinco anos quando h265 e AV1 se espalharem
Toolchains modernas se concentram em “não reinventar a roda”, mas, se cada dependência escolheu uma versão diferente da roda, basta puxar algumas dependências para acabar trazendo seis implementações da mesma funcionalidade de baixo nível
O que estava instalado, porém, era Flatpak, e dava para sentir o inchaço. Felizmente, o Chrome ainda pode ser instalado diretamente de forma nativa como RPM e realmente usa as bibliotecas compartilhadas do OS
Este texto nem sequer toca na dor central: bugs. Quase todo software parece ser o mais cheio de bugs possível. Toda vez que preciso usar um software por um caminho incomum ou em um fluxo anormal, fico com medo — e quase sempre dá errado.
Um tempo atrás, quando vendi um carro para a Carvana, só consegui concluir alternando entre Chrome e Firefox. No Chrome, o assistente de upload de imagens gerava uma exceção de JS; essa parte, por milagre, só funcionou no Firefox, mas o restante do site tinha tantos problemas que era óbvio que não havia sido testado no Firefox.
O pior é que, quando usuários não técnicos encontram bugs, eles acham que fizeram algo errado. Mesmo que seja inchado e lento, hoje eu aceitaria de bom grado um software estável e sólido.
Por outro lado, continuo vendo como tudo é cheio de bugs, e não sei se de fato há mais bugs ou se, à medida que envelheço e passo a conhecer os bastidores, minha paciência com o desenvolvimento de software ao estilo das grandes empresas diminui. Fico irritado com o gerente de produto imaginário que diz “lancem o recurso X imediatamente”, mesmo quando bugs óbvios de UX seriam fáceis de detectar.
Entendo argumentos como custo, custo de oportunidade e pragmatismo, e concordo em parte, mas às vezes é difícil afastar a sensação de que simplesmente aceitamos viver em um mundo construído pela metade.
Ainda hoje não parece ter melhorado. Quando crianças pequenas pegam um celular ou laptop, só de apertar botões rápido demais ou em uma ordem inesperada elas conseguem travar, congelar e derrubar dispositivos modernos com bastante confiabilidade. Elas nem estão quebrando fisicamente nada, mas esse é o estado da tecnologia moderna.
Entendo por que isso não foi corrigido. As pessoas passaram a esperar que, de vez em quando, seja preciso reiniciar; nesses casos é fácil culpar a criança, e reiniciar resolve. Ainda assim, eu esperava que, a esta altura do ciclo de vida dos sistemas operacionais, as coisas estivessem melhores.
Não falei disso no texto sobre C, mas um dos grandes motivos pelos quais uso C é que é difícil tornar o software inchado. Dá para adicionar funcionalidades, mas nem é fácil fazer uma única funcionalidade acrescentar 100 KB ao executável.
Não estou empregado no momento, mas uso uma máquina potente para “trabalho”. Mesmo assim, uso Neovim e tmux em vez de uma IDE; em vez de uma distribuição Linux comum, uso um Gentoo bastante modificado; uso OpenRC em vez de systemd; e, em vez de um ambiente desktop completo, uso um gerenciador de janelas em mosaico chamado Qtile.
Mantenho a máquina sem inchaço a ponto de, logo após dar boot e fazer login, haver apenas 40 processos. Agora estou realmente fazendo engenharia de software. Tento mitigar de forma eficaz os problemas do C e, ao mesmo tempo, manter o software pequeno e rápido; espero um dia conseguir construir um negócio em cima disso.
Acho que vamos descobrir se ainda existe mercado para software enxuto e ágil.
https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
https://gavinhoward.com/2020/12/my-development-environment-a...
https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...
Programas como WordPerfect, Lotus 123, MS-DOS 1.0 e o SubLogic Flight Simulator antes da aquisição pela Microsoft eram escritos em assembly. Observadores da indústria na época viam que, por serem escritos no C “inchado”, MS Word e MS Excel permitiam à Microsoft iterar novos recursos mais rapidamente e portar para outras arquiteturas mais depressa do que WordPerfect e Lotus 123. Os concorrentes permaneceram tempo demais no assembly.
Vejo o mesmo trade-off em software pessoal. Usar C#/Python, mais alto nível e “inchados”, em vez de C/C++ mais enxutos, permite concluir certas tarefas muito mais rápido. Sou mais proficiente em C++ e prefiro executáveis pequenos, mas, se C# termina o trabalho que quero mais depressa, essa vantagem perde o sentido. Eu também faço parte do problema do software inchado.
“Vou construir a ponte mais forte e mais leve do mundo” é algo maravilhoso; “vou construir uma ponte suficientemente leve e suficientemente forte por um custo que o cliente consiga pagar” é engenharia.
Li um pouco mais da metade e parei, mas o argumento central parecia ser que software precisa ser rápido, e não me lembro de nenhuma justificativa para essa filosofia além da insinuação de que é “simplesmente verdade”. O texto reconhece a objeção de que há casos em que os ganhos de eficiência jamais compensam o custo de tempo de perseguir eficiência, mas passa por cima sem realmente lidar com esse argumento
Outra característica central do texto era escolher dados a dedo e simplificar demais os domínios. Ele faz várias vezes o apelo emocional de “afinal, o que o software faz com todo esse tempo e espaço?”, mas não tenta responder seriamente a essa pergunta e usa o fato de não haver resposta como se fosse prova de uma resposta errada. Também compara vários softwares que não têm equivalência funcional como se a única diferença fosse desempenho
Há muito a dizer sobre os custos sociais, ambientais e de negócios da ineficiência e sobre softwares mais eficientes, mas também vale discutir que o software moderno permite que pessoas que, de outro modo, não conseguiriam criar nada façam algo “ruim” de que precisam. Assim como um engenheiro estrutural escolhe algo “forte o suficiente”, desenvolvedores modernos muitas vezes miram em algo “rápido o suficiente”
Há muitos pontos ricos para debate, mas este texto ficou na indignação emocional e não conseguiu lidar com razão e argumentação de fato. Há verdade em algumas afirmações, mas acho que o próprio texto deixou claro que não tem intenção de debater
A rede provavelmente também não é 2G de alguns kbps, e sim 5G de centenas de Mbps ou fibra. No fim, ações falam mais alto que palavras, e se a sociedade como um todo segue o axioma do “software mais rápido”, dá para aceitá-lo como verdade
Especialmente porque é um axioma vindo do mesmo lugar que a afirmação de que “o tempo do desenvolvedor vale mais”; a diferença é apenas o tempo de quem se economiza
Se o desenvolvedor não testar também em dispositivos de baixo desempenho, não tem como perceber esse problema. O problema real, mais do que o lado técnico, é a atitude defensiva e argumentativa que alguns desenvolvedores adotam ao encarar a verdade desconfortável de que o código é lento demais. É preciso sentar com o gerente de produto, reservar tempo para profiling e otimização, e ver como mitigar problemas de desempenho sem reconstruir tudo do zero
BASIC e SQL já existiam havia muito tempo com o propósito de permitir que pessoas criassem algo “ruim”, e o mesmo vale para Fortran e várias linguagens e tecnologias hoje desaparecidas
Python ou Java são, sendo generoso, conservadoras; considerando os avanços das linguagens de programação dos anos 70, na verdade deveriam ser chamadas de anacrônicas. J ou Prolog são conceitualmente muito mais avançadas que Rust ou Go, mas foram criadas antes. O C acumulado de C89 a C23 é uma linguagem moderna? Só C23 é moderno? Há mesmo uma grande diferença entre C89 e C23? Tudo isso é meio ambíguo
Se não for pelo momento em que foi criado nem por uma árvore evolutiva imaginária, fico curioso se há outra forma de definir modernidade
É uma reclamação antiga. Muitas conveniências que damos como certas têm um custo, e esse custo se acumula bastante. Uma tela 4K tem 17 vezes mais pixels que 800x600 e usa cor de 32 bits, então o tamanho bruto dos gráficos para telas modernas fica cerca de 68 vezes maior
Antes, imagens estáticas bastavam, mas hoje animações de alta qualidade e alta taxa de quadros são o padrão. Arial Unicode é uma fonte de 15 MB e provavelmente nem caberia na memória da maioria dos computadores que rodavam Windows 95
A verificação ortográfica em todos os lugares virou algo esperado, e essas coisas se somam. Mesmo assim, elas tornam o uso do computador muito mais agradável. Não sinto falta dos modos de vídeo de 16 cores, nem da época em que não dava para usar ao mesmo tempo duas línguas que não fossem inglês sem contornos muito irritantes
Mas não quero animações cujo único motivo de existir é fazer o tempo de espera parecer menos entediante. Unicode também vale o custo
Ainda assim, deveria ser possível desenhar um glifo na tela em milissegundos de um dígito, como em 1981. Há mais pixels e mais glifos, mas é possível; simplesmente não é prioridade
É parecido com pagar 100 mil dólares por uma BMW de desempenho e o engenheiro dizer que ela leva 30 segundos para ir de 0 a 60 mph, e que o usuário deve simplesmente aceitar isso porque não é especialista em desempenho
Vi uma tendência parecida na organização atual. No começo, quando a equipe era pequena, os detalhes importavam. Não podia ser lento, as animações tinham que ser suaves, a velocidade de rolagem e o tempo de carregamento importavam, e tentávamos criar o produto mais eficiente para aumentar a eficiência do usuário
À medida que a equipe cresceu, o valor mudou para aumentar a eficiência dos desenvolvedores. Entraram mais abstrações, camadas e frameworks, e passou a ser aceito o trade-off de gastar milhões de segundos de todos os usuários em troca de poupar um dia de um desenvolvedor
A diferença está na visibilidade. A diretoria consegue ver os custos do lado do desenvolvimento, mas não vê os benefícios de um tempo de execução um pouco mais rápido, de um cache melhor ou de uma rolagem mais suave. Porque isso não é medido. Quando uma organização chega ao ponto de se importar apenas com números mensuráveis, essa tendência parece natural
Claro, isso vale até chegarmos ao ponto em que a IA consiga consertar tudo que nós fizemos errado, ou que a própria IA fez errado, e também a própria IA altamente ineficiente, como prevê o texto original
Carros só foram otimizados depois de um choque externo do petróleo, e mesmo assim de forma muito desigual. Na prática, produtos ineficientes muitas vezes são mais lucrativos, porque o cliente precisa substituí-los com mais frequência. Um cabo ruim de iPhone que racha depois de um ano permite que a Apple cobre de novo, e de novo, por uma reposição. Eletrodomésticos quebram com mais frequência, mas são fabricados mais barato, aumentando o lucro por unidade. O que importa não é a eficiência de uso depois da venda, mas a eficiência de produção
No software, o capitalismo funciona despejando novas automações o mais rápido possível e fazendo o consumidor arcar com o desperdício de energia e tempo. A cadeia de produção fica cada vez mais padronizada e otimizada, a ponto de permitir substituir desenvolvedores React ou administradores Kubernetes como trabalhadores de depósito, com a consequente pressão sobre salários. Parte da automação é quase uma autojustificação, como tornar a terminologia contábil obscura para justificar empregos; o resto é sobre lucro
Tudo tem um custo. Se o custo computacional ou a piora na experiência do usuário forem grandes o suficiente, otimiza-se a eficiência. Modelos de ML são um exemplo. Em outros casos, não se otimiza, porque o usuário final não quer isso a ponto de aceitar menos funcionalidades
Carros também consumiam muito combustível no passado, mas isso mudou quando, por causa do custo do combustível e das preocupações ambientais, os clientes passaram a querer outra coisa. Muitos engenheiros se esquecem de que são pagos para criar produtos para os clientes
Além disso, o autor do texto original parece nunca ter esperado uma máquina Windows ou Linux antiga inicializar completamente. Versões modernas inicializam muito mais rápido porque os clientes quiseram isso. Celulares ficam ligados 24 horas por dia, então o cliente não se importa se a inicialização demora quando acontece uma vez a cada alguns meses
Meu BIOS leva cerca de 20 segundos no POST, e dizem que isso é normal. Depois disso, o boot do SO leva cerca de 10 segundos
Também se pode dizer que médicos ou engenheiros são pagos para desenvolver novos medicamentos ou novas fontes de energia, mas, por essas áreas serem sensíveis e importantes, há várias camadas de controle governamental. O software ainda não tem esse nível de controle
Elas têm poder para moldar o próprio ambiente, e por isso conseguem redirecionar bastante os resultados das “demandas dos clientes”
Este texto é de 2018, e houve algumas discussões anteriores
https://news.ycombinator.com/item?id=18012334 (set. 2018)
https://news.ycombinator.com/item?id=21929709 (jan. 2020)
https://news.ycombinator.com/item?id=31798580 (jun. 2022)
Concordo profundamente. Como desenvolvedores, é importante lembrar que temos escolhas. Não podemos escolher tudo, mas podemos escolher alternativas menos ruins
Você não precisa necessariamente usar Node. Também é possível escrever software excelente e retrocompatível nos ecossistemas .NET ou JVM, e esperar que ele ainda rode daqui a 10 anos sem alterações
Também não é obrigatório criar páginas web de página única. O HTML à moda antiga, que recarrega a página inteira a cada clique, funciona bem e, a esta altura, pode até ter menor latência
Também não é obrigatório criar apps desktop com Chromium. Dá um pouco mais de trabalho começar com um framework de UI, mas a qualidade compensa. Nem sempre temos poder de decisão, mas, quando temos, devemos escapar das escolhas ruins