jueves, junio 07, 2007

LALR

¿Tiene alguno de vosotros código que funcione para un generador LALR? Sí, ya sé que hay unos proyectos por ahí equivalentes a yacc/bison... pero me llevaría demasiado tiempo retocarlo y adaptarlo. El tiempo que no tengo ahora.
El caso es que tengo una idea de "producto": un generador de compiladores especialmente adaptado para .NET. ¿Cuál es el problema? Cuando se trata de compiladores .NET, o creas un compilador recursivo descendente, a mano (o con alguna ayuda de herramientas), o utilizas un analizador LALR(1), que suelen ser más potentes. Pero en este último caso, te encuentras un problema: el analizador suele llamar a un conjunto de rutinas para construir un árbol durante la compilación. Y esas rutinas por obligación reciben todos sus parámetros como valores de tipo object o de alguna clase base más o menos igual de primitiva. Como resultado, tienes que estar ejecutando conversiones dinámicas de tipos todo el tiempo. No se trata tanto de la pérdida de velocidad, que al final no es tanta, sino de la pérdida de seguridad, robustez, etc, etc. En un entorno nativo, podías realizar conversiones estáticas (arriesgándote a recibir un error en ejecución si te equivocabas), pero esto no es posible en .NET.
Hay otro problema: el modelo de desarrollo. Quien crea un compilador de esta manera tiene que programar, por una parte, la gramática "a secas". Luego de ejecutar la herramienta que la convierte en código ejecutable, tiene que ocuparse de establecer las correspondencias entre reglas de la gramática y rutinas semánticas. En sistemas más "primitivos", como el yacc, podías escribir las rutinas junto con las reglas. Sin embargo, GOLD Parser Builder, a pesar de ser una herramienta mucho más agradable de usar, sigue la filosofía de separar reglas y rutinas, en beneficio de la independencia del lenguaje.
Mi idea es crear un generador de compiladores basado en un lenguaje propio, de estilo funcional (es lo más adecuado en estos casos). Para cada no terminal de la gramática, se establecería un tipo para los nodos que generaría. Entonces, el generador podría crear pilas separadas para cada uno de los tipos asociados a las reglas. Así se evitaría el problema de las conversiones.
Por otra parte, por muy poca potencia que le des al lenguaje, se logra mucho. Como el objetivo de los "programas" es generar una estructura de datos arbórea, la mayoría de las llamadas serán a constructores. No es necesario que el lenguaje tenga "lazy evaluation", porque el algoritmo de análisis bottom-up garantiza que los parámetros de llamada a cada constructor ya estarán evaluados antes de esta llamada. Además, teniendo ya experiencia en compilar código para .NET sería extremadamente fácil que la herramienta crease directamente módulos o ensamblados, listos para utilizar, sin necesidad de pasar por un fichero intermedio con código fuente en otro lenguaje.
¿Alguien se anima?

Etiquetas: ,

26 Comments:

Anonymous Anónimo said...

Lo de tu comentario sobre el lalr supera mis conocimientos con creces y me recuerda mi total ignorancia sobre algunos temas de programación. Yo como programador de gestión pienso que conozco algo pero cuando veo estas cosas, me deprimo

jueves, junio 07, 2007 9:51:00 p. m.  
Blogger Ian Marteens said...

No tienes por qué, y no lo digo por cortesía. Es un conocimiento muy específico, de una técnica muy concreta y además, hay herramientas a montones que evitan tener que aprender los detalles. Es como lo de la raíz cuadrada: hay un algoritmo para calcularlas a mano, pero existiendo calculadoras, es mejor invertir la energía mental (o la memoria, o lo que sea) es hacer otra cosa de más alto nivel de abstracción.

En la misma programación de gestión hay un montón de cosas que nunca he logrado aprender.

viernes, junio 08, 2007 10:31:00 a. m.  
Anonymous Anónimo said...

Un saludo Ian, no es por meterme contigo, que no es mi intencion, pero una de las cosas que nunca has logrado aprender en aplicaciones de gestion es actualizar la serie D del curso de ADO.NET a la version 2.0, dicho sea sin acritud y con el mayor de los respetos.
Por cierto, el otro dia lei un hilo en un foro de C# entre Alfredo Novoa y Eugenio Serrano respecto a la necesidad de las tres capas en aplicaciones de gestion, o dejar solo dos capas, una de presentacion y otra de datos estando esta a cargo del sgbd como defendia Alfredo.
¿ Que arquitectura tendra la aplicacion de ejemplo del curso?
¿ Dos capas, tres, o solo una como Luis Candelas. ?

