PARTE 1 PARTE 2 PARTE 3 PARTE 4 PARTE 5

O Logo é uma tecnologia obsoleta?

Esta é uma discussão que foi mantida na comp.lang.logo (e na correspondente lista de discussão por e-mail de 16 de novembro a 2 de dezembro, em 1998. A discussão foi intitulada "O Logo é uma tecnologia obsoleta?"

De Ken Kahn:

"Minhas prioridades: 1. Dar aos estudantes oportunidades ricas e variadas para expressar seus pensamentos verbal, visual, auditiva e cinestesicamente."

Eu creio que esta é uma idéia muito excitante a ser perseguida. Nesta discussão eu tenho enfatizado a natureza animada/visual do ToonTalk. Estas outras modalidades sensoriais são importantes e eu tenho seguido nessa direção. O ToonTalk faz um uso pesado de efeitos sonoros. Ainda mais interessante, ele usa ao mesmo tempo voz gravada e um dispositivo texto- narração. Se você tiver um joystick com tecnologia "force-feedback" ( custam cerca de 100 dólares, por estes dias), então quando você utilizar o ToonTalk você sentirá as vibrações do motor do helicóptero, ou da parede quando entrar no recinto, ou o peso de alguma coisa em sua mão. Nos próximos 9 meses, eu planejo integrar entrada de sons (fala) no Toon Talk.

Talvez não seja necessário dizê-lo para esta audiência, mas estas modalidades deveriam estar disponíveis para que as crianças as utilizassem em suas próprias criações. Por exemplo, o ToonTalk não utiliza apenas o force-feedback mas dá às crianças a opção de incluir efeitos de força em seus próprios programas. Idem para efeitos sonoros e texto- narração. E entrada de sons(fala) quando estiver pronta.

Eu não reivindico ter as respostas para como usar da melhor forma e integrar essas variadas modalidades. É um espaço para a pesquisa básica, assim como uma variedade de esforços de planejamento, para explorar estas questões.

Saudações,
- Ken Kahn

De Ken Kahn:

Wen Su escreveu:
"Expressar seus pensamentos verbalmente, utilizando computadores, não é ainda muito diferente de utilizar lápis e papéis, como nossa geração anterior fazia."

Bastante verdadeiro. O lápis é uma "impressora de qualidade de letra". E a expressão visual em um computador não é profundamente diferente de pintar ou desenhar. Eu não desejaria abandonar o lápis e o pincel pelo computador. Os estudantes se beneficiariam pela exposição a todas estas ferramentas, eu suponho.

"Eu hesito em ser `do contra´ aqui. Mas embora seja muito bom fornecer aos estudantes uma ferramenta de construção multimídia de forma que eles possam expressar seus pensamentos através destas novas ferramentas multimídia, muitas ferramentas atuais não são ainda simples o bastante para serem utilizadas por jovens (ou mesmo por adultos)."

Novamente verdadeiro... como também para o lápis e o pincel. Apenas pergunte a um estudante se o que ele está escrevendo é fácil. Tente apenas pintar uma imagem e obtê-la do jeito que deseja.

Tom Woods

Ken Kahn escreveu:

"Nesta discussão eu tenho enfatizado a natureza animada/visual do ToonTalk. Estas outras modalidades sensoriais são importantes..."

AGORA você está dizendo que quando tiver a narração funcionando, você terá o equivalente de texto também? Isto seria extremamente benéfico para novos e emergentes leitores que freqüentemente começam lendo palavras que eles mesmos escreveram ou falaram. Você pode estar fazendo algo importante.


Tom Woods


Ken Kahn escreveu:

Eu concordo que a maioria das pessoas aprecia o que elas já conhecem. Isto pode significar que os professores não darão ao ToonTalk a chance que ele merece.

E também em outra mensagem em réplica a Tom Woods:

"Talvez eu deva reformular a questão da obsolescência do Logo como 'o Logo é ainda a melhor primeira linguagem a ser aprendida pelas crianças?'. Eu não creio. Eu acho que as linguagens visuais/animadas são mais atraentes para as crianças e mais fáceis de aprender."

Eu aprecio a forma pela qual você reformulou seu desafio ao Logo, o que o torna mais agradável para que eu observe o ToonTalk, quando tiver tempo para escrever relatórios.

Com relação aos professores dando ao TT a chance que ele merece: isto me faz pensar em alguma coisa em um livro chamado "Learning in Science", de Osborne & Freyberg (é um livro acerca de Ciência para crianças.), o qual eu acabei de rever para refrescar minha memória, eu cito:

"As idéias perdem `status´ quando se tornam menos inteligíveis, plausíveis e frutíferas. Inversamente, novas idéias aumentam seu prestígio quando se tornam mais inteligíveis, mais plausíveis e mais frutíferas". (48) [Eles escrevem mais sobre o que querem dizer com estes termos.]

Embora eu tivesse estado interessado muito tempo no MicroWorlds e o avalie bem nestes três critérios, eu penso que deveria dar uma boa olhada em sua alternativa. Seria ingênuo pensar que a próxima evolução do Logo/MicroWorlds será "sempre" a melhor primeira linguagem para crianças. A partir de outras perspectivas eu vejo outros problemas, entretanto:

Minha perspectiva: a tentativa que você está efetuando em comparação com o Superlogo não o MicroWorlds (eu não sei muito sobre o SuperLogo).

Sua perspectiva (minha também): o mercado real para linguagens de programação para crianças parece estar encolhendo, quando simulações mais sofisticadas pré-realizadas, como o "sim-life" etc... vêm à tona.

Bill Kerr

Brian Harvey escreveu:

"Eu não compreendo isto. Se os processos estavam embutindo a recursão, e portanto você realmente precisava manter a totalidade dos estados de todas as chamadas de procedimento ao redor, então eu não entendo por que você o está evitando. Se sua queixa é que a pilha de Java cresce atrás das chamadas, então o problema não são as sub-rotinas, mas as implementações de linguagens inferiores. Utilize, ao invés, a Logo Berkeley! Ela corrigirá a eliminação de chamadas por trás."

Eu concordo que as linguagens de procedimentos devem fazer a otimização da recursão por trás. Mas eu estava tentando destacar outro ponto. O ToonTalk poderia ser implementado como uma coleção de registros de processos não-ordenados. Um registro de processo é como uma estrutura de pilhas – ele contém um indicador para o código (robôs, no ToonTalk) e um vetor de argumento (uma caixa, no ToonTalk). Para ser justo com as linguagens convencionais, apesar de o ToonTalk ter processos muito econômicos, as chamadas de procedimentos ordinárias são mais custosas desde que elas utilizam o "heap" (área da memória) em vez da pilha. Mas o fato de que as pilhas não são utilizadas é que define por que a geração, suspensão e término dos processos são tão econômicos no ToonTalk.

"Mas (e este é o ponto principal que quero destacar aqui) existe outra forma de armar a concorrência sem incorrer em erros de sincronização: programação funcional! As condições de saída são possíveis apenas se os diversos `threads´ estão assinalando novos valores para as variáveis. Mas não há necessidade de fazê-lo (em termos do Logo, você nunca precisa utilizar MAKE). Quando você agrega programação funcional com programação seqüencial, eu creio que você não está fazendo justiça ao poder da chamada de procedimento como um mecanismo de controle. Algumas computações realmente se aplicam, a si mesmas, ao modelo imperativo de programação que você descreve. Mas o que ocorre com o exemplo clássico do Logo da geração de uma sentença inglesa? Eu creio que isto é melhor descrito como uma composição de funções. E mesmo se os argumentos para as funções são corretamente computados, não há problema de sincronização."

Eu concordo que em programas sem efeitos colaterais como na programação funcional todas as minhas objeções e preocupações acerca da sincronização desaparecem. E eu concordo que alguns programas interessantes podem ser escritos em um estilo funcional puro, por exemplo, seu gerador de sentença. Mas (e este é meu ponto principal aqui) existem muitos programas que não podem ser escritos como funções puras. O exemplo da conta bancária que eu dei anteriormente é um deles. Ou um marcador de pontos em um jogo. Ou muitas simulações, animações, jogos etc. Mesmo programas que fazem I/O são difíceis de se encaixar em estruturas puramente funcionais.

"Agora, por um lado, você proporciona chamada de funções, com os Pombos etc. Mas eu penso que, devido a você depreciar a idéia, sua metáfora torna a chamada de função muito mais complicada do que deveria ser. Eu ainda não vejo por que toda chamada de função DEVE ser um processo separado – talvez porque eu não entenda o que você está falando acerca de espaço na pilha. Você está dizendo que os processos separados asseguram a não-mutação de variáveis compartilhadas? Você não poderia atingir o mesmo objetivo não permitindo que os robôs (procedimentos, eu entendi) mudassem as coisas fora de si mesmos?"

Eu deveria antes dizer que eu proporciono uma técnica de programação ou padrão de utilização do ToonTalk que corresponde exatamente à chamada de função. E eu admito que é um pouco mais complicado quando tudo o que você deseja fazer é uma chamada de função. Mas eu afirmo que você deseja algo mais geral que a chamada de função. Suponha que você deseja devolver dois itens. No ToonTalk você apenas coloca dois Pombos em uma caixa e enquanto os valores são computados eles são dados aos Pombos e seus ninhos correspondentes são preenchidos. Suponha que você não deseja um valor simples, mas um fluxo de respostas. Talvez mesmo um fluxo infinito (por exemplo o Cone de Eratóstenes gerador de números primos). Suponha que você deseja criar uma rede de agentes cooperativos. E por que alguém deveria forçar a passagem de mensagens entre objetos para ajustar-se à estrutura da chamada de função?

Nós poexemplos estar perdendo todos, menos os programadores e cientistas da computação nesta lista, mas eu creio que são bons artigos. Eu estou aprendendo como ser mais claro acerca do que estou fazendo.

Saudações,
- Ken Kahn (www.ToonTalk.com)

De Brian Harvey:

Eu temo que ainda não compreendi; por que uma estrutura na pilha é mais custosa que uma no "heap"? É esta alguma característica específica do PC que eu não conheço?

"Eu deveria antes dizer que eu proporciono uma técnica de programação ou padrão de utilização do ToonTalk que corresponde exatamente à chamada de função. E eu admito que é um pouco mais complicado quando tudo o que você deseja fazer é uma chamada de função. Mas eu afirmo que você deseja algo mais geral que a chamada de função. Suponha que você deseja devolver dois itens."

Interessante – nós estamos tendo exatamente o mesmo argumento agora na comp.lang.scheme; os tipos implementadores têm colocado em valores de retorno múltiplos por razões de eficiência, e os fãs lambda o odiaram.

Mas eu não desejo que você faça tudo funcionalmente. O que eu quero é uma linguagem que não imponha um paradigma para mim, mas permita-me escolher o que é melhor para o programa a mão. Portanto, não é que eu deseje que você deixe nada de fora; eu desejo que você faça a composição de função mais fácil, também!

Brian Harvey escreveu na mensagem...

Eu acredito que este pode ser o centro da nossa discordância. Não está muito claro aquela afirmação em que você quer dizer "simples para o implementador" ou "simples para o usuário".

Se o for para o primeiro, nós, em princípio, discordamos. Se for para o segundo, nós discordamos quanto à estratégia de interface com o usuário. Eu não estou convencido de que os meios simplificados "dão ao usuário um martelo e o ensinam que tudo são pregos!"

Eu quero dizer o usuário. Embora eu gostasse de usuários avançados para ter uma idéia boa de como as coisas são implementadas. Os cursos de Scheme e Lisp não ensinam aos estudantes como escrever interpretadores de meta? Isso é muito mais difícil de fazer se a linguagem não for simples.

Quando eu cheguei à Xerox PARC (1984), fiquei bastante envolvido em um projeto de linguagem de múltiplos paradigmas (chamado Loops, depois InterLoops, depois CommonLoops, e eu saí fora quando ele passou a ser chamado de CLOS). Eu me lembro de estar revisando um papel escrito para a Bell Labs que discutia persuasivamente que havia custos cognitivos e colaboradores muito grandes para usar tais linguagens ricas.

Convenceram-me de que é difícil para a maioria das pessoas trocar entre paradigmas de programação diferentes mantendo as particularidades que essas linguagens permitem. E o autor do papel relatou os problemas às equipes da Bell Labs que teve devido a diferentes membros estarem usando modos muito diferentes de programar.

Os membros da equipe acharam difícil de entender e mudar para outro código. Também pode haver interferência entre as partes. Um componente do tipo Prolog, de programação lógica, tem dificuldades ao integrar bem uma linguagem imperativa substituta.

Um componente funcional puro permite todos os tipos de transformações de programa e execuções paralelas que quebram quando integrados com linguagens com efeitos colaterais. Você começou esta discussão inteira dizendo que a informática mudou desde o surgimento do Logo, e nós deveríamos apoiar novos paradigmas. Portanto, eu acredito que vale a pena observar que as linguagens populares que são compatíveis com paralelismo e OOP não excluíram outros mecanismos expressivos; pois isto é exclusivo ao TT.

Sim, a corrente principal acrescentou paralelismo às estruturas existentes. E os programadores profissionais têm uma dura tarefa de compreender e depurar programas Java com segmentos (e o Java é um dos melhores exemplos para isto). Os cientistas da computação continuam explorando a linguagem de programação atora, funcional, baseada em lógica e constraints que, assim como o ToonTalk, despreza algumas idéias antigas para ir em busca do progresso. Por outro lado, a indústria de computadores, ou corrente principal, simplesmente tenta enxertar coisas novas no velho. Este grupo de notícias é sobre o Logo – sobre linguagens de programação poderosas para crianças.

Ao contrário da corrente principal, as constraints de sistemas legados e retrocessos de compatibilidade são mínimos. E nós poexemplos dar às crianças a habilidade de criar programas paralelos sem forçá-las a dominar a complexidade de travas e regiões atômicas. E sem esperar que elas depurem condições de competição e paralisações completas.

Saudações,
Ken Kahn (www.ToonTalk.com)

Ken Kahn" <KenKahn@ToonTalk.com> escreveu:

Eu me lembro de estar revisando um papel escrito para a Bell Labs que discutia persuasivamente que havia custos cognitivos e colaboradores muito grandes para usar tais linguagens ricas. Convenceram-me de que é difícil para a maioria das pessoas trocar entre paradigmas de programação diferentes mantendo as particularidades que essas linguagens permitem. Eu acho que eu gostaria de saber se todos os paradigmas são igualmente difíceis neste sentido.

Minha experiência de ensino me fez (relutantemente!) concluir que a programação seqüencial é muito natural para a maioria das pessoas, e que programação funcional exige maior esforço mental (embora a compensação por esse esforço seja evidente). Onde está a programação simultânea naquele padrão? O que significa manter o custo marginal da composição de função em uma linguagem, naquele padrão, versus o custo marginal da simultaneidade inclusa? Também pode haver interferência entre as partes.

Um componente do tipo Prolog, de programação lógica, tem dificuldades ao integrar bem uma linguagem imperativa substituta. Um componente funcional puro permite todos os tipos de transformações de programa e execuções paralelas que quebram quando integrados com linguagens com efeitos colaterais. Também pode haver interferência entre as partes. Um componente do tipo Prolog, de programação lógica, tem dificuldades ao integrar bem uma linguagem imperativa substituta.

Um componente funcional puro permite todos os tipos de transformações de programa e execuções paralelas que quebram quando integrados com linguagens com efeitos colaterais. Eu concordava com você no exemplo de programação lógica, mas o funcional me parece ser um pouco falsário; lá você está falando sobre complexidade para o implementador, e não sobre carga cognitiva para o usuário. Sim, a corrente principal acrescentou paralelismo às estruturas existentes.

E os programadores profissionais têm uma dura tarefa de compreender e depurar programas Java com segmentos (e o Java é um dos melhores exemplos para isto). Os cientistas da computação continuam explorando a linguagem de programação atora, funcional, baseada em lógica e constraints que, assim como o ToonTalk, despreza algumas idéias antigas para ir em busca do progresso. Por outro lado, a indústria de computadores, ou corrente principal, simplesmente tenta enxertar coisas novas no velho. Sim, a corrente principal acrescentou paralelismo às estruturas existentes.

Eu estou convencido de que é difícil depurar programas que combinam simultaneidade com mutação de variáveis compartilhadas. Mas não estou convencido de que você não pode ter tudo da * simultaneidade * composição de funções sem mutação * mutação (não-compartilhada) de variáveis locais tudo na mesma linguagem, sem problemas. PS. Na Scheme nós poexemplos fazer funcional, seqüencial, simultâneo e OOP, embora a Scheme seja, pelo menos sob um sentido, uma linguagem muito simples. Ela não possui milhões de primitivas, como a CLOS, ou muita sintaxe, como o Java. Nós tentamos ensinar aos nossos estudantes a usar vários paradigmas de programação, mas prestar atenção a qual eles estão usando.

Eu suspeito que esses programadores que você mencionou que misturaram estilos adotaram uma Common Lisp manual sem nenhuma instrução explícita sobre paradigmas.

Brian Harvey escreveu na mensagem <73v2ml$lk6$1@agate.berkeley.edu>...

Eu acho que eu gostaria de saber se todos os paradigmas são igualmente difíceis neste sentido.

Minha experiência de ensino me fez (relutantemente!) concluir que a programação seqüencial é muito natural para a maioria das pessoas, e que programação funcional exige maior esforço mental (embora a compensação por esse esforço seja evidente).

Onde está a programação simultânea naquele padrão? O que significa manter o custo marginal da composição de função em uma linguagem, naquele padrão, versus o custo marginal da simultaneidade inclusa? Perguntas muito boas! Alguém conhece uma pesquisa que foi feita para dar as respostas a estes tipos de perguntas? Ou nos computadores e na literatura educacional ou na psicologia de programação?

(A única coisa que eu posso pensar é que a tese de mestrado de Mitch Resnick sobre o MultiLogo.) Um componente funcional puro permite todos os tipos de programa transformações e execuções paralelas que quebram quando integradas com linguagens com efeitos colaterais.

Aquela que é funcional me parece ser um pouco de falsário; lá vem você falando sobre complexidade para o implementador, não em carga cognitiva para o usuário. Que tal nos preocuparmos com a ordem de execução dos argumentos para uma função? No caso, você não precisa se aborrecer com isso. Caso haja efeitos colaterais, você agora tem uma coisa a mais para se lembrar. Eu estou convencido de que é difícil depurar programas que combinam simultaneidade com mutação de variáveis compartilhadas.

Mas não estou convencido de que você não pode ter tudo da * simultaneidade * composição de funções sem mutação * mutação (não-compartilhada) de variáveis locais tudo na mesma linguagem, sem problemas. Eu não tenho certeza. Nós simplesmente teremos de esperar até que alguém o construa (ou pelo menos o projete detalhadamente).

Mas você deverá concordar que não há nenhum dialeto do Logo que satisfaça esses critérios, certo?



Saudações,

- Ken Kahn (www.ToonTalk.com)

luvisi@andru.sonoma.edu escreveu:

Existem muitas linguagens que compartilham o mesmo modelo de computação do ToonTalk – Concurrent Prolog, Parlog, Guarded Horn Clauses, Strand, KL1, OC, Herbrand, Janus, Linear Janus e Oz. Você poderia dar alguns URLs e recomendações de livros?

Como um resolvedor de problemas profissional e sendo um ser humano, eu sempre estou tentando encontrar novas maneiras de encarar os problemas. Muito bom, mas teórico: Concurrent Constraint Programming (Acm Doctoral Dissertation Awards) Vijay A. Saraswat / Hardcover / publicado em 1993. Nosso preço: US$ 55.00 (pedido especial). Leia mais sobre esse título... Não li, mas deveria.

Parece bom: Objects for Concurrent Constraint Programming (Klwer International Series in Engineering and Computer Science, 426) Martin Henz / Hardcover / publicado em 1997.

Um pouco velho, mas uma boa coletânea de artigos; Concurrent Prolog : Collected Papers (Logic Programming Series) Ehud Shapiro(Editor) / Hardcover / publicado em 1988 Considere a diferença entre: cout << 2 << 3; == ( cout.operator<<( 2) ).operator<<( 2 );= 23 e: cout << (2 << 3); == (cout.operator<<(2 << 3 ); = 16 Eu sou o único a achar que isso é um pouco complicado? Ver isso me deixa contente por erros de sintaxe e confusões não serem um problema do ToonTalk.

início • busca • adquira • manual • novidades • dúvidas • suporte • download • imprensa • contato