Comentarios de Algoritmos y Programacion
De Gleducar, http://www.gleducar.org.ar
Fuente:Grupo Google logoes
ALGORITMOS Y PROGRAMACIÓN EN LA EDUCACIÓN ESCOLAR
Mil gracias a Daniel, a Diego, a Juan J., a Luis, y a todos los que leyeron la Guía de Algoritmos y Programación para docentes de educación básica.
Como primera medida, quiero ofrecer disculpas por la extemporaneidad en estas respuestas, pero tan pronto publicamos el trabajo de Algoritmos y programación, otras ocupaciones propias de Eduteka me absorbieron por completo. Ahora tengo un pequeño respiro y trataré de dar respuesta a algunas de sus observaciones (las cuales agradezco infinitamente):
De verdad que da gusto poner a consideración un trabajo cuando se recibe retroalimentación sincera que ayude a mejorar las próximas versiones del mismo.
Quiero empezar diciendo que este trabajo pretende ser meramente introductorio, por eso se presentan los ejemplos de la manera más sencilla y básica posible. Además, se pretende que se pueda realizar a lo largo de un año lectivo (en INSA se desarrolla durante un año de 3 horas semanales de 55 minutos y con niños de grado 5°). Por lo tanto, hubo que tomar decisiones que privilegiaron lo básico (cubrir las tres estructuras fundamentales: secuencial, iterativa y decisión).
da.ajoy arroba gmail.com
Daniel Ajoy View profile More options May 3, 12:11 pm
Hablan de MicroMundos y otros:
http://www.eduteka.org/AlgoritmosProgramacion.php
Daniel
ALGORITMOS Y PROGRAMACION EN LA EDUCACION ESCOLAR (EN COLOMBIA)
1. Daniel Ajoy View profile More options May 4, 10:50 am
http://www.eduteka.org/AlgoritmosProgramacion.php > En la mayoría de conjuntos de habilidades propuestos figura > la destreza para solucionar problemas; por esta razón, se > requiere seleccionar estrategias efectivas para ayudar a > que los estudiantes la adquieran. > Para atender esta necesidad, la programación de > computadores constituye una buena alternativa, siempre y > cuando se la enfoque al logro de esta habilidad y no a la > formación de programadores. de acuerdo. Creo que la filosofía de Logo siempre ha ido en esta línea. \[JCL: Mil gracias\] > Es importante insistir en esta orientación debido a que las > metodologías utilizadas en educación básica para realizar > cursos de Algoritmos y Programación, son heredadas de la > educación superior y muchos de los docentes que las > utilizan se dedican a enseñar los vericuetos de lenguajes > orientados a objetos, la mayoría de las veces, bajo el > paradigma de la programación estructurada. He escuchado que si lo que se desea es aprender a programar bajo el paradigma de objetos es mejor empezar en el paradigma de objetos. Por ejemplo el creador de C++ dice que para aprender C++ hay que empezar en C++ y no con C. Yo empecé con BASIC a programar bajo el paradigma de programación estructurada. Y nunca me acabaron de convencer los objetos. Quizá porque nunca he tenido que ser parte de un equipo para realizar aplicaciones grandes. Este mismo será el caso de la mayoría de la gente que sólo necesitará aprender a programar para desarrollar sus habilidades para resolver problemas. CONCLUSIÓN: enseñar a programar con orientación a objetos es inadecuado para la mayoría de gente. \[JCL: Hay muchas quejas, específicamente en la Universidad Icesi, sobre la dificultad que tienen los estudiantes para pasar a un paradigma orientado a objetos cuando han aprendido en el colegio programación estructurada. El problema es que quienes vana a ser ingenieros de sistemas si requieren elaborar aplicaciones grandes y participar en equipos de desarrollo, para lo cual es indispensable un enfoque más eficiente que la programación estructurada. Un punto intermedio consiste en enseñar en el colegio programación estructurada para elaborar pequeños procedimientos que luego se pueden homologar a la elaboración de métodos en OOP.\] > Hablar hoy de aprender a diseñar y construir aplicaciones > (programas) complejas, implica una labor titánica que está > fuera del alcance de la educación básica ya que demanda > necesariamente un enfoque de programación orientado a > objetos al que apuntan todas las nuevas tendencias en este > campo . Falso. las nuevas tendencias apuntan a poner en perspectiva la programación orientada a objetos: http://kawagner.blogspot.com/2006/08/oop-is-dead.html \[JCL: Mil gracias\] > Por esta razón, en la educación básica es recomendable > utilizar ambientes de programación como Logo , que aunque > no están orientados a objetos, De acuerdo. Pero con 170 diferentes versiones de Logo sí hay algunas que están orientadas a objetos. \[JCL: Válida la observación. Estoy cambiando por "...en la educación básica es recomendable utilizar ambientes de programación como Logo \[5\], que aunque la mayoría de sus versiones no están orientados a objetos...\] > son fáciles de utilizar y permiten realizar procedimientos > basados en estructuras básicas (secuencial, decisión y > repetición), pero siempre conducentes a solucionar > problemas. ok. \[JCL: Mil gracias\] > Solo en los últimos grados de básica secundaria o en la > media sería aconsejable introducir a los estudiantes a la > programación orientada a objetos mediante entornos de > programación visuales y amigables como Alice , KPL o > Processing . ¿qué mismo? ¿Enseñamos a resolver problemas o a programar con orientación a objetos para la formación de programadores? \[JCL: Válida la observación. No fui lo suficientemente claro en este párrafo. Lo estoy cambiando por: "... sería aconsejable introducir a los estudiantes a la programación orientada a objetos \[4\] mediante entornos de programación visuales y amigables como Alice \[7\], KPL \[8\] o Processing \[9\], pero siempre con orientación a solución de problemas\].
2. pure man View profile More options May 5, 12:49 pm
Daniel Ajoy <da.a... arroba gmail.com> wrote: > > Solo en los ?ltimos grados de b?sica secundaria o en la > > media ser?a aconsejable introducir a los estudiantes a la > > programaci?n orientada a objetos mediante entornos de > > programaci?n visuales y amigables como Alice , KPL o > > Processing . > ?qu? mismo? ?Ense?amos a resolver problemas o a programar > con orientaci?n a objetos para la formaci?n de programadores? Está un poco confuso esta idea en el artículo, por un lado postula la resolución de problemas, y en este parrafo pareciera que defiende la formación de programadores. Yo creo que el eje debe ser 100% la resolución de problemas, aun así pienso que tal vez los objetos puedan puedan ser útiles a este objetivo, ayudando en el modelado y dando mas capacidad de interacción transparente con objetos mas potentes; por ej. entregarle al chico un objeto tortuga que trabaje eficientemente con detección de coliciones y que el pueda partir de este objeto para construir programas mas complejos de los que haría con las instrucciones básicas. Un abrazo, Diego \[JCL: Válida la observación. No fui lo suficientemente claro en este párrafo. Lo estoy cambiando por: "... sería aconsejable introducir a los estudiantes a la programación orientada a objetos \[4\] mediante entornos de programación visuales y amigables como Alice \[7\], KPL \[8\] o Processing \[9\], pero siempre con orientación a solución de problemas\].
3. Daniel Ajoy View profile More options May 5, 3:26 pm
On 5 May 2007 at 10:49, pure man wrote: - Show quoted text - Tiene sentido, aunque por ejemplo MicroMundos EX, no lo hace bien. Ahora el código está desparramado por todo lado: en el área de procedimientos, en las tortugas, en los colores, en los botones. Si aparece un mensaje de error indicando una falla en el procedimiento XYZ hay que inspeccionar cada tortuga en cada página del proyecto para encontrarlo. Es más difícil depurar los programas, la complejidad de las interacciones es bastante mayor que cuando sólo hay un proceso y el código está en un solo sitio. Daniel \[JCL: De acuerdo, pienso igual\] '''4. pure man View profile More options May 6, 2:03 am ''' - Daniel Ajoy <da.a... arroba gmail.com> wrote: > Tiene sentido, aunque por ejemplo MicroMundos EX, no lo hace bien. > Ahora el código está desparramado por todo lado: en el área de > procedimientos, en las tortugas, en los colores, en los botones. Si, no está bien implementado en MM Ex, se vuelve confusa la interacción, además de no ser homogeneo en cuanto al tratamiento de los objetos. Me imaginaba algo mas onda Self, sin clases, solo objetos y mensajes, una metafora homogenea y minimalista, bien sencilla, pero que pudiese encapsular objetos complejos con una interfaz simple. Cuando descubrí Squeak pensé que era así, después me di cuenta que no, era homogeneo pero para nada mínimo, además de que hay que aprender bastante para empezar, con lo cual no cumple con la consigna de "sin piso" que me parece uno de los tantos logros de Logo. Un abrazo, Diego Lobos \[JCL: De acuerdo, pienso igual\]
5. Daniel Ajoy View profile More options May 6, 12:18 pm
On 6 May 2007 at 0:03, pure man wrote: > > Tiene sentido, aunque por ejemplo MicroMundos EX, no lo hace bien. > > Ahora el código está desparramado por todo lado: en el área de > > procedimientos, en las tortugas, en los colores, en los botones. > Si, no está bien implementado en MM Ex, se vuelve confusa la > interacción, Exacto. Si pasa algo inesperado en la pantalla es dificil investigar qué fue lo que lo ocasionó, que compleja interacción de: tortugas tocando colores colores tocando tortugas tortugas tocando tortugas ratón haciendo clic en color ratón haciendo clic en tortuga procesos when/cuando eventos programados a repetirse cada cierto tiempo eventos programados a efectuarse cuando aparezcan anuncios ... causo el comportamiento no deseado. Quizá sea un buen momento para recordar: http://mondragon.angeltowns.net/paradiso/LogoClasico.html ;) Daniel
6. pure man View profile More options May 6, 9:01 pm
- Daniel Ajoy <da.a... arroba gmail.com> wrote: > Quizá sea un buen momento para recordar: > http://mondragon.angeltowns.net/paradiso/LogoClasico.html Excelente artículo! En este momento estoy dando Informática Educativa en un Posgrado. La mayoría de los alumnos son profesores de Lengua, Historia y Economía. Pienso dar algo de Logo, principalmente porque me gustaría transmitirles la filosofía Logo, aunque no lo lleguen a usar para su matería. Veo que mucho hablan de constructivismo pero al momento de las práctica áulicas no hay diferencias con la forma en que me daban a mi Historia o Economía hace 20 años. Pienso que estudiar un poco de Logo les puede dar una idea mas clara y concreta de ese constructivismo que tanto promueven a nivel teórico. Pensando en eso este artículo me parece un buen punto de partida y motivación. Un abrazo, Diego Lobos \[JCL: Buen punto Diego. Los docentes de todas las áreas están ávidos por todo aquello de índole práctico que puedan implementar en el aula para mejorar los niveles de aprendizaje \]
ALGORITMOS Y PROGRAMACIÓN CON LOGO
Daniel Ajoy View profile More options May 9, 12:38 pm
On 9 May 2007 at 11:30, Juan Carlos López García wrote: > Nos encantaría conocer sus opiniones sobre estos recursos. Ya lo conocíamos desde el 3 de mayo :) http://groups.google.com/group/logoes/browse_frm/thread/aa45e6346ef520e0 Algo habíamos comentado: http://groups.google.com/group/logoes/browse_frm/thread/820e676fe74ea377 pero es un trabajo tan completo que seguramente habrá más por comentar. Daniel \[JCL: mil gracias a todos por tomarse la molestia de comentar este trabajo. Sus aportes son muy valiosos para mi. En estos momentos es que uno piensa, ¡qué vivan los sistemas modernos de comunicación! Hace 15 años, esta valiosa colaboración sería simplemente un sueño.\]
Jota Pe View profile More options May 10, 12:18 am
¡Hola Juan Carlos! Esta es una opinión super hiper personal (mía de mí): Sinceramente no creo en que los algoritmos estrictos (entiéndase: Diagramas de Flujo) sean algo digno de enseñar POR SI MISMOS. Creo, sinceramente, que la gran "gracia" de Logo es, precisamente, que el niño no tiene que "estudiar" esos conceptos tan fríos y ajenos a la realidad práctica del día a día. Por ejemplo: el típico ejercicio que te dan en clases de Algoritmos: "Cómo preparar una taza de café"... Y ahí tienes a los alumnos pensando en cómo dibujar el "maldito" diagrama de flujo, con todas las condicionales y etc. etc. etc. Pero... ¿Quién en la vida real hace un diagrama de flujo para preparar una taza de café? ¡NADIE!!! Entonces, ¿Para qué enseñarlo? ¿No tienen ya suficiente carga de estudios los chicos como para meterles más "leseras" en la cabeza? Para evitar todo eso es que se creo Logo. En Logo tú debes preparar la taza de café, cumpliendo con los estrictos algoritmos informáticos pero sin verlos y sin pensar en ellos, porque Logo es un lenguaje lo más parecido al lenguaje común, cotidiano, simple y directo. Un ejemplo sacado del foro de Logo en inglés para MSWLogo: to bosque repeat 100 \[make "xc -400+random 800 make "yc -300+random 600 pu setx :xc sety :yc pd ht árbol random 150+2\] end to árbol :tamaño if :tamaño<2 \[stop\] fd :tamaño lt 30 árbol :tamaño \* 0.7 rt 60 árbol :tamaño \* 0.7 lt 30 bk :tamaño end Ningún niño necesita diagrama de flujos para hacer eso. Insisto en que ésta es una opinión estrictamente personal. Tal vez, la loca idea de un viejo loco ¡PERO MUY VIVO! jejejeje. ¡DIOS LES BENDIGA A TODOS!!!!!!! Juan J. Paredes G. Desde Curicó, Chile, América del Sur, con mucho cariño \[JCL: Juan, mil gracias por tu apreciación. Con respecto a los diagramas de flujo, los veo como una herramienta de organización gráfica que los estudiantes deben aprender a utilizar. Bien sea para representar la secuencia de instrucciones de un algoritmo o los pasos de un proceso (manuales de procedimientos). Coincido en que no se deben enseñar por enseñarlos, deben cumplir una función de ayuda visual en la estructuración del pensamiento. Además, soy conciente que los diagramas de flujo no son una herramienta apropiada para representar todo tipo de algoritmo (como es el caso que se menciona más adelante respecto a la recursión).\]
Daniel Ajoy View profile More options May 10, 1:47 am
On 10 May 2007 at 0:18, Jota Pe wrote: > ¡Hola Juan Carlos! > Esta es una opinión super hiper personal (mía de mí): > Sinceramente no creo en que los algoritmos estrictos > (entiéndase: Diagramas de Flujo) sean algo digno de enseñar > POR SI MISMOS. > Creo, sinceramente, que la gran "gracia" de Logo es, > precisamente, que el niño no tiene que "estudiar" esos > conceptos tan fríos y ajenos a la realidad práctica del día > a día. estoy bastante de acuerdo con esto. Quizá el mérito de los diagramas es ver el flujo de ejecución explicitamente. Hablar sobre el flujo de ejecución y saber que existe. Nuevamente volviendo a la pesadilla que es depurar proyectos de MicroMundos hechos por niños que recién empiezan a estructurar sus ideas, pienso que los niños no adquieren este modelo mental de: flujo de ejecución. En vez de eso las cosa pasan casi por magia: cuando a se le dice a MicroMundos cuando \[tocando? "jugador "pelota\] \[patada\] pelota, hazclic jugador, hazclic (no sé muy bien los comandos en español) los niños no ven ningún flujo. Simplemente MicroMundos hace la cosas que uno le dice... o no las hace bien. Eso me parece mal. Pero en el apuro por querer que los niños lleguen pronto ha producir sus ansiados juegos, se pierden algunas oportunidades de que ellos aprendan cómo mismo es que funciona MicroMundos y la computadora. > Por ejemplo: el típico ejercicio que te dan en clases de > Algoritmos: "Cómo preparar una taza de café"... Y ahí > tienes a los alumnos pensando en cómo dibujar el "maldito" > diagrama de flujo, con todas las condicionales y etc. etc. > etc. Pero... ¿Quién en la vida real hace un diagrama de > flujo para preparar una taza de café? ¡NADIE!!! Todas las empresas tienen alguien que los hace, se llaman "manuales de procedimientos". - Show quoted text - ¿qué cosa? ¿copiar y pegar el código? No hace mucho tuve la bochornosa experiencia de no poder tipear de memoria el código necesario para hacer el famoso procedimiento del árbol. Y eso que lo he visto muchas veces, sé que es la recursión, he usado muchísimas veces la recursión, y he escrito sobre el procedimiento del árbol. Haz tú el experimento. No mires al código arriba y escribe el código necesario para dibujar un árbol. Por otro lado, un niño no \*podría\* usar diagrama de flujos para representar el código que pusiste arriba. Los diagramas de flujo son una herramienta muy pequeña para meterse con el concepto de recursión. Daniel \[JCL: Lo dicho, con respecto a los diagramas de flujo, los veo como una herramienta de organización gráfica que los estudiantes deben aprender a utilizar. Bien sea para representar la secuencia de instrucciones de un algoritmo o los pasos de un proceso (manuales de procedimientos). Coincido en que no se deben enseñar por enseñarlos, deben cumplir una función de ayuda visual en la estructuración del pensamiento. Además, soy conciente que los diagramas de flujo no son una herramienta apropiada para representar todo tipo de algoritmo (como en el caso de recursión)\]
From: Jota Pe <jotape1960 arroba yahoo.com>
Subject: Re: \[Lista LOGO\] Algoritmos y programación con Logo
To: LOGO <logo arroba me.gov.ar>
Message-ID: <265931.56817.qm arroba web54110.mail.re2.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
Hola Daniel!
Un placer saludarte, ya que te habías perdido un poco del foro en inglés. Tus motivos tendrás.
Con respecto a los algortimos y los diagramas de flujo..., mmm, no sé, no sabría decir si la balanza se ha cargado hacia la necesidad de hacer los diagramas o no. Insisto que esa opinión (la que dí), es mi opinión. Obviamente, no creo que el "círculo internacional de programadores serios" acepte mis conceptos, jejejeje (yo creo que, si ellos me escucharan, me odiarían).
En cuanto al "arbol", no veo que la "recursión" sea el tema central aquí. Yo lo veo por el hecho de crear la "intuición" de hacer algo grande con algo muy pequeño: el árbol, básicamente, es una línea, sólo una línea, pero que se repite de tal forma que dibuja un árbol. Increíble, pero cierto. Bueno, ok, acepto que se repite el procedimiento llamándose a sí mismo, de acuerdo, pero lo central, según yo lo veo, es ir de lo mínimo a lo máximo, de la línea al árbol. Es mi opinión.
¡DIOS TE BENDIGA!!!!!!!
Juan J. Paredes G.
Desde Curicó, Chile, América del Sur, con mucho cariño
DIAGRAMAS DE FLUJO VS. LINEA DE COMANDOS
Daniel Ajoy View profile More options May 10, 1:47 am Yo diria que los diagramas de flujo y mi forma de programar estan bien peleados. Por ejemplo en la página 40 de AlgoritmosProgramacion.pdf nos dan un ejemplo de cómo se ve la resolución del problema de encontrar la superficie de un triángulo: EJEMPLO 3-6 Escribir un procedimiento en MicroMundos para calcular el área de cualquier triángulo rectángulo. En él se debe pedir al usuario que ingrese los valores de la Altura y la Base del triángulo. para triánguloRectángulo ; declarar variables y constantes local "div local "base local "altura local "área da "div 2 ; ingresar altura y base pregunta \[Ingrese la Altura del Triángulo\] da "altura respuesta pregunta \[Ingrese la Base del Triángulo\] da "base respuesta ; realizar cálculos da "área :base \* :altura / :div ; reportar el resultado anuncia frase \[El �?rea del triángulo es:\] :área fin Yo no lo haría así, para mí la mejor solución al problema es: para superficieTriangulo :base :altura devuelve :base \* :altura / 2 fin muestra superficieTriangulo 5 4 10 porque entonces puedo experimentar, que pasa si voy cambiando el tamaño de la altura: muestra teje \[superficieTriangulo 5 ?\] \[4 4.5 5 5.5 6\] \[10 11.25 12.5 13.75 15\] Con logoFe podría hasta graficar mis datos con lo siguiente: muestra recorrido \[superficieTriangulo 5 ?\] \[4 4.5 5 5.5 6\] \[\[4 4.5 5 5.5 6\] \[10 11.25 12.5 13.75 15\]\] graflineas \[\] recorrido \[superficieTriangulo 5 ?\] \[4 4.5 5 5.5 6\] y ver que la relación entre la altura y el área de un triángulo es lineal. Volviendo a puro y simple FMSLogo: Si tengo muchos datos de triángulos puedo hacer: muestra teje \[aplica "superficieTriangulo ?\] \[\[5 4\] \[4 5\] \[50 40\] \[500 40\] \[5 3\]\] \[10 10 1000 10000 7.5\] o paracada \[\[5 4\] \[4 5\] \[50 40\] \[500 40\] \[5 3\]\] \[escribe lista ? aplica "superficieTriangulo ?\] \[5 4\] 10 \[4 5\] 10 \[50 40\] 1000 \[500 40\] 10000 \[5 3\] 7.5 Si se tratase de un procedimiento para calcular la hipotenusa no pediría las entradas con "pregunta"s ni entregaría las respuestas con anuncios. Sino así: para hipotenusa :c1 :c2 devuelve raizcuadrada :c1 \* :c1 + :c2 \* :c2 fin muestra hipotenusa 300 400 500 porque de esta manera puedo usar mi procedimiento para algo, por ejemplo para dibujar un triangulo: para dibujaTri :c1 :c2 avanza :c1 haz "p pos retrocede :c1 giraderecha 90 avanza :c2 ponrumbo hacia :p avanza hipotenusa :c1 :c2 fin borrapantalla dibujaTri 300 400 Es decir, el Area de Comandos está allí para interactuar. Eso de usar "pregunta"s y anuncios vs. la línea de comandos es la típica punga entre programación top-down versus programación bottom-up. Daniel \[JCL: Debo aclarar que los ejemplos de la guía son muy básicos, no están dirigidos a personas curtidas en programación. Tienes razón, los ejemplos se pueden hacer con menos pasos. Pero no se trata de mostrar soluciones optimizadas, en cambio se trata de mostrar a los docentes (muchos de ellos iniciándose en Logo y que desean implementar la elaboración de programas para desarrollar en los estudiantes habilidades de solución de problemas y pensamiento algorítmico), cómo pueden utilizar diversos comandos para construir procedimientos que solucionen un problema puntual. Un paso posterior es la afinación y documentación de los procedimientos. Resulta muy interesante retar a los estudiantes, una vez conocen cómo elaborar un procedimiento de la forma más básica, para que lo mejoren (ya que...) y optimicen. Por otro lado, utilizar el área de procedimientos ayuda a los estudiantes a ser más reflexivos y a abstraer las soluciones ya que hasta que no se ejecuta el procedimiento, ellos no ven nada. Por lo cual, deben elaborar la solución en sus cabezas y transferirla al computador. Esto sin restar importancia al área de comandos que permite trabajar por experimentación, lo cual también es muy valioso para ciertos procesos educativos\].
From: lrcvs <lrcvs arroba yahoo.es>
To: da.ajoy arroba gmail.com Hola Daniel: Respecto al tema "Digramas de flujo contra comandos directos", mi opinion es la siguiente: - Tendriamos que saber si el usuario es un niño o un adulto principiante. - Si el trabajo que esta haciendo es un mero juego de probaturas o un programa mas o menos complejo. Si un progama simple y con pocas ordenes se puede hacer, pero un programa complejo y largo, lo tienen que realizar distintas personas, al final tienen que acoplarse los distintos pasos y funcionar. No se puede estar probando al azar, hace falta una pauta de trabajo para cada persona. Creo que los diagramas de flujo se deben de conocer y saber aplicarlos, pues su utilizacion es amplia ejemplos:en resolucion de problemas de matematicas, fisica, quimica, programas informaticos, programacion de automatas ycualquier proceso por etapas. En mi opinion, aparte de los diagramas de flujo o similares, el mejor sistema de diseñar un proceso, bien secuencial o derivado es el GRAFCET en sus distintos niveles y adaptaciones. Al igual como los diagramas de flujo, este sistema se puede aplicar a cualquier forma de actividad industrial y educativa. Este sistemaes similar a los diagramas de flujo, sus pasos, condiciones, derivaciones y convergencias. Su eficacia, esta en el concepto de etapa (paso). El paso entre etapas solamente es posible si se cumplen unas determinadas condiciones.... Tiene siete ideas basicas (que mejor buscarlas en cualquier informacion sobre el Grafcet), y son totalmente aplicables a los diagramas de flujo o a cualquie sistema. Por cierto, sobre el tema de numeros/ texto, Ok. Atte.: Luis Belmonte Saludos \[JCL: Luis, mil gracias por tu aporte. Te aclaro que este trabajo está dirigido a maestros que tienen a su cargo estudiantes de básica primaria y secundaria. La idea es que realicen procedimientos sencillos, nada de aplicaciones complejas. Coincido plenamente en que los diagramas de flujo son una herramienta gráfica que los estudiantes deben aprender a utilizar. En este caso para representar algoritmos sencillos, pero luego pueden transferir ese conocimiento a otros problemas o procesos.\] Date: Thu, 10 May 2007 15:34:43 -0500
From: "Daniel Ajoy" <da.ajoy arroba gmail.com>
Subject: Re: \[Lista LOGO\] Diagramas de Flujo vs. Linea de comandos To: logo arroba me.gov.ar Message-ID: <46433B93.13952.183D2BAE arroba da.ajoy.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 10 May 2007 at 22:15, lrcvs wrote: > - Si el trabajo que esta haciendo es un mero juego de > probaturas o un programa mas o menos complejo. Si el trabajo es más o menos complejo es casi imposible usar diagramas de flujo. Mira el código cortito que puso JotaPe. Sólo esas poquitas líneas de código ya no se pueden expresar en diagramas de flujo (que yo sepa). Pero es cierto que para los algoritmos sencillos de varias ciencias (y técnicas) se usan los diagramas. Mejor sería que escriban en código de algún lenguaje de alto nivel verdadero, en español. ¿Cuántos de esos hay? Yo sólo conozco Logo :) Daniel