¿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.