ToonTalk -- Um ambiente de programação animada para crianças

Ken Kahn, Animated Programs

Versão de 22 de Novembro de 1995

Traduzido por Leonel Morgado em Janeiro de 2001

Este documento é uma actualização e expansão do constante, com idêntico nome, em:

Proceedings of the National Educational Computing Conference (NECC'95),

combinado com parcelas da comunicação:

"Metaphor Design -- Case Study of an Animated Programming Environment",

incluída em "Proceedings of the 1995 Computer Game Developers Conference".

Palavras-chave: programação de computadores, crianças, jogos de vídeo, jogos de computador, programação concorrente.

Resumo

Seymour Papert, em certa ocasião, descreveu a concepção da linguagem de programação Logo da seguinte forma: pegar nas melhores ideias da informática, no tocante a concepção de linguagens de programação, e fazer com elas "engenharia infantil" [Pap77]. Vinte e cinco anos após o nascimento do Logo, verificaram-se imensos progressos na investigação de linguagens de programação e nas interfaces homem-máquina. Actualmente, existem linguagens de programação muito expressivas, muito elegantes do ponto de vista matemático, mas que continuam a ser de aprendizagem e domínio difíceis. Acreditamos estar na altura certa para repetir o êxito de quem concebeu o Logo, realizando a engenharia infantil de uma destas linguagens modernas.

Aquando da construção inicial do Logo, uma questão crucial foi a recolha dos elementos computacionais da linguagem de programação Lisp e a concepção para estes de uma sintaxe agradável para as crianças. No Lisp, havia instruções como "CAR", que foi substituída por "FIRST" ("primeiro"), e "DEFUN", que passou a "TO" ("para", "até"), os parênteses foram eliminados, etc.. Hoje em dia, há linguagens completamente visuais, cujos programas existem sob a forma de imagens, em vez de texto. Acreditamos estar perante um passo na direcção certa, mas melhor do que os programas visuais são os programas animados. A animação adequa-se muito melhor à dinâmica dos programas de computador do que diagramas ou ícones estáticos. Embora tenha havido progressos enormes nas interfaces gráficas de utilizador, nos últimos vinte e cinco anos, optámos por não procurar a maioria das ideias na metáfora do ambiente de trabalho, mas sim nos jogos de vídeo. Estes são geralmente mais directos, mais concretos e mais fáceis de aprender do que o restante software. São também mais divertidos.

Construímos um sistema genérico de programação concorrente, o ToonTalk, no qual o código-fonte é animado e o ambiente de programação é um jogo de vídeo. Todos os pormenores da computação abstracta foram concretizados em metáforas específicas. Por exemplo: uma computação é uma cidade, um objecto ou agente activo é uma casa, há pássaros que transportam mensagens de casa para casa, um método é um robô treinado pelo utilizador, etc. O programador controla uma "personagem-programador" neste mundo de vídeo, para construir, executar, depurar e modificar programas. Acreditamos que o ToonTalk se adequa particularmente bem a conferir às crianças a possibilidade de construir verdadeiros programas, de um forma divertida e fácil de aprender.

1º objectivo: um sistema de programação para crianças para auto‑aprendizagem

A programação pode ser uma actividade divertida e potenciadora, mas acessível apenas a quem consegue ultrapassar a grande barreira inicial. Esta barreira é constituída, entre outros aspectos, pela aprendizagem de uma linguagem de programação formal e conceitos computacionais, como as variáveis, os procedimentos e o controlo de fluxo. Se fosse possível minimizar esta barreira e ultrapassar o que restar, com divertimento, as crianças e os adultos seriam capazes, de forma criativa, de moldar os computadores à forma que desejassem. Aprender a usar computadores sem aprender a programar é como aprender a ler sem aprender a escrever.

O nosso objectivo é criar um sistema informático que possa ser utilizado pelas crianças para construir uma grande variedade de programas, sem que seja necessário ensiná-las. Muitos acreditam que um sistema tão fácil de aprender, que qualquer um utiliza sem ajuda de qualquer professor, é necessariamente bastante limitado. O ToonTalk, contudo, é um sistema de auto-aprendizagem flexível e expressivo. É possível construir uma grande variedade de programas, desde jogos como ténis, o enforcado e o PacMan, a programas para controlo de motores e sensores de Lego ou de outros brinquedos de construção, passando por exemplos de programação convencional, como factoriais e ordenação quick sort em paralelo.

Existem precedentes, em areas exteriores à programação de computadores, de sistemas com muitas potencialidades, que possuem características de auto-aprendizagem. Por exemplo: as crianças aprendem sozinhas a fazer construções complexas em Lego. Conseguem dominar jogos de video que implicam exploração e resolução de problemas em mundos fictícios complexos. A análise dos sistemas dos jogos de vídeo e do Lego contribuiu com muitas das ideias que fazem com que o ToonTalk seja fácil de aprender ([Mal80] e [Pro91]).

Entre os princípios de concepção obtidos a partir de bons jogos de vídeo ou de construção, incluem-se os que se seguem.

1. Fazer com que a primeira experiência seja simples, aumentando a complexidade gradualmente.

2. Incentivar a exploração e a curiosidade.

3. Apresentar e manter fantasias interessantes.

4. Ser um desafio constante, mas não frustrante.

5. Utilizar frequentemente princípios e técnicas de cinema e de animação (esta ideia provém exclusivamente dos jogos de vídeo).

Ao construir o sistema de programação do ToonTalk, esforçámo-nos por seguir estes princípios. Também recorremos, fortemente, à tecnologia dos jogos de vídeo. Por exemplo: imitámos o método, utilizado frequentemente pelos jogos de video, de colocar o jogador no mundo do jogo, disponibilizando uma personagem ou avatar, que o jogador controla e com a qual se identifica. As crianças reagem aos acontecimentos como se fossem, por exemplo, um dos irmãos Mario, nos jogos Mario Brothers. No ToonTalk, o programador é uma personagem animada que constrói, testa e depura programas.

A brincadeira das crianças com as peças de Lego pode ser decomposta, em termos práticos, em três componentes: concepção, construção e utilização. Para algumas crianças, em certos projectos, a concepção é muito difícil. Mas conseguem divertir-se bastante e sentir-se realizadas quando constroem um brinquedo, seguindo instruções pormenorizadas, e depois brincam com esse brinquedo. As crianças mais experientes, ou com maiores ambições, fazem uso da criatividade para construir versões de projectos que já existem, ou mesmo conceber novos projectos de raiz. Da mesma forma, a parte mais difícil da programação é a concepção de programas. Construí-los é, geralmente, uma sequência de tarefas monótonas, como escrever ou corrigir erros de sintaxe. O ToonTalk é distinto dos restantes ambientes de programação por fazer com que o processo de construção de um programa seja uma brincadeira divertida. Um utilizador novato do ToonTalk, ao construir programas, pode não ser mais criativo do que na construção de um modelo de avião, ou a seguir as instruções pormenorizadas de Lego. Mas em todas estas situações, o processo de construção, bem como a brincadeira com os resultados, podem ser actividades divertidas. Uma forma muito eficaz de fazer com que as crianças aprendam a conceber algo é a brincar com as boas concepções de outras pessoas.

O ToonTalk, ao contrário do Logo ou do Basic, foi concebido para que uma criança, em casa, possa tornar-se um programador competente sem formação veiculada por humanos. A título de exemplo, refira-se que uma sondagem recente indicou que, nos Estados Unidos, o tempo médio empregue pelos alunos do ensino secundário na programação de computadores era inferior a 20% do tempo total de utilização dos mesmos. [Bec93] Na maior parte dos casos, trata-se de tempo manifestamente insuficiente para que as crianças possam aprender a arte da programação.

A comunidade Logo também está empenhada em conferir às crianças a capacidade de programar, por motivos epistemológicos [Pap93]. Advogam que a programação é um terreno fértil para a aprendizagem de competências fundamentais de raciocínio e de resolução de problemas. A criança aprende conceitos como representação, decomposição de problemas, abstracção, depuração, etc. Estas actividades podem ocorrer durante a aprendizagem da programação e são muito importantes. Mas, infelizmente, não são parte dos resultados habituais da aprendizagem do Logo [Yod94]. Embora seja nossa espectativa que este tipo de aprendizagem venha a ser cada vez mais frequente com o ToonTalk, já ficamos satisfeitos se o resultado for simplesmente conferir às crianças a capacidade de dominar os computadores de forma criativa.

2º objectivo: um sistema poderoso de programação para crianças

O ToonTalk foi construído por forma a ser simultaneamente muito fácil de aprender e ser uma ferramenta de programação muito poderosa e flexível. Estes objectivos são considerados, normalmente, como estando opostos, implicando compromissos. Uma linguagem como o C++ é muito flexível e poderosa, mas é também muito difícil de aprender. O HyperTalk, por outro lado, é uma linguagem que foi aprendida e utilizada por muitas pessoas que não são programadores, mas possui muitas limitações inerentes. As crianças podem fazer de conta que ajudam no jardim com pás e ancinhos de brincar, mas se realmente quiserem fazer jardinagem, devem ter ferramentas de verdade, adaptadas às suas necessidades especiais.

A concepção de linguagens de programação apoiada em conceitos teóricos produziu muitas linguagens que são pequenas, mas poderosas. Entre os exemplos contam-se a maioria das linguagens de programação lógica ou funcional, bem como algumas linguagens de programação orientada a objectos. O problema reside em que linguagens como o Scheme, o ML, o Prolog, o FGHC (Flat Guarded Horn Clauses) e o SmallTalk-80, apesar de serem pequenas e elegantes, são de aprendizagem difícil, até mesmo para alunos de informática. Seria absurdo esperar, de alunos do ensino básico, o domínio de uma linguagem de programação que é considerada muito difícil, mesmo para programadores profissionais.

Mas talvez a dificuldade não esteja nos conceitos em si, mas na falta de metáforas acessíveis. Considere-se, a título de exemplo, o conceito de canais de comunicação, presente em muitos sistemas concorrentes. Associados a estes canais estão privilégios de leitura e de escrita. Alguns adoptam o conceito de que uma tentativa de leitura de um canal vazio suspende a actividade até que algo seja escrito no canal. Geralmente, estes conceitos são ensinados em disciplinas de informática avançada. Mas este conceitos abstractos difíceis podem ser substituídos por analogias concretas com o dia-a-dia, perfeitamente equivalentes. No ToonTalk, os canais de comunicação são os pássaros e os ninhos. A capacidade de escrever num canal é um pássaro que se comporta como um pombo-correio. O acesso de leitura ao canal é o ninho desse pássaro. Os pássaros podem ser copiados, pertencedo todas as cópias ao mesmo ninho (ou seja, cada cópia do pássaro possui capacidade de escrita no mesmo canal). O comportamento dos pássaros implementa a semântica operacional dos canais. Quando um pássaro recebe uma mensagem, voa para o ninho, deixa lá a mensagem e regressa ao ponto de partida. Se já estavam coisas no ninho, coloca o novo item sob esse conteúdo (o que constitui uma implementação de uma semântica first-in, first-out, relativamente às mensagens em fila: o primeiro a entrar é o primeiro a sair). Se algum outro pássaro estiver a colocar alguma coisa no ninho, o primeiro espera pela sua vez (o que representa a arbitragem entre várias escritas no mesmo canal). Um pássaro consegue sempre encontrar o ninho correspondente, ainda que se tenha deslocado (assim, a capacidade de leitura continua a funcionar, mesmo após uma transferência). Estas regras de comportamento dos pássaros são fáceis de compreender, mesmo para uma criança de 7 anos.

O desafio consiste assim em pegar numa boa concepção de linguagem, de orientação teórica, que seja pequena e poderosa, e encontrar um conjunto coerente de concretizações, que abarquem todos os elementos da linguagem. O ToonTalk baseia-se numa linguagem de lógica concorrente por restrições [Sar93], semelhante ao Janus [SKL90] e ao Linear Janus. O Janus é suficientemente semelhante a outras linguagens de programação em lógica concorrente, pelo que programas escritos em linguagens de programação em lógica concorrente, como FGHC (Flat Guarded Horn Clauses), FCP, Parlog, Strand e PCN [Sha89], podem ser construidos de forma simples em ToonTalk. Reciprocamente, os programas em ToonTalk, embora construídos de forma interactive e animada, podem ser traduzidos para estas linguagens, em formas textuais equivalentes.

Escolhemos a programação concorrente por restrições como base global para o ToonTalk por vários motivos. Um deles é que ao longo de mais de dez anos de utilização, em muitos centros de investigação, ficou demonstrado que não há qualquer risco de que a linguagem seja inadequada à construção de uma grande variedade de programas grandes [Sha89]. As linguagens são pequenas, contudo muito poderosas. Estes factos fizeram com que a concepção do ToonTalk fosse muito mais simples do que se nos baseássemos nas linguagens convencionais.

Outro motivo para esta escolha é que estas linguagens são inerentemente concorrentes. Muitos consideram surpreendente que uma linguagem concorrente seja mais adequada às crianças do que uma linguagem sequencial. Têm a visão de que a programação sequencial já é suficientemente difícil, para ainda se ter que levar em linha de conta a existências de vários programas sequenciais interagindo entre si. Contudo, as linguagens sequenciais que foram expandidas por forma a tornarem-se concorrentes são muito complexas, enquanto que as linguagens concebidas de raiz como concorrentes conseguem ser muito elegantes.

Geralmente, os programas tentam modelar a realidade. E a realidade é concorrente. As linguagens de programação sequencial disponibilizam um mundo onde só pode ocorrer uma coisa de cada vez. Trata-se de um mundo muito estranho. As crianças, quando se lhes apresenta pela primeira vez a programação, particularmente a programação orientada a objectos, estão à espera que ela seja concorrente. A maioria dos programas que as crianças querem escrever são, por natureza, concorrentes. Um jogo de ténis, por exemplo, é composto – pelo menos – por uma raquete, uma bola e um marcador de pontuação. Uma boa concepção orientada a objectos indica que cada um destes elementos deve ser tratado por um componente computacional independente. As crianças (e a maioria das pessoas que não sejam programadoras, quando se lhes apresenta um sistema de programação orientada a objectos) estão à espera que cada objecto esteja permanentemente em execução. Como é estranho, ter de passar a atenção entre o controlo da raquete, da bola e da pontuação, em vez de simplesmente deixar que cada um faça o que tem a fazer! Mas o resultado será anárquico, a menos que os componentes possam comunicar e sincronizar-se. Tornar concorrentes as linguagens convencionais, com mecanismos de comunicação e sincronização, conduz a uma confusão de complexidade, que confere à programação concorrente a actual reputação de ser algo muito difícil. Uma linguagem nova, de programação concorrente, com uma concepção motivada para a obtenção de boa semântica, pode evitar esta confusão.

Resnick tentou introduzir o conceito de concorrência às crianças, expandindo a linguagem de programação Logo para suportar várias linhas de execução concorrentes [Res88]. As linguagem era muito complexa, mas a investigação confirmou que as linguagens de programação concorrentes são adequadas às crianças. Resnick também construiu uma forma paralela do Logo, chamada StarLogo, com a limitação – simplificadora mas grave – de que só era possível executar em paralelo cópias idênticas do mesmo programa. Recentemente, o MicroWorlds Logo da LCSI introduziu no Logo uma forma muito simples de paralelismo. Embora seja por vezes útil, é muito limitada quanto à capacidade de descrever a comunicação e sincronização entre actividades paralelas.

As actuais linguagens de programação visuais não bastam

Grande parte da investigação sobre linguagens de programação visuais tem objectivos idênticos aos desta obra. A ideia de base é que a utilização de imagens para representação de programas faz com que a programação seja fácil de aprender, além de originar programas de compreensão fácil. Provas caricatas indicam que linguagens visuais de programação poderosas, embora mais fáceis, continuam a ser de aprendizagem e domínio difíceis. Outras linguagens visuais possuem um âmbito ou capacidade expressiva limitados, mas são de aprendizagem e utilização fáceis (por exemplo, o KidSim [Smi94]).

Uma das deficiências da maioria dos sistemas de programação visuais é o facto de não animarem a execução dos programas – ou fazê-lo, mas sendo a animação não mais do que o realçar de algumas imagens. A maior parte dos sistemas que produzem efectivamente animações da execução dos programas começam por programas em texto com anotações (por exemplo, [Bro87]). O Pictorial Janus [KS90b] foi uma tentativa de remediar este problema, por via do suporte de visualizações completas do código-fonte e respectiva execução. Esta característica ajudou os utilizadores a compreender os próprios programas, bem como os programas de terceiros. Também facilitou a aprendizagem do modelo computacional subjacente. Mas isto não bastava. A aprendizagem levava algum tempo, estando o domínio da linguagem ao alcance apenas de utilizadores relativamente sofisticados (por exemplo, estudantes do ensino superior).

Em nossa opinião, é esta a dificuldade: para que uma imagem estática represente o comportamento dinâmico de um programa, tem de se apoiar num grande conjunto de codificações. O fluxo de controlo e de dados tem de ser codificado em diagramas abstractos. É possível afirmar, embora seja uma opinião discutível, que estes são de utilização mais fácil pelas pessoas, relativamente aos formalismos simbólicos; mas ainda assim, são muito difíceis. Porque não dar o passo seguinte no caminho que vem desde as linguagens de programação visuais estáticas, começando a utilizar imagens dinâmicas, ou seja, animações, para representar os processos dinâmicos de um programa?

Código-fonte animado

A ideia fundamental por trás do ToonTalk é que o código fonte seja animado. (Chama‑se ToonTalk, porque se está a "falar" por meio de bonecos, cartoons.) Isto não quer dizer que se vá pegar numa linguagem de programação visual e substituir alguns ícones estáticos por ícones animados. Significa que a animação é o meio pelo qual se comunica, tanto aos seres humanos como aos computadores, todo o significado dos programas. Enquanto que as vantagens do código-fonte animado são em grande número, a construção das animações é, regra geral, difícil e demorada. As boas ferramentas de criação de animações constituem uma boa ajuda, mas continua a ser muito mais difícil animar uma acção do que descrevê-la simbolicamente.

Felizmente, há um tipo de animação por computador que é de produção trival pelos utilizadores – a animação dos jogos de vídeo. Até mesmo crianças pequenas conseguem facilmente produzir um vasto conjunto de animações sofisticadas, quando brincam com jogos como o Mario Brothers. Embora este conjunto seja, evidentemente, muito limitado se comparado com o que permite uma ferramenta geral de criação de animações, a animação dos jogos de vídeo serve perfeitamente para o efeito em causa: comunicar programas aos computadores. Se, por exemplo, um pedaço de programa necessitar de trocar valores presentes em dois locais, nada mais natural e simples do que agarrar o conteúdo de um dos locais, pousá-lo, agarrar o conteúdo do outro, colocá-lo no primeiro local e depois colocar o primeiro objecto no segundo local. (Consulte a figura 1.) Este tipo de acção pode ser compreendido e executado por crianças muito novas, enquanto que a escrita do código que se segue, equivalente a estas acções, já só está ao alcance de um programador:

temp := x;

x := y;

y := temp;

Uma vez tomado o passo de utilizar a tecnologia dos jogos de video para construir código-fonte, é fácil ver outras formas de utilização desta tecnologia, para consultar, editar, executar e depurar programas. E há mais ideias dos jogos de vídeo em que nos podemos basear. Alguns jogos de video possuem personagens animados, cuja função é ajudar os utilizadores. Estes personagens pode assumir o papel de sistemas on-line de ajuda e iniciação.

Os jogos de vídeo, tal como a literatura e o cinema, devem a respectiva popularidade a momentos de “ausência de incredulidade". O participante humano aprecia ser conduzido pela fantasia subjacente. Um ecrã de ajuda, num jogo de video, ou uma cena desfocada, num filme, interferem no desfrutar desse prazer. A manutenção de uma fantasia coerente e ininterrupta é algo difícil. Por exemplo: quase todos os programas com interface de utilizador gráfica suportam várias teclas de atalho. O acrescento directo de teclas de atalho a um sistema como o ToonTalk iria interferir nesta ausência de incredulidade. Para resolver esta questão, transformámos todas as ferramentas em personagens de desenhos animados. Por exemplo: há um aspirador portátil no ToonTalk, para eliminar coisas. Normalmente, usa-se deslocando a mão do personagem programador por cima dele, agarrando-o, deslocando-o para cima do item que se deseja eliminar e, então, clicando no botão que liga o aspirador. Basta carregar numa tecla de atalho para obter o mesmo resultado de forma mais rápida, mas como pode tal método funcionar sem interferir na fantasia sujbacente? Como o aspirador é uma personagem animada, a história que o sistema apresenta é a de que a tecla de atalho não é mais do que uma forma de assobiar, para que o aspirador venha a correr para a mão.

Figura 1 – Instantâneos da troca de dois elementos

ToonTalk – a linguagem e a metáfora

Os jogos de vídeo, particularmente os de aventura e de personagens, colocam o utilizador num universo artificial. As leis destes universos são concebidas por forma a respeitar as limitações das formas de jogar, aprender e entreter. Ao jogar estes jogos, o utilizador aprende se há ou não gravidade, se as portas têm de ser abertas com chaves, se a constituição física pode ser restaurada obtendo e ingerindo ervas, etc. E se as leis do universo de jogo fossem concebidas para permitir computação genérica, além de irem ao encontro das limitações de um bom ambiente de jogo?

Ao que parece, nunca ninguém o tentou. (E quando descobrimos como faze-lo, solicitámos o registo de patente da invenção.) Rocky's Boots e Robot Odyssey foram dois jogos da The Learning Company, do início dos anos 80, que entusiasmaram muitos investigadores da informática. Nestes jogos, é possível construir circuitos lógicos à vontade do utilizador, utilizando-os para programar robôs. Tudo se passa no contexto de um jogo de vídeo. O personagem do utilizador, no jogo, pode explorar uma cidade com auxiliares robóticos. Frequentemente, para poder continuar, o utilizador tem de construir (de forma animada e interactiva) um circuito lógico para os robôs, para resolver um problema que tenha em mãos. O ToonTalk leva ao extremo as ideias subjacentes ao Robot Odyssey, dando suporte a computações genéricas por parte dos utilizadores (não apenas as computações em lógica de Boole do Robot Odyssey).

Já foi feita muita investigação acerca de sistemas demonstrativos ou de programação por exemplo. O primeiro foi possivelmente o Pygmalion, construído em meados dos anos 70 por David Canfield Smith, como parte da sua tese de doutoramento [Smi75]. Inclusivamente, David Smith fala dos programas como sendo "filmes". Mas não havia nada que se assemelhasse a um mundo de jogo animado onde o programador pudesse trabalhar. Como alternativa, era possível seleccionar ícones e menus, bem como gerar ícones que representassem uma sequência de selecções.

Os investigadores da informática almejam encontrar boas abstracções para a computação. Aqui, para além disto, procuramos encontrar boas "concretizações" dessas abstracções. O desafio é duplo: disponibilizar objectos de alto nível, para expressão de programas, e disponibilizar sistematicamente no jogo elementos análogos a estes objectos, mas que sejam concretos, intuitivos e fáceis de aprender. Afinal de contas, uma máquina de Turing é simultaneamente algo concreto e um formalismo universal da computação. (Alan Turing procurava não apenas formalismos matemáticos da computação, mas também elementos análogos concretos.) Pode-se imaginar um jogo de máquina de Turing no qual, teoricamente, se suporte a construção de construções arbitrárias, mas não consigo conceber a utilização de tal jogo na concepção de programas reais.

O mundo do ToonTalk assemelha-se a uma cidade do século vinte. Há helicópteros, camiões, casas, ruas, bombas de dar ar, caixas de ferramentas, aspiradores portáteis, caixas e robôs. A vida animal limita-se aos pássaros e repsectivos ninhos. Este é apenas um tema coerente, de muitos que poderiam servir de base a um sistema de programação como o ToonTalk. Um tema espacial, com naves vaivém, teletransportadores, etc., também funcionava perfeitamente. Assim como um tema medieval com magia, ou um baseado na história da Alice no País das Maravilhas.

Uma computação completa em ToonTalk é uma cidade. A maior parte da acção decorre dentro das casas da cidade. A comunicação entre casas (e entre características embutidas) é obtida por intermédio de pássaros (semelhantes a pombos-correio). Os pássaros aceitam coisas, voam para os seus ninhos, deixam-nas lá e regressam. Normalmente, as casas contêm robôs, treinados para desempenhar tarefas simples. Os robôs têm balões de pensamento, com imagens do estado local necessário à execução da tarefa de cada um. O estado local é guardado em buracos em forma de paralelipípedos (ou seja, caixas). Estas caixas também são utilizadas para mensagens e dados combinados (ou seja, tuplos). Se um robô receber uma caixa com tudo o que está no balão de pensamento, inicia a repetição das acções que lhe foram ensinadas. A abrstração é introduzida por via do seguinte facto: a imagem no balão de pensamento pode não ser completa, mas ainda assim corresponder ao que o robô recebe. Os robôs correspondem, aproximadamente, aos métodos ou condições das linguagens orientadas a objectos. Uma linha de robôs representa algo como a construção "if then else" (se/então/senão). Há balanças animadas que podem ser colocadas nos compartimentos das caixas. Os pratos inclinam-se para o lado onde o conteúdo do compartimento vizinho seja maior (ou no caso do texto, que se siga na ordem alfabética) do que o conteúdo do compartimento do lado oposto. Colocando balanças com pratos inclinados para um dos lados, as condições podem incorporar “maior que” e “menor que”. (Mais à frente são apresentados exemplos de utilização destas concretizações.)

A sincronização é conseguida no ToonTalk, pelo facto de que se um robô receber uma caixa, estando no balão de pensamento objectos ausentes da caixa, ele pára até que esses objectos apareçam. Mais concretamente: um buraco vazio pode ser preenchido, e um ninho num buraco pode ser coberto por um objecto trazido por um pássaro. Se o robô quer receber um tipo de caixa específico (por exemplo, uma caixa com o número zero), estando na caixa um objecto diferente (por exemplo, o número um), então este robô passa a caixa para o robô seguinte em linha.

O comportamento de um robô é exactamente aquele que o programador o treinou para ter. Este treino corresponde, em termos tradicionais, à definição do corpo de um método ou condição. As acções possíveis são:

enviar uma mensagem, dando uma caixa ou tábua a um pássaro;

gerar um novo agente, largando uma caixa e uma equipa de robôs num camião (que se mete em marcha para construir uma nova casa);

realizar operações simples de primitivas, como adição, multiplicação ou construir uma pilha de números (que são combinados por um ratinho com uma grande marreta);

copiar um item, usando uma varinha mágica;

exterminar um agente, accionando uma bomba;

alterar um tuplo, tirando itens dos compartimentos da caixa e largando-lhes novos itens.

Estas acções correspondem às que são admissíveis para os actores ou agentes de programação em lógica concorrente [KS90a, Agh87]. A última dela pode aparentar, aos investigadores da informática, estar a introduzir na linguagem estruturas de dados mutáveis, que se sabe serem fonte de imensa complexidade nos programas paralelos. Contudo, visto que as caixas são copiadas, nunca partilhadas, tal não se verifica. O que parece ser uma operação destrutiva numa cópia privada é, semanticamente, equivalente à construição do resultado final a partir do nada. Mas geralmente é mais conveniente realizar a operação destrutiva. Nas situações em que a cópia desnecessária de caixas introduziria uma sobrecarga de processamento, pode-se construir uma casa para guardar uma cópia única, obtendo-se a partilha por meio da cópia de pássaros, que transmitem pedidos para essa casa.

Quando o utilizador controla o robô que desempenha estas acções, está a agir sobre valores concretos. Está-se numa situação com muitos pontos em comum com a programação de macros de teclado e com a programação por exemplos [Smi75]. O problema de difícil resolução para os sistemas de programação por exemplos é a forma de introduzir abstração nos exemplos, introduzindo variáveis genéricas. O ToonTalk não recorre a indução ou aprendizagem. Em seu lugar, o utilizador realiza explicitamente a abstração de um fragmento do programa, retirando pormenores do balão de pensamento. Desta forma, as pré-condições são relaxadas. As acções realizadas no corpo são genéricas, visto que foram gravadas relativamente ao comportamento da caixa sobre o qual se agiu, não relativamente aos objectos que se pudessem encontrar na caixa.

Se um utilizador nunca desligasse o computador nem quisesse partilhar um programa com outro, este mundo de casas e robôs estaria adequado. Para possibilitar o armazenamento permanente, incluímos cadernos no ToonTalk. Um programador pode utilizar os cadernos para armazenar qualquer coisa que tenha construído. Os cadernos podem conter outros cadernos, por forma a disponibilizar um sistema de armazenamento hierárquico. Por meio dos cadernos, é disponibilizada uma interface para a funcionalidade essencial do sistema de ficheiros, sem sair da metáfora do ToonTalk. O caderno inicial contém exemplos de programas e pontos de acesso a funcionalidades como a animação e os sons.

É possível compreender o ToonTalk por si só. Por exemplo: um pássaro, ao receber alguma coisa, voa para o seu ninho, deixa-a lá e regressa. Geralmente, é assim que as crianças compreendem o ToonTalk. Contudo, os investigadores da informática podem ter interesse em compreender a relação entre a computação e estes objectos e actividades do ToonTalk. Apresenta-se de seguida uma tabela de associação entre abstracções computacionais e as concretizações do ToonTalk:

Abstracção computacional	ToonTalk
computação	cidade
agente (ou actor, processo ou objecto)	casa
métodos (ou condições ou fragmentos de programas)	robôs (com balões de pensamento)
pré-condições dos métodos	conteúdo dos balões de pensamento
acções dos métodos	acções ensinadas aos robôs dentro do balão de pensamento
comparações	balanças
geração de agentes	camiões carregados
eliminação de agentes	bombas
constantes	tábuas com números ou texto, imagens
capacidades de transmissão por canais	pássaros
capacidades de recepção por canais	ninhos
armazenamento de programas	cadernos

Para além da linguagem de programação

A linguagem de programação Logo é mais do que uma versão de engenharia infantil do Lisp, incluindo também os gráficos de tartaruga. Apesar do Logo ser por vezes utilizado para computação com números e texto, a atracção principal que possui foi sempre o pacote de gráficos de tartaruga. Embora os gráficos de tartaruga continuem a ser uma atracção, tendo muitas das implentações modernas do Logo expandido a ideia, possibilitando a existência de várias tartarugas com imagens diferentes, não atraem tanto as crianças como a programação de jogos. Embora seja possível programar jogos com os gráficos de tartaruga, é difícil.

O ToonTalk, presentemente, não suporta gráficos de tartaruga – em seu lugar, realizouse um esforço de disponibilização de suporte para a programação de jogos. O nível base de suporte é uma interface de transmissão de mensagens para uma biblioteca de bonecos. Por “bonecos” pretendemos indicar elementos gráficos animados, utilizados para construir jogos. O boneco Mario é deste tipo, assim como os cogumelos que ele pode comer, etc. O aspecto de um boneco é seleccionado a partir de um conjunto de ciclos de animação. As alterações ao tamanho e localização de um boneco também podem ser animadas. É disponibilizado um mecanismo de detecção e acção sobre colisões entre bonecos. Uma interface do ToonTalk para transmissão de mensagens sobre esta funcionalidade permite obter o pássaro correspondente a um boneco, e dar-lhe mensagens com significados tão diversos como "anda para cima 10 unidades", "muda para o tamanho 20", "põe a velocidade a 30" ou "estás a colidir em alguém?". Esta interface é muito genérica e poderosa, mas acabou por se constatar ser uma forma demasiado desagradável e confusa de realizar acções simples.

Para além da interface de transmissão de mensagens, o ToonTalk disponibiliza o controlo directo dos bonecos: estes podem ser virados de costas. Inicialmente, na parte de trás só está um caderno com os controlos remotos do boneco. Neste caderno pode-se encontrar, por exemplo, o controlo da largura. Alterando a largura do boneco, o número no controlo também se altera. O utilizador pode alterar directamente o valor deste controlo, que a largura do boneco é alterada imediatamente. Actualmente existem controlos remotos para a posição, velocidade e tamanho, para detecção de colisões e para selecção do aspecto dos bonecos.

Podemos treinar um robô para, por exemplo, incrementar repetidamente um número, colocando-o depois a trabalhar sobre a velocidade de um boneco, pelo que o boneco acelera. Podemos colocar este robô e o controlo remoto de velocidade nas costas de uma imagem e desvirá-la. Se, posteriormente, esta imagem for copiada ou guardada num caderno, quando lá a formos buscar ainda mantém o comportamento de aceleração, activo, nas costas. Esta característica possibilita a construção de bibliotecas recheadas de comportamentos úteis para bonecos, como fazer ricochete em paredes ou seguir o movimento do rato. Para compor bonecos, basta colocá-los uns sobre os outros. (Para os voltar a separar é necessário utilizar o aspirador portátil.) Os comportamentos podem ser copiados e combinados directamente.

Actualmente, os robôs e as caixas são colocados, simplesmente, nas costas das imagens. Em breve, os utilizadores poderão construir uma cidade inteira nas costas de qualquer boneco. Esta estrutura dá suporte a comportamentos complexos e dinâmicos por parte dos objectos. A metáfora de cidades nas costas dos objectos é, possivelmente, estranha; até talvez mesmo incoerente num tema do século vinte, mas adequa-se bem à semântica, deve ser fácil de aprender e de utilizar, e pode ser divertida (imaginem-se cidades que estão dentro de cidades que estão dentro doutras cidades, que...).

Para além dos gráficos de tartaruga, muitas das implementações do Logo incorporam bibliotecas para controlo de motores e sensores para as construções da Lego, Fisher Technic ou Capsula [Pap93]. Estas permitem às crianças construir brinquedos com comportamentos. Há crianças que constroiem robôs, carros que seguem uma linha traçada no chão, electrodomésticos como máquinas de lavar roupa de brinquedo (que páram quando se abre a porta), semáforos que mudam de cor e respondem ao accionamento de um botão para peões...

Tal como o LegoLogo, o ToonTalk disponibiliza uma interface para ligar e desligar motores e luzes, e ler sensores. A interface é idêntica à dos controlos remotos dos bonecos. É possível obter um controlo remoto para um motor (por exemplo) e utilizá-lo como qualquer outro número. Se o valor for definido a, por exemplo, 5, o motor liga-se e o nível de potência é colocado a 5. Se for dado a um robô treinado para adicionar repetidamente o número 1 a outro número, o motor começa a acelerar. Da mesma forma, há sensores no ToonTalk, que são números em actualização constante, por forma a mostrar o estado do sensor Lego que lhe corresponde. É também desta forma que o ToonTalk lida com outros dispositivos de entrada, como o rato do computador.

Embora a nossa experiência no controlo de aparelhos em Lego com o ToonTalk seja reduzida, parece indicar que a concorrência subjacente ao ToonTalk permite um controlo muito mais modular do que o que é possível com o Logo. Uma casa do ToonTalk pode ser construída contendo robôs para controlar um semáforo, outra para controlar o carro que pára no vermelho, etc. Por oposição, no Logo um programa sequencial tem de alternar a atenção entre os vários elementos. Também a transição entre a manipulação directa e a manipulação pelo programa é muito fácil de se fazer no ToonTalk.

Ferramentas do ToonTalk

Era necessário que o ToonTalk disponibilizasse ao utilizador as possibilidades de copiar, remover e restaurar itens, bem como a possibilidade de lhes alterar o tamanho. A concepção inicial recorria para o efeito a três varinhas mágicas, que se distinguiam visualmente, para as várias funções, pela cor e por efeitos de animação abstractos. Em vez de utilizar uma varinha para cada uma das cinco funções, foram concentradas numa ferramenta funções opostas. A varinha de remoção de objectos também conseguia restaurar objectos que tinham sido removidos. Outra varinha conseguia tanto aumentar como encolher os objectos.


Varinha de copiar	Varinha de aumentar e encolher	Varinha de tirar e pôr

Figura 2 – Primeira versão: 3 varinhas mágicas

Estudos preliminares de utilização revelaram que este método não era óbvio, levando os utilizadores a confundir as varinhas, apesar das cores e da animação. Para que os utilizadores adivinhassem mais facilmente a função de cada ferramenta, mas também para lhes permitir distingui-las mais facilmente, substituí a varinha de alterar tamanhos por uma bomba de dar ar às bicicletas. Substituí a varinha de remover e restaurar por um aspirador portátil.

Podia igualmente ter substituído a varinha de copiar por várias metáforas, como uma fotocopiadora ou uma câmara instantânea. Contudo, a fotocopiadora não se adequava muito bem: as outras ferramentas são utilizadas agarrando nelas, enquanto que uma fotocopiadora é estacionária, sendo necessário levar-lhe os originais a copiar. Além disto, uma fotocopiadora ou câmara, como metáforas, podem implicar que o resultado não é uma cópia funcional, mas uma imagem do item original. A desvantagem da utilização de uma varinha mágica para copiar coisas é ser difícil adivinhar a função desta a partir do aspecto, além de não se enquadrar no tema, como as bombas e os aspiradores. Para suavizar o problema, deu-se à varinha o aspecto das varinhas utilizadas habitualmente pelos ilusionistas do século vinte.

Nova varinha de copiar

Bomba de dar ar Aspirador portátil

(substitui a varinha de aumentar e encolher) (substitui a varinha de pôr e tirar)

Figura 3 – Versão actual: varinha mágica, bomba de dar ar e aspirador manual

Esta nova concepção também permite uma dualidade ferramenta/personagem. No ToonTalk, a bomba de dar ar e o aspirador não são apenas objectos inertes que se utilizam: podem transformar-se em personagens animados, com capacidade para agir por si próprios. (vd. as figuras 3 e 4.) Uma vantagem dos personagens animados é que estes podem afastar-se quando não são precisos, regressando quando fazem falta. Também contribuem para aumentar o divertimento, atracção e aspecto das ferramentas. Estas metamorfoseiam-se para os respectivos estados inertes quando não estão a ser usadas, evitando assim distrair o utilizador. Esta dualidade entre objecto e personagem também funcionou bem com a caixa de ferramentas e os cadernos do ToonTalk. A dualidade é uma fantasia divertida, explorada com grande sucesso em filmes como A Bela e o Monstro, da Disney.

Figura 4 – A bomba de dar ar e o aspirador, sob a forma de personagens animados

Comunicação no ToonTalk

O conceito original do ToonTalk para comunicação entre robôs espelhava os correios, com caixas de correio, transportades postais e endereços de remetente. Mas a ligação semântica era fraca, pois a comunicação no ToonTalk permite comunicação da capacidade de enviar ou receber mensagens. E os endereços de reencaminhamento apenas conseguem dar resposta parcial a esta situação. Avaliei muitas outras possibilidades, incluindo jangadas em rios, faxes, correio electrónico e papéis mágicos, antes de me decidir por pássaros (parecidos com pombos-correios) e ninhos.

Além de a adequação semântica ser perfeita, a concepção geral com pássaros e ninhos vai de encontro a outros critérios: facilidade de aprendizagem e utilização, serem divertidos e atraentes, e coerência geral com o tema da cidade. Até crianças bastante novas têm facilidade em compreender que quando se dá alguma coisa a um pássaro este leva isso para o ninho e volta. Até se pode fazer um pássaro entregar uma caixa com outro pássaro ou um ninho.

Figura 5 – Um pássaro entrega uma caixa (com um ninho) ao seu próprio ninho

Aritmética no ToonTalk

Pode-nos parecer óbvia uma metáfora do ToonTalk para operações aritméticas – dar ao utilizador uma calculadora virtual. De facto, tal esteve planeado durante algum tempo. Embora uma calculadora seja algo comum, pelo que deveria ser fácil de aprender e utilizar, não se adapta bem ao que é habitual no ToonTalk para cálculo com números já existentes. Considere-se o utilizador que precisa de adicionar dois números. O utilizador poderia largar um número na calculadora para o introduzir, carregar no botão "+" e largar o segundo número, carregar no botão '=' e copiar o número resultante. No geral, um processo desagradável e pouco divertido.

Avaliámos várias alternativas, entre as quais a adição por empilhamento e a multiplicação utilizando a varinha de copiar para fazer "n" cópias. Embora sejam atraentes do ponto de vista pedagógico, torna-se complicado abranger todas as operações comuns (divisão, por exemplo) e ainda trabalhar com valores não-inteiros.

A aritmética no ToonTalk é actualmente executada por um rato com uma grande marreta. Quando se coloca um número em cima de outro, o rato vem a correr e esmaga-os um contra o outro, restando apenas a soma. Caso se coloque em cima "x5", o rato multiplica por cinco o número que está por baixo. Seguindo este método são disponibilizadas todas as operações aritméticas normais. O trabalho com crianças veio mostrar que esta funcionalidade é fácil de aprender e utilizar, e que elas a consideram divertida e atraente. Outro benefício deste método é que pode ser generalizado para o texto (largar texto sobre texto produz uma concatenação) e para as imagens (largar imagens sobre imagens produz grupos compostos).

Figura 6 – Um rato a executar 1+2

Construção de um jogo de pingue-pongue no ToonTalk

Numa tentativa de possibilitar uma compreensão mais pormenorizada do ToonTalk, considere-se que uma criança quer construir do zero um jogo parecido com o pingue-pongue. (De seguida, tenta-se descrever por palavras uma experiência animada interactiva. Grande parte da complexidade é aparente, desaparecendo quando esta matéria é apresentada sob a forma de demonstração. A actual versão beta do ToonTalk contém uma demonstração, que inclui um diálogo imaginário entre duas crianças, à medida que tentam construir um jogo de pingue-pongue. Ao contrário do cenário que se apresenta de seguida, os processos de exploração, depuração e experimentação, durante a construção do jogo de ténis, são também representados. Os leitores que o desejem podem contactar o autor para obter uma cópia da versão beta do ToonTalk.)

Inicia-se o ToonTalk, encontrando-se o utilizador num helicóptero, a sobrevoar uma cidade. Conseguem-se ver casas, lá em baixo.

Figura 7 – O programador a voar sobre as casas

O utilizador pousa em frente a uma casa, na qual entre pela porta da frente. É seguido para toda a parte por uma personagem em forma de caixa de ferramentas.

Figura 8 – O programador e a caixa de ferramentas, na rua

No interior, está um marciano amigável, pronto a disponibilizar visitas guiadas ou conselhos, mas o utilizador ignora-o, pois já utlilizou o sistema algumas vezes e acha-se capaz de construir sozinho um jogo de pingue-pongue simples.

Figura 9 – O programador e a caixa de ferramentas, dentro da casa

O programador senta-se no chão, vindo a caixa de ferramentas a correr para a frente dele, onde se abre. Um caderno voa de lá de dentro. Um aspirador portátil com pernas sai de lá a correr. Uma bomba de dar ar salta para fora. E uma varinha mágica sai a flutuar. Ficam na caixa de ferramentas oito tipos de coisas, que o programador pode usar para construir o jogo: placas com números, placas com texto, caixas, ninhos, balanças, robôs, camiões e bombas.

Figura 10 – Aspecto do chão, depois de se sentar

Para construir o programa da raquete, começa-se por folhear o caderno que está no ecrã, até encontrar uma imagem boa para a raquete. Pega-se nela, obtendo assim uma cópia. O plano, neste momento, é criar um painel de controlo para a raquete, que apresente a velocidade vertical da raquete e a velocidade vertical do rato. Pretende-se colocar um robô nas costas da raquete, que copie continuamente a velocidade vertical do rato para a raquete. Começa-se por virar a raquete. Nas costas, está um caderno cheio de controlos remotos. Folheando-o, encontra-se o controlo remoto da velocidade vertical. Pega-se nele, colocando no chão a cópia que assim se obtém. Volta-se ao caderno inicial, que se folheia até se encontrar um outro caderno, com sensores. Um deles, descobre-se, é relativo à velocidade vertical do rato. Larga-se este junto ao anterior, com a velocidade vertical da raquete, ficando as duas caixas juntas, sob a forma de uma caixa com dois compartimentos. Então, tira-se um robô da caixa de ferramentas e dá-se-lhe esta caixa recém-construída. Como o robô ainda não foi treinado, não sabe o que há-de fazer. Aparece então uma cópia da caixa no balão de pensamento do robô, sendo apresentada uma animação que mostra o robô a entrar para dentro do balão de pensamento (consultar a figura 11).

Figura 11 – Momentos seguintes à construção de uma caixa de controlo da raquete

Neste momento, o programador está a controlar o robô, para o treinar dentro do balão de pensamento. Como só se quer que a raquete siga os movimentos verticais do rato, faz-se com que o robô pegue na varinha de copiar, copia-se a velocidade do rato, escreve-se "=" e larga-se o resultado no compartimento que tem a velocidade vertical da raquete (consulte a figura 12).

Figura 12 -- Ensinar o robô a fazer com que a raquete imite os movimentos verticais do rato

Carrega-se num botão, para indicar que já se acabou de treinar o robô, voltando o ecrã a mostrar o que está no chão, e o programador encontra-se novamente a controlar a mão que aparece no ecrã. Geralmente, após treinar um robô, é necessário utilizar o aspirador manual para tornar abstractos os valores particulares que estão no balão de pensamento, que ficam vazios, indicando que qualquer valor é aceitável. Quando são colocados no balão de pensamento número constituídos por controlos remotos, o ToonTalk faz este passo automaticamente, visto que os valores particulares não interessam, por se alterarem dinamicamente. (Assemelham-se mais a mostradores do que a constantes.)

Larga-se então o robô nas constas da raquete. Volta-se a dar a caixa ao robô. Desvira-se a imagem. O robô está agora a ser executado nas costas da raquete. Em cada momento, copia a velocidade vertical do rato para a raquete. Experimentando, a raquete move-se agora para cima e para baixo, seguindo o movimento do rato, e ignora os movimentos horizontais. Estando o programador satisfeito com o resultado, larga a raquete no caderno, para aí ficar guardada até mais tarde. (Encontra-se agora no disco rígido, onde permanence ainda que o computador falhe.)

A atenção do programador centra-se agora na bola. Pretende-se que a bola ressalte em todos os objectos com os quais colida. Vira-se a imagem da bola, obtendo assim o respectivo caderno. Primeiro, o programador centra-se no movimento horizontal. Prepara-se uma caixa que contém um detector de colisões e um controlo remoto com a velocidade horizontal. Dá-se esta caixa a um robô novo, que é treinado na multiplicação da velocidade por -1.

Figura 13 – Treino de robôs para os ressaltos da bola

O robô é colocado, juntamente com a caixa respectiva, nas costas da bola, sendo testado, verificando-se que a bola ressalta quando se desloca para a direita ou para a esquerda. O robô é copiado, recebendo uma caixa semelhante, com os controlos de movimento vertical. O novo robô é também testado, ficando o programador satisfeito com os ressaltos. Outro robô é treinado, por forma a emitir um som sempre que ocorre uma colisão.

O programador pega num rectângulo, para pano de fundo do jogo, colocando nele três rectângulos, que funcionam como paredes superior, inferior e direita, nas quais a bola irá ressaltar. Acrescenta-se a raquete e lança-se a bola (mantendo premida uma tecla modificadora quando se solta a bola). O programador joga o novo jogo, que funciona bem, à parte o facto de que quando não se acerta na bola esta continua a andar para a esquerda, sem parar. Com as balanças, treina-se um robô para agir sempre que a posição horizontal for inferior a zero. O robô faz um som diferente e repõe a bola na area direita do rectângulo de jogo.

Figura 14 – Acrescentar outra bola ao jogo da raquete

Joga-se com o jogo um bocado, largando-o depois como um todo no caderno, para ficar guardado. De seguida, volta-se a tirar, colocando-lhe outra bola, para ficar mais difícil (consulte a figura 14). Como fica demasiado difícil, o programador larga-lhe em cima também outra raquete. Começa-se então a ponderar a forma de acrescentar um marcador de pontuação, mas também a pensar numa forma de transformar o jogo de pingue-pongue num jogo de derrubar blocos, utilizando os blocos explosivos que um outro colega programador contruiu no dia anterior.

Resumo e planos para o futuro

Apresentámos aquilo que cremos ser o primeiro sistema com suporte para código-fonte animado e que utiliza tecnologia dos jogos de vídeo, como base de suporte à programação genérica. Desde Novembro de 1995, o ToonTalk possui versões funcionais de todos os elementos aqui descritos. O personagem marciano está funcional como orientador e sistema de ajuda, mas ainda não funciona como professor.

Os testes do ToonTalk numa turma da 4ª classe e em algumas famílias iniciaram-se em Janeiro de 1995. Mais de 40 crianças brincaram com o ToonTalk durante aproximadamente uma hora. Uma constatação encorajadora, que se retirou desta utilização informal pelas crianças, foi que se verificou algum sucesso do ToonTalk como forma divertida de construir programas. As crianças gostam de brincar com os pássaros, o aspirador portátil, a bomba de dar ar e a varinha mágica, gostam de ver as casas a ser construídas e destruídas, de voar no helicóptero, etc. Isto apesar de não estarem a construir nenhum programa útil. Actualmente é ainda demasiado cedo para avaliar qualitativamente a capacidade das crianças construirem programas com o ToonTalk, mas é muito encorajante saber que elas consideram que brincar, simplesmente, com o equivalente a um editor de programas, é muito divertido.

A realização de testes em pequena escala mostrou que embora as crianças dominem facilmente os objectos e ferramentas do ToonTalk (ou seja, as "primitivas" da linguagem de programação), necessitam de orientação para poder avançar. O sistema está actualmente a ser melhorado, incorporando exemplos, demonstrações, folhas de instruções e uma iniciação interactiva, para lhes permitir avançar por si.

A primeira versão foi feita para computadores compatíveis PC, com o Microsoft Windows. Não deve ser difícil transportar o sistema para o Macintosh.

É possível imaginar, com alguma facilidade, variantes do ToonTalk. Um versão do ToonTalk em realidade virtual permitir-nos-ia construir programas dentro da realidade virtual. Visto que o ToonTalk foi construído sobre bases concorrenciais, uma versão por modem ou via rede seria uma extensão perfeitamente natural. Podem-se desenvolver jogos para muitos utilizadores, além de ser possível a vários programadores trabalhar em conjunto no mesmo mundo. Penso, frequentemente, no aspecto que teria uma versão profissional do ToonTalk. Um compilador poderia expandir o interpretador do sistema, fazendo com que os programas mais ambiciosos fossem muito mais rápidos e compactos.

O ToonTalk é um autêntico ambiente de programação – contudo, não está dependente de um teclado. É útil ter um teclado para recorrer a aceleradores, mas é possível utilizá-lo apenas com um controlador de jogos, um joystick ou um rato. Esta característica abre a possibilidade de transportar o ambiente para uma máquina de jogos. Emociona-nos a possibilidade de ter milhões de crianças por esse mundo fora, com uma máquina de jogos em casa, a utilizar o ToonTalk para criar os seus próprios jogos e fazer autêntica programação.

Agradecimentos. Agradeço imensamente a ajuda, conselhos e apoio que recebi de muitas pessoas durante este projecto. Em particular a David Kahn, Mary Dalrymple e Markus Fromherz, que merecem agradecimentos especiais por toda a ajuda que me prestaram. Igualmente grandes agradecimentos seguem para Ruth Colton e a sua turma da 4ª classe. Agradeço igualmente imenso a Greg Savoia pelos belos desenhos e animações com que contribuiu para o ToonTalk.

Referências

[Agh87] G. Agha, Actors: A Model for Concurrent Computation in Distributed Systems. The MIT Press, 1987.

[Bec93] Henry Becker, Teaching with and about computers in Secondary Schools, Communications of the ACM, Maio de 1993, Vol. 36, N.º 3

[Bro87] Marc H. Brown. Algorithm Animation. The MIT Press, 1987.

[KS90a] Kenneth Kahn e Vijay Saraswat. Actors as a special case of concurrent constraint programming. Em Proceedings of the Joint Conference on Object-Oriented Programming: Systems, Languages, and Applications and the European Conference on Object-Oriented Programming. ACM Press, Outubro de 1990.

[KS90b] Kenneth M. Kahn e Vijay A. Saraswat. Complete visualizations of concurrent programs and their executions. Em Proceedings of the IEEE Visual Language Workshop, Outubro de 1990.

[Mal80] Thomas Malone. What Makes Things Fun to Learn? -- A Study of Intrinsically Motivating Computer Games, Tese de doutoramento do Departamento de Psicologia da Stanford University, 1980.

[Pap77] Seymour Papert. Apresentação em Agosto de 1977, na Logo Users Meeting, MIT.

[Pap93] Seymour Papert. Children's Machines. Basic Books, 1993.

[Pro91] Eugene Provenzo, Video Kids – Making Sense of Nintendo, Harvard University Press, Cambridge, Ma. 1991.

[Res88] Mitchell Resnick. Multilogo: A study of children and concurrent programming. Relatório técnico, MIT Media Lab, 1988.

[SKL90] Vijay A. Saraswat, Kenneth Kahn e Jacob Levy. Janus – A step towards distributed constraint programming. Em Proceedings of the North American Logic Programming Conference. MIT Press, Outubro de 1990.

[Sar93] Vijay A. Saraswat. Concurrent constraint programming languages. Doctoral Dissertation Award and Logic Programming Series. MIT Press, 1993.

[Sha89] Ehud Shapiro. The family of concurrent logic programming languages. ACM Computing Surveys, 1989.

[Smi75] David Smith, Pygmalion: A Creative Programming Environment, Stanford University, relatório técnico de Computer Science, n.º STAN-CS-75-499, Junho de 1975.

[Smi94] David Smith, Allen Cypher e Jim Spohrer, KidSim: Programming Agents without a Programming Language, Communications of the ACM, Vol. 37, n.º 7, Julho de 1994.

[Yod94] Sharon Yoder, Discouraged?.. Don't Dispair! [sic], Logo Exchange, Vol 12, n.º 4, Verão de 1994, Revista do Special Interest Group do ISTE para educadores que usam Logo.