Intermezzo técnico
¿Me permite un pequeño descanso antes de continuar con la serie sobre ideologías? En el último post sobre Freya, en los comentarios, Daniel Alvarez me señalaba unos artículos en Internet sobre integración con Visual Studio, en la Bitwise Magazine inglesa. Me llamó la atención, merodeando por dicha página, el siguiente artículo:Cuidado, no estoy diciendo que esté de acuerdo con todo lo que se dice en el artículo. En realidad, creo que las opiniones de Huw y Dermot son muy diferentes, y en ocasiones incluso hablan de cosas muy diferentes sin darse cuenta.
Lo que quiero destacar es la importancia que Dermot concede al uso de interfaces... aunque en su caso, se refiere concretamente a las interfaces COM. Destaco esta opinión (basada en la práctica) porque coincide con lo que he podido comprobar por cuenta propia en estos últimos años... y que difiere radicalmente de las recomendaciones de Microsoft sobre el uso de tipos de interfaz.
En concreto, me gusta plantear la funcionalidad y arquitectura de un sistema mediante un conjunto pequeño de interfaces. Luego, las clases entran en escena, pero sólo como un recurso de implementación. Por ejemplo, el compilador de Freya está basado en unas pocas interfaces como ISymbolTable, ICodeGenerator e IParser que son luego implementadas por clases que funcionan como singletons dentro de una instancia del compilador. Luego tenemos interfaces como IAstNode, IStatement e IExpression, que son implementadas luego por una larga colección de clases. Lo importante es que toda comunicación entre módulos se especifica por medio de tipos de interfaz: el canal de comunicación que abren las interfaces es mucho más estrecho que el de las clases. Y la misma situación se da en Proteus, en XSight RT...
¿Mi consejo? Lea, analice, experimente y compare. Y luego, cuando decida, cuéntenos su decisión.
Ian Marteens, 7:25 p. m.
18 Comments:
A mi el artículo no me ha parecido gran cosa. Es superficial y descuidado.
Respecto a lo otro, yo me olvido completamente de la OO para diseñar la arquitectura de un sistema, pero si la uso para implementar las aplicaciones que componen el sistema.
Yo las interfaces las uso sólo para conseguir herencia múltiple (que pocas veces la necesito), y reservo la herencia de clase para la herencia más importante. En lugar de IParser tengo una clase abstracta que llamo ParserBase y luego tengo varias clases que se llaman Parser en distintos ensamblados y cargo dinámicamente la que quiero. Apenas tengo "singletons" por que puede haber mucha gente compilando a la vez. En mi caso Statement y Expression descienden de Node, y tengo un juego de clases para el árbol sintáctico y otro para el árbol semántico.
Lo que si tengo son varias interfaces IVisitor para recorrer los árboles.
A mi el artículo no me ha parecido gran cosa. Es superficial y descuidado.
Sí. Está escrito por Huw, que se ve que quiere obligar a Dermot a decir lo que Dermot no quiere decir.
Apenas tengo "singletons" por que puede haber mucha gente compilando a la vez.
Sí, me expresé sin cuidado: en realidad, no son singletons. Como no sabía lo que podía encontrarme al intentar soportar IntelliSense y esas cosas, me ocupé de que no hubiese estado global propiamente hablando en ningún módulo (algún generador de variables temporales quizás, pero quiero cambiarlo para que el resultado de la compilación sea "determinista"). En una de las betas de Delphi a alguien se le escapó que el compilador tenía problemas de reentrancia (no me extraña si, como sospecho, vienen arrastrando el compilador de la época de Delphi 1, como mínimo), y que eso era lo que provocaba que el Code Insight fuese tan ineficiente en comparación con IntelliSense. Y ya sobre aviso...
Por curiosidad, ¿qué haces? ¿un lenguaje? ¿Te pongo un enlace?
En lo que más coindido con el artículo es con esto que dice Dermot:
"I think that OO works well for ‘frameworks’ like the .NET Framework and it’s also not bad when you need to make small changes to existing programs. But most programs simply don’t fall into those categories. I would guess that most programming activity goes into databases of one form or another and the changes to these are not driven by anything approaching OO methodologies."
La OO te sirve para programar una interfaz gráfica de usuario y también te podría servir para implementar un SGBD, pero no tiene nada que decir en el nivel superior del sistema de información.
Pues estoy implementando mi idea de lo que debería de ser un SGBD distribuido, y también los componentes para utilizarlo desde las aplicaciones con muy poco esfuerzo.
Por supuesto su lenguaje es Turing completo con extensiones procedimentales, herencia, tipos definidos por el usuario etc. Es decir que también me tengo que pegar bastante con Parsers, Lexers, generadores de código y todo eso.
¿Un enlace a donde?
¿Un enlace a donde?
A la página tuya, o al blog, o a lo que tengas, que no los conozco.
No tenía yo de eso. Me acabo de crear uno. Ahora queda llenarlo.
¿Que tal si para empezar comento el capítulo sobre el Modelo Relacional de La Cara Oculta de C++ Builder 4?
Prometo no ser muy ácido O:-)
¡Madre mía! Bueno, no me trates muy mal: recuerda que el libro es de la cosecha del 98. Y pásame el enlace para incluirlo aquí y en la página "tradicional".
Si, pero probablemente lo va a leer mucha gente nueva en Brasil y Portugal, y algunas cosas del capitulo 1 no están muy allá que digamos.
Por cierto que me lo tuve que bajar con la mula.
Ya sabes lo que se dice sobre la dentadura del caballo subvencionado. Si se trata de algo gratis que usas como promoción de algo por lo que sí cobras, todavía le puedes dedicar algo de tiempo. Pero si es un libro gratis sobre un producto que ya, en la práctica, no "existe", es poco lo que se puede hacer.
Bueno, tampoco te preocupes: te pondré el enlace en cualquier caso. Para eso existen también las réplicas :)
Por cierto que me lo tuve que bajar con la mula.
Está en un servidor en mi oficina. Cada X días, el McAfee bloquea todos los puertos del servidor, porque sí, porque él lo vale. En el momento en que lo instalé, los distribuidores de DLink me intentaban colar el firewall por hardware por unos 500-700 euros (luego he descubierto que son más baratos que los routers, como dice la lógica). Por eso tiene un firewall de software.
En algún momento lo cambiaré... pero es el mismo problema que te mencionaba: es gastar dinero en algo que no te reporta beneficio económico. Hubo un tiempo, when I was young, como dicen las canciones, en que perseguía la fama y la fortuna, y si fallaba la fortuna, me quedaba con la fama. A estas alturas de la vida, le regalo la fama a quien quiera quedársela. Estoy pensando incluso en cambiar de profesión.
Pon el NOD32 o el Kaspersky. El McAca es una ...
Por cierto, ¿qué usas, un analizador recursivo descendente? El problema más gordo que tengo con el compilador de Freya (LALR(1)) es que hay que trabajar con una pila que almacena la información semántica como System.Object. Cada vez que hay una reducción, hay que convertir a mano los punteros a object al tipo exigido por el constructor del nuevo nodo... y sospecho que eso consume mucho más tiempo que el análisis sintáctico en sí (que no es mucho, de todos modos: en 3 milésimas se puede tragar un fichero fuente de 500 líneas, una vez superado el JIT). El problema no es el tiempo, claro, sino la mantenibilidad del asunto: es fácil olvidar la conversión adecuada, sobre todo teniendo en cuenta que hay dos parsers (uno especializado para el soporte de Intellisense). Tenía la idea de usar tantas pilas paralelas como tipos maneje el AST builder, pero generar y mantener a mano el código sería una tortura.
Por cierto, si te interesa la compilación para lenguajes funcionales y lógicos, me compré este libro:
Modern Compiler Design
La primera parte es bastante mediocre, pero luego cuenta algo sobre lenguajes funcionales (Haskell, sobre todo) y Prolog, que como introducción no está mal. Sobre todo, porque me sirvió para localizar un libro sobre la WAM (Warren Abstract Machine) para Prolog. Estoy dándole vueltas a la idea de, en vez de algo estilo LINQ, meter un motor de inferencias tipo Prolog para el acceso a datos "integrado". Pero todavía lo tengo muy verde...
Uso un analizador recursivo descendente, pero lo he hecho a pelo como mi abuelo. Fue lo primero que hice y es un tema que ya no me preocupa por que es muy eficiente y claro de leer como el cristal.
Ya se que esto horrorizaría a cualquier experto en compiladores, pero yo no lo soy, y en el tiempo que me hubiese llevado evaluar, elegir y aprender a usar un generador de analizadores, ya tenía el analizador casi acabado. Tampoco fue para tanto, la parte más fácil con diferencia. Mi analizador construye el árbol sintáctico directamente sobre la marcha y no hay un solo typecast.
A lo mejor hay alguna herramienta que genera un analizador de este tipo sin usar typecasts.
El mantenimiento del analizador no me parece un problema por que rara vez tengo que tocar más de media docena de líneas para cambiar cualquier cosa que se me ocurra. Además he usado clases parciales y lo tengo todo ordenadito en un montón de carpetas y archivos :)
Es curioso, ya se que no quiere decir mucho, pero acabo de hacer una pequeña pueba y me ha tardado unos 3,6 milisegundos en analizar 500 líneas. Bastante parecido.
El parser no hace nada de análisis semántico por que quiero tener las dos fases bien separadas. Por ejemplo el cliente le manda al servidor un árbol sintáctico en lugar de texto.
Si uso pilas para el análisis semántico y para el intérprete de los planes de consulta, aunque el tipo más específico es Node. Yo no necesito una pila por cada tipo, con unas cuantas para las familias de nodos más importantes ya evito la gran mayoría de los casts.
Gracias por la recomendación del libro. En la mula tienes una "versión de evaluación" de Engineering a Compiler, que lo recomiendan varios en esa página de Amazon.
Yo lo que quiero tener es algo del tipo de LinQ, pero bien hecho, con relaciones y tuplas como ciudadanos de primera clase (y no la chapuza de LinQ), y adiós al "impedance mismatch" ese.
He vuelto a leer el primer capítulo de La Cara Oculta de C++Builder y es largo de cojones :)
Como parece que tampoco tienes mucho interés por saber que puede estar mal, y como hay mucha tela que cortar, ya iré comentando cosas poco a poco y sobre los libros de informática en general.
Ya me he puesto a escribir cosillas en el Blog, a ver si cojo la costumbre
Como parece que tampoco tienes mucho interés por saber que puede estar mal
:) ¿He dicho eso? En todo caso, no sería saber qué está mal, sino qué crees que está mal. Probablemente, unas cuantas cosas. Otra cosa es la prioridad que le dé a corregir algo que estoy regalando respecto al trabajo que me permite comer. En ese sentido, agradecería infinitamente más saber qué está mal, por ejemplo, en el libro de C#, porque hay una segunda edición en marcha.
Entendido, me pondré con ello, aunque la cosa da para escribir un buen rato.
Recuerda pasarme la URL del blog, para enlazarte.
El Programador Gruñón
Aquí te dejo algo sobre lo primero que veo a primera vista en el libro de C#.
Lo encontrarás muy quisquilloso, pero yo lo encuentro bastante molesto, y creo que contribuye a que no se entiendan bien las cosas y a darles un halo de esoterismo.
Te he puesto ya el enlace en la barra lateral, pero no es muy visible. Mañana añado una entrada mencionándolo. Si alguien más lee esto y quiere que le enlace, que me lo diga. Sé que tengo unos cuantos enlaces pendientes (el de Nico, por ejemplo, pero el otro día, intentando buscar su blog, me fallaba la conexión).
Gracias, se ve de sobra.
El libro de C# está muy bien, solo veo algunas minucias.
Publicar un comentario
<< Home