domingo, abril 29, 2007

"Orientado a objetos" 1

Recuerdo una frase de Stroustrup que decía:
Certainly not every good program is object-oriented, and not every object-oriented program is good.


Pues bueno, tengo planeado divagar sobre el paradigma objetual y para esto planeo hacer 2 o 3 post al respecto. Inicialmente trataré de definir que es lo que quiere decir orientado a objetos, hablaré un poco de la historia de los lenguajes de programación (creo que mas que la historia, sobre el desarrollo de los diferentes paradigmas en una forma muy libre).

Al principio, todo era caos y oscuridad. Inicialmente la programación se realizaba siempre en lenguaje maquina. Dada la escasez de maquinas, y las capacidades limitadas se requería que cada programa fuese óptimo. De hecho, una anécdota interesante es que cuando se diseñaba FORTRAN se decía que este debía generar código comparado al generado "manualmente" en ensamblador ya que sino nadie lo utilizaría.

Pues bueno, en esta época de programas dependientes de las máquinas, había total libertad, por ejemplo se podía generar control flujo mediante la modificación del mismo programa. (Una forma de hacer esto es reescribir una instrucción de salto con una que no haga nada dada una condición.) y bien... posteriormente llego la programación procedimental a la que siguió la estructurada.

El cambio entre la programación procedimental a estructurada fue básicamente dado por un articulo de Edsger Dijkstra "Go To Statement Considered Harmful"... La idea detrás de la satanización del goto era básicamente dada porque un programa elaborado con sentencias de selección (switch, if) y sentencias loop (repeat for while) era mas fácil de entender. Y esto es consecuencia simplemente porque cada bloque podría entenderse por separado. (cabe mencionar que existe una demostración de equivalencia entre programación estructurada y funciones computables... turing completitud?)

En fin. De la misma manera, surge posteriormente el paradigma objetual. Lo que hacia la programación estructurada modularizando los procedimientos, lo hacia el objetual con fragmentos de código-datos en algo llamado TDA (tipos de datos abstractos). Y bien, es en este punto donde la gente discute sobre la revolución de los objetos. Es acaso el polimorfismo? la noción de mensaje que introdujo smalltalk? encapsulamiento? no se. Realmente, pese a que todas las características anteriores son propias de objetos hay una falta de formalismo que responda a.

Que es un objeto?

Eso lo dejo para el próximo post.

(Correcciones a mi introducción historica seran bienvenidas... porque la hice de memoria y probablemente abunden :P)

martes, abril 24, 2007

Frustración

Pues, si.

Este es un post fruto de la ineptitud y auto-compasión de alguien que hace una huxley-ana jerarquía de la humanidad, quiere ser un alfa, pero al parecer es un beta. Peor aun... no soporta ser un beta.

La búsqueda de practica fue una perdida de tiempo. Terminaré probablemente en el mismo lugar que aquel asesino del hacha. En el subconjunto al que no quiere pertenecer.

A todos los que les dije imbéciles en la cara, siguen siendo imbéciles.

jueves, abril 12, 2007

Verdadero amor

Y si... tan especial como la primera vez

Nada tan incomodo y emocionante como la pasta dura :D



Recién me los trajeron ayer, pero ya hay cositas super interesantes (como la frase que cite en la entrada anterior de Stroustrup) Pero bueno, todavía me falta invertir mucho mas tiempo a ambos libros, pero contemos algo que sucedió que tal vez a alguno le sorprenda.

Hace poco estuve en un pequeño seminario de investigación con algunos profesores de la universidad. El tema que se trato fue el de la aplicación de métodos formales en la industria y la persona que daría la charla no era nada mas ni nada menos que una de las profesoras en la universidad que cuenta con doctorado (chan chan chaaan).

Dentro del tema, surgió UML (porque?, no sé) el caso es que un amigo hizo la perfecta pregunta. ¿UML es solo para orientación a objetos? la respuesta de la señora esta fue, palabras mas palabras menos, que uml dentro de su montón de diagramas especificados de carácter sobrespecífico tenia posibilidad de modelar de formas diferentes a la objetual (una respuesta mas diplomática que correcta)

Con el handbook Computer Science en mi poder, me dio por revisar cuales eran los temas tratados en la sección de ingeniería de software. Casualmente pasando paginas encontré diagramas de casos de uso. Este diagrama hacia parte de una breve explicación de UML (3-4 pags máximo) de un capitulo llamado Object Oriented Design, el cual contaba con alrededor de 12 pags (si, aunque no lo crean UML ES para diseño orientado a objetos y mas sorprendente aun, mas de la mitad de la sección de diseño orientado a objetos no era UML)

Para poner las cosas en perspectiva, esta sección de diseño orientado a objetos con una tercera parte de UML es el segundo capitulo mas pequeño dentro de la sección de ingeniería de software (después de arquitectura de software), es decir, de 10 capítulos de la sección de ingeniería de software, UML es la tercera parte del segundo capitulo mas pequeño. Y HAY DIAGRAMAS EJEMPLO!!