search

Program-AR / pilas-bloques-ember

Repositorio auxiliar de Pilas Bloques. Repo principal en el link.
https://github.com/Program-AR/pilas-bloques-app
GNU Affero General Public License v3.0
69 stars 29 forks source link

Cambio nombre categorías #44

Closed asanzo closed 6 years ago

asanzo commented 8 years ago

seleccion_043

Las categorías que charlamos fueron:

La idea es separar arriba lo que implica efecto, y abajo lo que no. Las tres últimas categorías serían expresiones, nombre que decidimos no utilizar porque utilizado correctamente implicaría poner todos los últimos bloques ahí adentro.

Otra cosa para notar es que descartamos subcategorización porque ensucia la experiencia de usuario con clicks (al menos mientras no hagamos cambios grandes sobre la interfaz actual). Ojo, no sólo es una cuestión tecnológica, sino también de simplicidad conceptual para el usuario.

Y como ahora, sólo aparecerían las categorías para las que tenga sentido mostrar bloques en el estadío actual del recorrido didáctico (para no "ensuciar" con cosas que no conocen)

asanzo commented 8 years ago

@gobstones-admin , @faloi ,

faloi commented 8 years ago

¿Cuál es la motivación de cambiar los nombres actuales?

A mí Acciones me gusta, aunque sí le agregaría el "Mis" a Procedimientos, para que quede bien claro que los creé yo. Las expresiones las dividiría en Lógica-Matematica, Sensores, Valores y Mis Funciones.

Sería interesante también ver una división, no clickeable, algo como:

Procedimientos

Expresiones

faloi commented 8 years ago

(Aunque Control dentro de procedimientos no me convence. Quizás lo pondría afuera, sin categorizar.)

fidel-ml commented 8 years ago

A mí la palabra "control" no me gusta. Es demasiado operacional. Para mí son "formas de combinación de comandos"... ;) FF

2016-04-01 20:29 GMT-03:00 Federico Aloi notifications@github.com:

(Aunque Control dentro de procedimientos no me convence. Quizás lo pondría afuera, sin categorizar.)

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Program-AR/pilas-engine-bloques/issues/44#issuecomment-204607126[image: Web Bug from https://github.com/notifications/beacon/AIaqtgrHzAIPBraZJ_R3AXWF-c_DdRuBks5pzapMgaJpZM4H9zfr.gif]

Este mensaje ha sido analizado por el servidor antispam2.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

asanzo commented 8 years ago

@faloi la motivación del cambio es repensar. Si descubrimos que iban esos nombres, quedan, pero la idea es no dejarlos ahí sin una justificación. En particular, una de las cosas que nos movió a poner "Procedimientos primitivos" es:

Es de esa asociación de la que nos queremos colgar para aprovechar a meter terminología correcta. Es en esta línea que "Comandos" sería un mejor nombre que "Acciones", y, si vamos a separar los primitivos de los propios, por qué no aprovechar y poner:

Procedimientos primitivos Mis procedimientos

y @gobstones-admin , tenés un buen punto en que a "Control" no le dimos mucho pensamiento. ¿Se te ocurre un buen nombre, suficientemente correcto y aceptablemente corto?

fidel-ml commented 8 years ago

¿"Combinaciones de comandos"? ¿"Comandos compuestos"? FF

2016-04-11 15:29 GMT-03:00 asanzo notifications@github.com:

@faloi https://github.com/faloi la motivación del cambio es repensar. Si descubrimos que iban esos nombres, quedan, pero la idea es no dejarlos ahí sin una justificación. En particular, una de las cosas que nos movió a poner "Procedimientos primitivos" es:

  • La primera vez que el alumno entra, los nombres pueden ayudarlo (por ejemplo, acciones).
  • Pero a medida que pasa el tiempo, empieza a asociar conceptualmente el nombre de la categoría con lo que contiene.

Es de esa asociación de la que nos queremos colgar para aprovechar a meter terminología correcta. Es en esta línea que "Comandos" sería un mejor nombre que "Acciones", y, si vamos a separar los primitivos de los propios, por qué no aprovechar y poner:

Procedimientos primitivos Mis procedimientos

