Estos días está circulando por las redes un artículo escrito hace unos meses en el que se comparan los lenguajes de programación visuales, tipo Scratch o Kodu, con lenguajes de programación basados en texto, como Logo, que son más similares a los que se usan en la industria. El artículo es muy completo e interesante, y se centra en las ventajas que presentan los lenguajes visuales para los aprendices jóvenes, como la desaparición de los errores de sintaxis o la sencillez para crear aplicaciones gráficas.
En ocasiones en los cursos que impartimos, en conferencias en las que participamos y, especialmente, por las redes, nos encontramos con gente que considera que los lenguajes visuales «no son lenguajes de programación de verdad», «que eso no es programar» o que «con esos lenguajes tan sencillos no se aprende nada».
Nosotros somos firmes defensores de los lenguajes de programación visuales para aprendices (tanto para niños como para adultos), y aunque ya hemos hablado de este tema en otras ocasiones y hemos explicado por qué consideramos que las afirmaciones del párrafo anterior no se sostienen, en esta ocasión nos vamos a centrar más en las causas de este tipo de actitudes.
¿Por qué creemos que hay gente que defiende que los aprendices, incluso estudiantes de primaria, deberían trabajar con lenguajes basados en texto?
Por un lado, creemos que este movimiento de llevar la programación informática a las aulas está en muchas ocasiones mal enfocado. Desde la industria del software se está promoviendo la visión de un futuro con una gran escasez de profesionales informáticos, y muchas administraciones públicas han comprado este discurso y se centran mayoritariamente en las posibilidades laborales para los alumnos que aprendan a programar desde edades tempranas. Y claro, si se quiere que todos los niños sean programadores, lo ideal es que desde la escuela se trabajen con las herramientas que se encontrarán en la industria.
Por tanto, para ayudar a los aprendices a transitar desde los lenguajes visuales a los lenguajes basados en texto, se están creando lenguajes de programación que utilizan un enfoque mixto. Un ejemplo de estos nuevos lenguajes es PencilCode, creado por Google, que permite programar bien usando bloques visuales, bien escribiendo directamente el texto, y ofrece la posibilidad de comprobar cómo se traduce el texto a bloques y viceversa.
Ejemplo de un programa en texto y su traducción a bloques en PencilCode
Por otro lado, en ocasiones los lenguajes visuales producen una falta de conexión con la profesión informática o falta de autenticidad, tal como la describe Mark Guzdial en su libro Learner-centered design of computing education. Así, a veces vemos alumnos que quieren ser informáticos de mayores que nos dicen «pero esto no es programar, yo quiero programar como los hackers de verdad». Claro, ellos no quieren usar herramientas «de juguete o de niños pequeños», quieren programar usando los lenguajes que aparecen en las películas o que ven que utiliza en casa algún familiar más mayor, por ejemplo.
Un estudio del año 2010 que comparó lo que aprendieron sobre programación un grupo de estudiantes que usó un lenguaje visual, Scratch, y otro grupo de estudiantes que usó en lenguaje basado en texto, Logo, pone de relevancia el impacto de la autenticidad. A pesar de que no hubo apenas diferencias en el aprendizaje, aunque el grupo de Scratch aprendió algo más sobre el uso de condicionales, el grupo de Logo mostró más confianza en su aprendizaje, en el sentido de que estaban convencidos que habían aprendido «de verdad», como lo hacen los informáticos.
La visión de Programamos
Como ya hemos defendido muchas veces, nosotros no queremos que todos los niños sean programadores. Por el contrario, nos centramos en los beneficios educativos que el desarrollo del pensamiento computacional ofrece a los estudiantes, ya que se trabajan una serie de habilidades, como la creatividad, la capacidad de resolución de problemas o el trabajo en equipo, que serán muy importantes para todos ellos, sin importar el campo en el que desarrollen su futura actividad profesional. En consecuencia, defendemos que se usen las herramientas que favorezcan en mayor grado el desarrollo de estas habilidades, sin tener en cuenta si se trata de tecnologías que se usen en la industria. En nuestra opinión, las herramientas ideales son, sin duda, las plataformas visuales.
Además, defendemos que los adultos que quieran aprender a programar también lo hagan usando lenguajes visuales. De hecho, nosotros vemos un futuro en el que todo tipo de personas, así como profesionales de todos los campos, van a crear sus propios programas y aplicaciones personales que los ayudarán en su día a día, tanto en su vida laboral como en sus momentos de ocio. Y estamos convencidos de que lo harán utilizando lenguajes visuales del estilo de GP, un lenguaje de propósito general que permitirá crear todo tipo de aplicaciones profesionales usando bloques.
Simulación de un hábitat y una población de conejos creada con GP
No queremos decir con esto, por supuesto, que los lenguajes basados en texto vayan a desaparecer. Los ingenieros de software y programadores profesionales o habituales seguirán usándolos, pero para el resto de la población que programe de forma esporádica o que esté en fase de aprendizaje, las ventajas de los lenguajes visuales harán que se decanten por ellos.
Vale, pero, ¿cómo luchamos contra el problema de autenticidad de los lenguajes visuales?
La forma en la que nosotros convencemos a nuestros estudiantes hackers de que los lenguajes visuales no son «de juguete ni de niños pequeños» es mostrándoles las posibilidades reales que tienen. Así, en el caso de Scratch, les mostramos proyectos como esta réplica de Super Mario, esta de Tetris o este videojuego de Star Wars, por plantear tan solo unos ejemplos, y les pedimos que echen un ojo al código. Al ver las oportunidades que estas herramientas les ofrecen, sus reticencias desaparecen y se sienten más cómodos utilizándolas.
En cualquier caso, si nuestra visión se hace realidad, en poco tiempo los lenguajes visuales serán parte del día a día y este problema desaparecerá gradualmente 🙂
[…] Estos días está circulando por las redes un artículo escrito hace unos meses en el que se comparan los lenguajes de programación visuales, tipo Scratch o Kodu, con lenguajes de programación basados en texto, como Logo, que son más similares a los que se usan en la industria. El artículo es muy compl […]
Para mi las herramientas visuales son fantásticas. Realmente hay quien aún defiende hoy en día escribir pseudocódigo con papel y boli como paso previo a programar, o meter una chapa de teoría sobre programación antes de realizar el primer programa, pero ni caso!. Utilizando entornos de programación gráfica se aprende a estructurar programas sin preocuparse por la sintaxis, y se obtienen resultados impresionantes en poco tiempo, lo cual incide mucho en la motivación. Con este paso previo ponerse después a programar en un lenguaje determinado es mucho más fácil, pues ya tienes experiencia resolviendo problemas de forma estructurada.
Y no sólo vale para quien está empezando, sino también para un aprendizaje más avanzado. Introducir conceptos a través del lenguaje visual facilita la tarea de la comprensión de estructuras complejas que, una vez entendidas, se pueden trasladar más fácilmente a código.
Sin duda, apoyo al 100% la programación visual! 🙂
Muchas gracias por tu comentario, María.
Me encanta lo que comentas en el segundo párrafo, acerca de que los lenguajes visuales son también interesantes para aprendizajes más avanzados. Se me viene a la cabeza, por ejemplo, la sincronización entre procesos por envío de mensajes, que es algo totalmente natural en los entornos de programación visuales y que puede servir para entender el concepto antes de implementarlo en otros lenguajes.
Saludos!
Uno a favor del código escrito 😉
No es cierto que los que defendemos los lenguajes de texto pensemos de una manera más «finalista», para mi, igual que para vosotros, lo más importante no es la programación, sino los procesos mentales y cognitivos que esta favorece.
Desde ese punto de vista, creo que la programación textual exige mayor esfuerzo de abstracción, mayor atención al error, es más «escalable» cuando vamos hacia proyectos más complejos y, como bien explicáis, su imagen de «autenticidad» es un factor motivador.
No digo que los lenguajes gráficos no valgan (ni mucho menos), pero si que creo que es necesario pasar en algún momento al lenguaje textual.
Un saludo y gracias por generar el debate 🙂
Muy interesante tu punto de vista, Tucho. Muchas gracias por compartirlo.
En la situación presente, es normal que si trabajas con alumnos que ya saben programar y queréis hacer proyectos más avanzados, paséis a trabajar con lenguajes basados en texto.
No obstante, yo creo que los lenguajes visuales van a ir mejorando (de hecho, los nuevos lenguajes visuales que están naciendo ya lo están haciendo) para minimizar algunos de los problemas que actualmente presentan, y que tú mencionas. Y pensamos que eso hará que el esfuerzo que requiere trabajar con lenguajes basados en texto solo merezca la pena para los que se dediquen profesionalmente a la programación o para quienes programen de forma frecuente.
En informática ha sido habitual que las transformaciones sean adoptadas primero en el ámbito educativo y tarden unos años en estandarizarse, como ocurrió, por ejemplo, con la programación orientada a objetos. Jugando un poco a adivinar el futuro, creemos que, tal como indica Jens Mönig, la programación visual puede ser uno de estos casos:
https://twitter.com/moenig/status/791381365161877504
Saludos!
Personalmente defiendo el pseudocódigo como «única» forma de programación. Realmente utilizar código o bloques es codificación, el proceso de programación es el más complejo y el más enriquecedor. Tanto con código como con bloques se debería hacer una planificación previa, y eso es el pseudocódigo básicamente (muy básicamente, lo sé).
De todos modos las verdades absolutas son peligrosas.
Si alguien se encuentra cómodo enseñando con bloques, ese es su camino, si alguien se encuentra cómodo enseñando código, ese es su camino.
Probablemente con bloques se hace algo antes, con código una vez pasado el «trauma» inicial se avanza más rápido y se llega a hacer cosas más complejas. Todo tiene sus ventajas.
Yo al ver que un programa de bloques el segundo programa ya me lo generaba mál decidí dejarlo, pero no digo que el que lo use lo esté haciendo peor que yo.
Hola, Diego,
Muy interesante lo que comentas de la necesidad de un diseño previo antes de ponerse manos a la obra a programar.
De hecho, en una investigación de un instituto de Israel comprobaron que estudiantes que aprendieron a programar con Scratch se lanzaban directamente a crear sus programas sin una planificación previa, algo que Papert llamaba «programación por bricolaje» (https://pdfs.semanticscholar.org/cbc5/eaf4995813fa1401f5ad932202650b95338a.pdf). En sus conclusiones indican que el rol del docente es fundamental para evitar estas situaciones, ya que la plataforma casi invita a ello.
La verdad es que molaría hacer un experimento para comprobar si dos grupos de alumnos, unos aprendiendo con un lenguaje visual y otros con uno basado en texto, muestran diferencias en términos de diseño previo.
Gracias por la idea! 🙂
@Jesús: La verdad es que yo siempre he trabajado programación textual y he hecho poco de gráfica. Lo primero que di en clase fué Python y html, en aquel momento ni conocía Scratch ni similares. Por cuestiones de reparto horario en centros, Scratch sólo lo he trabajado en 2ºESO dos cursos y en 4º otro curso. Lo que quiero decir es que no es que mis alumnos vengan con conocimientos de programación, he tenido un par de veces en las que hemos empezado con algo de Scratch en segundo y en tercero ya nos metiamos con código escrito, y otras en las que directamente entraron con el texto en 3º o 4º. La verdad… no tengo todavía muy claro que es mejor, porque la muestra es muy pequeña.
De todas formas, aunque los lenguajes de bloques mejoren, yo creo que les seguiré dando texto. Por el mismo motivo que, aunque haya maneras mucho más efectivas de diseñar una página web, yo les sigo dando html. Aunque hay editores con autocorrección y predicción que son mucho más sencillos y productivos, seguimos empezando a programar con editores que no tienen ninguna de estas funciones. Aunque hay librerías que se usan a nivel profesional y que facilitan mucho el trabajo, empezamos a pelo ( http://cadernodefracasos.blogspot.com.es/2016/03/explorando-xogos-facil-vs-dificil.html ) . Eso, a mi juicio, hace que nuestros productos no sean «tope gama», pero el proceso es más enriquecedor.
Uno de los artículos que enlazabas decía «Harder isn’t better», pero yo creo que «better is harder» 🙂
Interesante debate!
No sé si es necesario indicarlo, pero me gustaría resaltar que los que defendemos la programación visual para nada estamos en contra del código escrito, y comparo con Tucho la conveniencia de acercarse a el en algún momento, por lo menos para saber de qué va la cosa. Yo personalmente lo dejo para Bachillerato, aunque puntualmente con alumnado más avanzado de 4º si he trabajado algo.
En cuanto a la planificación, esto no tiene nada que ver con si el entorno es visual o de texto, o en si usas un lenguaje u otro, sino que, como bien indica Jesús, es algo en lo que la labor docente es fundamental, sea cual sea la metodología empleada. Scratch es muy motivador para los más pequeños, enseguida se lanzan a hacer cosas, y eso es muy bueno, pero para avanzar y hacer cosas más complejas es muy necesario ir marcando pautas y normas, enseñar a buscar y solucionar los errores y, sobre todo, intentar que piensen las cosas antes de hacerlas. La diferencia entre el alumnado en términos de diseño previo pienso que tendrá más que ver con como han aprendido (a su aire o con una secuenciación didáctica) que por el entrono (gráfico o textual). Habría que añadir esos ítems al experimento.
Lo que tengo claro por experiencia es que el alumnado que previamente ha manejado entornos de programación gráfica para realizar programas complejos (scratch, Lego, visualino, etc) se enfrenta mucho mejor a un lenguaje basado en texto, y sin traumas!
En mi opinión la arquitectura gráfica, es de más compresión y recepción tomando en cuenta los pasos iniciales en programación; y es que desde que nacemos la percepción de imágenes por nuestro cerebro; concentra mayores recuerdos
Lo que comenta Tucho y lo que indica María en su último párrafo es algo que se está estudiando intensamente en los últimos años, y las conclusiones de la mayoría de las investigaciones indican que parece buena idea que los alumnos aprendan los fundamentos de la programación con un lenguaje visual antes de comenzar a programar con un lenguaje basado en texto. Se han hecho experimentos con estudiantes de diferentes edades, usando distintos lenguajes y, en general, existe un consenso en reconocer este enfoque como una práctica positiva que mejora y acelera el aprendizaje.
Por cierto, María, muy interesantes tus apreciaciones en relación al posible experimento. ¿No sería fantástico que de este debate naciera un proyecto para realizar una investigación sobre estos temas? 🙂
[…] ¿Lenguajes de programación visuales o lenguajes basados en texto? […]
[…] Estos días está circulando por las redes un artículo escrito hace unos meses en el que se comparan los lenguajes de programación visuales, tipo Scratch o Kodu, con lenguajes de programación basados en texto, como Logo, que son más similares a los… […]
[…] Programamos.es: ¿Lenguajes de programación visuales o lenguajes basados en texto? […]
«Un estudio del año 2010». ¿En qué página habla de eso?
Acá no encuentro la referencia
https://books.google.com.ec/books?id=t4dCCwAAQBAJ&pg=PR6&lpg=PR6&dq=S00684ED1V01Y201511HCI033&source=bl&ots=4KVr_7111P&sig=K2qNF38ymVwlS4LQRhz6a5CHlZg&hl=en&sa=X&redir_esc=y#v=onepage&q&f=false
El enlace no era el correcto, Daniel. Gracias por el aviso. El estudio en el que se compara Logo y Scratch es éste: http://dl.acm.org/citation.cfm?id=1734383
Saludos.
Hay que darse cuenta que estas herramientas visuales ayuda a conoser los mecanismo y ademas en saber el orden para lograr lo que uno quiere y descubres cosas interesantes y es facil para crear; lo que dicen que uno no aprende programacion en realidad no es del todo sierto en realidad por que aprendes cosas siertas como for, if, x, y variables y mas pero no lo puedes usar por no sabes como se emplea con sus caracteres y eso dependiendo del lenguaje, pero si le incluyen ver el texto del lenguaje creado por los bloques hay si, y gracias a que existe esta herramienta aprendes y emplear la imaginacion por que es facil para crear sin ella no emplearan la mente ni fuera emosionante conoser el mundo de los mecanismos de la programacion.
[…] Además, los autores reclaman más investigaciones en las que se comparen los aprendizajes del alumnado utilizando diferentes tipos de lenguajes de programación (visuales vs texto, por ejemplo), algo de lo que ya hemos discutido en Programamos en alguna ocasión (ver artículo “¿Lenguajes de programación visuales o lenguajes basados en texto?“). […]
Inteligencia es la capacidad de resorber un problema, no importa como, lo importante es la eficiencia, utilizar el menor tiempo posible..
Al hilo de lo que se propone en https://twitter.com/programamos/status/1251794414206246916, continúo el debate ….
Al hilo de lo que se propone en https://twitter.com/programamos/status/1251794414206246916, continúo el debate ….
Mi opinión sobre los lenguajes de programación basados en bloques ha cambiado progresivamente. Al principio no me parecían nada serios y tenía poca confianza en ellos, pero a medida que los he ido usando he cambiado de parecer. Cuando comprobé que niños de 6 a 8 años son capaces de crear sencillos programas en poco tiempo y, además están supermotivados tuve claro la potencia didáctica que tienen. Después, descubrí algunos videojuegos espectaculares desarrollados con Scratch, como por ejemplo los que hace https://scratch.mit.edu/users/griffpatch/.Así que pienso que como lenguajes para iniciarse en la programación superan con creces a los lenguajes basados en texto. No me imagino a un niño de 7 años (que no sea un Mozart de la programación) programar y disfrutar con el más sencillo de los lenguajes basados en texto. El solo hecho de superar la barrera impuesta por la sintaxis del lenguaje ya les da una ventaja considerable respecto a los lenguajes basados en texto. Además la representación visual bidimensional que ofrecen los bloques de tipo lego ofrecen una potente metáfora al estudiante que, rápidamente encaja la estructura y el flujo del programa.
Sin embargo creo que los lenguajes de programación basados en bloques presentan, hoy por hoy, algunas carencias que les impide ser utilizados de forma profesional. La primera de esas carencias es que someterlos a control de versiones no es inmediato, y mucho menos práctico. En aplicaciones profesionales es imprescindible usar sistemas de control de versiones para mantener varias ramas de desarrollo y permitir el trabajo colaborativo en el que varios programadores pueden trabajar simultaneamente incluso sobre la misma parte del código. La fusión de código desde otras ramas y la resolución de conflictos que se producen en estas fusiones son tareas cotidianas en el ámbito profesional . Para ello es imprescindible contar con herramientas que muestren claramente las diferencias en el ódigo y donde se dan. Esto con ficheros de texto plano es inmediato, pero con bloques… no lo veo.
Otro problema que veo en los lenguajes de programación basados en bloques es lo que en un artículo que leí hace tiempo (https://arxiv.org/pdf/1705.09413.pdf) llamaban «viscosidad». Se trata de que realizar pequeños cambios en el código cuando usamos lenguajes de bloques es más costoso (coñazo) que en su contrapartida de texto. De hecho escribir una expresión algebraica en Scratch, si esta es mínimamente compleja, puede ser un trabajazo, y corregirla otro.
Otro problema para mí y desde mi experiencia es que me resulta mucho más difícil analizar el código de un programa «grande» en Scratch que el de uno «grande» en, por ejemplo, Python. Cuando estás analizando el funcionamiento de un código resulta vital poder hacer búsquedas (especialmente de variables) y hacer pequeños cambios para ver cómo afectan. Incluso a veces conviene tener abierto dos o más ficheros simultáneamente y a la vista para ir siguiendo un razonamiento. Y eso no veo cómo hacerlo con los lenguajes de bloques.
Finalmente, cuando trabajamos con lenguajes de texto podemos estructurar el código en ficheros, siguiendo arquitecturas que son escalables y permiten que el programa crezca y se pueda modificar sin que ello afecte al resto de la aplicación. Aquí las baterías de tests unitarios y de integración juegan un papel relevante. Tampoco veo cómo hacer esto con los lenguajes de bloques actuales.
Posiblemente la tendencia vaya por la senda del camino mixto; plataformas como pencilcode pero que permitan trabajar en editores locales y guardar los ficheros en formato de texto plano, de manera que podamos usar la fantástica ayuda que ofrecen los bloques sobre la sintaxis y la mejor visión que, en ocasiones, dan los bloques para entender alguna estructura o algoritmo. También es importante que se pueda alternar fácilmente entre la edición de bloques y textos. Y que la traducción de texto a bloques sea tan eficaz como la de bloques a texto. Es decir, tener la posibilidad de usar lo mejor de cada mundo.
Todo está por ver, pero lo cierto es que, aunque el fin último de un lenguaje de programación sea dar instrucciones a una máquina, la función que tienen como medio para expresar y comunicar ideas es lo que los hace más o menos útiles, y en ese sentido los lenguajes de programación basados en texto tienen muchas ventajas. El futuro (próximo) nos dirá.