Mis proyectos de sistemas en la USAC parte IV: Lenguajes Formales…

Se me olvidaba un curso de 4to semestre, paralelo a IPC2, uno de los que enseñan lo que es desvelarse echando punta, Lenguajes formales, impartido por el mismísimo Satán.  Era un curso introductorio a Compiladores, y por lo tanto, a nivel de éstos en cuanto a extensión y dificultad en sus proyectos, aunque con menor magnitud obviamente…  Aquí se realizaban 3 proyectos, los cuales se enfocaban en usar 3 diferentes lenguajes para comprobar 3 diferentes paradigmas supuestamente.

1. StaticS:

Éste realizaba cálculos de estadística descriptiva, leyendo un archivo de texto en donde estaba los datos, y sacándolos en un bonito HTML Éste proyecto fue desarrollado en otro lenguaje que destesto,  Pascal;  Quérian obligarme tal y como lo hicieron en IPC 1 a usar el Turbo Pascal, pero no pudieron, mi subversión me llevó a programarlo en Linux usando Free Pascal, un compilador libre y gratuito de Pascal, que tenía muchas más características que el raquítico compilador de Borland. El proyecto se encuentra aqui:

svn checkout http://proyectos-kreig-usac.googlecode.com/svn/trunk/pascal/LFP-proy1-StaticS/ statics

2. O-tell-O

Era el primer proyecto de la U que desarrollaba en Java, y como subversivo en cuanto a compiladores, lo desarollé en Netbeans mientras la mayoría prefería usar el Borland JBuilder (Cual era las gana de usar herramientas de Borland me pregunto yo?) ,  Éste proyecto no era más que el jueguito de otello, reversi, o como le quieran llamar, obviamente sin IA ni nada de eso, dado que no daba tiempo para implementarlo.  A continuación el código:

svn checkout http://proyectos-kreig-usac.googlecode.com/svn/trunk/java/LFP-proy2-OTELLO/ otello

3. Conjuntivity:

El primer proyecto en el que tuve contacto con un parser verdadero, que tuve que desarrollar a pata con la poca teoria que tenía de parsers recursivos descendentes.  La verdad fue el que me hizo crecer mi expectación por los compiladores, a pesar de ser desarrollado en otro lenguaje que destesto, el Visual Basic .NET. Obviamente, aqui no pude ser tan subversivo, pues para esa época no me quería arriesgar a desarrollarlo en Mono por cuestion de tiempo. no quedó de otra que echar mano del Visual Studio .NET 2002 (el mas buggy de todos) y desarrollarlo.  La solución se encuentra aquí:

svn checkout http://proyectos-kreig-usac.googlecode.com/svn/trunk/vb.net/LFP-proy3-Conjuntivity/ conjuntivity

Esos fueron los proyectos de Lenguajes, en los próximos posts estaré de regreso en el 5to semestre, publicando los de Compiladores 1…

PD. Para poder bajarlos, deben instalar el cliente subversion de consola en gnu/linux y ya instalado ejecutar el comando dado en el directorio donde se vaya a bajar. Tambien recomiendo usar el TortoiseSVN si van a bajarlos en Windows

Mis proyectos de sistemas en la USAC parte III: Estructuras de Datos…

Uno de los cursos más difíciles en la vieja escuela, continuación de IPC 2 en un semestre que no tenía nada de trivialidad al llevar cursos de Circuitos Digitales, y Compiladores simultáneamente con éste… y un curso que tuve que repetir en vacaciones con los proyectos ya ganados, (eso era lo bueno), y que, en la actualidad, esta mas orientado a web services y J2EE que a estructuras de datos puras. como cuando la llevé. pero bueno, hace tres años todavía teníamos que hacer Matrices Ortogonales, Árboles AVL, Hash tables, y todo tipo de estructuras desde cero, pues usar librerías como las collection de Java y las STL de C++ era un pecado para los auxiliares. En fin, de éste curso incluiré solamente 1 proyecto, el de un dizque Excel hecho en Java que utilizaria Matrices Ortogonales para manejar las celdas. y 1 práctica ratosa.

1. Proyecto ElectricSheet

Nombre basado en la canción electric Eye de Judas priest,  la verdad se trataba de una aplicación de Hojas electrónicas hechos en Java. que hace uso de la estructura de datos Matriz ortogonal, para representar las celdas del dizque excel.  Programado bajo Netbeans, y que además, ponía en práctica lo que llevaba en compiladores, al tener que implementar un mini parser hecho en JLex y Cup para interpretar las fórmulas, no era algo obligatorio, pero aproveche de una vez para aprenderlo, ya que me iba a servir en compiladores 2.  El código se encuentra hospedado en:

