A edição Pharo do ActivePapers
A edição Pharo do ActivePapers, por Konrad Hinsen, publicada em 10 de maio de 2019 A família ActivePapers ganhou um novo membro: a edição Pharo do ActivePaper . Ao contrário das edições Python e JVM, que implementam basicamente as mesmas ideias e conceitos em duas plataformas diferentes, a edição Pharo persegue um objetivo distinto: explorar a interface humano-computador para pesquisas auxiliadas por computador que sejam reprodutíveis, compreensíveis e verificáveis.
Uma das perguntas mais frequentes que recebi sobre a edição Python do ActivePapers foi: “Isso funciona com notebooks do Jupyter?” Inicialmente, minha resposta foi: “Ainda não, mas estou trabalhando nisso.” E trabalhei. No entanto, esse trabalho nunca levou a um resultado satisfatório. Uma das razões foram obstáculos técnicos. Tentei incluir notebooks do Jupyter dentro de um ActivePaper, mas isso se mostrou impossível porque o design de dois processos do Jupyter (o kernel e o editor de notebook são processos separados conectados por um protocolo de comunicação) não era compatível com a restrição da biblioteca HDF5 de que apenas um processo pode escrever em um arquivo por vez.
Isso significa que você não pode armazenar um notebook e os resultados que ele computa no mesmo arquivo HDF5. Contudo, quanto mais eu pensava em integrar o ActivePapers e o Jupyter, mais percebia que seus notebooks lineares (uma sequência de células de código, documentação e resultados) não são realmente adequados à tarefa de documentar um cálculo científico, exceto em casos simples. Se você observar os vários ActivePapers publicados, eles invariavelmente contêm múltiplos scripts além de alguns módulos de biblioteca.
Superficialmente, pode parecer que os notebooks podem substituir os scripts e, assim, fornecer documentação. No entanto, uma boa documentação deve documentar o todo, não apenas algumas de suas partes. Ela deve integrar múltiplos scripts e códigos dos módulos de biblioteca.
Geralmente, os métodos computacionais são implementados nos módulos de biblioteca, e os scripts os aplicam a conjuntos de dados. Se a documentação for feita script por script, como documentar os métodos?
Hoje há muitos notebooks do Jupyter publicados; então, como eles lidam com isso? É claro que não examinei todos eles, mas, até agora, minha impressão é que existem dois casos. O caso mais frequente são notebooks que documentam análises de dados baseadas em métodos padrão bem conhecidos, implementados em bibliotecas também bem conhecidas. Espera-se que os leitores do notebook já estejam familiarizados com os métodos ou que aprendam sobre eles em outro lugar. O outro caso são notebooks que incluem a implementação completa do método.
Relacionado: — Cursos interativos de Python e ciência de dados que você codifica diretamente no navegador.
Além de ser limitado a métodos simples, essa abordagem tem a grande desvantagem de que a implementação do método não é reutilizável. Como minha própria pesquisa foca principalmente no desenvolvimento e avaliação de novos métodos computacionais, concluí que os notebooks não são adequados para o meu trabalho.
Na verdade, cheguei a essa mesma conclusão na prática. Sempre que iniciava um novo projeto como um notebook, rapidamente migrava para módulos e scripts no estilo antigo, com documentação em arquivos de texto separados. Considero essa técnica perfeitamente adequada para meu uso pessoal, mas um conjunto de arquivos, mesmo bem organizado, não resulta em algo que outro cientista, mesmo um colaborador, esteja ansioso para explorar. Quando comecei a olhar para o Pharo há alguns meses, largamente por acidente (inscrevi-me no MOOC de Pharo para obter alguma experiência de MOOC do ponto de vista do aprendiz, antes de assumir o papel de instrutor no MOOC de Pesquisa Reproduzível ), descobri um tipo muito diferente de ambiente de computação interativa.
A família Smalltalk, da qual o Pharo é um dos membros mais jovens, tem uma longa história de valorizar a explorabilidade e a compreensibilidade (veja esta postagem de blog para mais detalhes). Então, descobri rapidamente o Glamorous Toolkit , um novo ambiente interativo construído sobre o Pharo e visando um nível ainda maior de explorabilidade por meio de ferramentas de desenvolvimento moldáveis; a ideia é que os desenvolvedores possam estender o ambiente com ferramentas de inspeção específicas de domínio.
Favorito do leitor: — Caminhos de ciência de dados baseados em projetos com um terminal guiado e conjuntos de dados reais.
O background intelectual dessas ideias foi bem resumido em uma postagem de blog por Rafael Luque. Comparados aos ambientes atuais e futuros do universo Pharo, os notebooks computacionais parecem muito limitados e restritivos. O que não é realmente surpreendente, considerando suas origens.
Os atuais Jupyter e RMarkdown são variações menores da ideia de notebook introduzida no início da década de 1980 pelo Mathematica . O Mathematica, por sua vez, como a maioria dos outros sistemas de álgebra computacional, baseou-se na herança do Lisp, que na década de 1950 introduziu muitas características revolucionárias na computação, entre elas a interatividade via Loop Ler-Avaliar-Imprimir (REPL), que era uma maneira natural de implementar a interação dentro das restrições do hardware de interface do usuário da época: um terminal orientado a linhas.
O Smalltalk, por outro lado, surgiu na década de 1970 já com displays gráficos e dispositivos apontadores desde o início, ao preço de depender de hardware ao qual muito poucas pessoas tinham acesso na época. Como Marshall McLuhan nos ensinou, primeiro moldamos nossas ferramentas e depois nossas ferramentas nos moldam. Os terminais orientados a linhas da década de 1950 imprimiram uma forma de pensar nos usuários de computador que até os notebooks computacionais de hoje retiveram, apesar de abordagens superiores existirem há décadas.
E essa tecnologia superior não é meramente o Smalltalk, que sempre permaneceu um sistema de nicho. Interfaces gráficas não lineares são o que todos usamos para trabalhar com imagens ou arquivos de som.
Essas tarefas são quase impossíveis de fazer linha por linha, então elas realmente não aconteciam antes das GUIs. Para cálculos, as GUIs provavelmente chegaram tarde demais: o pensamento linear já se tornara uma norma cultural. A edição Pharo do ActivePapers visa moldar o ambiente GToolkit em um ambiente para realizar pesquisas auxiliadas por computação, em vez de desenvolvimento de software. Essas duas atividades são distintas, mas compartilham muitas características comuns.
A principal diferença é que a ciência foca em dados e em modelos, sendo o software apenas um meio para um fim. No entanto, é um meio tão importante que tudo o mais é estruturado em torno dele. Além disso, o desenvolvimento de software também lida com dados (sobre software) e modelos (como especificações).
No final, as diferenças são graduais, não fundamentais. Essa jornada acabou de começar, e eu realmente não sei aonde ela levará. Fique atento às atualizações! Enquanto isso, você pode assistir a este vídeo de demonstração . comentários fornecidos por Disqus
Ganhe certificados de universidades reais
Uma assinatura para certificados Python e de ciência de dados apoiados por universidades