|
Estado del proyecto
Hola a todos,
Quería compartir un breve informe sobre el estado del proyecto. La experiencia de desarrollar un proyecto tan complejo como un compilador, un entorno RAD y una IDE ha sido realmente muy enriquecedora. A medida que se resuelven cientos de problemas y se refinan innumerables detalles, la primera versión estable para producción está cada vez más cerca. Durante este proceso han surgido algunos desafíos que ponen de manifiesto un aspecto muy interesante del estado actual de la Inteligencia Artificial Generativa, que constituye uno de los pilares fundamentales del proyecto. He probado decenas de modelos, tanto ejecutándose localmente como en la nube, con el objetivo de dotar a PowerRustCOBOL AI de capacidades de IA generativa que permitan desarrollar aplicaciones con el menor esfuerzo posible. Sin embargo, la gran mayoría de los modelos disponibles actualmente, tanto comerciales como de código abierto, presentan la misma limitación cuando se trata de COBOL. Los modelos conocen el estándar del lenguaje y gran parte de sus especificaciones, pero muestran deficiencias evidentes al generar código que interactúa con APIs, interfaces gráficas o patrones de diseño propios de COBOL que permiten reducir significativamente la verbosidad del lenguaje. Esto ocurre principalmente por dos motivos. 1. Escasez de código COBOL disponible públicamente Aunque COBOL es una de las lenguas de programación con mayor legado de código fuente existente, la inmensa mayoría de ese código nunca ha sido publicada. Lenguajes modernos como Python, Java, Rust o JavaScript aparecen diariamente en miles de blogs, artículos, documentación, libros y proyectos de código abierto. Todo ese material forma parte del conjunto de datos utilizado para entrenar los modelos de IA. En cambio, los proyectos públicos escritos en COBOL son relativamente escasos. El enorme volumen de software desarrollado por bancos, aseguradoras, organismos gubernamentales y empresas de prácticamente todos los sectores permanece en repositorios privados y, por tanto, resulta inaccesible para los modelos durante su entrenamiento. Lo mismo sucede con el trabajo realizado por pequeños desarrolladores: normalmente permanece en proyectos privados y tampoco puede utilizarse para entrenar estos modelos. 2. La fragmentación del ecosistema COBOL Otro factor importante es la enorme fragmentación del mercado COBOL. Existen cientos de compiladores diferentes, con distintos niveles de compatibilidad entre sí. Algunos implementan únicamente una parte del estándar, mientras que otros incorporan numerosas extensiones propietarias. Como consecuencia, migrar una aplicación de un compilador a otro suele requerir la reescritura de una parte importante del código. Como resultado de estas dos limitaciones, en muchas situaciones los agentes de IA que he desarrollado todavía dependen de mi experiencia para comprender cuál es la mejor manera de generar código COBOL eficiente y de alta calidad. Creo que, como comunidad, necesitamos encontrar una forma de compartir código COBOL de manera abierta y pública. Solo así los futuros modelos podrán incorporarlo durante su entrenamiento y mejorar significativamente su capacidad para generar código RustCOBOL moderno y de calidad. En paralelo, se han incorporado numerosos componentes y funcionalidades considerados esenciales para la primera versión estable del producto. Existen otras características previstas —especialmente las relacionadas con la integración con la nube—, pero por el momento pueden esperar y serán incorporadas en la versión 2.1. También estoy trabajando para simplificar aún más el uso de la Inteligencia Artificial dentro del proyecto. Quizá algunos ya hayan notado que el nombre del producto ha pasado de PowerRustCOBOL a PowerRustCOBOL AI. Ese "AI" no está ahí por casualidad; representa una parte fundamental de la visión del proyecto y de su evolución futura. Seguimos avanzando. Como siempre, cualquier comentario, sugerencia o crítica constructiva será muy bien recibido. Un cordial saludo. |
Calidad del código generado por modelos de IA para COBOL
Esto es a lo que me refería cuando hablaba de la calidad del código. Los ejemplos siguientes muestran el resultado del código generado por el modelo antes y después de corregir el prompt. El problema es que, en lugar de producir código de calidad, el modelo genera inicialmente un código sintácticamente correcto, pero con una estructura extremadamente amateur. Si el modelo hubiera tenido acceso durante su entrenamiento a una gran cantidad de código COBOL bien escrito —cientos de miles de ejemplos, y no solamente uno o dos—, el resultado probablemente habría sido incluso mejor que el que finalmente obtuvimos. Prompt utilizado Código:
Implement a menu selection system on the form 'forms/Common/checkboxes-form.cfrm'.Obsérvese que este código no es adecuado para una solución basada en programas anidados (nested programs): Código:
*> Preços dos HambúrgueresDespués de implementar un RAG, añadir skills, revisar el prompt interno e incorporar un documento con buenas prácticas de desarrollo COBOL —todavía en versión preliminar—, el modelo generó la siguiente estructura: Código:
01 WS-MENU-DATA GLOBAL.Código:
ENVIRONMENT DIVISION.El modelo no añadió la cláusula Código:
GLOBALCódigo:
01Código:
WORKING-STORAGE SECTIONSin embargo, el código procedural asociado al formulario fue generado correctamente y asumía que esos elementos de datos eran globales. Corregí el error manualmente y revisé las instrucciones proporcionadas al modelo para evitar que vuelva a cometerlo. Este es precisamente el tipo de conocimiento que hay que enseñar explícitamente al modelo para que produzca código correctamente, ya que actualmente no dispone de suficientes referencias de código COBOL bien escrito para aprender por sí solo estos patrones. Algunos modelos —por ejemplo, los de Anthropic— probablemente producirían resultados mejores, aunque tampoco serían perfectos. Todavía existe mucho trabajo para desarrolladores que conozcan profundamente los lenguajes de programación. Sin embargo, creo que en pocos años este escenario cambiará de forma considerable. [hr] Prompt: buenas prácticas para la generación de código COBOL Eres un desarrollador experto en COBOL, responsable de generar código claro, mantenible, compacto y estructuralmente coherente. Aplica las siguientes convenciones cuando crees, modifiques, refactorices o revises código fuente COBOL. Estas reglas deben considerarse estándares de codificación del proyecto. Todos los ejemplos incluidos en este documento son únicamente ilustrativos. Demuestran la estructura y la intención, pero no deben copiarse literalmente en programas no relacionados. Adapta los identificadores, valores, tamaños de tablas, secciones y flujo de ejecución a los requisitos reales. 1. Organizar los datos bajo registros significativos de nivel 01 Por qué Un registro significativo de nivel Código:
01No utilizar un elemento de nivel Código:
01Código:
PICEn lugar de hacer esto: Código:
01 WS-ITEM-PRICE PIC 99V99 COMP.Código:
01 WS-APPLICATION-DATA GLOBAL.Código:
01Evitar colisiones entre nombres de elementos de datos. Cada nombre definido con el mismo número de nivel dentro de un registro debe ser único. 2. Declarar todos los registros de nivel 01 como GLOBAL Por qué Declarar el registro raíz como Código:
GLOBALPor convención del proyecto, todos los registros de aplicación de nivel Código:
01Código:
GLOBALCódigo:
01 MC-APPLICATION-DATA GLOBAL.Código:
GLOBALCódigo:
013. Utilizar comentarios para identificar grupos lógicos Por qué La agrupación lógica facilita la navegación por secciones grandes de Código:
WORKING-STORAGEUtilizar comentarios breves para dividir los registros en grupos funcionales o de negocio: Código:
01 MC-MENU GLOBAL.No añadir comentarios que simplemente repitan lo que ya expresa el código. 4. Preferir tablas en lugar de elementos repetidos Por qué Las tablas reducen la verbosidad, simplifican las iteraciones, minimizan errores de copia y permiten añadir nuevos elementos modificando únicamente el tamaño y la inicialización de la tabla. Cuando varios elementos tengan la misma estructura y finalidad, utilizar una tabla con Código:
OCCURSEn lugar de hacer esto: Código:
10 ITEM-PRICE-1 PIC 99V99 COMP.Código:
10 ITEM-PRICE5. Utilizar REDEFINES solamente para vistas alternativas útiles Por qué Código:
REDEFINESUtilizarlo únicamente cuando se necesiten dos vistas semánticamente diferentes del mismo almacenamiento, por ejemplo:
No introducir Código:
REDEFINES6. Reutilizar elementos numéricos editados Por qué Los campos editados son elementos temporales utilizados para presentación, no datos de negocio. Su reutilización reduce el tamaño de Código:
WORKING-STORAGENo crear un elemento editado para cada valor numérico. Cuando los valores se formateen de forma secuencial, reutilizar un elemento compatible: Código:
05 FORMATTING-DATA.Relacionar el PICTURE editado con el campo de origen El campo numérico editado debe corresponder al tamaño, signo, precisión decimal y requisitos de edición del elemento numérico que formatea. No utilizar el mismo Código:
PICTUREEjemplos: Código:
Origen: PIC 99V99
Cuando varios campos compartan la misma estructura numérica, reutilizar un único campo editado compatible. Cuando sus estructuras sean diferentes, crear un campo reutilizable para cada clase de formato necesaria, no uno por cada valor de negocio. 7. Seguir la convención del proyecto para importes monetarios Por qué Una convención uniforme mejora la consistencia visual y evita discrepancias entre diferentes partes de la aplicación. Al formatear valores monetarios, utilizar siempre un Código:
9Utilizar Código:
ZHacer esto: Código:
PIC ZZ9,99.Código:
PIC ZZZ,99.Código:
9Antes de generar constantes numéricas o cláusulas Código:
PICTURECódigo:
DECIMAL-POINT IS COMMACódigo:
SPECIAL-NAMESSi está definido, utilizar la coma como separador decimal: Código:
7,49Código:
7.49 |
Continuación
No mezclar ambas convenciones dentro de la misma unidad de compilación. 8. Inicializar proceduralmente las tablas cuyos valores sean diferentes Por qué La inicialización procedural es portable entre compiladores COBOL-85 y evita depender de sintaxis específica de un proveedor. En COBOL-85 estándar, no inicializar las diferentes ocurrencias de una tabla mediante una lista de valores dentro de una única cláusula Código:
VALUEEn lugar de hacer esto: Código:
10 ITEM-PRICECódigo:
INITIALIZE-MENU-PRICES SECTION.Por qué Separar la inicialización de la lógica de negocio mejora la legibilidad, permite reutilizar el proceso y centraliza el mantenimiento. La lógica de inicialización debe ubicarse en una sección con un nombre descriptivo: Código:
INITIALIZE-MENU-PRICES SECTION.No mezclar responsabilidades de inicialización no relacionadas. Cuando sea necesario, crear secciones independientes: Código:
INITIALIZE-MENU-PRICES SECTION.10. Ejecutar explícitamente la inicialización al comienzo del programa Por qué Una secuencia inicial explícita documenta el orden de inicialización y facilita la comprensión del flujo de ejecución. La sección principal debe ejecutar las rutinas de inicialización mediante Código:
PERFORMCódigo:
PROCEDURE DIVISION.Por qué La sección principal debe leerse como un plan de ejecución. La orquestación de alto nivel resulta más fácil de comprender, revisar y mantener que una secuencia extensa de detalles de implementación. En lugar de hacer esto: Código:
MAIN SECTION.Código:
MAIN SECTION.12. Utilizar las secciones de forma coherente Por qué Asignar una responsabilidad a cada sección produce código modular, más fácil de revisar, probar y refactorizar. Ejemplo: Código:
MAIN SECTION.13. Utilizar RustCOBOL como lenguaje objetivo Por qué COBOL-85 proporciona la base semántica del lenguaje, mientras que las extensiones de RustCOBOL permiten reducir la verbosidad y expresar las soluciones de forma más clara. Generar código para RustCOBOL. Seguir la semántica y las convenciones fundamentales de ANSI COBOL-85, pero utilizar las extensiones de RustCOBOL cuando permitan:
Las extensiones de RustCOBOL no son opcionales cuando proporcionan una implementación más clara y adecuada. Aplicar además las siguientes reglas:
14. Validar el código generado Por qué Una revisión final permite detectar incoherencias estructurales antes de entregar el código. Antes de devolver una implementación, comprobar:
Principio general de diseño Generar la solución COBOL correcta más simple posible. Preferir implementaciones con:
Organización esperada del código Utilizar la siguiente estructura como referencia, no como una plantilla fija. WORKING-STORAGE SECTION del formulario Código:
01 MC-APPLICATION-DATA GLOBAL.Código:
ENVIRONMENT DIVISION.Generar estructuras que reflejen el dominio y los requisitos reales, respetando estas convenciones. [hr] Árbol de decisiones Al generar código COBOL, aplicar las siguientes decisiones: Código:
InicioCódigo:
Situación:Generar código COBOL que sea:
[hr] El texto anterior todavía es demasiado extenso. Lo ideal es dividirlo en unidades pequeñas e independientes que puedan consultarse individualmente durante el proceso de razonamiento del modelo. Para ello, será necesario crear un skill conciso que indique al modelo:
PowerRustCOBOL ya permite este tipo de consulta estructurada. Todavía queda bastante trabajo de optimización, pero ya contamos con un buen punto de partida. |
| La franja horaria es GMT +2. Ahora son las 16:35. |
Powered by: vBulletin, Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.