[Venimos de Herr Frankenstein] El dilema de enfrentarse a ser un moderno Prometeo debería ser algo que esté en la primera línea de nuestras preocupaciones en estos tiempos que corren…nunca es gratuito querer jugar a ser Dios. No podemos obviar nuestra responsabilidad al momento de "liberar" nuestras creaciones al mundo, y sobre las eventuales consecuencias que ello puede acarrear (aunque la realidad parece desmentir este acerto).
Por suerte Pier no será de esas criaturas que se vuelven contra su creador: él simplemente se siente "desbordado" al vislumbrar el horizonte de posibilidades que se le presentan…, y por esta vez creo que será conveniente esperar a que se compense anímicamente antes de llamarlo de nuevo a la acción.
El tema que cubriremos en la página presente y en la subsiguiente es el de la comunicación entre scripts (siempre que sean parte de un mismo proyecto) mediante el envío de mensajes. Recordemos algo mencionado oportunamente: bajo Scratch es posible que los objetos tengan varios scripts asociados, los que pueden estar o no corriendo simultáneamente… la cuestión por ver es cómo lograr que puedan trabajar mancomunadamente e interactúen entre sí.
Para presentar el tema volveremos a apelar a la creación de un mini-proyecto "paralelo" a aquel que tantos desvelos nos deparó durante los primeros 3 pasos —y al que ya retornaremos cuando dominemos con cierta soltura estos nuevos conceptos y su aplicación práctica—. Nuevamente haremos una pequeña animación controlada por el mouse y por el teclado, pero no la protagonizará Pier (por razones obvias…)
Quien protagonizará esta saga será un personaje al que bien le cabría el mote de "un guerrero de mil batallas": el gato de Scratch. Él va a pasearse por el escenario hasta que lo detengamos tocándolo con el puntero del mouse; lo hará 2 veces en respuesta a dos criterios de programación distintos, y en la segunda oportunidad además de caminar nos maravillará con una serie de trucos visuales que nos tendrá preparado, los que sólo cesarán si se presiona la barra espaciadora por al menos 1 segundo… ¿complicado? Si.
Hablando con gestos
Así como dije que el tema de la entrada por teclado en Scratch me parecía de simple comprensión (aunque su implementación dentro del programa podía exigirnos voluntad y paciencia), ahora digo que la capacidad de envío de mensajes entre scripts puede parecer engañosamente simple… alguna que otra vez he cliqueado la banderita verde casi con suficiencia ¡para encontrarme con un resultado no previsto!
Primero una aclaración —que es la misma que les hago a mis pequeños alumnos al explicar este tema—: me parece más apropiado que, en vez de estar pensando en la idea de envío de mensajes, intentásemos visualizar este mecanismo de comunicación como el de un intercambio de señas, de guiños o de gestos entre los scripts del proyecto.
Estos "gestos" les permitirán sincronizarse y dar un ordenamiento temporal a sus acciones, casi como el necesario entre un grupo de músicos o de actores haciendo lo suyo sobre un escenario (no el escenario virtual de Scratch precisamente). Y al igual que lo que ocurre entre las personas, perder esta sincro puede ocasionar resultados no deseados.
Entraremos ahora de lleno en el análisis de los mecanismos que se ponen en juego al ser enviado un mensaje.
¿Una estación de radio en Scratch?
Para empezar: desde cualquier script de cualquiera de los objetos de un proyecto puede enviarse o "irradiarse" un mensaje a todos los scripts restantes —mantendremos, más allá de nuestra consideración previa, la denominación mensaje que en Scratch se da—.
Cuando decimos irradiar es porque de alguna forma la acción es comparable a la de un canal de radio o TV de aire: desde un punto se transmite un mensaje que puede ser captado por innumerables receptores (si es que tienen los medios o si están preparados para recibirlo). Esto nos indica que no es una transmisión "selectiva" entre dos o más scripts, que dejan de lado al resto.
NOTA
En el idioma original de Scratch (el inglés) no hubiese sido necesaria tanta explicación: el bloque de envío se denomina broadcast (emitir, transmitir, aplicado dentro del ámbito de la radiodifusión).
Usando un parangón más moderno, podríamos comparar el envío de un mensaje con el envío de un tweet (de Twitter estamos hablando): cualquiera puede recibirlo, aunque la mayoría de los potenciales receptores quizás no estén interesados en el mismo —la selección la hace el receptor—.
La simplicidad de la propuesta de comunicación usada en Scratch 1.4 se refleja en la cantidad de bloques involucrados en el mecanismo: sólo tres.
Dos estarán dedicados a la transmisión, sólo uno es usado para la recepción (y es un bloque tipo sombrero).
Dos estarán dedicados a la transmisión, sólo uno es usado para la recepción (y es un bloque tipo sombrero).
Algunas consideraciones:
- Es posible la generación de la cantidad de mensajes que querramos dentro del proyecto, por supuesto cada uno convenientemente identificado con su propio nombre.
- Desde cualquiera de los tres bloques mencionados resulta posible la creación de un nuevo mensaje, tal como se muestra en la imagen (el proceso es más que simple y no abundaré en mayores detalles).
- Es importante tener en cuenta que los mensajes no son "propiedad" de un objeto o de un script: son señas o gestos que pueden ser usados y reusados por todos los scripts tantas veces como sea necesario (¿jugaste alguna vez al truco?).
¿Estaciones de radio que se dediquen al envío de señales o gestos de indubitable interpretación? No es algo imaginable en el mundo real donde vivimos, lleno de intereses, dobles sentidos y subjetividades colonizadas. Pero en el mundo Scratch funciona… ¡aprovechémoslo!.
El dilema de ¿transmitir y después qué?
La existencia de dos posibilidades a la hora de enviar un mensaje —cada una de ellas en correspondencia con cada uno de los bloques de envío— nos enfrenta con una lógica serie de preguntas…
- ¿cuál bloque usar y por qué?
- ¿que implicancia tendrá la elección de uno u otro bloque en el comportamiento de nuestro proyecto?
Desde aquí haremos nuestro pequeño aporte para clarificar un poco este tema, que suele ser una fuente habitual de conflictos y de dudas al momento de programar. El envío de mensajes puede servir para muchas cosas, entre ellas separar la ejecución de un proyecto en etapas, o el poder generar algoritmos que basen su funcionamiento en la idea de subrutina (what?)
- Subrutina
-
En computación, una subrutina o subprograma (también llamada procedimiento o función), como idea general, se presenta como un subalgoritmo que forma parte del algoritmo principal, el cual permite resolver una tarea específica.
Una subrutina al ser llamada dentro de un programa hace que el código principal se detenga y se dirija a ejecutar el código de la subrutina.Fuente: Wikipedia
Frenemos un poco aquí: el concepto de subrutina es de vieja data y está más vinculado a lo que podríamos llamar "lenguajes de programación tradicionales", los que no contemplaban la idea de varios hilos de ejecución… —recordemos que Scratch si lo hace—
Un hilo es básicamente una tarea que puede ser ejecutada en paralelo con otra tarea.
Fuente: Wikipedia
Si queremos aprovechar la idea de subrutina para trabajarla dentro de Scratch 1.4, deberemos revisar la definición que mostramos previamente:
- El primer párrafo sigue manteniendo su validez, y apunta al núcleo conceptual que queremos aprovechar… pensar una subrutina como un algoritmo "secundario" que permite resolver una tarea específica. Quizás lo que sea más discutible es hablar de un algoritmo principal dentro de Scratch (ya que sólo cuando no hay más que un hilo de ejecución tiene sentido hablar de algoritmo principal).
- El segundo párrafo (recortado del original) ya deja de ser estrictamente válido en Scratch: lo que allí se llama "código principal" —para nosotros el algoritmo que ejecuta el envío del mensaje— podrá detenerse o no según sea el tipo de bloque de envío que sea utilizado.
Llegamos a la médula del asunto. Cuando desde un algoritmo querramos enviar un mensaje nos enfrentaremos a dos posibilidades:
- que inmediatamente después del envío permitamos que este algoritmo siga procesando las instrucciones subsiguientes, o
- hagamos que este algoritmo se detenga momentáneamente, quedando el mismo en modo de espera hasta que los scripts que reciban el mensaje (y "se accionen" en consecuencia) terminen su proceso, momento a partir del cual volverá a retomar su trabajo.
El segundo caso es el que se asemeja más al concepto primigenio de subrutina, ya que existirá una "transmisión de mando" que va desde el algoritmo transmisor hacia el/los algoritmo/algoritmos receptores.
Esta opción presupone en principio que el control volverá eventualmente al algoritmo desde dónde se inició la transmisión.
Esta opción presupone en principio que el control volverá eventualmente al algoritmo desde dónde se inició la transmisión.
El primer caso sólo es posible de ser planteado a partir de la capacidad del entorno de manejar múltiples hilos de ejecución (se pueden "correr" varios scripts simultáneamente), algo que representa una enorme ventaja potencial pero que puede dificultar el mantenimiento de un férreo control sobre el comportamiento de nuestro proyecto.
NOTA vinculada a Scratch 2.0
En la versión 2.0 se presenta como parte del lenguaje lo que puede llamarse con absoluta propiedad la implementación de subrutinas, a través de la creación de bloques personalizados.
El término con que se denomina en la presentación teórica no es el de subrutinas sino el de procedimientos (procedures), y desde ya ambas denominaciones remiten a lo mismo (ver aquí).
Una vez más: este montón de palabras realmente cobrará sentido después de ver en acción algún proyecto en donde se apliquen las ideas presentadas, y es desde ya aconsejable la relectura de esta página una vez terminado nuestro primer experimento de programación usando envío de mensajes. Hacia un nuevo mini-proyecto vamos… ¡a ajustarse los cinturones!
Última actualización: Febrero 26, 2014
No hay comentarios.:
Publicar un comentario