Apresentação no HN: uma nova linguagem visual para ensinar programação a crianças

 (pickcode.io)
4 pontos por GN⁺ 2023-11-23 | 1 comentários | Compartilhar no WhatsApp
  • O Pickcode é uma IDE online para aulas de ciência da computação do ensino fundamental II e médio, voltada a uma plataforma simples e estável que reduz o tempo que os professores gastam para conduzir as aulas
  • Suporte a Chromebook, monitoramento do trabalho dos alunos, colaboração em tempo real e verificação do histórico de código são os principais recursos de gestão de aula
  • Os professores podem personalizar e organizar materiais de aula e tarefas, e o Pickcode afirma explicitamente que não oferece recurso de assistência de código por IA
  • Há avaliações de professores dizendo que a ferramenta ajudou os alunos a acessar mais facilmente e trabalhar de forma independente em aulas de Java, Web Development, Python e AP Computer Science Principles
  • Em vez de uma IDE profissional complexa, é uma ferramenta focada na criação de aulas e na gestão de alunos, podendo ser vista como uma opção para reduzir distrações no ambiente de sala de aula

IDE online pensada para a sala de aula

  • O Pickcode é uma IDE online para aulas de CC no ensino fundamental II e médio
  • Enfatiza uma plataforma simples e estável para economizar o tempo dos professores na condução das aulas
  • Oferece caminhos básicos de entrada para começar, fazer login e acessar a página de preços

Recursos de gestão da aula e reação dos professores

  • Os principais recursos do Pickcode são voltados à condução das aulas e ao acompanhamento do trabalho dos alunos
    • Funciona em Chromebook
    • Permite monitorar o trabalho dos alunos
    • Oferece colaboração em tempo real
    • Permite verificar o histórico de código
    • Permite personalizar materiais de aula
    • Permite organizar tarefas
    • Não possui recurso de assistência de código por IA
  • Os professores avaliam que a interface é simples, mas escalável, e que alunos de várias faixas etárias gostam dela
  • Há casos de uso em aulas de Java, Web Development, Python e AP Computer Science Principles
  • Também há relatos de que ajudou os alunos a usar a ferramenta com mais facilidade, acompanhar o próprio trabalho e avançar de forma independente
  • A equipe de suporte também é avaliada como rápida e prestativa, e muitos dos feedbacks enviados teriam sido implementados

Leituras relacionadas

