Pensamiento denotacional vs. pensamiento operacional y su importancia en la abstracción.
En varios posts anteriores hemos insistido con la importancia del
pensamiento denotacional por sobre el pensamiento operacional. ¿Por qué
insistimos tanto en esto? La razón, que discutiremos en este post, es
que las personas NO solemos pensar de manera operacional, sino de manera
denotacional, y por lo tanto entender y manejar los programas de manera
denotacional es fundamental para poder lograr una verdadera habilidad
de programación.
Es innegable que los programas son, en el fondo, entidades operacionales; o sea, un programa es, si lo reducimos a su forma más elemental, un elemento destinado a guiar a una máquina durante su ejecución. La forma tradicional en la que interpretamos esta naturaleza operacional es a través de una secuencia de instrucciones (aunque hoy día, con máquinas de múltiples procesadores, ya no sea cierto que un programa es simplemente una secuencia de instrucciones).
Consecuentemente, la mayoría de los cursos tradicionales de programación comienzan con esta definición, y se concentran en determinar la secuencia adecuada para resolver determinado problema. Es notable que la gran mayoría de las personas cuando se enfrentan a un problema simple de programación, empiezan por pensar de esta manera. En una conversación reciente sobre este fenómeno, un docente de programación sugirió que podía ser así por la forma en que están planteados los problemas... Es un tema fascinante que da para mayor indagación.
Sin embargo, cuando las personas pensamos en solucionar un problema, no lo hacemos de forma operacional. Si por ejemplo se plantease como problema "realizar un viaje a un país vecino", no es natural empezar pensando en levantarse de la silla, caminar hasta la puerta, subir al auto, etc., aunque estas son operaciones que DEBERÁN ser parte de la solución. Es mucho más natural para una persona pensar en algunas actividades grandes vinculadas al viaje, por ejemplo, decidir el medio de transporte, decidir el tipo de alojamiento que vamos a utilizar, decidir qué tipo de cosas vamos a llevar con nosotros. Luego, cada una de ellas involucra nuevas tareas: por ejemplo, si decidimos que el medio de transporte es por avión, deberemos reservar pasajes, decidir la forma de pago, ver cómo nos movilizaremos al aeropuerto, etc. En lugar de concentrarnos en las operaciones invididuales que serán necesarias para solucionar el problema, lo que hacemos naturalmente es *descomponer el problema en subproblemas* cuyas soluciones combinadas permitan solucionar el problema mayor. A esto es a lo que nos referimos cuando hablamos del *pensamiento denotacional*.
¿Por qué si nuestra forma de pensar es naturalmente denotacional, cuando pensamos un programa lo hacemos de manera operacional? La respuesta es simple: en la definición clásica se le da más importancia a la máquina que soluciona el problema que al problema en sí, o a su solución. Son las operaciones primitivas de la máquina las que pasan a primer plano, y para ejemplos pequeños resulta más fácil pensar en esos términos. ¿Puede hacerse de otra manera? Creemos que sí, y por eso el enfoque didáctico Gobstones utiliza otra definición del concepto de programa, y otro enfoque para comenzar a pensar los programas.
Nuestra propuesta de definición para el concepto de programa es **descripción ejecutable** de la solución a un problema computacional. Esta definición es suficientemente general, e incluye por partes iguales los aspectos denotacional y operacional. Así como no es sabio focalizarse exclusivamente en el comportamiento operacional de un programa, tampoco lo es hacerlo en el sentido opuesto: un programador tiene que formarse para poder ver *ambos* niveles y focalizarse en el que haga falta en cada momento. Sin embargo, y dado que el aspecto operacional se impone de una manera ineludible, nuestra propuesta didáctica resalta mucho más el aspecto denotacional, e intenta que el mismo sea tenido en cuenta desde el principio.
De esta forma, la propuesta incluye comenzar enseñando procedimientos (ver "¡Dame más comandos!"), que las expresiones y los comandos sean enseñados en conjunto, sin privilegiar a ninguno de ellos (ver "¿Comando mata expresión?"), que la representación de información se pueda abstraer soslayando las definiciones con bolitas (ver "¡Está lleno de bolitas! (o "It's full of stones")"), así como otra serie de elementos que permiten poner el foco en el aspecto denotacional y que serán tema de futuros posts (precondiciones, ausencia de debugging, definición precisa de nociones como parámetros o formas de repetición, etc.)
Para ir cerrando el post, creemos que la conceptualización de un programa como una descripción de la solución a un problema, o sea, su naturaleza denotacional es un elemento imprescindible en la formación de pensamiento abstracto, ya que permite soslayar detalles irrelevantes de la ejecución para concentrarse en qué solución se describe. Dicho en otras palabras, el pensamiento denotacional es una forma de abstraer los programas, y por ello es tan importante a la hora de enseñar abstracción.
Gobstones tiene esto en cuenta, y por eso es importante.
Es innegable que los programas son, en el fondo, entidades operacionales; o sea, un programa es, si lo reducimos a su forma más elemental, un elemento destinado a guiar a una máquina durante su ejecución. La forma tradicional en la que interpretamos esta naturaleza operacional es a través de una secuencia de instrucciones (aunque hoy día, con máquinas de múltiples procesadores, ya no sea cierto que un programa es simplemente una secuencia de instrucciones).
Consecuentemente, la mayoría de los cursos tradicionales de programación comienzan con esta definición, y se concentran en determinar la secuencia adecuada para resolver determinado problema. Es notable que la gran mayoría de las personas cuando se enfrentan a un problema simple de programación, empiezan por pensar de esta manera. En una conversación reciente sobre este fenómeno, un docente de programación sugirió que podía ser así por la forma en que están planteados los problemas... Es un tema fascinante que da para mayor indagación.
Sin embargo, cuando las personas pensamos en solucionar un problema, no lo hacemos de forma operacional. Si por ejemplo se plantease como problema "realizar un viaje a un país vecino", no es natural empezar pensando en levantarse de la silla, caminar hasta la puerta, subir al auto, etc., aunque estas son operaciones que DEBERÁN ser parte de la solución. Es mucho más natural para una persona pensar en algunas actividades grandes vinculadas al viaje, por ejemplo, decidir el medio de transporte, decidir el tipo de alojamiento que vamos a utilizar, decidir qué tipo de cosas vamos a llevar con nosotros. Luego, cada una de ellas involucra nuevas tareas: por ejemplo, si decidimos que el medio de transporte es por avión, deberemos reservar pasajes, decidir la forma de pago, ver cómo nos movilizaremos al aeropuerto, etc. En lugar de concentrarnos en las operaciones invididuales que serán necesarias para solucionar el problema, lo que hacemos naturalmente es *descomponer el problema en subproblemas* cuyas soluciones combinadas permitan solucionar el problema mayor. A esto es a lo que nos referimos cuando hablamos del *pensamiento denotacional*.
¿Por qué si nuestra forma de pensar es naturalmente denotacional, cuando pensamos un programa lo hacemos de manera operacional? La respuesta es simple: en la definición clásica se le da más importancia a la máquina que soluciona el problema que al problema en sí, o a su solución. Son las operaciones primitivas de la máquina las que pasan a primer plano, y para ejemplos pequeños resulta más fácil pensar en esos términos. ¿Puede hacerse de otra manera? Creemos que sí, y por eso el enfoque didáctico Gobstones utiliza otra definición del concepto de programa, y otro enfoque para comenzar a pensar los programas.
Nuestra propuesta de definición para el concepto de programa es **descripción ejecutable** de la solución a un problema computacional. Esta definición es suficientemente general, e incluye por partes iguales los aspectos denotacional y operacional. Así como no es sabio focalizarse exclusivamente en el comportamiento operacional de un programa, tampoco lo es hacerlo en el sentido opuesto: un programador tiene que formarse para poder ver *ambos* niveles y focalizarse en el que haga falta en cada momento. Sin embargo, y dado que el aspecto operacional se impone de una manera ineludible, nuestra propuesta didáctica resalta mucho más el aspecto denotacional, e intenta que el mismo sea tenido en cuenta desde el principio.
De esta forma, la propuesta incluye comenzar enseñando procedimientos (ver "¡Dame más comandos!"), que las expresiones y los comandos sean enseñados en conjunto, sin privilegiar a ninguno de ellos (ver "¿Comando mata expresión?"), que la representación de información se pueda abstraer soslayando las definiciones con bolitas (ver "¡Está lleno de bolitas! (o "It's full of stones")"), así como otra serie de elementos que permiten poner el foco en el aspecto denotacional y que serán tema de futuros posts (precondiciones, ausencia de debugging, definición precisa de nociones como parámetros o formas de repetición, etc.)
Para ir cerrando el post, creemos que la conceptualización de un programa como una descripción de la solución a un problema, o sea, su naturaleza denotacional es un elemento imprescindible en la formación de pensamiento abstracto, ya que permite soslayar detalles irrelevantes de la ejecución para concentrarse en qué solución se describe. Dicho en otras palabras, el pensamiento denotacional es una forma de abstraer los programas, y por ello es tan importante a la hora de enseñar abstracción.
Gobstones tiene esto en cuenta, y por eso es importante.