Un saludo con cariño ( sin sarcasmo, es sincero ).

viernes, junio 08, 2007 10:47:00 p. m.  
Anonymous Anónimo said...

Hola, estoy de acuerdo con el tema del curso, y otra cosa, he intentado conectar con el servidor de intsight desde donde me podía bajar los archivos de los cursos y no me funciona ¿?. Te agradecería un comentario.

Gracias y saludos.
Miguel.

sábado, junio 09, 2007 1:08:00 a. m.  
Anonymous Anónimo said...

Te pongo la página: http://www.classiquecentral.com/dman/dman.dll
la respuesta es domain expired. ???.

Gracias y saludos.
Miguel.

sábado, junio 09, 2007 1:10:00 a. m.  
Blogger Unknown said...

Tampoco estoy lo suficientemente familiarizado con el tema como para entender exactamente tus necesidades. En cualquier caso, te pongo la dirección de un parser generator que usé hace tiempo y que está hecho en c# además de ser open source:
http://grammatica.percederberg.net/

sábado, junio 09, 2007 10:52:00 p. m.  
Blogger Ian Marteens said...

Te pongo la página: http://www.classiquecentral.com/dman/dman.dll
la respuesta es domain expired. ???.

Es que estoy pensando en cerrar la empresa. Se descojona uno currando, para ganar una mierda de dinero, y para que esa mierda venga después papá Estado y se la lleve. Estoy pensando en irme a los Estados Unidos, donde viven mis padres, y donde quizás debía haberme instalado desde un principio. Me buscaré algún trabajo "normal" mientras tanto, pero para serte sincero, eso es lo que hay: que estoy bastante harto de este "negocio" (por llamarlo de alguna manera).

domingo, junio 10, 2007 3:40:00 a. m.  
Blogger Ian Marteens said...

Un saludo con cariño ( sin sarcasmo, es sincero ).

Hombre... supongo que no será tu caso, pero hay cariños que matan. Hace poco me decía un viejo conocido que había estado mirando lo de Freya, y que le parecía una tontería. ¿Por qué - me pregunta este buen señor - no había hecho algo más útil, como un esqueleto de aplicación de gestión para que la gente lo descargase gratuitamente?

No le dije nada, pero te puedes imaginar lo que pensé. La avaricia, la tacañería y ese puñetero gustito que tenemos de pensar y hacer las cosas a lo pequeño se han cargado el mercado de software de este país. Lo del gusto por lo pequeño lo digo porque, mientras Francia, Alemania, Italia y el resto de Europa producían óperas y sinfonías, aquí nos dedicábamos en cuerpo y alma a la zarzuela: el "género chico". Es sólo un ejemplo, pero creo que es representativo. Un país así es cojonudo para retirarse, o para pasar unas buenas vacaciones, pero no para vivir y trabajar. En otro país, ya habrían salido un par de patrocinadores para Freya, por poner un ejemplo. Aquí no: hay bastante gente interesada, pero siempre que no les cueste un duro.

Pues bien, me parece estupendo si las cosas son así: no me gusta ir sermoneando a la gente sobre lo que debe o no debe hacer. Pero es lógico que me sienta asfixiado. Tengo cuarenta años y una sensación cada día más clara de estar tirando mi cerebro en cosas que no lo merece.

Mira, a lo mejor, me hago escritor de novelas. Me van a salir ácidas que te cagas, pero eso vende. A veces la gente tiene un punto masoquista. Ahí tienes a los admiradores del doctor House.

domingo, junio 10, 2007 4:28:00 a. m.  
Blogger Jose Luis said...

