APRENDER A PROGRAMAR EN LAS ESCUELAS
AULA VIVA - APRENDER A PROGRAMAR EN LAS
ESCUELAS
Adrián Somá
Propuesta para aprender a
programar en las escuelas escrito en forma de diálogo educativo.
Es obvio que hay muchísimo para debatir porque esto recién
empieza, pero propongo de entrada sumarme a lo que está sucediendo en el mundo:
¡hay que enseñar a programar en las escuelas! Sí, a programar. Y cuando digo
escuelas, me refiero a las escuelas primarias y secundarias.
Sí, es una muy buena idea-fuerza.
Hoy en nuestro país (Argentina) podemos realizar la tarea de enseñar a
programar en las escuelas. Aquí y ahora disponemos de todas las herramientas
necesarias, las mejores por cierto, para comenzar. A continuación diré, según
mi visión, qué es programar, qué es enseñar a programar y cómo llevar a cabo
tan hermosa tarea.
El artículo continuaba:
Para la gran tarea de enseñar a programar en las escuelas, gente
que sepa programar hay, pero no parecen suficientes para el número de alumnos.
Comencemos cambiando el enfoque.
En lugar de pensar el
"problema" como una Gran Tarea o Gran Empresa para la que hay que
coordinar y disponer de grandes cantidades de recursos humanos, materiales y
temporales... vamos a pensarlo como lo hace un buen programador: de modo
simple, gradual y de menor a mayor.
Luego explicaba:
Para enseñar a programar (o lo que fuere) hacen falta dos
partes: los que enseñan y los que aprenden…
Comencemos a definir nuestro "problema" que en adelante llamaremos tarea.
En lugar de "enseñar a programar" diremos que nuestra tarea es aprender a programar. Parece sutil el cambio pero más adelante veremos que no lo es.
También podríamos cambiar
la palabra "programar" por "desarrollar", pero por ahora
ese cambio es un tanto presuntuoso; luego lo haremos si hace falta. La idea es
que un Desarrollador no "hace" programas que "hacen" algo,
los "pone" en una "computadora" y luego les "da"
ejecución... sino que más bien un Desarrollador se expresa, desarrolla, hace funcionar ideas en
un espacio lógico-personal llamado espacio computacional.
Entonces... nuestra tarea es aprender a programar. Cambiamos
"problema" por tarea y enseñar por aprender.
Programar es hacer funcionar ideas (conceptos, modelos, cosas que vemos) en un espacio computacional. Como el espacio computacional es lógico, la tarea de programar o la programación es lógica y por ende la ciencia de la programación es una Ciencia Exacta.
Es común escuchar y leer otra "definición" de programación -limitada y errada para mí- muy arraigada en la mayoría de las personas, técnicos y académicos inclusive, en la que programar es "decirle" qué hacer a la compu para resolver un problema. De esta idea surge inmediatamente la necesidad de un lenguaje (de programación) para poder decirle a la compu qué queremos que haga. Y también surge, como inevitable consecuencia, que cuanto más "potente" sea el lenguaje que usemos "más" y "mejores" cosas podremos decir... Con este enfoque quedan separados el programador, el lenguaje y la computadora. El lenguaje pasa a ser la parte más importante de la programación y peor aún, se convierte en algo ajeno al programador, independiente del tema (o dominio) que está modelando, el lenguaje es externo, desarrollado por otra empresa. Dicho de otro modo, con esta "definición" de programación, el programador no puede crear, ni utilizar un lenguaje propio para cada problema o idea que quiera desarrollar.
¡Sí!
Afortunadamente en el año
1968 Dan Ingalls y Alan Kay crearon otro paradigma o teoría de la programación,
en donde no hay necesidad de un lenguaje de programación, ni el programador
está separado de la computadora... "Solo hay objetos y envío de mensajes
en un espacio computacional único-personal". Esa creación genial se llama Smalltalk, la teoría de programación más simple y productiva del mundo
que consta de solo dos nociones: objetos y envíos de mensajes. Sí, es así... con solo dos nociones se puede modelar cualquier
problema y ahí termina todo lo que hay que saber del lenguaje para empezar a
programar. Qué simple, ¿no?
¿Y cómo expresamos nuestras ideas y las hacemos funcionar?
Con Smalltalk como ya dijimos y VEO un ambiente totalmente visual para desarrollar software. VEO extiende y potencia las capacidades esenciales de Smalltalk, las hace visuales, intuitivas y muy interactivas.
Ya hemos definido
bastantes cosas; definiremos aún más.
El artículo continuaba con una pregunta:
¿Y qué pasaría si los alumnos y los docentes aprendieran juntos? Es decir, ¿Qué pasaría si todos los días los alumnos tuvieran en todos los colegios y escuelas del país, una hora en donde la educación se transforma en algo “horizontal”…? dentro de la misma escuela, habrá grupos que podrán cooperar con los que tienen más dificultades. En ese caso, las diferencias de edades y de grados y de “jerarquías” deberían quedar de lado.
Es exactamente lo que propongo y la herramienta teórica-tecnológica es esencial para lograrlo.
En un ambiente Smalltalk no hay que saber nada de antemano para programar, por lo tanto no hay alguien en sí que "sabe y enseña" y alguien que "no sabe y aprende". No hay jerarquías: es horizontal por definición.
En Smalltalk no hay ningún lenguaje
que medie entre la computadora y el programador. No hay que aprender
previamente ninguna tecnología para programar. Es un ambiente vivo, lo "abrimos"
y ¡listo! ya podemos comenzar a crear y hacer funcionar nuestras ideas o las de
los demás, siempre experimentando y aprendiendo. En general, diré que un Smalltalker (un desarrollador Smalltalk) no entiende primeramente
un "problema" en su cabeza o en un papel y luego lo programa en la
computadora, sino justamente avanza al revés: comienza a programar (a crear
objetos y mensajes) para ver y entender el problema.
Bueno... pero ¿Cómo aprendemos? o ¿Cómo sabemos que aprendemos? ¿Alguien nos guía? ¿Cómo...? Son buenas preguntas que contestaré para avanzar en nuestra
tarea.
En una herramienta tan
simple y conceptual como Smalltalk se notan mucho las debilidades y fortalezas de lo que
programamos. Fácilmente podemos ver y probar si funciona o no el modelo
construido y si la idea expresada en el programa modela bien la situación o el problema
requerido. Podemos ver y medir inmediatamente la cantidad y calidad de los
mensajes usados, la responsabilidad de los objetos diseñados, etc. etc.
Supongamos que los alumnos tienen como tarea programar o modelar un automóvil y uno de los mensajes a implementar en el Automóvil es arrancar. Al programar el mensaje arrancar el programador podría no haber considerado, por ejemplo, que un auto tiene partes y que para arrancar tiene que verificar al menos si sus partes están, si andan... Cualquier otro programador en el rol de revisor al mirar el código fuente verá inmediatamente cómo se ha diseñado el Automóvil, si tiene partes o no, si andan, etc. El programador revisor también puede probar arrancar el automóvil. Para ello solo tiene que evaluar la expresión Smalltalk: "Automóvil nuevo arrancar" y ver si hay algún error. También puede mirar el objeto automóvil (con el inspector) para ver si efectivamente el automóvil arrancó.
Es muy divertido y formativo comparar entre todos los alumnos "mejores" y "peores" diseños de autos. En mi trabajo a esta práctica obligatoria de comparar lo que programamos la llamamos Revisión de Código. Cada programador revisa el código fuente escrito por otro programador y puede modificarlo si encuentra fallas o posibles mejoras al código revisado.
Otros ejemplos de tareas de
programación podrían ser: "programar una caja de cartón", "programar
servir una mesa", "dibujar figuras geométrica", "hacer
cálculos", etc. etc... Así podremos crear, pensar y hacer funcionar
cualquier cosa que se nos ocurra y compararla entre todos. De estas
comparaciones y otras más realizadas con la red guía surgirán las medidas de avance
de nuestro aprendizaje.
La red guía (el nombre es indicativo)
La red guía es un sitio web (parte o conectado al sitio web de la escuela) en donde se registra y administra toda la información del plan "Aprender a programar en las escuelas". La red guía mantiene el registro de las escuelas, alumnos, docentes, ayudantes y profesionales vinculados al proyecto.
Los alumnos-programadores utilizarán la red guía para almacenar y compartir el código fuente de los programas que van
desarrollando, para bajar y consultar las tareas de programación a realizar, para
bajar y actualizar el ambiente de programación, etc. etc. También podrán
consultar en la red guía la revisión (por otros
programadores) de sus tareas y las medidas de su avance como programadores.
Ya estamos muy cerca de hacer
funcionar (o programar) nuestra tarea...
Revisemos todo lo que
hemos definido y explicado hasta aquí:
Desarrollo (programación)
La escuela en la que
vamos a trabajar es una escuela inscripta -le doy un nombre- en el Sistema Aula Viva - Programación Viva.
Se dictará simultáneamente en todas las aulas de la Escuela y para todos los alumnos y docentes dos horas seguidas de clase-taller de programación dos días a la semana. Cada docente de la materia o especialidad que fuere y cada alumno de la afinidad o gusto intelectual que fuere, en esas dos horas, estarán haciendo lo mismo: Programando en una computadora.
Todos los alumnos dentro y fuera de la escuela deberán disponer de una computadora propia o la distribuida por el gobierno y deberán bajar en sus casas previamente la guía de temas y tareas a desarrollar en la clase de programación. La Escuela no necesariamente debe contar con acceso a Internet para realizar la clase.
Todos los alumnos luego
de cada clase de programación, en la escuela o en sus casas, podrán subir a la red guía lo que han programado para intercambio y revisión. La red guía asignará al azar una primera revisión de código fuente
entre pares, en donde a cada alumno le tocará revisar el trabajo de
programación de otro alumno. El alumno revisor deberá probar si el código
fuente recibido funciona y sugerir correcciones si lo desea. Esta revisión
entre pares se realizará una vez por semana como mínimo.
Con el correr de las
clases los alumnos van a avanzar como programadores de modo diferente según su ritmo
de aprendizaje, interés y dedicación. Lo que producirá que algunos alumnos
estén en un punto de la guía de programación y otros estén en otro. Como toda
la escuela estará abocada a programar en las dos horas dedicadas a tal fin, los
alumnos podrán cambiarse de aula y agruparse según la tarea en la que estén trabajando
sin importar su edad, género o rol escolar.
Independientemente del avance individual, siempre hay que incentivar en cada alumno su curiosidad, su interés por descubrir cómo funciona algo, su capacidad para razonar lógicamente y principalmente su espíritu crítico, que es para mí la capacidad de crear conocimiento y destruirlo inmediatamente al comprobar que no funciona.
Los alumnos aprenderán todas
estas capacidades esencialmente cognitivas de manera práctica, siempre en
continua interacción con la computadora y con los ayudantes profesionales... quiero
decir por ejemplo, que para aprender a razonar lógicamente no se dictará una
clase teórica (de dos horas) de lógica, sino que se trabajará el razonamiento
lógico al programar. Si alguien quiere hacer andar un automóvil sin ruedas... ¡que
lo programe! Que experimente a ver qué pasa... tal vez encuentre que su automóvil
es en realidad una lancha... ¿Y para qué llamarlo automóvil?
Es muy importante
transmitirles a los alumnos y docentes que no hay ningún merito ni valor en
completar antes o después tal o cual parte de la guía de programación (o toda).
Lo que realmente importa es superarse, ayudar, aprender de los demás y
disfrutar de lo que se está aprendiendo y compartiendo en las horas de
programación.
Durante las dos horas de programación
habrá ayudantes profesionales altamente calificados que introducirán y guiarán los
trabajos de programación. La cantidad de ayudantes será la necesaria según la
cantidad de alumnos de la escuela y las posibilidades físicas del
establecimiento. Puede haber por ejemplo escuelas con anfiteatros o aulas
magnas en las que se podrá dar la clase introductoria a cada tema a una mayor cantidad de
alumnos.
La clase introductoria de
un tema ocupará a lo sumo la primera media hora de las dos horas de clase y se
hará -como toda la enseñanza- desde la computadora, proyectando su pantalla. La
clase será grabada (filmándola y con un programa de captura de pantalla) y será
subida a la red guía para consulta.
El cálculo de los ayudantes calificados que necesita una Escuela y otras consideraciones serán evaluados antes de agregar una nueva escuela al Sistema Aula Viva - Programación Viva.
Podemos notar que este sistema
de aprendizaje de programación es gradual, se desarrolla de menor a mayor y es de
crecimiento geométrico si se sostiene la voluntad y la dedicación a aplicarlo.
Los alumnos que ya avanzaron 2 o 3 niveles en la guía de programación, si lo
desean, podrán ayudar en la revisión del código fuente (a través de la red guía) a los alumnos de los otros niveles. Además, cualquier
persona puede proponer nuevos programas, temas o problemas a desarrollar y/o mandar
nuevas versiones con mejoras a los programas existentes subidos por los alumnos.
De esta manera lograremos en poco tiempo más variedad, cantidad y calidad de
ejemplos para los nuevos alumnos y todas las personas que quieran aprender a
programar.
El artículo finalizaba con otra pregunta:
¿Estamos preparados para eso? ¿Estamos preparados como sociedad
a aprender junto a y de nuestros hijos?
No sé... ¡pero sí sé y estoy absolutamente convencido! de que hoy con acciones concretas podemos comenzar a saberlo.
De mi parte ofrezco la herramienta VEO (el Ambiente Visual Vivo para Desarrollar Software) y toda mi experiencia y conocimientos para enseñar y realizar activamente el proyecto. Estoy completamente seguro de que podemos comenzar a realizarlo ya, de hecho, considero humildemente que estas páginas muestran un plan bien definido, claro y factible de ser desarrollado exitosamente.
Muchas gracias por leer la
propuesta, quedo a disposición para consultas y demostración de lo presentado.
Adrián Somá
Datos del autor: Adrián Somá - soma.adrian@gmail.com
Argentino, desarrollador,
investigador e innovador en Ciencias de la Computación. Especializado en
tecnología de objetos e interfaces visuales dinámica, vivas. Autor de VEO, un ambiente visual de objetos
vivos para desarrollar software, Aula
Viva - Aprender a Programar en las Escuelas y su trabajo más reciente VEO Live - Una plataforma de Conocimiento Vivo.
Conferencia Internacional
Smalltalks 2022 - UBA
https://smalltalks2022.fast.org.ar/speakers
Aula Viva - Aprender a programar
en las escuelas (documento actual pdf)
https://drive.google.com/file/d/1ZrbgXYhcP6IurzhiDdEhgwaNzXAyxGNk/view?usp=sharing
VEO Live - Una plataforma de Conocimiento Vivo
https://veo-live.blogspot.com/2023/03/blog-post.html
Videos de algunas habilidades de VEO (nivel técnico medio, con audio no profesional)
www.youtube.com/user/VEOAdrianSoma
Más información
www.linkedin.com/in/adrian-soma/
Artículo referencia del diálogo
http://www.pagina12.com.ar/diario/contratapa/13-219587-2013-05-09.html
Comentarios
Publicar un comentario