lunes, 27 de agosto de 2012

¿Hacia dónde debe ir el pseudolenguaje de PSeInt?

Escribo este post para abrir formalmente un debate con la comunidad de usuarios de PSeInt. Quiero pedir sus opiniones y hacer que sean partícipes del futuro de PSeInt, y entonces comienzo escribiendo esto para dejar claro mi punto de vista y mis objetivos como principal y único desarrollador de este proyecto. La motivación del debate reside en la necesidad de ampliar (o no) el pseudolenguaje que utilizo. Varios usuarios, en la mayoría docentes, me han pedido extender el pseudolenguaje para poder hacer tal o cual cosa. Por ejemplo: definir funciones/subprocesos, manejar cadenas, escribir y leer archivos, controlar mejor la salida por consola (ubicación, colores, etc). Por otro lado, algunos usuarios alumnos escriben preguntando ¿cómo hago tal cosa? que actualmente no se puede hacer, e indirectamente también están aportando una nueva idea. Entonces, tengo que decidir si el lenguaje va a crecer o no para permitir estas cosas, cuales debo permitir y cuales no, y sobre todo, de qué manera se integran. Para tomar esta decisión de la mejor forma y dejar contenta a la mayor cantidad de personas posibles es que quiero iniciar antes un debate. En primer lugar voy a describir mi visión del pseudocódigo, y debo advertir que será innegociable. A continuación, presentaré algunas de las posibles mejoras, mencionando los pros y contras que veo en ellas, como se relacionan con mi visión innegociable, y tratando de dejar abierto el camino para la futura discusión.

Respecto al pseudocódigo, debo decir que me interesa mucho más la parte de pseudo que la de código. Que no pretendo crear un verdadero lenguaje de programación, útil para escribir programas de en serio. Lo que pretendo es que sea una herramienta didáctica, y todo el esfuerzo debe ir en esa dirección. Me gustaría que el lenguaje sea natural, intuitivo, de forma que cumpla el verdadero objetivo de un pseudolenguaje: que el alumno centre su atención en los fundamentos, en los conceptos subyacentes como variable, arreglo, estructura de control, función, expresión, y demás conceptos que debe internalizar para lograr la abstracción necesaria para convertirse en un programador. La función del pseudocódigo en la enseñanza es permitir al alumno aprender fundamentos y lenguaje por separado, en distintas etapas, para que el camino sea más fácil, más progresivo. Si uno tiene que aprender a programar directamente en un lenguaje, se mezclan los errores de lógica con los de sintaxis con las mañas del intérprete/compilador, con la dificultad del idioma inglés, etc. Entonces, el lenguaje debe ser claro, intuitivo, no debe meterse en el camino, sería mejor si ni siquiera existiera (por eso puse tanto empeño últimamente en el editor de diagramas de flujo entre otras cosas). Considerando todo eso, el mensaje es claro: quiero mucho de pseudo y poco de código, y no pienso ceder en ese sentido. Sin embargo el lenguaje es un lenguaje, con sus reglas y sus limitaciones, y mis limitaciones. Sus reglas son fundamentales, se le debe enseñar al alumno desde el comienzo que, por dar un ejemplo, el algoritmo no debe dar lugar a ambigüedades, que debe ser preciso. Entonces, si bien las construcciones sintácticas están pensadas para parecer más o menos naturales o coloquiales, y para ser entendidas aún sin conocer el lenguaje, las reglas están y deben respetarse. Por otro lado sus limitaciones pueden ser eliminadas hasta cierto punto, pero dependen también de mis limitaciones. No puedo hacer un intérprete de lenguaje natural, que entienda inteligentemente, pseint no estaba planteado así desde el comienzo, y no tengo el tiempo y probablemente tampoco los conocimientos necesarios para hacerlo. Entonces seguirá teniendo sus reglas bien definidas, su sintaxis de lenguaje de programación, pero buscando que esa sintaxis se parezca al lenguaje natural dentro de lo posible.

Ahora sigamos con las cosas que a mi y/o los usuarios nos gustaría que el lenguaje permita hacer. El primer tema, y el más recurrente, es la definición de funciones/subprocesos. En ese punto estoy de acuerdo en agregarlo, porque además es conceptualmente importante, es parte de esos fundamentos de los que hablaba al principio del párrafo anterior. Permitir al alumno aprender funciones, entender ejemplos básicos de recursividad y otras cosas relacionadas, en un pseudocódigo podría ser muy útil en muchos casos. Todavía no estoy en condiciones de trabajar en esto, antes tengo que hacer algunos ajustes más en el interior del intérprete, pero tarde o temprano llegará, ya hay trabajo hecho en esta dirección, y en su momento discutiremos mejor la sintaxis. Así que vamos a dejar este punto fuera de esta discusión.

