miércoles, 28 de marzo de 2012

¿Quien es quien? Hoy: ZinjaI

Siguiendo con las presentaciones, toca hablar de ZinjaI (aclaración: la ultima letra es una i, pero en mayúsculas, no una L como parece con muchas fuentes, y lo pronuncio zinyai, por su significado: "ZinjaI is not just another IDE"). ZinjaI es actualmente un IDE (entorno de desarrollo integrado) para programar en C/C++, que debería ser útil tanto para principiantes como para programadores avanzados. Pero originalmente, no iba a ser así.

Todo empezó por un programa de becas que tienen en mi facultad para que alumnos de grado se inicien en investigación. El alumno se presenta con un director y un plan de trabajo para dedicarle algunas horas a la semana durante año y medio a algun proyecto de investigación o relacionado. A cambio recibe, entre otras cosas, una formación básica, una primer experiencia, y un punto más en su CV.  En un momento de mi carrera, el docente titular de las primeras materias de programación, aprovechando lo que ya tenía encaminado con las primeras versiones de PSeInt me ofreció aplicar para una de estas becas, para formalizar ese desarrollo y continuarlo.

Como la parte más importante (el intérprete en sí) de PSeInt ya estaba desarrollada, me puse a pensar qué otra herramienta nueva podría ser de utilidad en el aula. Dado que en nuestra carrera, luego de pseudocódigo pasamos a utilizar C++, lo lógico era pensar en una herramienta para empezar a trabajar con C++. 

lunes, 19 de marzo de 2012

Juguemos al diagrama de flujo

El diagrama de flujo es una alternativa directa al pseudocódigo. Siempre digo a mis alumnos que se puede pasar del pseudocódigo al diagrama y al revés mecánicamente, todas las veces que se quiera, y sin perder nada en el intento. Esto es bastante cierto, la información importante para el intérprete no varía. Es decir, no se pierde ninguna instrucción ni ningún argumento en el pasaje. A algunos estudiantes les resulta más fácil empezar planteando sus algoritmos en un diagrama antes que en un código. Cuando el algoritmo involucra estructuras de control (condicionales y/o bucles), el diagrama de flujo permite visualizar mejor las posibles lineas de ejecución que un código escrito secuencialmente.

Actualmente PSeInt permite ir del pseudocódigo al diagrama, pero no al revés, no permite editar el diagrama. Además de que los diagramas que muestra no son de los más lindos, y el visor no es de los más rápidos, siempre me pareció un punto bajo, un hueco donde se podía aportar mucho. Pues bien, en la próxima versión incluiré nuevo y fantabuloso visor/editor de diagramas de flujo, parecido al que se muestra en el video:

lunes, 12 de marzo de 2012

Su consulta no nos molesta

Antes de que lean esta entrada tengo que hacer una aclaración: en un proyecto de software libre, los usuarios son uno de los recursos más valiosos, no solo lo digo yo, lo deja muy claro Eric Raymond en "La Catedral y el Bazar" (no dejen de leer ese ensayo). En particular, en mis proyectos, donde no hay un gran equipo trabajando en el testing, el diseño, la documentación, etc. como sí puede suceder en una gran empresa, o en una fundación con más recursos, el feedback de los usuarios es vital, y por eso hay que cuidarlos, y no atacarlos como voy a hacer a continuación.

Creo que el problema se debe en gran medida a que el usuario medio, por decirlo de alguna manera, está acostumbrado a utilizar software privativo (pensando en enlatados de uso diario, no en desarrollos a medida para una empresa), y esto le ha generado muy malos hábitos, al menos desde la perspectiva de un desarrollador de software libre. Más allá de mis alegatos a favor del software libre, no soy un extremista, y sé que hay software privativo de muy buena calidad, que hay empresas serias y desarrolladores muy capaces en ellas; pero la forma en que se trabaja de un lado y del otro es muy diferente, y los usuarios, en consecuencia, también lo son.

miércoles, 7 de marzo de 2012

Sobre tipos de variables y bolas de cristal

En PSeInt siempre tuve un dilema interesante, y aún hoy no tengo certezas sobre cual es la mejor solución. El problema es cómo determinar el tipo de una variable. En este lenguaje, no es necesario declarar las variables y decir de que tipo son, pero sin embargo cada variable tiene un tipo asociado. Es decir, hay variables para guardar texto, otras para números, y otras para valores de verdad. El usuario casi nunca dice explícitamente de qué tipo son las variables que usa en su algoritmo (en realidad a veces sí, se puede configurar, pero en la mayoría de los perfiles no). Entonces, el interprete debe "adivinarlo", y para ello debe analizar qué se hace con estas variables, o qué datos se guardan. O sea, en realidad debe tratar de deducirlo. Pero no siempre se puede, y el problema es ¿qué hacer cuando no?.

Por ejemplo, tomando el siguiente fragmento de pseudocódigo:
    Leer A
    Escribir "Usted ingreso: ",A
La variable A podría ser de cualquier tipo, según qué ingrese el usuario. Si analizamos qué ingresa el usuario para determinar el tipo, en cualquier caso el algoritmo funciona. Pero este otro fragmento:
    Leer Clave
    Si Clave="123" entonces ...
funcionaría mal, ya que al leer 123 el interprete deduciría que es numérica, pero al querer comparar con la cadena de texto "123" generaría un error.

domingo, 4 de marzo de 2012

¿Quién es quién? Hoy: PSeInt

Antes de poder escribir sobre tópicos o problemas específicos de alguno de mis tres proyectos, por prolijidad debería escribir artículos presentándolos. Debería contar para qué sirven, como nacieron, en qué estado están, hacia a donde van, qué tienen de interesante, etc. Por eso, este artículo inaugura una trilogía de posts llamada ¿quién es quién? donde trataré de hacer las debidas presentaciones. Según el orden cronológico, de los tres proyectos que se considerarán centrales por ahora en este blog (no quiere decir que no haya tenido otros más chicos dando vueltas, o que no aparezca uno nuevo en el futuro), el primero en cobrar vida fue PSeInt; y su historia comienza así:

Tuve la suerte de aprender a programar (o algo similar, porque era un cavernícola, pero me las rebuscaba) mucho antes de entrar en la universidad. Aprendí de muy chico con Logo y Basic, y seguí con este último y sus derivados durante largos años, tal vez más de lo aconsejable. Probé desde el primer Basic para DOS hasta los modernosos Visual Basics de la época, pasando por apbasic, zbasic, qbasic, quickbasic, etc. Aunque podría resumirlo en Quick Basic y Visual Basic, los demás son solo leves variaciones. Programar siempre fue un hobbie, casi un arte, como tocar la guitarra, o escribir cuentos, algo divertido, así que hice mucha mucha práctica. El punto es que llegué a la universidad sin saber lo que era una clase o un puntero, pero con un dominio casi absoluto sobre los ifs anidados, los fors, los whiles, y las expresiones matemáticas que uno usa habitualmente al programar.