svn checkout http://proyectos-kreig-usac.googlecode.com/svn/trunk/java/EDD-proy1-ElectricSheet/ electricsheet

2. Practica de Mapeo lexicográfico.

La verdad no es la gran cosa, solo calculaba la posición lineal de un elmento en una matriz de n x m… no me recuerdo como se usa, por lo que dejo el código hecho en C++.

svn checkout http://proyectos-kreig-usac.googlecode.com/svn/trunk/c++/EDD-mapeolex/ mapeolex

Los Otros proyectos no los incluyo, pues el 2do me quedo bastante feo, y el 3ro, era un website que en realidad no era la gran cosa y dejo de existir para el bien de la humanidad.

PD. Para poder bajarlos, deben instalar el cliente subversion de consola en gnu/linux y ya instalado ejecutar el comando dado en el directorio donde se vaya a bajar. Tambien recomiendo usar el TortoiseSVN si van a bajarlos en Windows

JAVAizando sistemas de la USAC.

Una de las cosas por las que la gloriosa y tricentenaria Universidad de San Carlos de Guatemala se ha dado a conocer a nivel nacional, por ser una de las universidades en donde ganar los cursos es un sacrificio sinigual, Decir que alguien se graduó de la USAC muchas veces significa que es una persona que ha superado etapas de burocracia, catedráticos trabadores, y sobre todo, muchos desvelos. Y qué decir del prestigio de salir de Ing. en Ciencias y Sistemas, una de las carreras que por mucho tiempo fue considerada como la más desafiante dentro de la USAC. Ahh un gran sacrificio, mas por los 80s; sin Internet, ni wikipedia, ni Sourceforge, sin Amarok o Winamp y obvio sin mp3 de Kreator que escuchar para una mayor iluminación de algoritmos, etc…, y con una gran carga algorítmica dada en los cursos científicos computacionales y que había que desarrollar e investigar en bibliotecas convencionales.

Sin embargo todo esto ha ido cambiando, y desde el 2005, desde que entro el dizque decano Paiz, y su equipo de trabajo, específicamenteel Ing. Mazariegos, ex director de la Escuela de Sistemas, quien propuso al inicio de su gestión, “cambios” que supuestamente beneficiarían al estudiantado. Estos cambios fueron fundamentados en la necesidad de renovación de enseñanza en la carrera, que según él, eran más aplicables, llevaron a convertir esta carrera de alta demanda en Guatemala, en algo asi como una carrera enfocada más en tecnologías cortoplazistas y triviales, removiendo todo rastro de ciencia que tenía la carrera, y convirtiéndolo en J2EE, etc, una tecnología que si bien los conocimientos de ésta tienen alta demanda en el mercado, todos sabemos muy bien que el mundo tecnológico cambia a un ritmo acelerado, y lo que hoy es tecnología de punta, mañana es tecnología inservible, e inútil. y Java no va a ser la excepción.

Hasta donde yo se el nombre de la carrera es “Ingeniería en Ciencias y Sistemas”, mas no “Ingeniería en Java y Paradigmas Tecnológicos Actuales de Sistemas”, ya que pareciese que se removió cualquier rastro de ciencia que quedaban en cursos de 3er semestre al 6to, Convirtiendo los contenidos de cursos tan importantes como Estructuras de Datos, de Arboles B a Web Services e i18n en Java, y a la masterización de herramientas como NetBeans y JDeveloper…

El problema ha llegado a tal extremo que la pobre generación que comenzó Programación 1 en el 2do semestre de 2005 no sabe ni siquiera el concepto de puntero en C/C++, mucho menos van a saber la implementación óptima de un arbol B en C/C++, o de un Arbol de Sintaxis Abstracta, muy útil para los cursos de Compiladores, que afortunadamente siguen sin cambio en sus temas titulares y el contenido se sigue basando en el Libro del Dragon sin embargo…

A esto viene la siguiente pregunta: Cuando se ha visto que un compilador este hecho en una plataforma tan ineficiente sobre Java??? pues señoras y señores, esto es lo que se está haciendo en los laboratorios de Compiladores 1 y 2, imponer el uso de herramientas tan ineficientes como JLex y Cup y crear un intérprete o compilador en lenguaje Java que se ejecute ineficientemente sobre la JVM…