1 comentários

 
GN⁺ 2023-11-23
Opiniões no Hacker News

  • Fico me perguntando se há um bom motivo para exigir as palavras-chave var, set e call. BASIC não tinha isso e, pelas lembranças vagas de quando aprendi programação pela primeira vez quando criança, acho que essas palavras-chave teriam sido complexidade desnecessária
    Por exemplo, em LOGO bastava escrever forward 10, left 90, mas call paint.forward(10), call paint.left(90) parece exagerado e ruidoso

    • As palavras-chave foram incluídas para tornar cada linha fácil de ler em voz alta. Especialmente em set x = 7, a palavra-chave deixa claro se a intenção é alterar uma variável ou afirmar uma igualdade
      Tecnicamente, no contexto de um programa de desenho, também seria possível fazer de forward() um método de nível superior, mas decidimos deixá-lo mais orientado a objetos pensando no momento em que os alunos passarem para um motor de jogos 2D e precisarem controlar vários sprites
    • Aqui os nomes me parecem um pouco pouco intuitivos. forward e left parecem direções de movimento, o que confunde especialmente quando se quer “mover para a esquerda” o pintor
      Na prática, forward é desenhar/mover e left é uma rotação no sentido anti-horário que também aceita argumento negativo, então call paint.draw(10), call paint.rotate(90) ou rotate("up") me parecem mais claros
    • Isso vai entregar minha idade, mas o BASIC que aprendi primeiro tinha um comando gosub para chamadas de sub-rotina
      A propósito, como dizem que os BASICs antigos eram assim, coloquei até a numeração dos links começando em 1 :)
      [1] https://picaxe.com/basic-commands/program-flow-control/gosub...
      [2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
    • No Basic que eu usava havia LET X=10
    • Tive a mesma primeira impressão. Passo o dia inteiro olhando código muito mais complexo, mas, tentando pensar do ponto de vista de uma criança pequena, acho que esse ruído desnecessário poderia causar bastante confusão

  • Estou apresentando Godot a uma criança de 10 anos. Nos últimos 6 meses ela fez jogos no Scratch e gosta dele, mas também se frustrou com as limitações
    Achei que ela fosse gostar mais usando uma linguagem de script de verdade, mas, assim que começou com GDScript, ficou rapidamente frustrada pela quantidade de digitação. As mãos são pequenas, é difícil aprender digitação por toque, e leva tempo demais para digitar nomes de variáveis e chamadas de método
    Isto parece um equilíbrio perfeito, então vou dar uma olhada

    • A limitação da velocidade de digitação é um ponto muito bom e, estranhamente, eu nunca tinha pensado nisso
      Estou fazendo umas aulas bem leves de Python com uma criança de 3 anos e ficava me perguntando por que o avanço era lento em relação ao nível de compreensão. Agora percebo que só digitar coisas como parênteses e aspas já levava bastante tempo
      Gostei deste projeto e estou ansioso para experimentá-lo. Estou mudando de opinião para o lado de que, em programação para crianças, quanto mais, melhor. Parece bom expô-las à dinâmica de escolher entre várias linguagens e fluxos de trabalho
    • Fico curioso sobre o motivo de não usar um teclado de tamanho infantil
    • Minha experiência é parecida. Apresentei Scratch ao meu filho quando ele tinha 8 anos e, agora, 2 anos depois, ele está criando jogos muito mais avançados do que eu esperava
      Mas, quando mostro uma linguagem de programação “de verdade”, ele diz que dá para fazer tudo aquilo no Scratch também e que não há motivo para digitar tanto
      Também experimentamos GameMaker juntos e criamos resultados legais, mas basta eu me distrair um pouco e ele volta para seus projetos no Scratch. Às vezes me pergunto se teria sido melhor ele começar programando em código desde o início, como eu antigamente ;-)
    • Senti que a limitação do Scratch está no fato de não ficar claro para a criança como gerenciar a complexidade quando o programa fica grande demais
      Ainda assim, só de apontar o problema e perguntar o que poderia ser feito, a criança começa a pensar nisso e encontra várias formas possíveis dentro do Scratch. Por exemplo, dividir o programa em vários objetos ou agentes
      Scratch é muito mais poderoso do que a primeira impressão ou o primeiro programa sugerem
    • GDScript é uma linguagem surpreendentemente boa. Em vários aspectos é melhor que Python; por exemplo, tem var e const

  • Parabéns pelo lançamento do Pickcode. O acabamento dos detalhes é bom e dá para ver que foi feito com cuidado
    Acho que há pelo menos duas correntes na programação visual que tenta tornar a programação mais acessível para não desenvolvedores
    Algumas iniciativas reduzem, com uma interface visual, o ônus de aprender sintaxe, mas não escondem o caráter imperativo nem a necessidade de pensamento algorítmico. Na prática, podem ser vistas como IDEs com outro nível de acessibilidade, e acho que Pickcode e Scratch entram nessa categoria
    A outra vertente explora outros paradigmas de programação que podem se encaixar em certa medida em metáforas visuais. Ela também induz o usuário a um modo de pensar diferente da programação imperativa. Node-RED é um bom exemplo de exploração de programação baseada em fluxo, que é uma parente próxima da programação funcional reativa. LabVIEW também é uma parente próxima baseada em fluxo de dados, mas com mais elementos quase mágicos. Na prática, são padrões bem inteligentes e nomes internos de variáveis. Apple Automator também vem à mente
    Não acho que uma abordagem seja necessariamente melhor ou pior, mas, ao olhar para linguagens visuais, é útil pensar na distinção entre imperativo e reativo, porque isso muda bastante a experiência final do usuário

    • Lembro que ensinar workshops de uma linguagem funcional como Elm para iniciantes era, na verdade, mais fácil do que ensinar para especialistas. A mente dos iniciantes não tinha sido contaminada por um tipo de pensamento imperativo em C

  • Achei muito legal o fato de que “a experiência de edição de código é totalmente estruturada, e em vez de digitar você escolhe em menus”
    Eu gostaria que existisse algo assim para programadores adultos, isto é, um editor estrutural genérico que pudesse ser usado com várias linguagens de programação. Ao programar, a intenção que vem primeiro à cabeça é semântica: definir uma função aqui, verificar uma condição ali, e assim por diante
    Então não entendo por que não transmitir essa intenção semântica diretamente ao editor. Por que primeiro serializar a intenção em uma string, para depois o editor ter de analisá-la de novo de uma forma sujeita a erros? Isso abre espaço para erros sintáticos bobos, como typos, parênteses desbalanceados e erros de precedência de operadores; não seria melhor deixar apenas os erros semânticos?
    Um editor desses não precisa necessariamente ser hostil ao teclado. É parecido com o fato de o Excel não ser hostil ao teclado. Acho que ele poderia funcionar como IMEs de idiomas do Leste Asiático: você digita em uma “janela de composição” e escolhe na “janela de candidatos” para inserir

    • Já houve muitas tentativas desse tipo. Está mais para uma “ideia em que muita gente pensou e tentou, mas que logo esbarrou em grandes problemas” do que para uma “ideia que ninguém jamais imaginou”
      Pelo que entendo, o grande problema nesse caso é que você passa a querer impor a restrição de que todos os estados intermediários pelos quais o código passa sejam semanticamente válidos. Superficialmente isso é atraente, mas na prática vira uma restrição fatal. Mesmo pessoas excelentes pensam de forma um tanto frouxa e depois corrigem o código, inclusive em nível de linha. A imposição de que tudo tenha de estar 100% válido o tempo todo entra em grande conflito com a forma real de pensar
      Eu tendo a ver esse desencontro como algo fundamental. Não sei se sequer uma fração minúscula dos seres humanos pensa desse jeito. Dizem que até matemáticos profissionais, no trabalho real, muitas vezes pensam à frente e só depois preenchem o rigor. Se nem eles avançam rigidamente um passo de cada vez, quem avançaria?
      A programação se consolidou em torno de autocompletar com consciência semântica e sugestões, e é bem provável que isso não seja apenas resultado de preguiça, mas sim o ponto ótimo na prática
      Talvez alguém consiga resolver o problema se insistir até o fim, mas eu diria que, mesmo que haja frutos aqui, eles não são frutos fáceis de colher
      Como saurik disse, o mundo Lisp usando Emacs é o que mais se aproxima disso, mas ainda assim você pode fazer o que quiser. Há apenas muitas ferramentas que ajudam a trabalhar de forma mais semântica; nada é imposto de maneira absoluta
    • Acho que existe bastante coisa assim. Há Scratch e seu parente Snap (https://snap.berkeley.edu/snap/snap.html), editores visuais de fluxo para React (https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...), e coisas parecidas como https://retejs.org/
    • Você disse que queria algo assim para programadores adultos, mas o Blythe Omnis 7 já existia em 1996 ou antes. Era uma plataforma/solução RAD que suportava tanto Windows quanto Macintosh
      Consegui um emprego porque era o único candidato que já tinha ouvido falar daquele software. Foi graças a um texto curto que li uma vez em uma revista
      https://en.wikipedia.org/wiki/Omnis_Studio
      Programar clicando em listas suspensas e pop-ups não era exatamente algo bem projetado. O programa parecia uma lista e, ao tentar editar uma linha, aparecia uma caixa de diálogo modal na qual você só podia corrigir exatamente aquela linha. IntelliSense ou autocompletar código, claro, não existiam
      Só de pensar nisso sinto que o PTSD vai bater, a ponto de eu precisar de bebida ou cigarro
    • Por exemplo, https://github.com/nocode-js/sequential-workflow-designer é projetado desse jeito. Você programa a lógica colocando ações predefinidas na ordem correta e acaba programando em alto nível
    • Pelo que sei, pessoas que lidam com Lisp no Emacs têm essa experiência. Porque conseguem pensar e trabalhar em termos de formas, não apenas texto simples

  • Uma das minhas funcionalidades favoritas do Scratch é que não dá para criar erros de sintaxe. Os blocos ou se encaixam, ou não se encaixam. Por isso acho que as crianças conseguem começar a brincar com mais facilidade, sem explicações separadas nem aulas particulares
    Segui os primeiros passos do tutorial do quadrado e depois fui clicando aqui e ali por conta própria; acabou sendo criado call math paint.forward(), gerando um erro de sintaxe. Claro que aquela linha é lixo, mas não consegui descobrir como o comando math deveria funcionar. Provavelmente a explicação aparece se eu continuar seguindo o tutorial, mas acho que descobribilidade também é importante

    • O Scratch não permite criar erros de sintaxe, mas também não reclama quando algo sai do lugar. Por exemplo, se ao manipular blocos um deles se solta, o programa ainda executa, mas não funciona corretamente
      Quando há muitos blocos, eles também podem se sobrepor, o que fica bem difícil de encontrar. Há ainda o problema de esquecer argumentos dos blocos. Mesmo assim ele executa, só não funciona
      Programação visual é claramente melhor para crianças, mas acho que é necessária uma abordagem mais rigorosa do que a do Scratch e uma capacidade de depuração melhor
    • Outra vantagem do Scratch, mais precisamente dos blocos, é que eles podem ser adaptados com bastante facilidade a uma nova linguagem. Usamos blocos para que clientes de IoT configurassem dispositivos para reagir a eventos e enviar eventos a outros dispositivos, e tudo isso era convertido em uma configuração JSON que era enviada por upload

  • É muito bom de ver. Isso me lembra a época em que a Khan Academy estava criando uma versão baseada em blocos do editor ProcessingJS
    A UI era um pouco tosca e difícil de manter, então acabamos abandonando, mas isto parece bem fluido. Gosto do fato de oferecer mais caminhos para novos programadores entrarem na programação com tipos. Também acho que a maior parte da programação em blocos fica distante demais do código real

    • Parece que essas UIs de edição em blocos deveriam poder ser geradas automaticamente a partir de uma descrição abstrata da gramática, como as usadas por parsers tree-sitter
      Às vezes, esse tipo de edição baseada em blocos também é combinado com verificação de tipos, permitindo preencher “buracos” de forma inteligente e baseada em consultas. Talvez isso seja mais visível em editores para linguagens puramente funcionais como Agda

  • Lembra o BASIC do ZX81. Você não digitava palavras-chave; havia uma tecla para cada palavra-chave no teclado especial.
    O editor era sensível ao contexto; em outras palavras, o analisador léxico guiado pelo parser era o próprio usuário. Na época, parecia um pouco mágico descobrir se você queria inserir uma palavra/número ou uma palavra-chave, e que tipo de palavra-chave era. Na verdade, a parte educacionalmente importante é que eu sabia disso
    O ponto importante no ZX81 era que ele armazenava tokens para economizar memória, em vez de uma representação em texto. A RAM era de 1 KB, e isso incluía até a memória de vídeo. Também não havia GPU separada. Como o parsing era feito na entrada, a execução também deve ter ficado mais rápida

  • O site é muito bem polido, mas não concordo totalmente com o objetivo. É uma IDE impressionante, mas acho que eu teria focado em um subconjunto de Python, em vez de uma nova linguagem.
    Caso contrário, pode acabar sendo ignorado porque Scratch é mais fácil de ensinar, e Python é mais útil de aprender. O primeiro se aplica a escolas com professores desenvolvedores; o segundo, a pais programadores que ensinam seus filhos.
    Como desenvolvedor de software, já ajudei nas aulas de programação da minha esposa para o ensino fundamental/educação infantil, então conheço um pouco os problemas dessa área

    • Fico curioso se existe alguma alternativa que seja um “subconjunto de Python”. Seria interessante se houvesse uma ponte natural para a programação “de verdade”

  • Posts relacionados:
    Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - novembro de 2022, 14 comentários
    Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - julho de 2022, 32 comentários
    Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - maio de 2022, 4 comentários
    Reposts são aceitáveis depois de mais ou menos 1 ano, e os links para threads anteriores são para leitores que quiserem saber mais

  • Estou trabalhando em um conceito parecido na área de programação musical:
    https://glicol.org
    Acho que seria bom ter alguns exemplos logo na landing page.
    Ao tentar fazer a aula, dá para travar; há uma dica à direita, mas ela não chama muita atenção. Talvez dê para reposicioná-la, como no Svelte Tutorial (https://learn.svelte.dev/tutorial/welcome-to-svelte).
    Não tenho certeza sobre a sintaxe. Fico curioso se vocês consideraram usar LOGO