Nuevo compilador de Cobol .NET de código abierto

[Joseg]

Próximamente nuevo compilador Cobol de código abierto para el entorno .NET

https://otterkit.com/

[Kuk]

@Joseg, joder qué decepción, o sea, digo obsesión, con el puñetero .NET :rofl:

Bueno, ya veremos qué tal. Pero tiene pinta de que todavía le falta, ¿no? Está lleno de TODOs :)

Estaba el de Raincode también, creo :piensa:

[Joseg]

Também não gosto do .NET
Muito pesado!

Sim, Raincode tabém compila para .NET

[KTSnowy]

@Kuk, Hola, soy el actual "desarrollador principal" de Otterkit.

La decisión de optar por dotnet se debió en parte a la gran cantidad de compiladores COBOL propietarios y costosos en este espacio. GnuCOBOL ya existe en el espacio C nativo, por lo que pensamos que la comunidad podría beneficiarse más de un compilador COBOL de código abierto para dotnet. Si tiene alguna sugerencia sobre qué lenguaje de programación podríamos compilar en su lugar, tal vez podríamos agregarlo al "codegen" en el futuro.

Además, las "TODO" en el sitio web se deben a que hemos estado extremadamente ocupados trabajando en el compilador y actualmente no tenemos tiempo para trabajar en el sitio web.

Tuve que usar Google Translate para esto porque mi español no es muy bueno, espero que esto no rompa ninguna de las reglas del foro.

[Kuk]

@KTSnowy, hola compañero y bienvenido! Un placer tenerte entre nosotros!

Enhorabuena por esta iniciativa, que me parece fantástica. :bien: Todo lo que sea Cobol + Open Source, sea cual sea la plataforma/framework etc. es bienvenido porque como dices lo hay muy poco.

Lo de .NET. Yo personalmente no soy muy fan de Microsoft.
Puestos a soñar, para mi lo ideal sería un pack con un compilador hacía binario nativo, que sea cross-platform + un GUI decente tipo Qt o similar con su editor gráfico WYSIWYG.

Pero esto es mi opinión nada más. Y en cualquier caso vuestra iniciativa me parece muy de agradecer.

En el foro todos o casi todos andamos mal de tiempo, pero bueno si podemos ayudaros en algo y contribuir con nuestro granito de arena, yo creo que más de uno estaremos encantados :acuer:


Por cierto, vuestro compilador imagino que se integra directamente con el MS Visual Studio?

[Josber]

@KTSnowy, Creo que ninguno nos esperábamos que apareciera el/uno, (supongo, porque serán varios), de los creadores de semejante proyecto.

Ansioso de darle un vistazo cuando esté terminado. Un excelente trabajo y como dice @Kuk, todo lo que sea COBOL y Open-source, bienvenido, a ver si empresas como Microfocu$, aprenden un poco

Lo dicho y pensado por todos, bienvenido por aquí.-

[KTSnowy]

@Kuk, Nuestro compilador no se integra directamente con Visual Studio, sino que compilará COBOL en C# y llamará a la CLI de dotnet internamente para compilar los archivos de C# en un binario. Esto nos permite no limitarnos a compilar solo en C#, podríamos compilar en Rust y llamar al compilador de Rust sin tener que volver a escribir todo el compilador.

El repositorio para el compilador está aquí si alguien está interesado: https://github.com/otterkit/otterkit

@Josber, Sí, el compilador COBOL de Micro Focus es bastante caro. Esperamos que nuestro proyecto ayude a la comunidad COBOL de código abierto. El ecosistema COBOL necesita un poco más de código abierto.

[Kuk]

@KTSnowy, vale lo entiendo, entonces habéis elegido la misma táctica que los de COBOL-IT y GNU Cobol que es crear un traductor a otro lenguaje y utilizar un compilador de terceros.

Oye pues ya que estamos, si te parece bien, te voy a preguntar varias cosas más, así tenemos más conocimientos sobre vuestro proyecto.


