Visualizando o código para falhar mais rapidamente

Em O que o senhor não pode ver, não pode obter Mencionei de passagem como estava frustrado com o fato de o estado da arte dos editores de código e IDE ter avançado tão pouco desde 2003. Vários comentaristas apontaram a incrível Bret Victor falar Inventando por princípio. Eu não tinha visto isso, mas obrigado por mencioná-lo, porque eu definitivamente deveria ter visto. Talvez o senhor também não tenha visto?

Bret Victor – Inventing on Principle (Inventando por princípio) de CUSEC em Vimeo.

O vídeo é um pouco longo, com 54 minutos, mas vale a pena ser visto em sua totalidade. O que Bret mostra aqui é exatamente o tipo de coisa que deveríamos estar fazendo, mas não estamos.

De certa forma, regredimos em relação aos meus antigos dias de Visual Basic 6.0, quando o senhor recebia notificações dinâmicas sobre erros à medida que o senhor digitavae não apenas quando o senhor compilou ou testes unitários executados. A ideia de que o o senhor deve ser capaz de digitar (ou gesticular, ou falar) e imediatamente Veja o resultado dessa mudança é simples, mas extremamente eficiente. Ele é velocidade de iteração no pequeno. Essa é essencialmente a base do meu argumento de que mostrar a marcação e a saída renderizada lado a lado, e atualizá-las dinamicamente à medida que o usuário digita, é muito superior para o aprendizado e a experimentação em comparação com qualquer tentativa de WYSIWYG.

Mas Bret vai além disso. por que não mostrar os efeitos das mudanças previstas e as mudanças ao longo do tempo? O tempo é o elemento que falta em uma exibição estática de código e saída renderizada; como podemos mostrar isso?

Novamente, assista ao vídeo porque é mais fácil ver em ação do que explicar. Mas talvez o senhor queira brincar com isso sozinho? Esse é o tipo de ponto, não é mesmo? Como eu escrevi em 2007:

Anseio pelo dia em que as páginas da Web sejam regularmente ilustradas com o tipo de visualizações belas e dinâmicas que Ben Fry cria.

Esse dia, tenho o prazer de informar, parece ter chegado. Artigo de Bret, Subindo e descendo a escada da abstração é extremamente interativo no velho e chato HTML 5.

Sim, é artístico, sim, esses projetos são, em sua maioria, de brinquedo, mas não se trata apenas de uma bobagem de visualização de arte abstrata. Projetar ferramentas que permitam que o senhor faça mudanças rápidas e veja o resultado. efeitos dessas mudanças o mais rápido possível pode ser transformador.

Paul percebeu que o que precisava ser resolvido não era, de fato, o voo com motor humano. Isso era uma pista falsa. O problema era o processo em si e, junto com ele, a busca cega de um objetivo sem uma compreensão mais profunda de como enfrentar desafios profundamente difíceis. O senhor encontrou um novo problema que se propôs a resolver: como o senhor pode construir um avião que possa ser reconstruído em horas e não em meses?. E ele conseguiu. Ele construiu um avião com Mylar, tubos de alumínio e arame.

O primeiro avião não funcionou. Era muito frágil. Mas, como o problema que ele se propôs a resolver era criar um avião que pudesse ser consertado em horas, ele conseguiu fazer iterações rapidamente. Às vezes, ele pilotava três ou quatro aviões diferentes em um único dia. O ciclo de reconstrução, reteste e reaprendizado passou de meses e anos para horas e dias.

Dezoito anos se passaram desde que Henry Kremer abriu a carteira para sua visão. Ninguém conseguiu transformar essa visão em um avião. Paul MacCready se envolveu e mudou a compreensão do problema a ser resolvido. Meio ano depois, o projeto de MacCready Gossamer Condor voou 2.172 metros para ganhar o prêmio. Um pouco mais de um ano depois disso, o Gossamer Albatross voou pelo canal.

Não me entenda mal, estamos falhando muito rápido com nossas ferramentas existentes. Mas não consigo deixar de pensar que poderíamos falhar ainda mais rápido se otimizássemos nossos IDEs e editores de código para visualizar melhor os efeitos de nossas alterações em tempo real à medida que as fazemos.