Para muestra un boton, el proyecto publicado en este blog esta hecho en Java, con una ineficiencia enorme, y no tanto por culpa del programador(o sea yo ;-)), sino de la plataforma Java y su JVM, Esa ineficiencia se hubiera minimizado si se hubiese hecho en un lenguaje igual de portable, e incluso soportando más plataformas de hardware/software que el mismo Java como C/C++ bajo GCC usando Flex y Bison o ANTLR(y si no me creen lo de la portabilidad, dos preguntas sencillas… Con que lenguaje está hecho y bajo que esta compilado el kernel de Linux?? en C bajo GCC obviamente, y en cuantas plataformas de Hardware se ejecuta?? Muchísimas, incluyendo teléfonos móviles…), por lo que la excusa de la portabilidad era el motivo para el uso excesivo de Java en los cursos de programación en la Escuela, con el anterior argumento se acabó.

Y no es que esté en contra de tecnologías y paradigmas como J2EE, .NET, , ni de lenguajes como Java o C# o tendencias como Web Services o i18n, Se que con ellas se pueden realizar muy buenas aplicaciones con el mínimo de esfuerzo, y reconozco que estas tecnologías se tienen que seguir impartiendo, sin embargo como temas de laboratorio, no de la clase titular. De lo que sí estoy en contra es de la sustitución de la base científica fundamental por éstas, que bien se sabe que lo que es ciencia, perdura por los siglos de los siglos.

Afortunadamente yo todavía tuve la oportunidad de ser la última generación en aprender lo que quedaba de Ciencia de la computación… ya que gracias a este background científico, aprender nuevas tendencias como Ajax, Ruby on Rails, J2EE, se hace mucho mas sencillo, y el cambio de paradigma menos costoso y doloroso… a que si le ponen a un alumno carnet 2005 a que les desarrolle un sistema de archivos para una base de datos usando Árboles B+ bajo C++. Que las cosas buenas continúen, y la ciencia computacional regrese a donde debe estar, he dicho.

Proyecto, Generador de Analizadores LALR en Java

Bueno señores, a continuación, un post aburridon y geek como cosa rara, pero estoy seguro que le puede servir a muchos estudiantes de Sistemas que van a llevar algun curso de Compiladores. Aqui publico el código fuente de uno de los más grandes y costosos proyectos que me ha tocado hacer en la carrera, un generador de analizadores sintácticos LALR. Este fue realizado para el laboratorio del curso Organización de lenguajes y Compiladores 2, y fue desarrollado en un mes aproximadamente. El proyecto fue hecho en parejas, complicándome yo mismo al elegir la parte más difícil (perdón pero la mejor manera de simplificarme la vida es complicándomela jaja) lo cual consistía en la de la creación de la tabla LR usando el famoso método LALR del famoso libro del dragón, así como también la interpretación del lenguaje de las acciones semánticas, si no entienden algo de lo que a continuación voy a escribir, por favor, ganen compiladores 1 y/o léanse (y entiendanlo que es lo mas difícil) el libro del dragon (Compilers, Principles, Techniques, and Tools. 1986. Aho, Sethi, Ullman ) del capitulo 1 hasta el capitulo 6 jeje.

El proyecto consiste en un compilador de una gramática en formato similar a los archivos de entrada de CUP, el lo compila hacia un paquete .lalr dado, el cual es un archivo binario que contiene toda la información necesaria (tal como la tablas LR(1) de goto y accion, tokens, y acciones semánticas) para poder interpretar cualquier fuente que está descrito con esa gramática, ejecutando las acciones dadas en cada producción.

Para ponerlo mas sencillo vean el sig. ejemplo:

– Tenemos un archivo de gramática para una calculadora con lo siguiente:
/**Definimos terminales y no terminales*/
terminal mas, por, num;

no terminal Inicio, S, E;

/**Definimos la gramática*/
S ::= E:res {:echo $res;:}

E ::= E + E {: RESULT = $e1 + $e2;:}
E ::= E:e1 * E:e2 {: RESULT = $e1 * $e2;:}
E ::= num:n {: RESULT = $n; :}
E ::= apar E:e1 cpar{: RESULT = $e1; :}
– Tenemos tambien un archivo de entrada que cumple con la gramatica anterior con lo siguiente:
1*2+(35*20)
NOTA: posiblemente las entradas dadas anteriormente necesitarán algunas modificaciones para que se puedan ejecutar, ya que no recuerdo muy bien la especificación del lenguaje, y esto lo escribí en base a lo que me recuerdo jeje, además que obvie las partes donde se definen las expresiones regulares y la parte de las funciones definidas por el usuario para su uso en las acciones.

