- Pickcode es un IDE en línea para clases de ciencias de la computación en secundaria y preparatoria, y busca ser una plataforma simple y estable que reduzca el tiempo que los docentes dedican a gestionar la clase
- La compatibilidad con Chromebook, el monitoreo del trabajo de los estudiantes, la colaboración en tiempo real y la revisión del historial de código son sus funciones clave para la gestión de clases
- Los docentes pueden personalizar y organizar materiales de clase y tareas, y Pickcode deja en claro que no incluye funciones de asistencia de código con IA
- Hay opiniones de docentes que indican que ayudó a que los estudiantes accedieran más fácilmente a las clases y trabajaran de forma más independiente en cursos de Java, Web Development, Python y AP Computer Science Principles
- Al ser una herramienta enfocada en crear clases y administrar estudiantes, más que un IDE profesional complejo, puede verse como una opción para reducir distracciones en el entorno del aula
IDE en línea diseñado para el aula
- Pickcode es un IDE en línea para clases de CS en secundaria y preparatoria
- Enfatiza una plataforma simple y estable para ayudar a los docentes a ahorrar tiempo en la operación de la clase
- Ofrece rutas básicas de acceso hacia las páginas de inicio, inicio de sesión y planes
Funciones para la gestión de clases y reacción de docentes
- Las funciones principales de Pickcode están orientadas al desarrollo de la clase y a revisar el trabajo de los estudiantes
- Funciona en Chromebook
- Permite monitorear el trabajo de los estudiantes
- Admite colaboración en tiempo real
- Permite revisar el historial de código
- Permite personalizar los materiales de clase
- Permite organizar tareas
- No incluye asistencia de código con IA
- Los docentes evalúan que la interfaz es simple pero escalable, y que gusta a estudiantes de distintos rangos de edad
- Hay casos de uso en clases de Java, Web Development, Python y AP Computer Science Principles
- También se incluyen comentarios de que ayudó a los estudiantes a usar la herramienta con mayor facilidad, hacer seguimiento de su trabajo y avanzar de forma independiente
- El equipo de soporte también recibe valoraciones de ser rápido y útil, y de haber implementado muchas de las sugerencias recibidas
1 comentarios
Opiniones en Hacker News
Me pregunto si hay una buena razón para exigir las palabras clave
var,setycall. BASIC no tenía eso, y por mis recuerdos borrosos de cuando aprendí a programar de niño, creo que esas palabras clave habrían sido complejidad innecesaria.Por ejemplo, en LOGO simplemente escribías
forward 10,left 90, perocall paint.forward(10),call paint.left(90)se siente excesivo y ruidoso.set x = 7, la palabra clave deja claro si se intenta cambiar una variable o afirmar una igualdad.Técnicamente, en el contexto de un programa de dibujo también podríamos hacer que
forward()fuera un método de nivel superior, pero decidimos hacerlo un poco más orientado a objetos pensando en cuando más adelante los estudiantes pasen a un motor de juegos 2D y controlen varios sprites.forwardyleftparecen direcciones de movimiento, lo que confunde especialmente cuando quieres “mover” al pintor hacia la izquierda.En realidad,
forwarddibuja/mueve yleftes una rotación en sentido antihorario que también acepta argumentos negativos, así quecall paint.draw(10),call paint.rotate(90)orotate("up")me resultan más claros.gosubpara llamar subrutinas.Por cierto, como dicen que los BASIC antiguos eran así, también hice que la numeración de los enlaces empezara en 1 :)
[1] https://picaxe.com/basic-commands/program-flow-control/gosub...
[2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
LET X=10.Estoy introduciendo a mi hijo de 10 años a Godot. Durante los últimos 6 meses hizo juegos con Scratch y le gusta Scratch, pero también se frustraba con sus límites.
Pensé que le gustaría más usar un lenguaje de scripting real, pero apenas empezó con GDScript se frustró rápido por la cantidad de tipeo. Tiene las manos pequeñas, le cuesta aprender mecanografía al tacto, y escribir nombres de variables y llamadas a métodos le toma demasiado tiempo.
Esto parece un equilibrio justo, así que voy a revisarlo.
Estoy haciendo unas clases muy ligeras de Python con mi hijo de 3 años, y me preguntaba por qué avanzábamos tan lento en comparación con lo que entiende. Ahora veo que solo escribir cosas como paréntesis y comillas ya le tomaba mucho tiempo.
Me gusta este proyecto y me entusiasma probarlo. Estoy cambiando de opinión hacia la idea de que, en programación para niños, mientras más, mejor. Parece bueno exponerlos a la dinámica de elegir entre varios lenguajes y flujos de trabajo.
Pero cuando le muestro un lenguaje de programación “real”, me dice que todo eso también puede hacerlo en Scratch y que no hace falta tipear tanto.
También probamos GameMaker juntos y consiguió resultados geniales, pero en cuanto me doy vuelta un momento, ya está de regreso en su proyecto de Scratch. A veces me pregunto si habría sido mejor que empezara con código desde el principio, como yo antes ;-)
Pero basta con señalar el problema y preguntarle cómo podría resolverlo para que el niño piense en eso y encuentre varias formas posibles dentro de Scratch. Por ejemplo, dividir el programa en varios objetos o agentes.
Scratch es mucho más potente de lo que sugieren la primera impresión o los primeros programas.
varyconst.Felicitaciones por el lanzamiento de Pickcode. Tiene muy buen acabado en los detalles y se nota que fue hecho con cuidado.
Creo que hay al menos dos corrientes dentro de la programación visual que intentan hacer la programación más accesible para personas no desarrolladoras.
Algunos intentos reducen con una interfaz visual la carga de aprender sintaxis, pero no ocultan el carácter imperativo ni la necesidad de pensamiento algorítmico. En la práctica, se pueden ver como IDE con otro nivel de accesibilidad, y creo que Pickcode y Scratch entran en esta categoría.
La otra corriente explora otros paradigmas de programación que pueden encajar hasta cierto punto con metáforas visuales. También lleva al usuario a una forma de pensar distinta de la programación imperativa. Node-RED es un buen ejemplo de exploración de la programación basada en flujos, que es una pariente cercana de la programación funcional reactiva. LabVIEW también es una pariente cercana basada en flujo de datos, aunque con más elementos mágicos. En la práctica, son valores predeterminados bastante inteligentes y asignación interna de nombres a variables. También me viene a la mente Apple Automator.
No creo que una opción sea necesariamente mejor o peor que la otra, pero al ver lenguajes visuales es útil pensar en la distinción entre imperativo y reactivo, porque la experiencia final del usuario cambia mucho.
Me parece genial que “la experiencia de edición de código esté completamente estructurada y que, en lugar de escribir, se elija desde menús”.
Me gustaría que existiera algo así para programadores adultos: un editor estructural de propósito general que pudiera usarse con varios lenguajes de programación. Al programar, la intención que viene primero a la mente es semántica: definir una función aquí, comprobar una condición allá, y así.
Entonces no entiendo por qué no se le puede comunicar directamente esa intención semántica al editor. Me pregunto por qué primero hay que serializar la intención como una cadena de texto y luego hacer que el editor la parseé de nuevo de una forma propensa a errores. Eso abre espacio para errores sintácticos tontos como typos, paréntesis que no coinciden o errores de precedencia de operadores; ¿no sería mejor dejar solo los errores semánticos?
Un editor así tampoco tendría por qué ser necesariamente incómodo con el teclado. Sería parecido a que Excel no es incómodo con el teclado. Creo que podría funcionar escribiendo en una “ventana de composición” y eligiendo en una “ventana de candidatos” para insertar, como los métodos de entrada de idiomas de Asia oriental.
Según lo entiendo, el gran problema en este caso es que uno termina queriendo imponer la restricción de que todos los estados intermedios por los que pasa el código sean semánticamente válidos. En apariencia es atractivo, pero en la práctica se vuelve una restricción fatal. Incluso la gente brillante piensa de forma algo laxa y luego corrige el código, incluso a nivel de una sola línea. Obligar a que siempre sea 100% válido choca mucho con la forma real de pensar.
Yo tiendo a ver ese desajuste como algo fundamental. No sé si siquiera una fracción ínfima de los humanos piensa de esa manera. Dicen que incluso los matemáticos profesionales, en el trabajo real, muchas veces piensan por adelantado y rellenan el rigor después. Si ni ellos avanzan estrictamente paso a paso, ¿quién lo haría?
La programación terminó asentándose en el autocompletado consciente de la semántica y las sugerencias, y es muy probable que eso no sea simplemente resultado de la flojera, sino el verdadero punto óptimo.
Tal vez si alguien lo lleva hasta el final pueda resolver el problema, pero diría que, si aquí hay frutos, no son frutos al alcance de la mano.
Como dijo saurik, el mundo Lisp usando Emacs es lo más cercano a esto, pero aun así puedes hacer lo que quieras. Simplemente hay muchas herramientas que ayudan a trabajar de forma más semántica; no hay nada impuesto de manera absoluta.
Conseguí trabajo porque fui el único postulante que había oído hablar de ese software. Todo gracias a haber leído una vez un texto corto en una revista.
https://en.wikipedia.org/wiki/Omnis_Studio
La forma de programar haciendo clic en listas desplegables y popups no estaba tan bien diseñada. El programa se veía como una lista y, al intentar editar una línea, aparecía un cuadro de diálogo modal que solo permitía modificar exactamente esa línea. Por supuesto, no había IntelliSense ni completado de código.
Con solo pensarlo siento que me da PTSD, al punto de necesitar alcohol o un cigarro.
Una de mis funciones favoritas de Scratch es que no puedes crear errores de sintaxis. Los bloques encajan o no encajan. Por eso creo que los niños pueden empezar a jugar más fácilmente, sin explicaciones adicionales ni clases particulares.
Seguí los primeros pasos del tutorial del rectángulo y luego probé haciendo clic por mi cuenta, pero se generó
call math paint.forward()y produjo un error de sintaxis. Claro que esa línea es basura, pero no logré descubrir cómo debía funcionar el comandomath. Supongo que si siguiera más el tutorial habría una explicación, pero creo que la descubribilidad también es importante.Cuando hay muchos bloques, también pueden superponerse entre sí, lo que vuelve bastante difícil encontrarlos. También está el problema de omitir argumentos de los bloques. Aun así se ejecuta, pero no funciona.
La programación visual es claramente mejor para los niños, pero creo que hace falta un enfoque más estricto que Scratch y mejores capacidades de depuración.
Se ve realmente bien. Me recuerda a cuando en Khan Academy estábamos creando una versión basada en bloques del editor de ProcessingJS.
La UI era un poco tosca y difícil de mantener, así que al final la abandonamos, pero esto se ve bastante fluido. Me gusta que ofrezca más caminos para que nuevos programadores entren a la programación con tipos. También creo que la mayor parte de la programación por bloques está demasiado alejada del código real.
A veces, este tipo de edición basada en bloques también se combina con verificación de tipos para permitir rellenar “huecos” de forma inteligente mediante consultas. Probablemente se vea con más claridad en editores para lenguajes funcionales puros como Agda.
Me recordó a BASIC de la ZX81. No se escribían las palabras clave; el teclado especial tenía una tecla para cada palabra clave.
El editor era sensible al contexto; dicho de otro modo, el analizador léxico guiado por el parser era el propio usuario. En esa época, descubrir si uno quería ingresar una palabra/número o una palabra clave, y qué tipo de palabra clave era, se sentía un poco mágico. En realidad, la parte importante desde el punto de vista educativo era que yo sí lo sabía.
Lo importante en la ZX81 era que ahorraba memoria al almacenar tokens en vez de una representación textual. Tenía 1 KB de RAM, y eso incluía la memoria de pantalla. Tampoco tenía una GPU aparte. Al parsear durante la entrada, seguramente la ejecución también era más rápida.
El sitio está muy bien pulido, pero no estoy del todo de acuerdo con el objetivo. Es un IDE impresionante, pero creo que me habría enfocado en un subconjunto de Python más que en un lenguaje nuevo.
Si no, puede quedar ignorado porque Scratch es más fácil de enseñar y Python es más útil de aprender. Lo primero aplica a escuelas con docentes que son desarrolladores; lo segundo, a padres programadores que enseñan a sus hijos.
Como desarrollador de software, ayudé en las clases de programación de primaria/kínder de mi esposa, así que conozco algo de los problemas de esta área.
Publicaciones relacionadas:
Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - noviembre de 2022, 14 comentarios
Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - julio de 2022, 32 comentarios
Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - mayo de 2022, 4 comentarios
Las republicaciones están bien después de más o menos un año, y los enlaces a hilos anteriores son para los lectores que quieran profundizar.
Estoy trabajando en un concepto parecido orientado a la programación musical:
https://glicol.org
Creo que estaría bueno tener algunos ejemplos directamente en la landing page.
Al probar las clases, uno se queda trabado; hay pistas a la derecha, pero no llaman mucho la atención. Podrías reorganizarlas como en el Svelte Tutorial (https://learn.svelte.dev/tutorial/welcome-to-svelte).
No estoy seguro de la sintaxis. Me pregunto si consideraron usar LOGO.