6. No me dejan imprimir... (o "I/O considered harmful")

Las razones por las que NO se debe incluir E/S en un curso inicial.

  Una característica fundamental de Gobstones es que carece completamente de comandos de "entrada/salida" (o sea, comandos para leer información del teclado y para imprimir información por una pantalla -- excepto en el modo interactivo, pero ese es tema de otro post). Esta es una característica totalmente intencional.

   La razón fundamental para esta decisión tan controversial tiene que ver con la manera en que queremos que los programas sean comprendidos, y con una forma particular de pensarlos: según su naturaleza denotacional.
   Como hablamos en "La importancia de empezar por los procedimientos", los programas tienen dos formas de ser comprendidos:

1. la *naturaleza operacional*, o sea, qué es un programa desde el punto de vista de la máquina
2. la *naturaleza denotacional*, o sea, qué es un programa desde el punto de vista de las personas que lo leen.

   La naturaleza operacional permite entender a un programa como una secuencia de instrucciones compleja, y se focaliza en la forma en que el programa ejecuta, las formas concretas en las que la información se representa. Esta forma es compleja de entender para una persona cuando el programa tiene más de unas docenas de líneas, y es normalmente complejo tratar de deducir lo que un programa hace contenmplando solo esta forma. Sin embargo, es útil para, por ejemplo, poder hacerse una idea del tiempo que demandará ejecutar el programa.

   La naturaleza denotacional, por otra parte, permite entender a un programa como una transformación de información, y se focaliza en los efectos que el programa tendrá luego de completar su ejecución. Esta forma es normalmente la que es interesante para las personas, pues permite entender al programa como la solución a un problema (transformar cierta información en otra distinta) y analizar sus características, sin importar lo que las instrucciones individuales hagan. (Para los veteranos de la programación, esta forma se conoce usualmente con la denominación de "programa como caja negra", haciendo alusión a la caja negra de los aviones. Sin embargo creemos que esta denominación es inadecuada y confusa.)

   Volviendo al tema de este post, la posibilidad de poner comandos de entrada/salida (E/S) en un programa hace que el programador se focalice casi exclusivamente en la naturaleza operacional del mismo, olvidando o soslayando la naturaleza denotacional.
   Puesto que el objetivo del enfoque didáctico Gobstones es que los estudiantes de programación adquieran la capacidad de entender a sus programas como transformaciones de información, es necesario que los comandos de E/S no sean parte del repertorio de herramientas a utilizar.

   Para reemplazarlo, las herramientas que implementan Gobstones (PyGobstones, al momento de escribir este post) utilizan como mecanismo de comunicación la visualización del tablero antes de que corra el programa (*el tablero inicial*) y la visualización del mismo después que el programa finalizó (*el tablero final*). Esto permite destacar al programa como una forma de conseguir que el tablero inicial se transforme en el tablero final, sin que importe el orden en que los pasos individuales necesarios para lograr tal transformación son realizados.
   Creemos que la naturaleza denotacional de un programa requiere mayor aprendizaje y entrenamiento para ser adecuadamente comprendida que la naturaleza operacional. Por esa razón, los comandos de E/S, que enfatizan la segunda y dificultan la conceptualización de la primera, fueron removidos de Gobstones.

   Y esta es la razón fundamental para que Gobstones no tenga E/S: la secuencia Gobstones busca formar pensamiento de naturaleza denotacional, abstracta. Y para eso, la E/S es dañina.

  Continuaremos en futuros posts analizando las características de Gobstones.

5. ¿Comando mata expresión?