Lo primero que se debe hacer es generar el paquete de la gramática escrita, luego con el paquete ya compilado, se analiza el archivo de entrada que cumpla con la gramatica especificada, e inmediatamente ejecutará las acciones asociadas segun vaya parseando.

El lenguaje que se definió para las acciones semánticas es un subconjunto muy reducido del lenguaje PHP, aceptando expresiones aritméticas y booleanas básicas, sentencias de control if y while, además de funciones. sin embargo, debido al poco tiempo dado para el desarrollo del proyecto, quiza algunas características de la interpretación en PHP no funcionen muy bien (por ejemplo, la verificación de tipos), por lo que estan en toda libertad de modificar el código, si lo logran entender jaja.

La parte del generador léxico se las debo, ya que como el proyecto fue desarrollado en parejas, esta parte le tocó al compañero Chucho, del cual no tengo autorización de publicar su código. Sin embargo esta parte la pueden desarrollar fácilmente al utilizar clases de tipo Tokenizer o incluso métodos de la clase String de java.

Por cierto, el proyecto fue desarrollado en el lenguaje Java bajo el JDK 1.5, se utilizó como herramientas JLex y Cup (aunque a mi parecer hubiera salido más facil con ANTLR, pero las reglas son las reglas), además de desarrollarse en NetBeans 5.5. Si tienen alguna duda o problema con la compilacion, lean primero el javadoc del proyecto, revisen el código fuente, y si no pues, posteen aqui.

El proyecto lo pueden acceder desde esta direccion

O si usan subversion con un simple checkout

svn checkout http://proyectos-kreig-usac.googlecode.com/svn/trunk/java/COMPI2-proy1-vmw/  vmw

Recuerden que están libres de modificarlo y hacer lo que les permita la GPL, mediante me coloquen en los créditos jajaja.

Modularización, un problema pendiente…

Es lamentable que muchos estudiantes de la carrera de Sistemas no apliquen los conceptos más importantes de modularización, sea cual sea el lenguaje… Es algo inaceptable que un proyecto largo, como los que suelen dejar en los cursos de Sistemas de la USAC, venga si mucho un par de archivos fuente.

Recuerdo en mis tiempos, cuando llevé progra 1/progra 2, y se programaba en C existían proyectos con una modularización que daba pena, ya que ni modularizaban a nivel algoritmico ( o sea, todo lo hacian en el void main() olvidando los principios fundamentales de la programación descendente), mucho menos utilizaban diferentes archivos para la división semántica del proyecto, y en algunos caso llegaban a utilizar hasta sentencias goto!!(incluso todavía hay gente que lo utilizan en java… que pecado a la abstracción).

Por ello, es importante una buena modularización, tanto para el entendimiento del propio código, como del código ajeno (ojo Willy), además de que ayuda
evitar código redundante.

Cada lenguaje y compilador cuenta con sus propias herramientas y técnicas, además de “barreras naturales” para una mayor modularización, listaré algunos ejemplos básicos:

  • HTML/XHTML del lado cliente: Dividir el contenido, presentación e interacción en diferentes archivos .htm/.xhtml, .css,(Hoja de estilos) y .js (javascript). Esto es muy importante mas si se van a utilizar RSS Feeds.
  • Java: Utilizando un public class por cada .java, y aplicando el concepto de packages, ademas de utilizar generics cuando sea posible para evitar redundancia.
  • C#: Aplicando un public class por cada .cs, tratar de enfocar todo el motor en las librerías, y utilizar namespaces, generics, y reflexion cuando sea posible.
  • C: Contener la definición en un .h, y la implementación en un .c, tratando de colocar las estructuras de datos y declaraciones en el .h, y colocando sólo los algoritmos y funciones para estas estructuras de datos en su respectivo .c.
  • C++: Aplican los mismos principios que en C, ademas de hacer uso de namespaces para evitar colisiones, y templates para evitar redundancia.

Bueno, estos son los principales, en los que regularmente se suele hacer un espagueti de código (en especial C). Tomen el consejo… modularizen y sigan la regla KISS (Keep it simple, stupid!!)