y @gobstones-admin https://github.com/gobstones-admin , tenés un buen punto en que a "Control" no le dimos mucho pensamiento. ¿Se te ocurre un buen nombre, suficientemente correcto y aceptablemente corto?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Program-AR/pilas-engine-bloques/issues/44#issuecomment-208487998[image: Web Bug from https://github.com/notifications/beacon/AIaqtvwIT9o2o2OSI-jpucmKBGKu4tKDks5p2pLvgaJpZM4H9zfr.gif]

Este mensaje ha sido analizado por el servidor antispam2.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

faloi commented 8 years ago

Comandos compuestos abre el juego a hablar de Comandos simples, y no me queda claro qué sería esto último.

Yo suelo presentar a las primitivas como lo mínimo que puedo pedirle a mi autómata que haga, entonces los procedimientos me sirven justamente para combinar esas primitivas y lograr así solucionar problemas más complejos. Entonces, la notación que propone Fidel me crea una ambigüedad.

fidel-ml commented 8 years ago

¿Pero vos entendés a las combinaciones de comandos como primitivas? La repetición o la alternativa no son comandos primitivos en el sentido de "lo mínimo que puedo pedirle al autómata que haga"... Elegir o repetir son formas de combinar otros comandos, o de modificar el comportamiento de otros comandos... Si tengo que elegir, prefiero "Combinaciones de comandos" o "Modificadores de comandos". FF

2016-04-11 21:11 GMT-03:00 Federico Aloi notifications@github.com:

Comandos compuestos abre el juego a hablar de Comandos simples, y no me queda claro qué sería esto último.

Yo suelo presentar a las primitivas como lo mínimo que puedo pedirle a mi autómata que haga, entonces los procedimientos me sirven justamente para combinar esas primitivas y lograr así solucionar problemas más complejos. Entonces, la notación que propone Fidel me crea una ambigüedad.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Program-AR/pilas-engine-bloques/issues/44#issuecomment-208632085[image: Web Bug from https://github.com/notifications/beacon/AIaqtuPENzWaH4pIZ4X48kNmjdkykpWbks5p2uMugaJpZM4H9zfr.gif]

Este mensaje ha sido analizado por el servidor antispam1.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

faloi commented 8 years ago

¿Pero vos entendés a las combinaciones de comandos como primitivas?

No, justamente lo que estoy diciendo es todo lo contrario. :grin:

Yo enseño a los procedimientos como combinaciones de comandos (al principio primitivas y casi inmediatamente después otros procedimientos). Lo que digo es que presentar a las estructuras de control como combinaciones me crearía un problema, porque así presento a los procedimientos.

Al margen de esto, aunque entiendo las razones por las cuales querríamos evitar agruparlos bajo la categoría Control, no las comparto: la herramienta está inmersa en un paradigma imperativo, donde tarde o temprano hay que pensar en la secuencia. Pensando en esto último, se me ocurren "Modificadores de flujo" o "Modificadores de secuencia".

(Ok, acabo de releer cómo lo presentás vos en el libro y me recontra cierra la explicación. Pero aún así no me convence poner ese nombre en una herramienta que está pensada para ser usada por millones de estudiantes, que no van a tener a un Fidel al lado :wink:).

fidel-ml commented 8 years ago

1.- Los procedimientos no son combinaciones de comandos. Son comandos a los que se les asigna un nombre. Mediante ese nombre lográs que un comando compuesto luzca como si fuera primitivo (mediante "tus" comandos -- o procedimientos). Yo entiendo "procedimiento" como "mecanismo de abstracción de comandos (a través de un nombre)". O sea, estás enseñando mal lo que es un procedimiento... ;)

La idea de "procedimientos primitivos" es osada, porque entiende al procedimiento (abstracción) como lo fundamental, y lo que yo llamo comando primitivo sería algo así como la base de la abstracción. Queda corto en que no explica qué es un comando compuesto. Para que se entienda:

Avanzar()

es un comando (o procedimiento) primitivo, mientras que

Avanzar();Avanzar()

es un comando (o procedimiento?) compuesto. Finalmente

AvanzaraDosVeces()