La base aparentemente imperativa de Gobstones.

  Una cuestión de Gobstones que llama la atención a muchos expertos, especialmente en estos tiempos de programación funcional y programación con objetos, es el hecho de que su base es, en principio, imperativa, a través de comandos que modifican el estado del tablero.
   Sin embargo, Gobstones solo es imperativo en apariencia. La parte imperativa viene dada por los comandos, utilizados para describir acciones y modificaciones sobre el tablero (o sea, serían los "verbos" del lenguaje); pero Gobstones también tiene una parte importante del lenguaje dedicada a la descripción de valores y datos, de información: las expresiones (que serían los "sustantivos" del lenguaje).

  Con respecto a la parte imperativa del lenguaje, la misma tiene varias características que hacen que sea más simple de entender, y que permiten que los conceptos fundamentales se puedan aislar de los demás y así comprenderlos de manera separada del resto. Esto facilita el aprendizaje de dichos conceptos.  Por ejemplo, los parámetros en los procedimientos se entienden como un valor que se fija en cada invocación del procedimiento, y que permanece inmutable durante la ejecución resultante de dicha invocación. De esta manera, los parámetros se diferencian con claridad de las variables, concepto relacionado pero diferente (volveremos sobre este punto en futuros posts).
  También cada una de las formas de combinar comandos aparecen en una forma pura, y razonable para la secuncia didáctica: repetición simple (repeat), alternativa condicional (if-then-else), repetición indexada (foreach), alternativa indexada (switch) y repetición condicional (while), son las únicas formas de combinación (además de la secuencia y los procedimientos).
  Y para ser puros, los comandos no pueden devolver información, pues su única tarea es describir acciones, y no información.
  Por otra parte, las variables no representan espacios de memoria, sino que representan asociaciones temporales entre un valor y un nombre. Cuando se empiezan a agregar estructuras de datos (en XGobstones), las mismas se agregan con esa misma filosofía y eso hace que Gobstones no sea tan imperativo como puede parecer a primera vista.

  Con respecto a la descripción de información, se utilizan las expresiones y funciones, que son elementos puros (o sea, no modifican el tablero), lo que permite pensarlos de manera totalmente independiente de los comandos y procedimientos, y entender su utilidad para describir valores y datos. También volveremos sobre este punto en futuros posts.

  Esta clarísima separación entre "verbos" y "sustantivos" hace que el aprendizaje logrado con Gobstones sea transversal a los paradigmas. Si luego de aprender Gobstones, queremos que los estudiantes aprendan un paradigma funcional, simplemente nos concentramos en la parte de las expresiones, y dejamos los comandos completamente de lado. Si en cambio queremos que aprendan un lenguaje imperativo, dejamos las expresiones en 2do plano y nos concentramos en los comandos. Y si queremos que aprendan un lenguaje orientado a objetos, combinamos ambos, expresiones y comandos, incorporando los comandos como parte de los datos. 
  De esta forma conseguimos que Gobstones sea general y transversal a cualquier paradigma, cumpliendo así con uno de los objetivos originales, y mostrando que la separación de conceptos es fundamental para un aprendizaje como el propuesto.

   Es posible empezar con un lenguaje que no tenga estas características (por ejemplo, que tenga parámetros como espacios de memoria, otras formas de pasaje de parámetros, funciones con efectos, etc.) pero en nuestra experiencia es más complejo para los estudiantes comprender las ideas fundamentales cuando no aparecen en forma pura y además es luego más costoso enseñar a pensar con otros paradigmas.

  Por esa razón, si bien Gobstones tiene base aparentemente imperativa, la realidad es que su base es dual, y transversal; queremos resaltar que éste es uno de los elementos que hacen de Gobstones lo que es.

4. ¿Qué me importan las bolitas?

