[Compilador] Otterkit | Estamos buscando ayuda de la comunidad

[KTSnowy]

COBOL con su estándar 2023 es un lenguaje excelente y poderoso, pero aún faltan algunas cosas. Estas son cosas que creemos que no deberían integrarse en la sintaxis del lenguaje y, en cambio, deberían seguir lo que hicieron otros ecosistemas al introducir una biblioteca estándar reutilizable para proporcionar funcionalidad adicional.

Si bien todos los demás proveedores de COBOL han optado por ampliar e integrar la funcionalidad directamente en la sintaxis de COBOL, se ha demostrado que esto no es lo ideal dada la cantidad de dialectos incompatibles (a veces con extensiones en conflicto). Sería mucho más beneficioso seguir estrictamente la sintaxis estándar de COBOL y proporcionar métodos y funciones adicionales a través de una biblioteca estándar.

COBOL es capaz de compilación condicional similar a C, por lo que cualquier dialecto aún podría beneficiarse de esta biblioteca siempre que el compilador implemente las directivas de preprocesador requeridas y se brinde ayuda para descubrir las diferencias para que funcione.

Estamos buscando ayuda de la comunidad con sugerencias para la biblioteca estándar de Otterkit

https://github.com/orgs/otterkit/discussions/12

[jorgeamedina2020]

@KTSnowy, Hola colega, coincido contigo, me esta pasando esos temas, yo vengo de un dialecto de cobol (MicroFocus vers 4.50 del año 1984) y pretendo migrar a algo mas avanzado como Gnucobol 2023 (su ultima version), y realmente todavia hay diferencias de interpetacion tanto en sus dialectos como en sus funciones a la hora de compilar y runtime. La migracion es todo un tema, saludos,

[KTSnowy]

@jorgeamedina2020, Hola, sí, este es un gran problema con el ecosistema COBOL actualmente, es algo que esperamos solucionar con nuestro compilador siguiendo estrictamente el estándar (y sin extensiones de terceros).

COBOL es un lenguaje estandarizado, por lo que es un poco triste ver todos los dialectos incompatibles.

Avíseme si tiene alguna sugerencia para la biblioteca estándar de Otterkit, necesitamos ayuda para averiguar qué necesita la comunidad.

[Kuk]

@KTSnowy, el problema no son sólo los dialectos sino las diferentes convenciones de llamada que se utilizan (call-convention).

[Nitzer]

Completamente de acuerdo.
Como sugerencia siempre que vayáis a conservar la posibilidad de trabajar con ficheros indexados, sería la posibilidad de que éstos se generen en la RAM sin uso de Disco, ganaríamos en velocidad.
Yo actualmente trabajo con Sql Server, pero utilizo muchos temporales por diversas situaciones y WIndows cada vez está haciendo que estos sean mas lentos, hasta llegar a la desesperación.

[KTSnowy]

@Nitzer, El estándar COBOL no define en qué codificación o formato debe estar el archivo de organización indexado.

Así que tenemos que elegir un formato, y pensamos en usar un archivo JSON para facilitar la lectura y escritura. Podríamos leer fácilmente el archivo JSON en la RAM y solo guardarlo en el disco después de realizar todos los cambios.

No sé si esto sería compatible con sus necesidades actuales, así que necesito sus comentarios al respecto. ¿Funcionaría para usted un archivo JSON indexado en lugar de los archivos binarios indexados habituales?

Una ventaja de esto es que sería compatible con cualquier base de datos que admita datos JSON.

[Kuk]

@KTSnowy, la pregunta es cuál será el rendimiento. En un indexado lo que se espera es rapidez. Es verdad que hoy el hardware permite y tolera incluso aberraciones en código. Pero si hablamos de toneladas de registros (cosa que hoy en día no hace casi nadie y opta por un SGBD, salvo sistemas legacy... pero aun así hay que tomarlo en cuenta, yo creo), tipo millones de registros, ahí el rendimiento de un JSON vulgar y corriente va a caer en picado.

A lo mejor sería interesante meditar en algo como un JSON + un fichero INDEX al lado, como lo hacen los de Micro Focus. Así el JSON se puede usar como tal, con BBDD etc, pero el INDEX asegura el acceso rápido.

No me queda muy claro otro tema. El JSON es un formato clave:valor, es decir lleva las dos cosas, estructura + datos. Esto es algo nuevo, porque los ficheros Cobol, indexados o no, son "churros" de datos, una cadena de bytes, que le aplicamos la estructura como máscara en el programa. Si lleva la estructura del fichero dentro del mismo... esto cambia mucho las cosas. Como por ejemplo, cómo tratar los REDEFINES etc.

Estoy algo cansado hoy y lo mismo se me va un poco la pinza, pero lo veo complicado con imprevistos potencialmente complicados a tener que tratar.

[JCantero]

@KTSnowy, @Kuk, @Nitzer, aparte de las cosas que habéis apuntado, los ficheros indexados de COBOL implementan el sistema de bloqueos para el trabajo en multiusuario el cual está muy logrado y es muy necesario.

COBOL y base de datos es otra posibilidad con distinta filosofía de trabajo

[fastpho]

@KTSnowy Me parece que COBOL necesita archivos indexados si o si , que despues lo acompañes con archivos tipo Json eso es otra cosa
Saludos....