definido como el nombre del comando compuesto anterior es un comando (procedimiento) definido por usuario. Un procedimiento NO es un comando compuesto, sino la habilidad de darle nombre a un comando compuesto, y por eso abstraerlo, identificando su comportamiento denotacional.

2.- Si no empezás a cambiar las ideas, nunca cambian. La idea de "así lo hacen en otro lado, y no vamos a poder cambiarla" es falaz, porque entonces dejemos que se siga enseñando diagramas de flujo y Pascal (o peor, Pseint), o cualquiera de las otras barbaridades que andan dando vueltas.

2016-04-11 23:37 GMT-03:00 Federico Aloi notifications@github.com:

¿Pero vos entendés a las combinaciones de comandos como primitivas?

No, justamente lo que estoy diciendo es todo lo contrario. [image: :grin:]

Yo enseño a los procedimientos como combinaciones de comandos (al principio primitivas y casi inmediatamente después otros procedimientos). Lo que digo es que presentar a las estructuras de control como combinaciones me crearía un problema, porque así presento a los procedimientos.

Al margen de esto, aunque entiendo las razones por las cuales querríamos evitar agruparlos bajo la categoría Control, no las comparto: la herramienta está inmersa en un paradigma imperativo, donde tarde o temprano hay que pensar en la secuencia. Pensando en esto último, se me ocurren "Modificadores de flujo" o "Modificadores de secuencia".

(Ok, acabo de releer cómo lo presentás vos en el libro y me recontra cierra la explicación. Pero aún así no me convence poner ese nombre en una herramienta que está pensada para ser usada por millones de estudiantes, que no van a tener a un Fidel al lado [image: :wink:]).

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Program-AR/pilas-engine-bloques/issues/44#issuecomment-208675589[image: Web Bug from https://github.com/notifications/beacon/AIaqtiSXi59hIf_aWzhYqhbex6IOkO8cks5p2wVzgaJpZM4H9zfr.gif]

Este mensaje ha sido analizado por el servidor antispam1.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

asanzo commented 8 years ago

Segunda prueba:

Entiendo que, salvo la categoría Control, hay cierto consenso con esto.

Respecto de la visión denotacional del control de flujo, me falta leer un poco. Entiendo que un nombre que va por el lado de mayor corrección sería Combinadores de comandos (y no combinaciones) porque en escencia son formas de agruparlos con una semántica no secuencial (y estaría faltando el combinador por defecto que sería el secuencial). Sin embargo, según entendí de lo que leí en prácticamente la primer fuente que encontré, el modelado denotacional de programas tiene tratamiento especial cuando se habla de estado y control de flujo de ejecución. Antes de arriesgar una justificación infundada, hago preguntas que me parecen relevantes:

  1. Si es aceptado que existen visiones diferentes, ¿Qué tan dañino es mezclar conceptos de ambos mundos, el denotacional y el operacional? A mí me contaban que la luz la podés entender como partícula y también como onda.
  2. La segunda pregunta relacionada es, dado que PilasBloques es una herramienta para enseñar: ¿No sería provechoso aprovechar lo mejor de ambos mundos según convenga didácticamente? Recuerdo que entender a la luz como onda permitía entender mejor la idea del color de la luz, y entenderla como partícula permitía explicar mejor su generación a nivel de partículas subatómicas.
  3. Y finalmente la tercera pregunta es, y acá es donde tengo una opinión basada en sensaciones y no en pruebas: ¿No es más fácil entender los ciclos operacionalmente? La metáfora de la repetición como idea denotacional se te cae al piso cuando no sabés si primero comer y después avanzar, ó al revés.
fidel-ml commented 8 years ago

