- A preocupação de Jonathan Blow de que “a abstração enfraquece a capacidade de manter software essencial” faz sentido do ponto de vista da transmissão de conhecimento, mas muitos dos exemplos usados como base interpretam mal a história e o contexto
- Os debates sobre “five nines”, software robusto, estagnação do progresso técnico e queda de produtividade em grande parte não distinguem dispositivos de consumo e sistemas de alta disponibilidade ou se apoiam em exemplos seletivos
- A preocupação com a perda de conhecimento de baixo nível é parcialmente válida, mas C, assembly, Rust, portabilidade de sistemas operacionais, ensino de compiladores e atividades de código aberto continuam sendo caminhos para preservar a capacidade de sistemas
- Abstrações como sistema operacional, sistema de arquivos, rede, multitarefa e frameworks aumentam a complexidade, mas também lidam com mudanças de hardware e expectativas dos usuários, além de ampliar portabilidade, produtividade e acesso à criação
- Mais do que a abstração em si, riscos maiores são o churn contínuo, plataformas fechadas, anúncios, rastreadores e telemetria, além do enfraquecimento da privacidade e da liberdade; a base técnica para manter sistemas importantes ainda precisa ser preservada
Posição básica sobre o argumento de Blow
- A palestra de Jonathan Blow sustenta que abstrações de software levam à perda de conhecimento de programação de baixo nível e, no fim, podem resultar em colapso da civilização por incapacidade de manter software essencial
- Há concordância com a importância da transmissão de conhecimento, mas para sustentar esse tipo de argumento é preciso que os exemplos e o contexto histórico estejam corretos
- A principal objeção é que os exemplos de Blow dependem demais de mal-entendidos, casos seletivos e evidência anedótica, além de ignorarem partes da história da computação
Debate sobre “five nines” e robustez
- Blow afirma que, no passado, sistemas computacionais eram vendidos com o slogan “five nines”, ou seja, 99,999% de uptime, mas que os laptops atuais não alcançam esse nível
- É verdade que five nines significa cerca de 5 minutos de indisponibilidade por ano, mas a afirmação de que essa métrica era usada para vender laptops de consumo ou processadores de texto é considerada incorreta
- Five nines normalmente se aplica a áreas como centrais de resposta de emergência 911, sistemas hospitalares e processamento de transações financeiras
- Muitas vezes vem acompanhado de contratos de longo prazo que definem em detalhe quais situações não contam como downtime
- Empresas como IBM e Amazon ainda vendem sistemas e serviços desse tipo
- Também há contraexemplos à afirmação de que não se produz software robusto há décadas
- Um iPhone pode funcionar por semanas ou meses sem reiniciar
- Há um caso de servidor de arquivos e impressão da Novell com 16 anos de uptime
- Equipamentos Unix, Windows, VMS e sistemas turnkey como IBM i também são citados como exemplos de disponibilidade de longo prazo
Contestação sobre progresso técnico e produtividade
- Há concordância parcial com a frase de que “empresas de tecnologia não estão mais empurrando a tecnologia adiante”, mas empresas mais interessadas em dinheiro já existiam no passado
- Áreas “tediosas” como sistemas de arquivos, servidores web, bancos de dados e linguagens de programação continuam sendo desenvolvidas e melhoradas
- As camadas de abstração, virtualização e conteinerização que Blow detesta também continuam evoluindo por meio de muito trabalho, e o fato de ele não gostar delas não significa que deixem de ser progresso tecnológico
- A alegação de que a produtividade dos funcionários do Facebook está próxima de zero depende da premissa de enxergar os produtos do Facebook apenas como recursos de plataforma social
- Os funcionários da empresa incluem áreas como jurídico, contabilidade, design gráfico, administração de sistemas, pesquisa, RH e gerência intermediária
- Há também outros negócios, como Instagram, WhatsApp e Oculus VR
- O produto real do Facebook é uma plataforma de entrega de anúncios; coletar dados pessoais e privados e convertê-los em publicidade direcionada pode não aparecer como funcionalidade para o usuário, mas aparece como receita
Conhecimento de baixo nível e os dois lados da abstração
- Reconhece-se como verdade que muitos programadores preferem ambientes em que não precisam lidar com alocação de memória e ponteiros
- Abstração excessiva é vista como problema, como renderizar um blog simples com frameworks JavaScript desnecessários ou apps desktop lentos rodando dentro de um navegador empacotado
- No entanto, hoje pode haver mais gente capaz de lidar com C e maior volume de código em C e assembly do que no passado
- Linux e NetBSD continuam sendo portados para diversos alvos que se parecem com CPUs
- Rust oferece ponteiros e gerenciamento de memória ao mesmo tempo em que foca em robustez
- Harvard CS50 aborda publicamente temas como layout de memória, ponteiros,
malloc()efree()
- Coleta de lixo e programação funcional não são abstrações novas
- Lisp já oferecia ambos no fim dos anos 1950
- Lisp também era usado em ambientes “hardcore”, como o Jet Propulsion Lab da NASA
- COBOL ficou ausente da palestra de Blow, mas continua sendo uma linguagem de alto nível crucial para a civilização atual por sustentar a infraestrutura bancária e financeira
O caso do “Unix em 3 semanas” de Ken Thompson
- O feito de Ken Thompson ao criar um assembler, um editor e um kernel básico em 3 semanas é considerado extraordinário
- Ainda assim, não está claro quão robusto, amigável ou funcional era aquele software naquele momento
- As condições de trabalho daquela época e as dos desenvolvedores atuais são muito diferentes
- Documentação, code review, daily standups, organização de backlog, user stories, testes unitários, exigências de clientes, testes A/B, mensagens de commit e padrões corporativos de código fazem parte do desenvolvimento atual
- Um ambiente cheio de interrupções em open office também pode ser bem diferente do trabalho individual no estilo Bell Labs
- O caso de Thompson sozinho não prova que todos os programadores do passado eram mais produtivos
- Thompson também participou do Multics, famoso por atrasos
- Grandes projetos como o IBM OS/360 também sofreram longos atrasos, e Frederick P. Brooks escreveu em 1975 The Mythical Man-month com base nessa experiência
Evolução do software e expectativas dos usuários
- De modo geral, os computadores se tornaram mais robustos do que eram décadas atrás, e os programadores são vistos como pelo menos tão produtivos quanto os do passado
- Em alguns casos, porém, começar a trabalhar ficou mais complexo, o que pode reduzir a produtividade inicial
- Usuários modernos não querem aprender RPN para fazer aritmética simples, nem usar diretivas do troff para criar um panfleto
- Interfaces convenientes e recursos avançados aumentam a complexidade e o tempo de desenvolvimento independentemente da abstração
- Casos antigos de travamento durante cópia de arquivos no Amiga OS com corrupção da partição do disco mostram que sistemas antigos não eram necessariamente mais estáveis
- Sistemas operacionais modernos para computadores domésticos têm proteção de memória e sistemas de arquivos com journaling, então esse tipo de problema é muito menos comum
- O Windows 10 Home tem defeitos, mas também incorpora esses avanços
Alegações de que “antes era só fazer”
-
Copiar e executar programas
- Copiar um programa de um computador para outro e executá-lo ainda é possível se a arquitetura de destino e as condições de compilação forem as mesmas
- Há exemplo de um binário estaticamente linkado de
slack-term, compilado em Go, funcionando em Raspberry Pis - Mas para encontrar uma época em que programas standalone eram realmente comuns, é preciso voltar aos tempos do C64 ou do PC/XT; até o Deluxe Paint IV no Amiga dependia de vários arquivos auxiliares e bibliotecas de funções de terceiros
- Alguns jogos de Amiga usavam disquetes track-loaded que ignoravam o sistema de arquivos e funcionavam como uma espécie de contêiner da época, mas com a desvantagem de impedir instalação em disco rígido e multitarefa
-
A ideia de que o código roda se a CPU for a mesma
- Em teoria, é possível carregar código de máquina na memória e apontar o program counter para executá-lo na mesma CPU
- Porém, para tarefas reais como exibir gráficos, reproduzir som, processar entrada e gravar em disco, as diferenças de hardware pesam muito
- Computadores domésticos baseados em Z80 no passado tinham a mesma CPU, mas hardware periférico diferente, o que tornava a portabilidade prática difícil
- Na verdade, programas em um nível maior de abstração, como Basic, podiam ser mais facilmente portados entre máquinas
- Com a Apple lançando desktops baseados em ARM, depender de abstrações pode reduzir o esforço de portar para novas CPUs em comparação com ficar preso diretamente ao metal
-
Sistema operacional e acesso ao hardware
- O sistema operacional não apenas tira capacidades da CPU; ele também adiciona recursos como sistema de arquivos, rede e multitarefa
- Usuários como streamers da Twitch, que precisam rodar jogos junto com outros programas, necessitam de multitarefa para compartilhar recursos de hardware de maneira controlada e previsível
- Parte do software de Amiga e Atari acessava diretamente hardware e memória sem seguir as especificações e abstrações fornecidas pelo fabricante, e por isso quebrava até com pequenos upgrades, como mais memória ou disco rígido
- Software escrito de acordo com especificações e abstrações podia continuar sendo vendido mesmo depois de mudanças no hardware
-
Gráficos, programas não assinados e LSP
- Desenhar pixels na tela continua sendo possível em várias linguagens, e o Mode 13h já era acessado por meio do VGA BIOS, uma camada inicial de abstração de hardware
- Código dependente de hardware VGA específico não era portátil, mas programas gráficos usando abstrações do Windows podiam funcionar em ambientes que iam de Hercules a true-color XGA
- Também ainda é possível executar programas não assinados, e há quem compile e use o WordGrinder manualmente
- Parte das reclamações de Blow está mais relacionada ao bloqueio de sistemas por fabricantes de hardware e software e à redução do poder do usuário do que à abstração em si
- Em relação ao Language Server Protocol, há concordância geral com Blow, mas o LSP resolve mais problemas do que apenas “clicar no método e ir para a definição”
Jogos, desempenho e multitarefa
- Muitos apps modernos de produtividade apresentam mau desempenho e atraso sério de entrada
- Parte da causa é a abstração, mas o problema maior está em código ruim e na escolha de ferramentas inadequadas para a tarefa
- Mesmo programas que usam a mesma plataforma e o mesmo toolkit de UI podem ter desempenho percebido muito diferente na mesma máquina
- O problema citado por Blow de jogos que não restauram corretamente a resolução após Alt-Tab é uma experiência ruim e deveria ser corrigido
- Mas jogos antigos em DOS eram mais simples porque não precisavam se preocupar com outros processos
- Para jogar Doom no Windows 3.1, era preciso salvar o trabalho, fechar programas, sair do Windows e só então iniciar o jogo
- Muitos jogos de Amiga também davam boot pelo disquete, tomavam a máquina por completo e não conseguiam voltar de forma limpa ao sistema operacional
- A multitarefa em jogos hoje não é perfeita, mas é vista como melhor do que no passado
Perda de conhecimento e velocidade da mudança
- Blow vê conhecimentos como gestão de sprites no Unity sendo transformados em trivia em vez de compreensão profunda
- Há concordância com a ideia de que a velocidade das mudanças em software e hardware modernos muitas vezes é rápida demais para ser acompanhada de forma significativa
- Porém, isso está mais ligado à consistência ao longo do tempo e ao modelo de distribuição de software do que à abstração em si
- Um ritmo de lançar algo a cada 4 semanas pode dificultar que usuários tenham uma experiência estável
- Mudanças frequentes de UI fazem o usuário lutar com detalhes de uma interface sempre mutante em vez de focar no trabalho real
Complexidade é um problema criado por pessoas
- Blow afirma que, se decidirmos reduzir a complexidade, ela pode ser reduzida, e que muitas vezes nos enganamos achando que adicionar abstrações economiza tempo
- Usar o framework certo para o objetivo certo pode ajudar bastante um desenvolvedor web
- Ao mesmo tempo, há ceticismo quanto a tentar fazer tudo no navegador, de processamento de texto a jogos, ou trocar imediatamente para cada novo framework que aparece
- A complexidade do software não é só um problema de programadores; mercado e ambiente organizacional também a produzem
- Política interna, reuniões inúteis, software obscuro de apontamento de horas, prazos definidos externamente, exigências difíceis de clientes, decisões gerenciais estranhas, estimativas de prazo para requisitos abstratos e depuração de código legado influenciam as escolhas dos desenvolvedores
- A complexidade é um problema criado por pessoas, e reduzir a complexidade no ambiente de trabalho pode, no longo prazo, reduzir também a complexidade do software
Jovens desenvolvedores e a capacidade de criar engines
- A afirmação de Blow de que jovens desenvolvedores de jogos nunca escreveram suas próprias engines e de que essa capacidade logo poderá ser esquecida coletivamente se aproxima de uma ladeira escorregadia
- A maioria das pessoas que tinham C64, Amiga ou um PC 286 nunca se tornou desenvolvedora de baixo nível, e muitas nem se tornaram programadoras
- Abstrações e engines prontas permitem criar sem dominar gerenciamento de memória de baixo nível, ponteiros e algoritmos
- Hoje, crianças querem fazer algo parecido com jogos AAA vendidos em lojas, e o nível de expectativa para jogos modernos é muito mais alto do que na era do C64 ou do Amiga
- Os caminhos para aprender técnicas de baixo nível continuam existindo
- Linux atrai jovens desenvolvedores pela comunidade open source e desperta interesse por linguagens de sistema como Rust, C e C++
dwmé um gerenciador de janelas configurado por meio da modificação do código-fonte em C- Existem jovens desenvolvedores que usam C e assembly Z80, pessoas que montam distribuições Linux do zero, gente que constrói seu próprio hardware e desenvolvedores C que rodam sistemas operacionais de pesquisa em hardware moderno
- Cursos de ciência da computação e engenharia elétrica continuam ensinando fundamentos como C, assembly e projeto de compiladores
- O acesso a ferramentas de programação, literatura, vídeos educacionais e materiais como MIT OpenCourseWare é mais barato e melhor do que no passado
Julgamento final: problemas maiores do que a abstração
- A conclusão de Blow se aproxima de um survivalismo aplicado à tecnologia, e a analogia com a necessidade de alguém saber acender fogo durante um apagão faz sentido
- A sociedade depende da capacidade de manter alguns programas rodando quase continuamente
- Se isso falhar, consequências graves como colapso da economia global ou falha de sistemas nacionais de saúde podem ocorrer
- Registros históricos e atuais são cada vez mais armazenados digitalmente, então precisam continuar acessíveis no futuro
- A complexidade é frágil, e abstrações podem gerar ignorância nociva; um blog simples não precisa de shadow DOM, e um cliente de IRC com imagens não precisa de uma casca de navegador
- Porém, o churn contínuo artificial também é uma grande fonte de fragilidade
- O desenvolvimento “Agile” pretende evitar lançar coisas inacabadas e não testadas, mas na prática releases incompletos continuam saindo sem parar
- Sistemas de anúncios, rastreadores e telemetria funcionam na prática como backdoors por design e aumentam vulnerabilidade e insegurança
- O problema maior do mundo digital é a privacidade e a liberdade
- A razão pela qual talvez deixemos de conseguir interagir diretamente com hardware pode não ser a escolha pela abstração, mas o fato de restarem apenas plataformas cada vez mais fechadas e controladas remotamente
1 comentários
Comentários do Hacker News
Em Montana State, dão uma disciplina de sistemas que vai dos transistores até sistemas computacionais reais, mas há alunos que começam o curso sem saber direito o que é um sistema de arquivos
O Blow erra em alguns detalhes, mas acho que, para alunos da área de tecnologia, deveríamos considerar seriamente uma educação no estilo NAND-to-Tetris já no ensino médio
Usam modelos “antigos” como o Little Man Computer ou emuladores visuais simples de MIPS, e, embora não sejam realistas, dão uma noção de de onde viemos com um nível de complexidade que uma pessoa comum consegue entender
Quando vejo os livros recomendados hoje para arquitetura de 64 bits, só consigo rir, e conectar a tecnologia até suas raízes é um problema difícil
O problema é que os sistemas operacionais móveis e as empresas de software querem transformar os dados do usuário, tanto quanto possível, em jardins murados dentro de aplicativos
Mesmo quando você já está trabalhando com arquivos, fazem você “importar” os dados existentes para o armazenamento deles, e as versões modificadas precisam ser “exportadas” ou “compartilhadas” manualmente como novas cópias
Estou fazendo mestrado em engenharia industrial em Montana State e convivo todos os dias com doutorandos que não conseguem fazer nem uma derivada parcial simples
No semestre passado, em uma disciplina de matemática de nível 400, havia aluno que não sabia somar duas matrizes
É estranho um formando em ciência da computação não saber o que é sistema de arquivos, mas, comparado com as bizarrices que já vi aqui, isso até parece modesto
O clima está bem diferente de quando entrei na faculdade pela primeira vez, nos anos 2000, o que é deprimente, mas pelo menos me deixa mais confiante sobre as perspectivas do mercado de trabalho na primavera do ano que vem
Ao contrário do nome, ciência da computação não é uma disciplina sobre o computador em si; embora o computador seja uma ferramenta essencial, o núcleo da área é a abstração de domínios e a modelagem de linguagens, além de suas aplicações
Assim como um astrônomo só precisa saber lidar com telescópios na medida necessária, um cientista da computação só precisa saber lidar com computadores na medida necessária
Colocar o computador no centro do universo e tratá-lo como ponto de partida da ciência da computação é um grande erro e, historicamente, uma fonte de muita confusão
Até programação de “baixo nível” continua sendo abstração e linguagem; apenas usamos a linguagem do dispositivo computacional para simular abstrações do domínio que estamos discutindo
No meu tempo livre, descompilo assembly MIPS, e funções pequenas consigo reconstruir à mão em código C correspondente sem usar outras ferramentas
Mas ela não está se diluindo. É justamente porque existe ensino, e porque existem livros e computadores, que não precisamos chamar professores de bardos
No fim, isto é só mais um post de blog sobre outro post de blog; não sei o quanto esses blogueiros são “importantes”, mas fica um cheiro de blog pelo blog
Quando um desenvolvedor web mais velho critica abstrações, está mirando desenvolvedores React; quando um desenvolvedor Python critica, está mirando o desenvolvedor web mais velho; e quando um desenvolvedor de aplicações C++ critica, está mirando o desenvolvedor Python
O desenvolvedor de firmware mira o desenvolvedor de aplicações, e o engenheiro eletricista mira o desenvolvedor de firmware
Traçar a linha da abstração excessiva com base no nível que a própria pessoa conhece e chamar tudo depois disso de “destruição da civilização” é uma postura e tanto
Há muitas observações boas, e como eu também vi a palestra, acho importante criticá-la
Ainda assim, o que Blow disse sobre “não conseguir simplesmente desenhar pixels na tela” está correto
Trabalho como programador de engine de jogos em uma empresa média de games, e está ficando muito difícil contratar gente para mexer com código de gráficos
APIs da geração do DX12 exigem dos programadores um nível absurdamente maior do que a geração anterior, como DX11, e só fazer qualquer coisa com essas APIs já é um grande trabalho
A própria Microsoft já admitiu que aprender DX12 sem experiência prévia com APIs gráficas antigas é extremamente difícil, embora eu não consiga mais achar essa citação na documentação
Parte da resposta de que “essas APIs são para desenvolvedores que querem empurrar a placa de vídeo ao limite e fazer otimizações muito de baixo nível” está certa, mas elas agora viraram padrão da indústria e estão quase além do que se consegue ensinar a alguém sem experiência anterior
Se nada mudar, o pool de profissionais contratáveis vai continuar encolhendo
Ao criar aplicações de software, ficou difícil demais até desenhar um único botão na tela, então a maioria simplesmente usa aplicativos web progressivos que são 100 vezes mais lentos do que o desempenho possível
Será que em 2025 o melhor que temos para aplicações GUI ainda é Java Swing e Qt?
Existem grandes conceitos que amarram tudo, mas eles quase não aparecem sugeridos na documentação, e você só aprende participando de sessões de treinamento ou conversando com alguém que já sabe
Acho que coisas como JavaScript no lado do servidor e React realmente transformaram o desenvolvimento de software web numa bagunça muito pior do que o que de fato entregam
Hoje em dia, há gente mais nova que nem sabe que o que é renderizado no navegador é HTML. Acham que o próprio React é o que o navegador renderiza
Além disso, o CEO da Vercel disse uma idiotice absoluta ao chamar React de kernel Linux do desenvolvimento
https://news.ycombinator.com/item?id=42824720
Estou por aqui há tempo suficiente para lembrar da época de vanilla js, jQuery, Knockout e Angular 1, mas a confusão básica sempre existiu mesmo naquela época
React, e às vezes até só JSX, pode ser usado de forma razoável
Em vez disso, culpo as ferramentas movidas a capital de risco como Vercel, Next, Apollo e Prisma, e os influenciadores de desenvolvimento web pagos para encher a web de lixo
Pensando bem, tudo no processo de fazer software inchou, do board no Notion até escolhas duvidosas de banco de dados
Mas, como alguém que trabalha bem sem bibliotecas, também quero acrescentar que o DOM é uma das piores APIs já inventadas pela humanidade, e que “programação reativa” é um modelo superior ao jeito antigo
NextJS desfez anos de melhorias em ferramentas e é muito mais lento que Vite
Numa build estática de NextJS, uma página sem nenhuma interação baixa 100 KB de JavaScript só para não fazer absolutamente nada
O Facebook está tentando resolver com um “compilador” para React algo que basicamente seria só evitar rerenderizar componentes sem necessidade
Comparado ao Preact, que é quase um substituto direto, React é gigantesco, o que mostra o quanto o Facebook não liga
HTML é um formato de serialização, e o navegador o usa para construir um DOM na memória
React não serializa nada em HTML e renderiza diretamente no DOM
O fato de isso estar errado e ainda assim ter recebido tantos votos mostra bem como esta thread tem um ar de “velho socando nuvens”
Pelo que entendo, HTML é a entrada do navegador, que o converte em DOM e depois segue para desenhar a tela, processar entrada etc.
Essa diferença é importante, porque React e as bibliotecas JavaScript da família do DOM virtual não geram HTML, e sim comandos de manipulação do DOM em JavaScript
Há muita coisa boa nas críticas do Blow, mas acho que ele deixa passar que muito da regressão não vem de deriva geracional nem de entropia informacional, e sim da má-fé explícita de quem toma as decisões
Blow às vezes faz observações realmente excelentes sobre desenvolvimento, e às vezes erra completamente o alvo
Ele realizou bastante coisa e tem ideias que valem ouvir, mas também diz muita bobagem apresentada de forma indistinguível do resto
Senti fortemente que a conversa sobre colapso da civilização era uma dessas bobagens, ouvi duas vezes e ignorei a maior parte
Agradeço ao post original por fazer uma refutação mais baseada em princípios
Acho que Casey Muratori imita Blow, mas nem consegue reproduzir direito as partes boas
Muratori nem conseguiu terminar o jogo que começou 10 anos atrás
Enquanto isso, com engines modernas, incluindo coisas como Raylib, dá para fazer resultados bem decentes até em game jams de fim de semana, e um jogo do nível do Sokoban do Blow provavelmente poderia ser feito em algo como 6 meses por uma equipe de umas 10 pessoas
Vi parte do conteúdo dele e, nos temas que conheço, ele me pareceu humilde, mas claro nas opiniões, e achei que ele fez um ótimo trabalho com Handmade Hero
O tempo que o Jira leva para mostrar um único ticket, o tempo que o Slack leva para trocar de sala, o fato de o VSCode não conseguir acompanhar uma velocidade normal de digitação, tudo isso é realmente absurdo
Parece que ele solta declarações críticas amplas e depois some de novo para continuar não fazendo nada
Também é difícil dizer que ele conquistou algo grandioso; eu diria que fez um trabalho só razoável
Lançou só dois jogos, e eles se parecem mais com quebra-cabeças do que com jogos. Depois que você termina uma vez, quase não há motivo para voltar
Braid é ok, e The Witness é só tipo Flow
Depois disso, passou 10 anos fazendo uma linguagem de programação e não a publica porque “ainda não está pronta”
Desde que ganhou dinheiro por sorte, parece se considerar muito mais talentoso do que realmente é
O ambiente moderno de software claramente tem muitos problemas, e acho que abstração excessiva é um deles
Mas o extremo oposto também é ruim, e também existe uma tendência de romantizar demais o passado
Travamentos e reinicializações também eram um problema, sistemas como o Amiga tinham problemas de compatibilidade entre versões de hardware, e até sistemas que priorizavam compatibilidade não estavam livres de incompatibilidades
Mesmo no sistema moderno mais instável, o Windows 11, meu computador é muito mais estável do que qualquer computador que eu usava antes de 2010, e ainda consegue rodar software de Windows 95
Um computador que dá para usar no dia a dia é melhor do que um que não dá
Nem toda simplificação é abstração, e nem toda abstração é simplificação.
Mas, ao buscar simplificar, muitas vezes se acaba criando abstrações.
Não acho que abstrações matem software ou civilizações, mas abstrações ruins criadas em nome da simplificação de curto prazo reduzem flexibilidade, agilidade e acessibilidade.
Basta olhar para o açúcar sintático de quase todas as linguagens: em algum momento, a simplificação local obtida por essa nuance específica deixa de justificar o aumento da complexidade da ferramenta como um todo.
Em linguagens com muita sintaxe, as pessoas erram não por causa de um elemento específico, mas porque fica mais difícil usar a própria ferramenta para resolver bem problemas complexos.
Em Kotlin, a complexidade extra que async e corrotinas trazem, na minha experiência, ao lidar com código “parecido com thread” é completamente diferente da forma como Elixir/Erlang trata o mesmo tipo de problema.
Ambos oferecem abstrações e simplificações para o velho problema da computação paralela e assíncrona, mas o primeiro multiplica várias camadas de simplicidade e volta a produzir complexidade, enquanto o segundo chega mais perto de uma abstração realmente simples que simplesmente funciona.
O autor parece pertencer a uma geração mais jovem e, por isso, parece ter deixado passar o ponto principal do Blow sem sequer entendê-lo.
Ironicamente, o próprio texto parece um exemplo do que Blow estava dizendo.
É parecido com dizer que o Figma está destruindo o mundo do design em uma escala sem precedentes ao normalizar o próprio UX, UI e modo de gestão de produto ruins do Figma, e receber de volta a reação confusa de jovens designers achando que está tudo bem.
Esse conhecimento existe porque alguém cresceu naquele ambiente; eles não cresceram, e também não é fácil aprender em outro lugar aquilo que corresponde a cultura e experiência.
Esse tipo de ataque pessoal não acrescenta nada à conversa.
Ao contrário da frase “a alegação de que o software está melhorando é claramente falsa”, eu ainda uso com frequência os computadores Amiga que adoro.
Algumas semanas atrás, eu estava copiando arquivos para o disco rígido de um Amiga e, de repente, o computador travou — não porque eu tivesse feito algo errado, mas porque sistemas operacionais de computadores domésticos antigos não eram lá muito estáveis.
Como resultado, a partição do disco rígido foi corrompida, o sistema operacional não conseguiu revalidar o sistema de arquivos e, no fim, não restou alternativa além de reformatar a partição.
Não entendo muito de design, mas dá para perceber que a afirmação sobre o Figma é completamente errada, assim como a do Blow.
Isso é a nostalgia falando. Sempre houve muita coisa ruim em interfaces de usuário, e o mesmo vale para software e para todo o resto.
O que fica na memória são só as vantagens dos melhores exemplos do passado, enquanto se esquecem as porcarias e até os fracassos de coisas bem projetadas.
O problema são abstrações que não foram pensadas a fundo.
Muitas abstrações são lançadas claramente ainda com cara de primeiro rascunho ou primeira tentativa, antes de passarem por várias iterações, por causa do culto à velocidade e da arrogância da indústria de tecnologia.
Quando esse tipo de abstração vira parte de um projeto popular, outras pessoas copiam por impulso de manada, sob a bandeira vaga de “boas práticas”.
Repetindo esse processo por 10 ou 20 anos, surge um caos gigantesco.
Pior ainda: em uma sociedade paradoxalmente supersocializada por causa da tecnologia, o consenso social de não ser exposto como “impostor” continua espalhando soluções imaturas.
Gosto daquela apresentação do Jonathan Blow e a revejo pelo menos uma vez por ano. Para mim, ele não está dizendo algo polêmico; as pessoas ficam irritadas ou se sentem atingidas porque muitos desenvolvedores sabem, no fundo, que nem estão entregando o melhor de si nem orientando adequadamente as gerações mais novas.
Chegamos a uma cultura em que a busca pelo novo é rotineira e às vezes até celebrada.
Antes, soluções suficientemente examinadas eram o padrão cultural; agora, o padrão passou a ser o que é novo, independentemente de ser realmente bom.
Dá para discutir sem fim os detalhes do argumento do Blow, mas a evidência está por toda parte, bem na nossa cara.
E, em uma escala de tempo suficientemente longa, isso pode levar ao colapso da civilização; olhando para a quantidade de coisas quebradas no mundo, dá até para dizer que isso já está acontecendo.
É triste que uma tese falha precise ser desmontada com tanto detalhe.
Um empirista puro está tão desconectado da realidade quanto um teórico puro, e Blow constrói argumentos só porque eles batem com a própria experiência dele, escolhendo apenas exemplos que combinam com suas reclamações e tentando empurrar exceções como se fossem regra.