El universo de discurso de Gobstones.

 

  Una de las características distintivas del lenguaje Gobstones es su universo de discurso: el tablero, las bolitas y el cabezal. En este post discutiremos el por qué de la elección de este universo, así como las desventajas de otros universos, tanto específicos (como puede ser el de Logo) como generales (como es el de los lenguajes de programación generales como Python, Java, etc.).

  Comencemos con una afirmación básica: para programar se necesita un autómata capaz de expresar soluciones a problemas de manera mecánica, y que este autómata sea reconfigurable a través de diferentes descripciones ejecutables (programas).

  En el caso de los lenguajes de propósitos generales tradicionales, el autómata es una computadora de arquitectura von Neumann (memoria y procesador), y las soluciones se expresan en términos de modificaciones a la memoria, que es donde los datos se expresan mediante representaciones abstractas.
  Este modelo, si bien poderoso, es demasiado abstracto para comenzar a aprender a programar (con consecuencias indeseables en la forma en que los estudiantes perciben la disciplina). Y puesto que el objetivo de la secuencia Gobstones es formar la capacidad de expresar abstracciones, comenzar con un modelo demasiado abstracto pone una barrera inicial muy alta, lo cual provoca frustración en los estudiantes. Es, entonces, casi una decisión obvia que se hace necesario un tipo de autómata más simple, con un universo de discurso más concreto.

  Ahora bien: ¿qué autómata y qué universo? Esta pregunta ha sido formulada muchas veces antes, y respondida de diversas maneras.

  Por ejemplo, en el caso del lenguaje Logo se decidió que el autómata fuese una "tortuga" que se podía desplazar tanto dejando una línea a su paso, como sin dejarla. De esta manera, las tareas a resolver son la realización de dibujos diversos. Este modelo es bien concreto, pero su problema fundamental es que es *demasiado* concreto: es complejo migrar de estos dibujos a representaciones más abstractas, además de que no hay una correspondencia clara con modelos más abstractos. Por otra parte, para la realización de dibujos de cierta complejidad hacen falta conocimientos básicos de geometría y no poca manipulación numérica.
  Es por ello que el modelo provisto por Logo también resulta inadecuado para comenzar a aprender a programar más allá de los rudimentos más básicos.

  También podemos considerar herramientas/lenguajes como Scratch o Alice, donde el universo de discurso viene dado por un "lienzo" (en 2 o 3 dimensiones, según la herramienta) donde se pueden combinar diversos "actores" (elegidos de una biblioteca predefinida). Las tareas ahora resultan más ricas, puesto que se pueden expresar dominios diversos en términos de los actores, y no dependen prácticamente de conocimientos previos de geometría o matemáticas (aunque ciertas tareas lo requieran, las mismas usualmente se pueden evitar al comienzo).
  Sin embargo, estos modelos también resultan demasiado concretos, pues las abstracciones ya vienen provistas, y el estudiante solo las manipula. Por otra parte, están pensados, en general, para guiar a los estudiantes a aprender el paradigma de orientación a objetos, lo cual, como establecí en posts anteriores (Por qué Gobstones es importante), no es lo suficientemente general (ya que otras formas poderosas de programación, como la Programación Funcional, no son fácilmente expresables en términos de objetos). Es por ello que también estos modelos resultan inadecuados.

  En Gobstones elegimos que el universo de discurso sea un tablero y bolitas, junto a una máquina, denominada "cabezal", que puede realizar modificaciones al tablero. De esta forma, las tareas se expresan en términos de bolitas sobre el tablero.

  ¿Qué ventajas proveen un tablero y bolitas? Decidimos usar este universo de discurso por varias razones:

1. es lo suficientemente concreto para que los estudiantes se lo puedan imaginar con sencillez, aún sin tener desarrolladas formas avanzadas de pensamiento abstracto.
2. es lo suficientemente abstracto para permitir su utilización en la representación de numerosos problemas de diversa índole.
3. permite una transición gradual de formas e ideas concretas a formas e ideas abstractas.

  En su forma más concreta se lo puede entender de manera similar al lienzo de Logo, pero con la gran diferencia de que no se limita a eso y puede vérselo de otras maneras (además de que un tablero es mucho más "discreto" que un lienzo, que podría entenderse como más "analógico"). De hecho, dado un tablero suficientemente grande, Logo podría ser expresado en términos de Gobstones, pero con un tablero de Gobstones podemos expresar muchas otras cosas que no serían fáciles de expresar con un lienzo de Logo.

  En su forma más abstracta, el tablero puede entenderse como una memoria de computadora von Neumann, donde las bolitas codifican elementos abstractos.
  Sin embargo, la decisión de si se lo verá de manera concreta o abstracta no está prefijada, y es el docente el que elije en cada momento desde qué "distancia" (conceptual) se "mirará" el tablero. Además, es posible diseñar herramientas que ayuden en la adecuada manera de "mirar" y favorezcan la explicitación del uso de la abstracción (lo cual será tema de posts futuros).

  El último elemento del universo de discurso de Gobstones es el cabezal. Es el autómata que realiza las tareas. Sin embargo, esta máquina no se visualiza en ningún momento, favoreciendo el hecho de que la ejecución es un proceso abstracto y rara veces observable. Los programas deben razonarse por las transformaciones que producen sobre los elementos del universo de discurso (ya sean, o bien efectos sobre un estado, o bien transformaciones de información). La naturaleza del cabezal favorece este tipo de razonamiento (volveremos sobre este punto en futuros posts).

  Podrían proponerse quizás otros universos de discurso que sirviesen a los mismos objetivos. El enfoque didáctico de Gobstones no precisa de las bolitas de manera imprescindible. Sin embargo, sí es necesario un universo de discurso que posea las características enunciadas (suficientemente concreto, pero a la vez suficientemente abstracto) para que el enfoque didáctico Gobstones se manifieste en su máximo potencial. Nuestra decisión fue por la de un tablero y bolitas, y demostró ser extremadamente adecuada.

  En futuros posts continuaremos analizando las características que hacen que Gobstones importe.