Respondo por partes... No me convence "Comandos" para "Comandos primitivos". Porque los procedimientos también son comandos, y el resultado de armar una repetición o una alternativa con todas sus partes, también. Si vas por ese lado, prefiero "Primitivas" para los comandos primitivos y "Comandos" para los combinadores de comandos. Claramente yo solo opero como consultor, pero "Comandos" no da una idea de lo que realmente son (el problema con "Primitivas" es que también hay expresiones primitivas... :().

Sobre el tratamiento denotacional del "control", un enfoque tradicional es utilizar continuaciones. Si buscás bibliografía sobre "denotacional" te va a salir todo lo de "semántica denotacional" que es la formalización matemática de lo que yo intento mostrar de manera intuitiva cuando hablo de "denotacional". Para más detalle sobre "denotacional" en el sentido que yo lo uso deberías leer a Nördstrom acerca de la teoría de tipos de Martin-Löf, y sobre funciones intensionales (con s) -- pero te va a llevar un tiempo reconstruir todo eso... Jeje.

Sobre la metáfora de la luz, no sé, porque mi física se limita a la del secundario y a lo que leí por mi cuenta, y no puedo argumentar demasiado en ese campo. Yo no mezclaría, simplemente porque si bien como decís algunas cosas se explican mejor de un lado que del otro (y esto siempre es así cuando hay más de un lado), aprender que hay 2 lados y compatibilizarlos es una tarea que lleva tiempo, y entender los abusos de notación lleva más tiempo, y es causa de confusiones evitables. Dicho esto, no defiendo más la postura anti-control. Pero yo titularía las secciones como

"Comandos": "Primitivos", "Mis Procedimientos", "Combinadores" "Expresiones": "valores", etc.

Las variables las pondría en expresiones y la asignación en combinadores, y aunque entiendo que quieran ponerlas por separado me parece que no es del todo feliz, porque no es una distinción ni sintáctica ni semántica, sino por categorías artificiales...

Disgresión: ¿y si en vez de "Combinadores" los de comandos también fueran "Operadores"? Para eso sería fundamental darle título a cada sección, pero me gusta... ;) FF

2016-04-13 19:26 GMT-03:00 asanzo notifications@github.com:

Segunda prueba:

  • Comandos
  • Mis procedimientos
  • Control
  • Variables
  • Valores
  • Sensores
  • Operadores
  • Mis Funciones

Entiendo que, salvo la categoría Control, hay cierto consenso con esto.

Respecto de la visión denotacional del control de flujo, me falta leer un poco. Entiendo que un nombre que va por el lado de mayor corrección sería Combinadores de comandos (y no combinaciones) porque en escencia son formas de agruparlos con una semántica no secuencial (y estaría faltando el combinador por defecto que sería el secuencial). Sin embargo, según entendí de lo que leí en prácticamente la primer fuente que encontré https://en.wikipedia.org/wiki/Denotational_semantics, el modelado denotacional de programas tiene tratamiento especial cuando se habla de estado y control de flujo de ejecución. Antes de arriesgar una justificación infundada, hago preguntas que me parecen relevantes:

  1. Si es aceptado que existen visiones diferentes, ¿Qué tan dañino es mezclar conceptos de ambos mundos, el denotacional y el operacional? A mí me contaban que la luz la podés entender como partícula y también como onda.
  2. La segunda pregunta relacionada es, dado que PilasBloques es una herramienta para enseñar: ¿No sería provechoso aprovechar lo mejor de ambos mundos según convenga didácticamente? Recuerdo que entender a la luz como onda permitía entender mejor la idea del color de la luz, y entenderla como partícula permitía explicar mejor su generación a nivel de partículas subatómicas.
  3. Y finalmente la tercera pregunta es, y acá es donde tengo una opinión basada en sensaciones y no en pruebas: ¿No es más fácil entender los ciclos operacionalmente? La metáfora de la repetición como idea denotacional se te cae al piso cuando no sabés si primero comer y después avanzar, ó al revés.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Program-AR/pilas-engine-bloques/issues/44#issuecomment-209673776[image: Web Bug from https://github.com/notifications/beacon/AIaqtkWL1pxGXyYeNeIgFcSSDvblJoxZks5p3W2MgaJpZM4H9zfr.gif]

Este mensaje ha sido analizado por el servidor antispam2.unq.edu.ar de la Universidad Nacional de Quilmes en busca de virus y otros contenidos peligrosos, y se considera que está limpio.

asanzo commented 8 years ago

http://pilasbloques.program.ar

Tenemos versión 0.11.1 donde están parte de los nombres charlados, donde entiendo que hay una mejora respecto de la versión anterior. Ahora, además, aparecen siempre en el mismo orden.

¡Que siga la discusión!