El tema de ficheros, cómo lo habéis resuelto? Habéis creado vuestor propio File-Handler? Sobre todo lo digo por el tema de los ficheros Indexados, que no existen tal cual en otros lenguajes (que yo sepa). Además, está el File-Status también que hay que gestionarlo.
He visto que el compilador vuestro soporta sourfeformat fixed y free. No pensáis añadir sourceformat(variable)?


:)

[KTSnowy]

@Kuk, Todavía no hemos implementado el File Handler en la biblioteca de runtime, pero es parte del estándar COBOL, por lo que también lo implementaremos. Estamos planeando implementar todas las características del estándar COBOL 2022.

El compilador actualmente tiene una opción de línea de comando "--column", que le permite especificar un límite de longitud de columna personalizado. Si usa --fixed --column 250, debería comportarse como el formato variable. Implementamos esto como una opción de línea de comando para evitar agregar una directiva de compilador no estándar.

[Kuk]

@KTSnowy, este estándar ni sabía que existía. Habrá que echarle un vistazo a ver qué trae de nuevo.

El File-Handler, para mí que no es algo fácil a implementar y os va a tomar tiempo, yo creo... Habrá que prever muchas cosas, entre otras el buffering, para que el READ no haga muchas I/O etc.

No conozco C#, conozco algo de Java SE y sobre todo mi orientación es más bien hacía la compilación nativa. Pero bueno, si tenéis dudas sobre algo o queréis opiniones, aquí estamos. Estamos muy orgullosos de tener con nosotros a varios Gurus, tales como @Nitzer o @Eslopes :bien:


P.D. creo que nuestro gran amigo que por desgracia nos dejó hace unos años, Rui Pinto (@Rapinto), estaría encantado con la idea y podría aportar mucho... :(

[KTSnowy]

@Kuk, Creo que lo más notable que agregó el estándar COBOL 2022, fueron las 2 "statements" de mensajería asincrónica. "SEND" y "RECEIVE".

[Josber]

@Kuk, Creo que lo más notable que agregó el estándar COBOL 2022, fueron las 2 "statements" de mensajería asincrónica. "SEND" y "RECEIVE".

¡¡Anda!!, esas son nuevas para mí, ¿qué son?

Por cierto, ¿hay algún sitio donde se puedan ver las novedades del 2022?

Gracias.-

[KTSnowy]

@Josber, Las statements asíncronas "SEND" y "RECEIVE" le permiten definir eventos asíncronos de forma similar a como lo hace Javascript. Puede definir un servidor de mensajes que responda a estos mensajes de forma asíncrona y definir cómo responde a cada "tipo" de mensaje. Es como Javascript, te permite definir eventos personalizados.

Básicamente, "RECEIVE" sería similar a un evento "OnReceive" y "SEND" sería el emisor del evento.

No creo que pueda leer sobre esto en los sitios web de los proveedores actuales. Esta información se toma del actual borrador del estándar COBOL 2022. Deberá obtener una copia de la organización ISO, ellos albergan el grupo de trabajo actual de COBOL. Estamos usando esa versión ahora mismo para trabajar en Otterkit.

[Nitzer]

Empezar el año así, Impresionante, menuda noticia, todo lo que sea Cobol y Novedad es bienvenido, y como te han dicho por aquí los demás, un honor que hayas contado con nuestra pequeña comunidad.
Cualquier cosa que necesites, estaríamos encantados de participar para que el proyecto triunfe.

[KTSnowy]

@Nitzer, Muchas gracias, si desea ayudar con el compilador, puede encontrar el repositorio aquí: https://github.com/otterkit/otterkit

El compilador está bajo la licencia Apache 2.0 y siempre será gratuito y de código abierto.

Siéntase libre de abrir pull requests y issues en GitHub, estamos abiertos a cualquier contribución.