Ian, soy el del cariño y no era de coña, tu curso me ha venido muy bien y si por las circustancias que sean no puedes actualizarlo pues perfecto, con lo que obtuve por lo que pague me doy por satisfecho.
Pero me habria venido muy bien como profesional del software que soy, aunque como tu dices 'en pequeño', quiero montarme un esquelo de aplicacion de gestion a pequeña escala para actualizar mis aplicaciones al .NET, son aplicaciones de poco mas de 100 tablas por lo general y ningun cliente tine mas alla de cinco puestos.
He hechado un vistazo a 'Business Objects' de Rockford Lhotka y me parece excesivo para lo que yo necesito actualmente, y no estoy seguro de que ese sea el camino correcto para el mercado al que yo me dirijo.
Si conoces algun libro, web, o fuente de informacion que no me hable de 'arquitectura distribuida' para la aplicacion del taller de carpinteria de aluminio te agradeceria sobremanera me informaras de ello.
Tal vez el error este en la herramienta y no sea C# y .NET la opcion correcta, a lo mejor estas aplicaciones es mejor desarrollarlas con spftware mas 'obsoleto' pero mas productivo y eficiente para este tio de aplicaciones como: Fox, Clarion, u otra herramienta similar enfocada al desarrollo de aplicaciones de bases de datos.
Gracias por los servicios prestados y un consejo, tu curso era barato y bueno, demasiado barato y tan bueno como el que mas, si te vas a los USA te hecharemos de menos.
Un Saludo.

domingo, junio 10, 2007 1:55:00 p. m.  
Blogger Ian Marteens said...

Tal vez el error este en la herramienta y no sea C# y .NET la opcion correcta, a lo mejor estas aplicaciones es mejor desarrollarlas con spftware mas 'obsoleto' pero mas productivo y eficiente para este tio de aplicaciones

Tal vez... pero en tal caso, sería otra manifestación más del extraño amor por lo "pequeño". Porque el taller de la carpintería de aluminio americana, a diferencia del taller del barrio, se conecta ahora con el servicio de tracking de su mensajería para saber dónde está cada envío. Sin embargo, la filial española de la misma mensajería sólo aumenta sus precios desde la llegada del euro, y la forma que tienes de saber dónde está cada paquete es llamar a la sucursal de destino y rezar porque no se lo tomen a mal.

Pásate, por cierto, por cualquier sucursal de MRW y mira el software de localización de direcciones que tienen: una base de datos de texto (nada de imágenes) a la que acceden con una mierda de programa escrito probablemente en Clipper. Hace poco la sucursal de mi barrio no encontraba una dirección en Málaga. Me cabreó mucho, porque ponían en duda que hubiese "copiado" bien la dirección... que en realidad, pasa directamente de mi base de datos a la etiqueta del paquete. Cuando me senté en la oficina, una simple búsqueda me dio la dirección y un plano del lugar. Y no es que no se me haya ocurrido cuando estaba con esta gente: es que no se conectan a Internet quién sabe por qué. Quizás es una decisión del dueño de la sucursal, para evitar que los empleados aprovechen para chatear o ver porno. Quién sabe, repito. Pero lo que importa es el precioso tiempo que perdí por esta mierda de chorrada de restricción.

¿Sabías que la productividad del trabajo (euros que se obtienen por cada euro invertido en mano de obra) en Estados Unidos no sólo crece constantemente... sino que se aleja de la europea a un ritmo mayor cada año? ¿Y que la misma relación existe entre la productividad europea y la estadounidense?

Es por esto que C# y .NET parecen cañones en una cacería de gorriones: porque sobre nuestras cabezas no vuelan águilas. Cuando alguna se extravía, por el contrario, intentan derribarla a pedradas. Por esto también hay tanto cariño a Linux por estos lares. Si tu aplicación sólo tiene que escribir en un disco y utilizar los protocolos asíncronos de comunicación de hace 15 años, está claro que no se necesita más. Y además es gratis.

La zarzuela contra la ópera. Small is not beautiful: most of the times, it's simply stupid.

lunes, junio 11, 2007 3:28:00 a. m.  
Blogger Ian Marteens said...

Y para que no parezca que me lo invento:

El coste por hora trabajada...

lunes, junio 11, 2007 9:58:00 a. m.  
Blogger Ian Marteens said...

... aclaro que no es lo mismo que la "productividad", pero es uno de los factores que influyen en ésta.

Lo jodido del asunto es que ese incremento en lo que cuesta la hora luego no lo ve el propio asalariado: casi parece que se evapora.

lunes, junio 11, 2007 10:01:00 a. m.  
Blogger Jose Luis said...

