|
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:
Brian Harvey escreveu:
"Eu penso que a melhor solução para este problema é um sistema
híbrido, no qual as coisas que são facilmente expressas
graficamente possam sê-lo, mas também que tudo possa ser
expresso textualmente."
Eu creio que este é um grande
tópico de pesquisa. Mas eu me
preocupo com os compromissos que seriam necessários para fazer
que isto funcione corretamente para uma linguagem de programação
de uso geral.
E também tenho dúvidas se os híbridos
acrescentam alguma espécie de complexidade cognitiva. Por outro
lado, é sempre uma boa coisa ser capaz de ver ou compreender
alguma coisa de diversos modos.
"Talvez o ToonTalk o seja,
também, desde que você diz que ele
produz códigos Java. Se o código Java não é convoluto também (eu
ainda não tive chance de jogar com ele – eu tentarei fazê-lo em
breve!) e se você pode usar o código Java para criar novas
habilidades no GUI, eu ficarei satisfeito, então."
O código Java é
legível, mas não o tipo de código que alguém
poderia escrever do nada. Tornar possível alterar o código Java e
tê-lo refletido no ToonTalk é um problema muito difícil.
"Btw, dizer que a concorrência
é `natural´ para as pessoas levanta
muitas questões para mim. Realmente, eu creio que se você está
simulando um mundo de atores independentes, parece natural
programá-los separadamente. Mas meus alunos de Ciência da
Computação certamente não consideram natural os problemas de
sincronização que surgem se aqueles atores querem compartilhar
estados!"
Eu concordo que o compartilhamento de
estados é "direto" mais do
que através da passagem de mensagens. É por isso que eu estou
reclamando acerca das variáveis globais como os únicos meios de
comunicação no MicroWorlds. Eu escreverei um ensaio maior, em
breve, sobre esta questão e o enviarei para cá.
Saudações,
- Ken Kahn
Ken Kahn escreveu:
"O código Java
é legível, mas não o tipo de código que alguém
poderia escrever do nada. Tornar possível alterar o código Java e
tê-lo refletido no ToonTalk é um problema muito difícil."
Eu não estou solicitando isso. O que eu peço é que seja capaz de
escrever, em Java, um novo instrumento, ou um novo item de menu,
ou qualquer coisa assim, e integrá-lo no mundo do TT.
Brian Harvey escreveu:
"Eu suponho que o texto receba golpes
estes dias. Nós
costumávamos não ter nada além de texto, e todos reagiram de
forma exagerada. O texto ainda é um meio realmente expressivo!
Mesmo para emoções, deixemos os programas de computadores
sozinhos."
Eu concordo inteiramente. Nós temos um lado esquerdo do cérebro
que aprecia texto e um lado direito que aprecia figuras. Enquanto
tantos argumentos competitivos tentam provar que seu lado favorito é
"melhor", eu simplesmente replicaria, não há nada como utilizar os
DOIS! Realmente, eu geralmente agrupo pessoas em 4 categorias:
Lado direito dominante, lado esquerdo dominante, ambos, e, claro,
nenhum deles!
Bob
"Para obter NOVAS respostas, você deve formular NOVAS questões!" - Bob Gorman.
Bob Gorman escreveu:
"Nós temos um lado esquerdo do cérebro que aprecia texto e um
lado direito que aprecia figuras."
Eu aprecio texto (poesia, romances) que cria imagens em minha
mente. Por exemplo, eu gosto de ler Victor Hugo.
Com o Logo eu posso usar o texto para criar imagens que não são
exatamente como eu pensava que fossem.
Eu posso me surpreender a mim mesmo. Eu gosto disso.
Dale --- $ dale-reed@worldnet.att.net
Seattle, Washington U.S.A. $
De Ken Kahn:
"Nós temos um lado esquerdo do cérebro que aprecia texto e um
lado direito que aprecia figuras. Enquanto tantos argumentos
competitivos tentam provar que seu lado favorito é `melhor´, eu
simplesmente replicaria, não há nada como utilizar os DOIS!"
Algumas pessoas são chamadas
"pensadores visuais" porque elas parecem ser boas para
resolver problemas visuais e elas relatam a
utilização de imagens visuais quando pensam. Para essas pessoas,
as linguagens de programação textual são difíceis.
Os pensadores visuais provavelmente prefeririam linguagens de programação visual, e seriam mais eficientes utilizando-as, do que as linguagens
textuais.
Outras pessoas parecem preferir textos e símbolos. Talvez o
ToonTalk não seja apropriado para elas. Uma linguagem híbrida
visual-textual poderia satisfazer ambos os tipos de pensadores, mas
talvez não. Necessitam-se de compromissos para fazer um bom
híbrido.
E os híbridos tendem a ser mais complexos e muito mais
difíceis de projetar. Eu desconfio que as crianças, particularmente as
mais jovens, são mais visuais e menos textuais/simbólicas em seu
pensamento.
Eu sei que estas categorias são grosseiras e muito
simplistas, mas eu penso que existem modos poderosos de pensar
acerca destas questões. Alguém conhece algo acerca da pesquisa
psicológica nestas questões?
Saudações,
Ken Kahn
De Brian Harvey:
"Ken Kahn" <KenKahn@ToonTalk.com> escreveu:
"Necessitam-se de compromissos para fazer um bom híbrido."
Não, não!
Compromissos fazem um mau híbrido. São necessárias
sínteses para um adequado. (Eu aprendi isso nas aulas de
Marxismo.) Os compromissos seriam como aqueles antigos
sistemas "macro" para o Mac que gravavam cliques de mouse em
coordenadas pixel.
Assim, por exemplo, tome aquele
aspecto de troca de dois valores
que você fez no ToonTalk na outra noite. O código Java
correspondente se pareceria com Pixels, ou ele se assemelharia
com o modo que você programou uma mudança diretamente em
Java? (Bem, eu suponho que não seja o caso, exatamente, mas eu
fixei uma mudança [a, b] na qual a mudança é o procedimento que
você forneceu que descobre uma parte vaga interessante na tela.)
De Ken Kahn:
Brian Harvey escreveu:
Não, não!
Compromissos fazem um mau híbrido. São necessárias
sínteses para um adequado. (Eu aprendi isso nas aulas de
Marxismo.) Os compromissos seriam como aqueles antigos
sistemas "macro" para o Mac que gravavam cliques de mouse em
coordenadas pixel.
Assim, por exemplo, tome aquele
aspecto de troca de dois valores
que você fez no ToonTalk na outra noite. O código Java
correspondente se pareceria com Pixels, ou ele se assemelharia
com o modo que você programou uma mudança diretamente em
Java? (Bem, eu suponho que não seja o caso, exatamente, mas eu
fixei uma mudança [a, b] na qual a mudança é o procedimento que
você forneceu que descobre uma parte vaga interessante na tela.)
Alguma coisa entre isso. Aqui
está o programa Java intocado gerado
automaticamente treinando um robô para trocar dois números se
eles têm problemas. Um grande projeto (algum estudante graduado
está participando?) é construir uma ferramenta que transforme o
seguinte código Java em algo mais normal. Meu palpite é que um
bom avaliador parcial poderia fazê-lo.
Saudações,
- Ken Kahn (www.ToonTalk.com)
Import ap.ToonTalk.*;
Class Robot_P extends TTRobot {
Robot_P(TTNotebook n) {
Notebook =
n;
}
public TTObjects gets (TTObject given) throws TTException {
if (! Wants.matches (given)) return null;
// If given a box that matches the box in his thought bubble (called "wants"),
// this robot will do the following.
TTObject hand;
TTObject temp1;
// pick up what's in the first hole inside his box
hand = given.pickUp (0);
//drop it
temp1 = hand;
// pick up what's in the third hole inside his box
hand= given.pickUp(2);
//drop it on the first hole inside his box
given.holeGets(0,hand);
//pick up the last thing he made or found
hand= temp 1;
// drop it on the third hole inside his box
given.holeGets(2, hand);
return this;//This robot has finished and will see if the box still matches his thoughts and try again.
}
}
public class Applet_P extends TTApplet {
public static void main (String args[]) {
new TTFrame().begin (new Applet_P());
}
public void initialize() {
TTNotebook notebook = TT.NOTEBOOK;
Box = new TTBox (3);
Box.setHole(0, new TTInteger (2, "+"));
Box.setHole(1, new TTScale("> "));
Box.setHole (2, new TTInteger(1, "+"));
//We just made a box with 3 holes. The first hole contains the number 2. The
// second hole contains a scale tipped to the left. The third hole contains
// the number 1.
Robot= new Robot_P (notebook);
TTBox wants1 = new TTBox(3);
// This robot will only accept a box with 3 holes. Rthe first hole contains
// any number. The second hole contains a scale tipped to the left. The third
// hole contains any number.
Wants1.setHole (O, TT.BLANK_NUMBER);
Wants1.setHole(1, new TTScale( "> "));
Wants 1.setHole(2, TT.BLANK_NUMBER);
Robot.setWants (wants1);
Team = new TTTeam(box, robot);
SetStarting Team(team);
Display This(box);
}
}
De Brian Harvey:
Ken Kahn escreveu:
"hand =
given.pickUp (0);
temp1 = hand;
hand= given.pickUp(2);
given.holeGets(0,hand);
hand= temp 1;
given.holeGets(2,hand);"
Formidável! Eu estou impressionado. Funcionaria sem "hand"?
Quero dizer, se nós alterarmos o código Java para
Temp1= given.pickUp(0);
Given.holeGets (0, givenpick.up(2));
Given.holeGets(2, temp1);
A animação
ocorreria de alguma forma interessante? (Eu penso que
poderia ser incluída apenas ocorrendo, completamente, em um
"flash" – até que não explodisse ou deixasse confete na tela, ou algo
assim.)
Se este tipo de coisa funcionar, deixará a porta aberta para o tipo de
programabilidade de modo-texto que eu (seguindo Eisenberg) desejo.
[Muito ruim é o Java com
toda aquela coisa de "blá blá blá" público ... :-)
Se apenas fosse Logo, isso seria perfeito.]
De Ken Kahn:
Brian Harvey escreveu
"Formidável! Eu estou impressionado. Funcionaria sem "hand"?
Quero dizer, se nós alterarmos o código Java para
Temp1= given.pickUp(0);
Given.holeGets (0, givenpick.up(2));
Given.holeGets(2, temp1);
A animação
ocorreria de alguma forma interessante? (Eu penso que
poderia ser incluída apenas ocorrendo, completamente, em um
"flash" – até que não explodisse ou deixasse confete na tela, ou algo
assim.)"
Aquilo deve funcionar. E um pequeno "otimizador peephole" poderia
provavelmente gerá-lo automaticamente.
Mas eu devo esclarecer que o
aplicativo Java não exibe os gráficos do ambiente de programação do ToonTalk. Neste caso, você não vê
a passagem que está rodando como um aplicativo Java. Se, no outro
lado, você constrói uma aplicação gráfica no interior do ToonTalk
(por exemplo, o exemplo do jogo de pingue-pongue), então aqueles
gráficos serão transferidos para Java.
Saudações,
- Ken Kahn (www.ToonTalk.com)
Ken Kahn escreveu:
"Eu concordo, o texto é bom. Mas
como eu escrevi em outra parte
desta discussão com relação a se alguns paradigmas de
programação são superiores a outros – há uma necessidade de
prioridades aqui. Se um professor está ensinando apenas uma
linguagem em um curso, ela deveria ser visual ou textual?"
Parte da chave desta questão é a definição de "superior", e esta
depende de suas prioridades.
Minhas prioridades: 1. Dar aos estudantes oportunidades ricas e
variadas para expressar seus pensamentos verbal,
visual, auditiva e cinestesicamente. 2. Dar aos
estudantes oportunidades para refletir sobre como eles pensam.
Como as linguagens de
programação estão entre as coisas que oferecem
possibilidades nestas duas áreas, eu estou interessado em
explorar meios pelos quais elas possam ser incluídas no aprendizado
dos estudantes. Se eu tivesse de formular uma
questão como a que você fez acima, eu perguntaria, se um professor
vai ensinar apenas uma linguagem, qual atingirá melhor os objetivos
dos estudantes? " Eu apreciei a resposta de Brian Harvey:
"Eu penso que a melhor
solução para este problema é um sistema
híbrido, no qual as coisas que são facilmente expressas
graficamente possam sê-lo, mas também que tudo possa ser
expresso textualmente."
Tom Woods
•
•
•
•
•
•
•
•
•
|