Otro tópico recurrente es el manejo de cadenas. Poder cortas cadenas, extraer sus letras, saber su longitud, etc. Creo que sería algo interesante de tener porque abriría la puerta a todo un nuevo tipo de ejercicios, que podrían ser útiles en el aprendizaje. Tengo que decir que me sería muy fácil implementar funciones de manejo de cadenas, y de hecho algunos usuarios lo han intentado hacer por su cuenta con éxito. El problema es que aquí agregar simplemente funciones es la salida fácil, pero es casi como traducir una biblioteca de otro lenguaje a pseudocódigo, y eso no me convence porque tiene poco de pseudo y mucho de código. Es decir, es fácil tener la funcionalidad de la biblioteca cstring (strlen, strstr, strchr, strcat, etc) en pseudocódigo (con sus nombres traducidos al castellano), pero no suena muy intuitivo. Es trivialmente intuitivo desde el punto de vista de un programador que ya las conoce en su lenguaje, pero no creo que lo sea para el estudiante que aún no ha empezado con un lenguaje real. Sin embargo, tampoco tengo una mejor alternativa. No imagino que quede bien algo como "Escribir tercer caracter de NOMBRE;" o "N <- cantidad de letras de APELLIDO". Las construcciones con muchas palabras claves tienden a generar muchas variantes, potenciales confusiones con variables o con otros significados de las palabras dentro de una expresión mayor o una estructura de control, etc. Entonces, propongo discutir: ¿se debe agregar o no esto? ¿debe ser a través de funciones? ¿qué nombres tendrían estas funciones? ¿a alguien se le ocurre una sintaxis alternativa? ¿debo, por ejemplo, permitir acceder a un caracter como si fueran arreglos, como en la sobrecarga del operador [] en std::string?

Lo que sigue podría ser un mejor manejo de la entrada/salida. Empezando por poder escribir con colores, posicionar el cursor en alguna parte, etc. Y aquí hay dos enfoques, uno es utilizando un máquina de estados, que creo sería el enfoque clásico, y otro no. En el primero, por ejemplo, escribir "Hola" con rojo serían dos instrucciones: "Color Rojo; Escribir 'Hola'". En el segundo, solo una "Escribir 'Hola' en Rojo". Pero el segundo no tolera fácilmente mucho más que el color, creo que cosas como "Escribir 'Hola' en Rojo sobre fondo Negro en la columna 3 fila 5" sería demasiado. Por otro lado, este agregado no incluye nada conceptualmente interesante para el alumno, a menos que se haga énfasis en lo de máquina de estados, pero no se si conveniente explicitarlo en esa etapa del aprendizaje. El dilema se plantea igual, porque aunque no agregue nada conceptual, permite al alumno jugar. Le permite experimentar con su programa para que quede más "bonito", le permite hacer algunos juegos básicos más fácilmente, le permite volar un poco más con la imaginación. Y eso es un arma de doble filo: por un lado puede otorgar motivación extra, puede darle una práctica adicional (tratar de dibujar un menú elegantemente formateado en lugar de solo una lista opciones puede llevarlo a utilizar alguna lógica adicional), pero también puede hacer que pierdan tiempo en cosas que como dije antes no parecen aportar mucho de lo fundamental. Entonces pregunto nuevamente: ¿sería bueno agregar esto? ¿cual creen que el enfoque sintáctico correcto?

Otro punto sería el manejo de archivos. Aquí algunos pocos lo han pedido. Personalmente creo que no debería agregarlo. Esta claro que no vamos a manejar binarios en pseudocódigo. Y para los de texto... esto sí que no aporta nada para lo fundamental, sino que parece más una necesidad de alguien que pretende utilizar PSeInt como un lenguaje real para un problema verdadero. Por similares fundamentos también rechazo la posibilidad de generar un exe con el algoritmo "compilado", que en realidad sería con el intérprete más el pseudocódigo embebido (eso es lo más fácil de implementar, pero da igual, alguna forma de hacer un ejecutable para llevar). De cualquier modo, si alguien quiere ofrecer otro punto de vista será bienvenido.

Habrá otros items para esta lista que aún no se me ocurrieron o no me llegaron, o que me olvidé, siéntanse libres de sugerirlos. En todo momento hay que recordar que desde hace rato en PSeInt tenemos perfiles. Digo esto porque es obvio que al final, aunque llegue a algo que me guste a mi y a muchos, supongo que no va a haber un consenso definitivo, así que todo lo nuevo probablemente sea opcional, y cada docente pueda tomar sólo lo que considere adecuado para su forma de enseñar y sus objetivos. Estará el que quiera tener un C en castellano y utilice una sintaxis estricta, y tal vez no le moleste agregar miles de funciones; y estará el que quiera un verdadero pseudolenguaje. Intetemos hacer un lenguaje flexible, pero que mantenga alguna coherencia, que tenga un rumbo. En el caso particular de las funciones por tomar un ejemplo, si llegamos a un punto extremo en el que no hay acuerdo sobre cuáles y cómo, estas podrían pasar a formar parte del perfil. Es decir, podría tener un ítem en la configuración del lenguaje que sea "Habilitar funciones de manejo de cadenas" o tener un botón "Elegir archivo de funciones..." y que cada docente programe las que necesite.