Me parece perfecto lo que cuentas y seguro que tienes mas razon que un santo, pero lo que yo necesito es un pequeño consejo profesional.
Ya se que puedo ponerme a reescribir las aplicaciones en .NET a pelo, inventando la rueda cada vez que tenga que solucionar cualquier problema y acabar desarrollando cosas que seguro cientos de programadores han hecho antes que yo, para evitar esto estoy intentando documentarme para encontrar cual es la forma 'correcta' de enfocar un aplicacion de gestion.
La serie D de tu curso era el punto de partida ideal, una aplicacion de gestion en C# 2.0, y con esto me ahorraba un monton de horas de trabajo, que siendo importante no es lo principal que buscaba.
Lo que en realidad busco es tener una referencia profesional de alguien con los conocimientos y experiencia suficientes para que la pauta que marque sea la correcta y que los errores que yo voy a cometer, ya los haya cometido el, en resumen una especie de nuevo GoF sobre patrones para aplicaciones de gestion, desde el esqueleto al tratamiento de casos concretos.
Ya se que esto no existe, pero por pedir que no quede.

Un saludo.

lunes, junio 11, 2007 2:18:00 p. m.  
Blogger Ian Marteens said...

La serie D de tu curso era el punto de partida ideal,

Pero es que sigue siéndolo. Es más, no hay nada en ADO.NET que no estuviese ya, con otro nombre, en el TClientDataSet y el TDataSetProvider.

Por eso es que me ha llamado más la atención la duda sobre si "dos capas, tres o una sola": el defecto del curso es que se corta antes de entrar en la materia extraña de las tres capas y el control remoto... no por capricho, sino por saber, precisamente, qué es lo que me pedía mi clientela potencial.

lunes, junio 11, 2007 5:04:00 p. m.  
Blogger Ian Marteens said...

... y el otro problema no es que sea malo desear "código precocinado". ¡Todo lo contrario! Lo realmente malo es que no sea rentable escribirlo:

1- Por una parte, tienes un grupo que exige eso mismo constantemente, a gritos y con muy malos modales... y exige, además, que ese código no le cueste un duro. Estoy hablando de la moda del open source (que no es exactamente una moda, sino un factor que va a provocar una extinción global como la del límite K-T).

2- Por la otra, tienes toda la tribu aquella que padece el síndrome NMH ("not made here").

Si te ves pillado entre estos dos frentes (que a veces se convierte en una única y gigantesca ola de tsunami), ves como el auditorio potencial se te reduce a proporciones ridículas. Ese es el problema del que me quejo, no otro.

lunes, junio 11, 2007 5:52:00 p. m.  
Blogger Alfredo Novoa said...

La productividad por hora española es penosa, pero hay varios paises europeos como Irlanda, Francia, Bélgica y Noruega que tienen productividades mayores que la de Estados Unidos.

http://www.ipyme.org/NR/rdonlyres/44CAEB7F-71C8-4AC1-A889-D18B3DACD6C2/0/ProductividadEmpresarial.pdf

No me extraña que estés harto del negocio. En España casi lo único que se hace es implantar software extranjero.

Es dificilísimo encontrar financiación para cualquier proyecto que no de beneficios a cortísimo plazo.

Lo bueno del software es que da igual donde se produzca que se puede vender en todo el mundo. La única forma de hacer algo interesante y vivir más o menos bien es producir para exportar.

miércoles, junio 13, 2007 10:07:00 a. m.  
Blogger Alfredo Novoa said...

Me parece interesante lo del generador LARL, aunque yo ya tengo demasiados proyectos interesantes por acabar O:-)

¿Has visto JavaCC?

Está bastante bien y está basado en visitors.

Lo de las pilas me parece muy interesante. Yo las estoy usando un montón para el análisis semántico y la generación de código, y van de maravilla.

Si se pudiesen usar pilas y listas de estructuras en lugar de objetos, los programas irían bastante más rápido.

miércoles, junio 13, 2007 10:41:00 a. m.  
Blogger Alfredo Novoa said...

Yo a Jose Luís le recomendaría que dejase de buscar recetas y que profundizase en sus conocimientos sobre los fundamentos de la profesión. De esta forma las respuestas a sus preguntas se volverán obvias.

Uno de los errores más típicos (y muy español) es el de buscar recetas para seguir ciegamente, en lugar de tratar de entender las cosas por uno mismo.

miércoles, junio 13, 2007 10:52:00 a. m.  
Blogger Alfredo Novoa said...

Por cierto, aquí se hacían zarzuelas por que no había público que pudiese o estuviese dispuesto a pagar lo que valía una entrada de ópera. En épocas de crisis incluso se encogían las zarzuelas.

