Você já viu aquelas listas de empregos que estão procurando por um “JavaScript Rock Star” e provavelmente revirou os olhos. Parece bobagem pensar que qualquer habilidade que você tenha na programação vai te fazer aparecer na Rolling Stone. Além disso, esse é o novo passo para a programação.

A menos que você seja Sam Aaron, isso é. Ele é o criador do Sonic Pi, uma linguagem de codificação ao vivo para fazer música. É um projeto de código aberto que ele construiu que cria música a partir do código em tempo real. O mundo da música está tomando conhecimento: a Rolling Stone o descreveu como “transcendendo o presente” quando ele se apresentou no mesmo festival que Grimes.

Sonic Pi trabalha em simples loops de código. Você entra em alguns comandos que indicam batidas, melodias e amostras para tocar. Esses comandos são processados através de um backend sintetizador chamado SuperCollider. A essência disso é loop e repetição, mas se você mudar o código durante a performance, a música muda também. É uma maneira simples e poderosa de colocar qualquer um em funcionamento com música eletrônica ou conceitos básicos de programação.

“Se você é um programador que não sabe nada sobre música, então Sonic Pi pode ajudá-lo com isso”, disse Aaron. “Se você é um músico, que não sabe nada sobre programação, Sonic Pi pode ajudá-lo com isso. E se você não sabe nada sobre qualquer um, você tem uma jornada divertida e emocionante pela frente.

Em seu rosto, é gloriosamente simples. Tão simples, que uma criança de 10 anos pode usá-lo. Sob o capô, há alguns desafios técnicos surpreendentes para fazer uma linguagem como esta funcionar.

 

Começos

 

Antes de Sonic Pi, Aaron e seu amigo Jeff Rose criaram Overtone, outra linguagem de codificação ao vivo construída em Clojure. Este projeto aumentou seu interesse em linguagens específicas de domínio, que foi tema de sua tese de doutorado na Universidade de Newcastle. Ele continuou trabalhando em Overtone como pesquisador na Universidade de Cambridge. No entanto, o dinheiro para essa posição estava se esgotando, então Aaron sabia que teria que encontrar outra coisa para fazer.

Foi quando ele se deparou com um projeto de três meses da Broadcom Foundation — designers por trás do chip do Raspberry Pi — para construir algo para envolver mais as crianças na codificação. “Eu coloquei minha mão para cima e disse, eu acho que eu poderia fazer algo com isso. Talvez eu possa tomar overtone e torná-lo mais leve, mais simples, e reduzir a funcionalidade, mas focalizar especificamente em crianças.”

Essa ideia acabou por ser mais ambiciosa do que ele pensava. Ele inicialmente assumiu que o projeto de três meses seria produzir um protótipo. Mas na primeira reunião, eles queriam um protótipo, um professor, uma escola, planos de aula, e uma corrida naquela sala de aula com sua ajuda. Isso significava que tinha que ser um sistema testado em batalha em pleno funcionamento pronto para ser usado por uma sala de aula cheia de crianças.

Raspberry Pi versão 1 foi projetado para ser de baixo custo e acessível, o que também significava que ele era de baixa potência. Aaron inicialmente tentou uma porta reta de Overtone usando Clojure. Levou sete minutos para os namespaces carregarem. “A implementação do Overtone não foi projetada para a velocidade para a baixa potência do Raspberry Pi 1”, disse Aaron, “mas também o Raspberry Pi 1 tinha um suporte JVM muito, muito pobre na época. Por exemplo, os pontos flutuantes não eram suportados no hardware e eram apenas software. Felizmente as coisas melhoraram muito desde aqueles primeiros dias.”

Aaron mudou para Ruby, que teve um bom desempenho no hardware e também foi flexível. Na verdade, é tão flexível, que você pode modificar a própria linguagem para atender às suas necessidades. “Linguagens flexíveis como ruby podem ser massageados no domínio em que você deseja trabalhar”, disse Aarom. “Assim, Sonic Pi pode ser visto como tendo Ruby como um pedaço de argila, e moldando-o em um instrumento musical.”

O protótipo acabou por ser a parte fácil. O código da primeira versão inicial levou duas semanas para ser concluído. A interface gráfica, a linguagem, o tempo de execução foram todos concluídos rapidamente. “Era apenas um sistema muito, muito, muito simples”, disse Aaron. “Tudo o que ele fez foi bip.”

Quando as crianças de verdade conseguiram o protótipo, entenderam como funcionava e queriam mais. “O que realmente me surpreendeu nas aulas é que as crianças diriam: ‘Oh, este é um ritmo de bateria legal ou este é um baixo legal'”, disse Aaron. “E eles estavam dizendo: ‘Como eu toco bateria ao mesmo tempo que o baixo?’ O sistema não tinha sido projetado para isso. Isso não está no currículo de ciência da computação do Reino Unido. Mas era uma pergunta tão comum. Eu pensei, bem, vamos apenas adicioná-lo dentro.

Com a concorrência veio muito sob a complexidade do capô. Revelou algumas dificuldades fundamentais que os computadores têm com um tempo preciso. Uma vez que ele introduziu vários segmentos, eles rapidamente se afastam de sincronia.

 

Seja simples.

 

Inicialmente, Aaron usou o sono POSIX para gerenciar o tempo. Mas como a maioria das operações programadas de sono, esta operação fez com que o computador dormisse pelo menos uma vez T, em seguida, executar a próxima operação quando o agendador de idioma interno o pegou de volta. “Atualmente, os computadores são apenas sobre o rendimento, não sobre latência e tempo”, disse Aaron. Cada atraso se somaria para jogar fora o tempo pior e pior à medida que a música progredia.

A solução de Aaron foi construir esse atraso interno nos comandos do sono. Cada vez que você chama um comando de sono, ele rastreia quanto tempo leva para se recuperar. Em vez de dormir pelo tempo T, ele dorme para T menos qualquer tempo adicional que os cálculos anteriores levaram. Compensa a deriva automaticamente. SuperCollider, o sintetizador que realmente tocava os sons, foi capaz de aceitar timestamps. Isso significava que a linguagem seria um pouco à frente dos sons que produziu. “Não é gerenciar o tempo”, disse Aaron, “é gerenciar a ideia do tempo, quando as coisas devem acontecer e, em seguida, defini-las ligeiramente antes do tempo para que o sintetizador honre esses tempos tão bem quanto pode.”

Todo esse trabalho duro para criar este tempo é em grande parte invisível para o usuário final. Para eles, é um simples conjunto de loops ao vivo que qualquer um pode entender. “As restrições ori