3. ¡Motívame otra vez!

Las herramientas son hijas de la necesidad.

 

  Una de las características más importantes de el enfoque didáctico Gobstones surgió de manera natural durante los primeros dictados que hicimos de la misma, y no está vinculada estrictamente con la temática técnica de la programación. Nos referimos a la manera de presentar cada concepto y herramienta nueva: en lugar de simplemente explicar el concepto y luego ver cómo se puede aplicar, la idea es que antes de presentar un concepto o herramienta específica se propone a los estudiantes un ejercicio que resulte o bien complejo o bien imposible sin dicha herramienta, y se les permite intentar solucionarlo con las herramientas que tienen hasta ese momento. Luego de que los estudiantes han conseguido una solución, o se han frustrado por la imposibilidad de encontrarla, recién entonces se propone la nueva herramienta. Aprendimos luego que esta forma de trabajo tiene un nombre en pedagogía: aprendizaje por indagación.

  Al hacerlo de esta manera, los estudiantes experimentan a través de su propia experiencia la utilidad de la herramienta, y el concepto involucrado se fija con muchísima más facilidad que si sólo se explicase de manera teórica. En cursos con estudiantes de secundaria (14 años), sin formación previa en programación, luego de haber utilizado esta técnica un par de veces, los estudiantes pedían una herramienta nueva (y en algunos casos hasta dedujeron la herramienta necesaria), mostrando de esa manera que comprendían perfectamente la motivación provista por los ejercicios propuestos.

  Por ejemplo, antes de presentar el concepto de repetición simple (repeat), se les proponen problemas que requieren utilizar secuencias de cientos o miles de comandos idénticos (como ser, realizar un programa que coloque 1000 bolitas rojas en la celda actual), lo cual, con las herramientas manejadas hasta ese momento (comandos primitivos, secuencias, procedimientos simples) es engorroso, pues requiere 1000 copias en secuencia del comando Poner (los más adelantados en ocasiones lo solucionan con 100 procedimientos que colocan 10 bolitas, o 10 procedimientos que colocan 100 bolitas, mostrando así que entendieron perfectamente el uso de procedimientos -- volveremos sobre este tema y su utilidad para enseñar otros conceptos en futuros posts; otros descubren que pueden hacerlo con la herramienta 'copiar&pegar' del editor de texto, mostrando que sólo falta que formalicen ese concepto en una herramienta específica -- el repeat).
  Esto mismo se hace con todos los conceptos: procedimientos, alternativa condicional, repetición condicional, parámetros, etc. Por ejemplo, en el caso de procedimientos, cuando solo poseen comandos primitivos y secuencia, se les propone como ejercicio que dibujen un cuadrado, luego dos cuadrados y luego cuatro cuadrados. El programa resultante es una enorme secuencia incomprensible de comandos primitivos, y ahí se presenta la herramienta de definición de procedimientos, como una forma de definir nuevos comandos -- en este caso DibujarCuadrado(). Luego se les pide que vuelvan a realizar la solución, pero esta vez utilizando la nueva herramienta y se analiza la nueva solución -- que ahora solo tiene 4 comandos básicos.

  Sorprendentemente, esta forma de enseñar resulta mucho más difícil para personas que ya traen conocimientos previos de programación, pues al conocer la herramienta que se pretende motivar u otras que también sirven para solucionar el problema, tienen dificultades para imaginar soluciones simples, que no utilicen más que los conceptos básicos presentados hasta ese momento.
  Entendemos esta dificultad como una falencia de la forma tradicional de aprender a programar, que da por sentadas todas las herramientas de programación en lugar de motivarlas, y que privilegia algunas soluciones sobre otras, sin tener en cuenta el contexto en el que se inscribe la solución propuesta. Un ejemplo de esto se vé con la idea de variable como espacio de memoria: al programar en un contexto funcional, donde no existe memoria (y consecuentemente las variables no describen espacios de memoria), los programadores tradicionales tienen muchísimas dificultades para imaginar soluciones adecuadas, incluso ante programas sencillos. Estamos convencidos que el ejercicio de intentar encontrar soluciones con un conjunto limitado de herramientas es extremadamente adecuado para la formación de habilidades genéricas fundamentales para programar en cualquier paradigma.

  Como dijimos, el aprendizaje por indagación no está vinculado técnicamente a la temática de la programación. Sin embargo hemos comprobado que es tan útil e importante, que creemos que es otro de los pilares sobre los que se construye el enfoque didáctico Gobstones.