miércoles, junio 13, 2007 1:59:00 p. m.  
Blogger Ian Marteens said...

Por cierto, aquí se hacían zarzuelas por que no había público que pudiese o estuviese dispuesto a pagar lo que valía una entrada de ópera.

Dato interesante, por cierto. Normalmente para estas cosas se suelen invocar otras causas: "ej que somos así", etc, etc. Pero eso tiene más lógica.

El cabreo me viene porque veo venir la crisis. De hecho, ya está aquí, pero la gente viene negando la mayor desde hace tiempo.

En cualquier caso, el negocio del software en España tiene mal arreglo. Ocurre en todas partes, pero aquí se siente mucho más: el sector está "secuestrado" por los administradores de sistemas. Tendría quizás que escribir un artículo con todas las experiencias personales sobre proyectos en los que, al final, se han gastado una pasta en hardware en vez de decidirse por una solución software mucho más barata (en instituciones públicas y en empresas privadas, por cierto, que es lo más sorprendente).

Cuando el administrador de sistema, además, padece el NMH y cree en frases y palabros como "oscurantismo del código fuente" (me lo dijeron el otro día y por poco me descojono), la cosa se agrava, porque el buen señor dedica la mayor parte de su tiempo a reinventar la rueda. Más o menos como lo mío con la señorita Freya... pero mis vicios los pago yo (y siempre he dejado claro a la peña que es un experimento).

miércoles, junio 13, 2007 7:55:00 p. m.  
Blogger Unknown said...

Referente a lo que comenta Jose Luis de un programa de gestión desarrollado en .NET desde cero existe un proyecto que va en esa linea:

http://www.boxerp.org

Yo también estaría interesado en desarrollar algo así pero tardaría años en conseguir la madurez del software actual con mi disponibilidad de tiempo.

domingo, junio 17, 2007 12:07:00 p. m.  
Blogger Alfredo Novoa said...

Hay muchos proyectos como ese, pero luego todos se quedan en nada. Le he estado echando un vistazo y tiene muy muy mala pinta.

La idea del conocido de Ian de crear un esqueleto de una aplicación de gestión open source en C# si que es una tontería.

domingo, junio 17, 2007 1:37:00 p. m.  
Blogger Unknown said...

Alfredo, ¿podrías argumentar un poco más tus opiniones? Gracias.

domingo, junio 17, 2007 3:16:00 p. m.  
Blogger Alfredo Novoa said...

El proyecto ese es sencillamente ridículo. No tienen nada hecho y se ve claramente que no tienen ni idea sobre lo que se traen entre manos. Parece que la idea del proyecto es ser todo lo "buzzword compilant" que se pueda y ver si alguien pica.

Crear el esqueleto de una aplicación de gestión no tiene mucho sentido por que una aplicación de gestión depende completamente de su base de datos específica.

ADO.NET, Winforms y SQL Server ya son el esqueleto de un sistema de gestión. Reemplazar todo eso por algo mejor si podría ser una buena idea, pero es un trabajo de chinos.

domingo, junio 17, 2007 5:35:00 p. m.  
Blogger Unknown said...

En lo único que estoy deacuerdo contigo es en que boxerp esta en pañales.

Es cierto que en el mundo del software aparecen tecnologías constantemente. Algunas fracasan y otras tienen exito pero criticar algo de antemano no creo que tenga mucho sentido. Mas cuando muchas de las cosas que nos parecieron inútiles en el pasado se acabaron imponiendo.

Creo que boxerp reune una serie de características que por lo menos habrá ilusionado a más de uno y viene a cubrir un hueco que aún no tiene dueño: un erp hecho en .net (o mejor aún, en mono) de código libre. Ni Winforms ni sql server forman parte de boxerp.

domingo, junio 17, 2007 11:00:00 p. m.  
Blogger Alfredo Novoa said...

Además de estar en pañales parece que lleva un año abandonado.

No lo critico de antemano, sino que me he leido toda la documentación y buena parte del poquísimo código que tienen, y no he visto nada de valor.

Es fácil ilusionar a más de uno con declaraciones de buenas intenciones, pero para sacar las cosas adelante hacen falta conocimientos y mucho trabajo, y aquí no veo casi nada de ninguna de las dos cosas.

domingo, junio 17, 2007 11:44:00 p. m.  

Publicar un comentario

<< Home