Veremos qué sale. Espero que muchos se sumen aportando sus puntos de vista, o al menos votando a favor o en contra de las iniciativas que se propongan. También me gustaría que los que opinen se presenten mínimante, digan si son alumno o docentes, y en qué carrera o materia utilizan PSeInt para contextualizar un poco más la opinión, aunque no es obligatorio. Propongo que el lugar para el debate sea el foro y no los comentarios de este post. Ya inicié el tema en el foro, pueden acceder con este enlace y empezar participar. Les adelanto que no va a ser rápida mi respuesta, tal vez recién en las próximas vacaciones termine llevando a la práctica lo que salga, pero quiero escuchar todas las voces antes de decidir y sentarme a implementar.


P.D: aunque había dicho que faltaría bastante para ver subprocesos en PSeInt, resultó que no estaban tan lejos después de todo.

21 comentarios:

  1. Hola.

    Soy profesor de programación de nivel secundario. Mi nombre es Víctor Viegas Barros.

    Años atrás probé (y usé) este soft en mis clases, pero la simbología no se adecuaba a lo que normalmente hago en clase, por lo que decidí crear mi propia versión, que terminó muy distinta.

    Si usted está interesado en verlo, con gusto se lo envío. mi correo es viveba@gmail.com.

    ResponderEliminar
  2. Para mí sería una evolución lógica el agregado de funciones y manejo de cadenas por ejemplo, yo empecé usando zinjai (que supuestamente está hecho para pequeños proyectos y para aprendizaje) y lo terminé usando en proyectos bastante grandes. En el modo consola hice unos retoques en la librería conio.h para poder usar colores.
    En el caso de pseint no creo contraproducente en que haya mas cosas, siempre y cuando sea el profesor quien decida cuales usar configurando las mismas en los perfiles.

    ResponderEliminar
  3. SI tienes razon pseint no debe convertirse en un lenguaje de programacion con demasiadas funciones o tareas, solo las suficientes y necesarias pues para un estudiante que se inicie en esto de la programacion desarrolle su logica sin complicarse la vida debe hacerlo en un entorno de trabajo facil de utilizar y de entender.
    Lo que faltaria a pseint en mi punto de vista es la creacion de funciones nada mas!!!!!!!

    ResponderEliminar
    Respuestas
    1. Ayer le ayude con unos trabajos a mi hijo, y vi que PSeInt, si tiene funciones, en la practica, lo que tiene es algo llamado function... pero si funciones, por definicion la function es un subProceso que retorna un valor y que trata sus parametros por valor... y eso lo hace PSeint...

      subprocess «variable» <-- «NombreProceso» («parametros»)

      en definitive tiene procesos y cumpre con lo que debe tener... lo que necesita, quizas yo no lo conosca, es la forma de capturer el error de ingreso de datos de tal forma que se pueda manejar... si espero un entero que no ingresen un char... esto generada un error y esto es basico para todo el que inicia, aprendiendo... validaciones de entrada.

      Eliminar
    2. Cuando escribí esto todavía no tenía funciones/subprocesos. Ahora sí. Por otro lado, respecto a las entradas, se pueden validar desde el código los rangos, pero no los tipos, lo segundo no sería tan simple a nivel sintaxis. En caso de un error de tipos en la entrada, lo informa el intérprete como error en tiempo de ejecución, y en la misma consola se puede reingresar la entrada haciéndole doble click.

      Eliminar
  4. Una función futura seria poder convertir el código a otros lenguajes como JAVA, LUA PYTHON, ETC, están de acuerdo con esto?



    ResponderEliminar
    Respuestas
    1. Estoy de acuerdo con eso. En contra te digo que no conozco a fondo muchos otros lenguajes populares además de C++, por en este momento no soy quien para decidir como hacer la mejor traducción a, por ejemplo, python, java, o lua. A favor te digo que con un poquito más de documentación alguien podría tomar el código del modulo que convierte a C++ y adaptarlo al lenguaje que le guste. Sin embargo el objetivo de este post es discutir el "lenguaje" en sí, y no las funcionalidades del intérprete o el editor.

      Eliminar
  5. Zascar, para no desviar el post principal, podrías por favor crear un nuevo post, dando una guía de como crear un modulo para convertir el pseudolenguaje a un lenguaje determinado. de seguro que con esto muchos se apuntarían a crear estas extensiones

    Muchas Gracias

    ResponderEliminar
  6. Estoy de acuerdo con que PseInt amplíe sus funcionalidades. Eso beneficiaría por un lado al usuario, que tendría la posibilidad de crear programas cada vez más complejos, y por el otro al autor, que se exije más y aprende más programando. Estaría bueno que se agregue soporte para Escribir y Leer archivos, controlar mejor la salida por consola (ubicación, colores, etc), manejar Registros, agregar más palabras claves. Y el usaurio inexperto solo maneja lo básico y listo.
    (Alejandro Caro)

    (ALejandro Caro)

    ResponderEliminar
  7. Si, debemos de pasar de lo básico IF-THEN... FOR-WHILE a manejo por ejemplo de estructuras de datos, aunque habría que inventar la forma de hacerlo en pseudo-code ?como?, muchos de los programadores potenciales se estancan, al manejar punteros y abandonan por completo la programación por la sintaxis complejas de los lenguajes existentes.

    Veo un gran potencial en Pseint por que es independiente a los lenguajes de programación, si se incluye la manera de exportar el pseudo-code a otros lenguaje seria algo muy novedoso, no he encontrada nada similar en la red

    ResponderEliminar
  8. me gustaria que pueda reconocer algunos procesos matematicos como por ejemplo: n=n-(n/10)*10 ,que deberia extraer el ultimo digito del número y no darme como resultado 0. y por último como sugerencia poder dimensionar un vector con variables, para problemas que no especifican la cantidad de elementos de un vector.

    ResponderEliminar
    Respuestas
    1. N/10*10 es N... Está bien que te de cero! Hacer que redondee arbitrariamente no seria muy intuitivo. Por otro lado, lo de los arreglos de longitudes variables se configura en el perfil.

      Eliminar
    2. ¿Y el código n=n-(n/10)*10 en que entorno está y la variable n como está definida?, En PseInt siempre da 0 y Code::Blocks si n está definida como float también da 0 pero como int da 8, por eso depende del código y de como esté definida n.

      así da 0:

      #include
      #include

      int main()
      {
      float n;
      n=n-(n/10)*10;
      printf("%.0f", n);
      return 0;
      }
      así da 8

      {
      int n;
      n=n-(n/10)*10;
      printf("%d", n);
      return 0;
      }

      Eliminar
    3. Hombre, si quieres quedarte con el último dígito, haz n=n%10 Te quedas con el resto de dividir por 10 y esas son las unidades.
      Quique 8-)

      Eliminar
  9. bucle repetir mientras
    Creo que sería interesante añadir el bucle repetir ... mientras.
    Ya sé que existe el repetir ... hasta, pero en los lenguajes más utilizados, como C o Java, el bucle que existe es el repetir mientras. Uno y otro son iguales, basta con cambiar la condición por la contraria, pero sería mejor que se acostumbrasen al bucle que usarán en el futuro. Se puede y debe mantener el repetir hasta, pero yo añadiría el otro.
    Saludos
    Quique 8-)

    ResponderEliminar
    Respuestas
    1. Ya existe el bucle Repetir...Mientras Que.
      El perfil tiene que tener sintaxis flexible activada, y hay que poner el "Que" para diferenciar si se cierra el repetir o se abre un nuevo mientras anidado.

      Eliminar
  10. Soy profesor y programador, y desde que descubri PsInt me ha ayudado mucho en las clases de algoritmos. No he visto la recien version con Funciones, algo que hecho mucho de menos en la version actual que tengo. Para ello, usaba SLE 2.0 (http://www.cnc.una.py/sl/SL-index.html), que es muy parecido. Leyendo los posts sobre incorporacion de archivos, cadenas, SLE tiene las funciones basicas de cadenas y manejo de archivos. Y de hecho, lo utilizo para la enseñanza de estas funciones sencillas cuando mas tarde los alumnos se enfrenten con un lenguaje de programacion real. Algunas de estas funcionalidades pueden ser agregadas a PsInt.

    ResponderEliminar
  11. Lo más urgente y lo que más me urge para el manual que estoy haciendo es en orden:
    Permitir dimensiones como parámetros
    Soporte para registros
    (Alejandro Caro)

    ResponderEliminar
    Respuestas
    1. No me queda claro que es "dimensiones como parametros", pero los subprocesos pueden recibir arreglos (hay un ejemplo en la ayuda), y las dimensiones pueden darse a partir de variables si el perfil lo permite.

      Eliminar
  12. Creo que sería necesario contar con estructuras de datos tipo registros (¿y por qué no definicion de tipos de datos?)

    ResponderEliminar
  13. Estaria bueno que se pudiera Implementar Registros

    ResponderEliminar