2. ¡Dame más comandos!

La importancia de empezar por los procedimientos.

 

  Si miramos el enfoque didáctico y el currículum presentado en el post anterior, "¿Por qué es importante Gobstones?", vemos que inmediatamente después de presentar la idea básica de comandos primitivos, secuencias y bloques, el siguiente concepto que se presenta es el de procedimientos (en su forma simple, es decir, sin parámetros). Este es uno de los *pilares fundamentales* del enfoque didáctico Gobstones.

  El concepto de procedimiento es una de las herramientas de abstracción básicas de cualquier lenguaje de programación, y creemos firmemente que un curso inicial de programación que pretende formar el pensamiento abstracto debe comenzar con este concepto como el primero y más importante de los conceptos presentados.

  Un procedimiento es una herramienta del lenguaje que permite que el programador defina nuevos comandos en términos de los anteriores, y de esa manera exprese las subtareas que identificó como parte del planteo de una estrategia de solución para el problema a resolver, *pero en términos del problema* y no en términos de la máquina que lo resuelve y sus comandos primitivos. (Posteriormente en el enfoque didáctico Gobstones se presenta la noción de función, que expresa la misma noción en el mundo de las expresiones).

  En el caso de Gobstones, los comandos primitivos hablan de bolitas (ya tocaremos el tema del universo de discurso en próximos posts), pero la gran mayoría de los problemas que se presentan (todos, con excepción de los primeros ejemplos de introducción) hablan de otros elementos: pueden ser dibujos u otras entidades, tales como piezas de ajedrez, flores, animales, etc., expresados mediante determinadas combinaciones de bolitas. Entonces, en lugar del comando Poner(Rojo) sería interesante contar con el comando PlantarFlor() que abstrae el hecho de que la flor se representa con una bolita roja, y comunica la intención del programador para esa bolita roja. Este comando puede ser definido por el programador a través de un procedimiento. Por este medio se consigue que la bolita roja adquiera para el lector del programa un significado especial (en este caso, representar a una flor). Posteriormente, si se decide cambiar la representación de la flor a 2 bolitas rojas y 1 verde, solo hace falta cambiar la implementación de PlantarFlor() para que ponga esa cantidad de bolitas, pero el resto del programa no se vería afectado, pues utiliza el nuevo comando PlantarFlor() que se expresa en términos del problema y no de la representación subyacente.

  Es un hecho conocido por todo programador, aunque no siempre explicitado, que los programas tienen una naturaleza dual: son al mismo tiempo una prescripción de bajo nivel en términos de las primitivas de la máquina de qué pasos deben ejecutarse para solucionar el problema (la *naturaleza operacional* de un programa) y una descripción de alto nivel de las ideas que se combinan para obtener dicha solución en términos del problema (la *naturaleza denotacional* de un programa).

  Los *cursos tradicionales* se focalizan en la definición de programa como secuencia de instrucciones, haciendo hincapié en la *naturaleza operacional* de los programas (el programa como prescriptor de una ejecución en términos de las primitivas de la máquina), y poniendo como centro de atención a la máquina que resuelve el problema, en lugar de al problema en sí, o a la persona que lee el programa.

  Nuestra elección de empezar por procedimientos en la *secuencia didáctica Gobstones* permite conceptualizar a los programas como descripciones de solución a un problema en términos de los conceptos del problema, enfatizando la *naturaleza denotacional* del programa (el programa como descripción de una solución en términos del mismo problema) abstrayendo el hecho de que es la máquina la que soluciona el problema, y comenzando así a adquirir la capacidad de explicitar el proceso de abstracción mediante herramientas del lenguaje.

  Estamos totalmente convencidos que si queremos formar pensamiento abstracto, el proceso de abstracción debe ser explícito desde el mismísimo comienzo del aprendizaje. Y la mejor manera de lograr esto es a través del uso de las herramientas de abstracción provistas por cualquier lenguaje de programación.

  Por eso los procedimientos, y su tempranísima utilización, son quizás la mayor contribución de la secuencia didáctica Gobstones. No debe descuidarse este hecho, ni restarle la más mínima importancia.

  Para Gobstones, los procedimientos importan.

1. Por qué Gobstones es importante (o "Why Gobstones matters")

El enfoque didáctico Gobstones.

  Comienzo este blog para ir volcando las razones tras las decisiones que nos llevaron al diseño de Gobstones con la idea de, por un lado, explicitarlas, por otro, documentarlas, y finalmente, para fortalecerlas a través de la discusión. Hay muchos aspectos a tratar especialmente respecto de qué características (o su ausencia) son fundamentales a la propuesta de este enfoque didáctico, sin las cuales no sería Gobstones. También vale la pena discutir sobre el objetivo original de esta propuesta, y cómo se amplió con el tiempo, y qué características deben cambiar para ello. Finalmente, hay cuestiones relacionadas con las herramientas de soporte, y cómo éstas contribuyen a realzar la secuencia Gobstones.

  Lo primero a considerar es el objetivo básico original de Gobstones, y su contexto, para situar las decisiones y apreciar el valor de las características elegidas para lograr el objetivo.

  El *objetivo primario* del enfoque didáctico Gobstones es servir para que una persona con cero conocimientos previos de programación pueda *aprender los conceptos fundamentales* vinculados con esta disciplina, de manera tal de ser capaz de solucionar problemas sencillos mediante el uso de programas. Para este aprendizaje no necesita conocimientos previos de matemáticas ni de lógica, aunque es útil si los tiene.

  La *idea fundamental* detrás del aprendizaje propuesto es *formar la capacidad de pensar en términos de abstracciones*, siendo capaces de explicitar las mismas y expresarlas en términos de herramientas básicas de lenguajes de programación. Y como objetivo adicional, los conceptos aprendidos deben ser lo suficientemente generales y transversales para permitir posteriormente el aprendizaje de cualquier forma de programación (o sea, de cualquier lenguaje en cualquier paradigma).

  El propósito original de Gobstones fue servir en un primer curso universitario de programación con la intención de sentar las bases conceptuales sobre las que las siguientes materias construyesen conocimientos más específicos. Sin embargo, Gobstones demostró ser útil también para jóvenes de nivel secundario, y también tener algunas características que lo hacen interesante incluso para personas que no tienen intenciones de volverse programadores.
  El enfoque Gobstones sirvió como una de las bases de inspiración para las propuestas de la Iniciativa Program.AR, y el lenguaje Gobstones forma parte del conjunto de herramientas de aprendizaje recomendadas como parte de esta iniciativa. Estamos trabajando activamente en mejorar tanto el lenguaje como las herramientas asociadas. Además, Gobstones es el lenguaje elegido por Mumuki para la enseñanza de los fundamentos de la programación. Puede encontrarse toda la información sobre Gobstones en el sitio oficial, o alternativamente, en la página de Gobstones en Github.

  El enfoque didáctico propuesto con Gobstones es osado: elimina elementos que muchos programadores consideran imprescindibles (como variables -- al menos por buena parte del curso --, E/S, estructuras de datos, etc.) y resignifica otros usualmente tratados como accesorios (como los procedimientos o los parámetros) o totalmente ignorados en cursos tradicionales (como las precondiciones). Además hace énfasis desde el principio en cuestiones de estilo (buena elección de nombres, indentación, comentarios) que otros cursos introductorios no resaltan o simplemente lo dejan librado al azar.

  Todas estas cuestiones hacen que Gobstones importe y vale la pena detenerse en las mismas. En próximos posts desarrollaremos dichas ideas. La intención es que haya un post por semana, aproximadamente, y que se puedan generar discusiones interesantes a partir de cada uno, porque Gobstones importa.

PD: El currículum propuesto por este enfoque didáctico (resumido) es el siguiente:

1. Comandos primitivos, secuencias, bloques.
2. Procedimientos simples. Contratos: propósito y precondiciones.
3. Cuestiones de estilo: comentarios, indentación, elección de nombres.
4. Repetición simple.
5. Alternativa condicional.
6. Expresiones.
7. Funciones simples.
8. Parámetros.
9. Repetición indexada.
10. Repetición condicional. Recorridos simples.
11. Variables y memoria. Recorridos más complejos.

TRANSVERSALMENTE: Modelos de Representación, codificación vs. visión abstracta.

  Para ver el currículum completo y detallado, consultar el libro "Las bases conceptuales de la programación".