COBOL Foro

COBOL Foro (https://www.cobolforo.es/index.php)
-   Object-Pascal (https://www.cobolforo.es/forumdisplay.php?f=42)
-   -   [Noticia] Lazarus - el hermano OpenSource de Delphi (https://www.cobolforo.es/showthread.php?t=533)

Kuk 15 de diciembre de 2016 14:57

Lazarus - el hermano OpenSource de Delphi
 
1 Archivos Adjunto(s)
Amigos, os presento un IDE bastante potente que es gratuito y OpenSource: Lazarus Homepage

Es como el Delphi, utiliza el Object Pascal, pero además de ser gratuito crea aplicaciones con GUI bajo Windows y Linux, y el IDE también existe para ambos OS. Lo he probado en Linux Ubuntu, funciona a la perfección.

El Pascal es bastante agradable, se parece en algo al VB. Me parece una opción más que decente, siendo cross-platform y encima OpenSource.

Por cierto, muy rico en Controles (fijados en las pestañas del Tab de controles), casi igual que el Delphi. Y por lo visto se pueden añadir controles de terceros.

Kuk 21 de diciembre de 2016 14:23

Amigos, hay una Wiki en español bastante potente: Main Page/es - Free Pascal wiki

Por cierto, Lazarus también existe y crea aplicaciones para MAC. Además, no tiene dependencias a paquetes/componentes de terceros (salvo básicos de GUI en Linux, como GTK o QT).

¿Alguien lo ha probado?

Nitzer 21 de diciembre de 2016 14:29

Hola Kuk, yo lo "ojeé" hace tiempo.
Pero si os soy sincero, no me quito el cobol de la mente de ninguna de las maneras jajajajja.

Para mi lo mejor, la combinación de Ficheros indexados y bases de datos, da un juego infinito.

Dasije 22 de diciembre de 2016 14:50

Hola buenas.

He estado ojeando un poco la herramienta, me recuerda mucho a Delphi en sus primeras versiones, Pascal no es un lenguaje que haya prestado mucha atención en aprenderlo, pero si otros como C++ y Visual-Basic.

Se basa mucho en el principio de los compiladores de primera generación, para poder usar base de datos hay que incluir los objetos de conexiones y para depurar primero debe compilar el ejecutable (lo hace como archivo temporal), y esto ya me recuerda a PowerCOBOL.

Saludos.

Kuk 22 de diciembre de 2016 15:12

Nitzer, no es por presentar una alternativa e incitar a la gente a pasarse a él. Simplemente, me parece un IDE muy potente, y siendo OpenSource y Cross-Pltaform, lo hace más que interesante, en mi opinión. ;)

Dasije, el Delphi siempre ha estado igual (o casi igual) de potente que el Borland C++. Llega a niveles casi tan bajos como C++. El Lazarus viene a ser prácticamente una réplica del Delphi, así que hereda la misma potencia.

Cita:

Cita del post de Dasije (Mensaje 2577)
me recuerda mucho a Delphi en sus primeras versiones

En los últimos años, he sondeado diferentes versiones de Delphi, desde el arcaico 7 y hasta el XE8. Sigue siendo, en su mayoría, lo mismo y se basa en los mismos conceptos generales. Con lo cual, de primeras versiones nada. Además, lo de crear un fichero (incrustado en el ejecutable o separado) para hacer el Debug, lo hacen los Delphi los más nuevos también (y el C++ también). ¿Qué tienes en contra de ello? ;)

Cita:

Cita del post de Dasije (Mensaje 2577)
para poder usar base de datos hay que incluir los objetos de conexiones

Y esto viene a ser el modus operandi de toda la vida de programación con Frameworks o bibliotecas. :confused:

Cita:

Cita del post de Dasije (Mensaje 2577)
para depurar primero debe compilar el ejecutable

¿A qué te refieres con esto?

Total, según entiendo, parece que consideras el producto bastante anticuado. Si es así, me gustaría que contases un poco más acerca de las razones que te hacen pensarlo ;)

Nitzer 22 de diciembre de 2016 21:33

Por supuesto kuk :), si el problema es mio que soy ya incapaz de cambiar, demasiado tiempo en el mismo ambiente :(

Dasije 22 de diciembre de 2016 22:18

Nitzer, Por eso me tuve que pasar al lado oscuro :sis:

Kuk, Cuando descubres una herramienta que supera a las demás, te das cuenta de lo anticuado que se quedan algunas.

Ver vídeo

Kuk 22 de diciembre de 2016 22:55

Nitzer, mientras que no haya obligación realmente, que en mi opinión no la hay hoy en día, ni falta que hace plantearselo ;) Y si un día armamos un IDE Cobol decente ya ni te cuento.

---------- Post añadido : 23:55 ---------- Post anterior : 23:20 ----------

Dasije, gracias por el vídeo. Tiene buena pinta el asunto, además sé que eres bastante fan del WinDev :) Pero, por lo pronto, no hay que olvidar lo que has pagado por él :losiento: Y aquí se habla de algo que es gratis. Además, estamos hablando de cosas un poco diferentes, más que nada en estrategia.

El Lazarus sigue la estrategia más usada actualmente en todos (o casi todos) los IDE-s basados en la programación orientada a eventos y creación de aplicaciones con GUI. Visual Studio, los IDE-s de Embarcadero, el mismo PowerCOBOL... se basan en ella, que es un panel con componentes/controles configurables. Con lo cual, no estoy de acuerdo en que hoy en día eso sea anticuado.

A parte de ello, lo de tratar una BBDD como un fichero, sin importar el motor que esté detrás, a mi modo de ver, tiene una gran desventaja que es no aprovechar de la flexibilidad y comodidad de SQL. El hecho de que no tengas la obligación de configurar la conexión a un motor de BBDD específico manualmente, no quiere decir que no haya una configuración automática por detrás, lo cual también puede suponer una configuración no optima. Pero vamos, al fin y al cabo estamos hablando de detección de tipo de motor y configuración con valores por defecto o elegidos en base a algunos parámetros de manera automática.

Todo esto es como la caja de cambios del coche, automática y manual. Si quieres conducir cómodo sin mucha participación, la automática es la más preferida por la gente. Pero no te permite hacer lo que puedes hacer con la manual.

Así que, lo que tu describes es sólo una opción, pero de ningún modo deja los IDE-s "tradicionales", por así decirlo, en anticuados.

Por cierto, no me ha quedado claro lo de "no tener que compilar para depurar". Yo lo que he visto en el vídeo es que puedes lanzar un Form hijo directamente, sin haber lanzado el padre. Pero ese Form hijo es compilado igual antes de lanzarlo. ;)

Dasije 23 de diciembre de 2016 20:28

3 Archivos Adjunto(s)
Yo lo llamaba anticuado a la forma de trabajar, ya está muy visto, en tu caso lo llamas estrategía.

Sí que puede trabajar con querys con sentencias SQL, tanto enlazado a un objeto como un combox, una tabla, etc tanto como si fuera un fichero, así que tiene la dos formas de trabajar, como tu lo has llamado, automático o manual, tanto a nivel de fichero como la query (ver capturas adjuntas).

Lo de compilar sin depurar, me refería, antes de ejecutar la depuración (seguimiento de código) no hace falta generar el exe o los archivos intermedios, simplemente ejecuta el código grabado en el proyecto sin esperar a obtener el archivo compilado, cuando el proyecto este bien depurado se genera el exe, por lo tanto no es obligatorio generarlo antes para depurar.

Kuk 23 de diciembre de 2016 22:14

Cita:

Cita del post de Dasije (Mensaje 2583)
Yo lo llamaba anticuado a la forma de trabajar, ya está muy visto, en tu caso lo llamas estrategía.
Sí que puede trabajar con querys con sentencias SQL, tanto enlazado a un objeto como un combox, una tabla, etc tanto como si fuera un fichero, así que tiene la dos formas de trabajar, como tu lo has llamado, automático o manual, tanto a nivel de fichero como la query (ver capturas adjuntas).

Julio, ¿cual es el problema para ti exactamente, que para acceder a una BBDD tengas que poner un control demás (aparte de botones, combos etc.) y tener que configurarlo? Si es sólo por eso que lo llamas anticuado, me repito, estás llamando anticuados a todos los IDE-s los más extendidos del hoy en día. Además, a mi personalmente no me supone ningún problema esta acción adicional, y no por ello podemos denominar un IDE anticuado, ese es el comportamiento habitual actualmente.

Si lo consideras anticuado porque no incorpora un visor de BBDD (cosa a confirmar porque puede que lo lleve), yo tampoco veo ningún problema, porque hay herramientas gratuitas muy potentes como DBeaver que lo hacen. Que en el WinDev viene todo junto, pues muy bien, pero eso no significa que WinDev sea un estándar, porque no lo es. No todos los IDE-s actuales llevan un visor de BBDD integrado ni mucho menos.

Cita:

Cita del post de Dasije (Mensaje 2583)
antes de ejecutar la depuración (seguimiento de código) no hace falta generar el exe o los archivos intermedios, simplemente ejecuta el código grabado en el proyecto sin esperar a obtener el archivo compilado

Esto lo que dices es algo que es imposible. Existen analizadores sintácticos en modo diseño. Por ejemplo el Visual Cobol en Eclipse de MicroFocus te saca errores y warnings directamente en el editor antes de compilar. Pero es imposible depurar un aplicación que se está ejecutando sin haberla compilado (aunque sea en algo ejecutable). Que vale que no sea un EXE, a lo mejor ejecutas un objeto intermedio. Salvo una excepción: que WinDev también tenga un interpretador de script (y no sólo compilador). Y si es el caso, tampoco me parece nada extraordinario. ¿Cual es el problema de compilar y depurar después? No cuesta dinero como antes en las máquinas de IBM. No se tarda mucho tampoco, o sea que no perdemos tiempo tampoco... Qué ventajas tan absolutas trae WinDev frente a Visual Studio, IDE-s Embarcadero y el citado Lazarus... A mi no me ha quedado muy claro, con todos mis respetos hacía el WinDev, que me parece, insisto, un entorno interesante. Pero tampoco lo veo "el Mesias" de la programación, sinceramente.

Y vuelvo a decir que tanto WinDev, como Visual Studio, como Embarcadero, son entornos de pago y que valen mucho dinero.

Dasije 28 de diciembre de 2016 00:28

3 Archivos Adjunto(s)
Sí tengo que leer 10 tablas, tengo que poner 10 objetos ADO, y después ir agregando parámetros de conexión a cada uno, se me hace pesado el trabajo, ya que SQL no siempre soluciona todos los problemas de agrupaciones de información en las consultas.

He tenido que retroceder en el tiempo para responderte mejor a mis afirmaciones:

Cuando trabajaba con RMCOBOL el concepto de compilar para mí era la de generar el fichero objeto que después se ejecutaba desde un ejecutable runtime que los interpretaba.

También en Microsoft COBOL, ensamblador, y etc, también tenían sus compiladores que creaban archivos objetos para después ser enlazados para crear un ejecutable, se podía adjuntar varios archivos objetos por cada "módulo" dentro del ejecutable, en algunos incluso existían una utilidad "Make" que hacía los dos procesos juntos.

Ahora bien, aquí viene nuestra cuestiones de compilar o no para depurar, ambos tenemos razón, como ya sabemos los editores, no solo son para escribir código, sino también ejerce las funciones de comprobación y compilación del proyecto abierto, antes los ordenadores tenían mucha limitación en capacidad de disco duro y memoria ram, hablamos de la época de los 80 y principio de los 90, entonces cada fabricante tomaba su iniciativa de como funcionar su IDE que le acompañan con la suite de desarrollo.

La mayoría optaron la compilación y enlazado del ejecutable, para hacer un seguimiento del código fuente sobre el editor, así omitían de usar la limitada memoria, y se centraba sobre el disco al ejecutar el ejecutable, y cuando encontraba un error marcarlo en el editor en el momento que se pare la ejecución del proyecto.

Sí, hubo algunos fabricantes que compilaba y ejecutaba el proyecto sobre la memoria ram, sin crear antes el ejecutable, una vez que estuviera bien el código, entonces ejecutabas la compilación y el enlazado del ejecutable, esta es la forma de trabajar de Windev, también lo usa Visual-Basic, por eso sea la razón de su amplio uso aparte de su facilidad.

Es más rápido compilar sobre la memoria ram que sobre el disco duro, sobre todo los proyectos grandes, que solo va interpretando el código escrito y va ejecutando lo que vaya leyendo la compilación, y no tiene que realizar una compilación completa del proyecto.
Debí de llamarlo, compilación en memoria, por eso no comprendías lo que yo me refería, y sobre llamarlo "anticuado", me refería a lo que estoy acostumbrado a ver en casi todos los compiladores, tener estas opciones de compilaciones es sinónimo de modernidad al ser diferente.

Ahora, vuelvo con Lazarus, para ejecutar la aplicación debe ser compilado en el ejecutable y desde ahí depurar (ver captura de pantalla), y me parece un retroceso no poder compilar en memoria, aunque entiendo que es un producto opensource, por lo tanto implica que no hay obligaciones ni deberes de mejorar la herramienta de desarrollo, se usa tal cual vayan mejorando.

PD : Te adjunto una captura de pantalla de Turbo Basic y Turbo Pascal (Borland) donde se podía elegir el modo de compilación.

Kuk 28 de diciembre de 2016 08:28

Dasije, me gusta la discusión que estamos teniendo, la veo argumentada y sobre todo productiva.

Estoy a la vez de acuerdo y no contigo en ciertos aspectos. Claramente, llevas razón que la compilación en RAM es más rápida. Lo que pasa es que, justamente basándome en lo que tú también has dicho, referente a las posibilidades de las máquinas, este punto podemos decir que hoy en día ha perdido su importancia. Porque la RAM hoy no es un problema, ya no hablo de HDD-s, las CPU-s son mega rápidas, y por lo tanto en realidad nosotros casi ni vemos la diferencia entre una compilación a HDD y RAM. Y si tenemos un SSD ya ni te cuento.

En cuanto a los interpretadores, en realidad no compilan nada, sino que interpretan el fuente sentencia por sentencia, y llaman las funciones correspondientes (es el modus operandi de las líneas de comandos en SO). Llegando a una sentencia con error sintáctico, se para la ejecución. El VB en realidad es casi sinónimo del VBS el cual es interpretado. El Run-Time del VB contiene un interpretados de script. Los módulos "compilados" en VB (y lo pongo entre comillas aposta), no son nativos, sino una especie de código binario de formato propio (similar a Java) y es la máquina virtual/run-time del VB la que interpreta dicho binario. La ventaja de este tipo de compilación, como sabemos, es la portabilidad entre plataformas, y la garantía de que la sintaxis es buena.

En cuanto a controles ADO, yo suelo usar código embebido. Me he acostumbrado a ello en el trabajo. Con lo cual, usando esta técnica, sólo 1 control de conexión es requerido. No sé, a mi me parece la mejor opción.

Volviendo al Lazarus, los 2 puntos que comentas y que vienen digamos modernizados/mejorados/ampliados en WinDev, desde mi punto de vista no son realmente tan importantes ni suficientes como para considerar que el WinDev deja tan atrás los demás IDE-s que no lo hacen. Puede que traiga otras cosas que en tal caso sí que dejaría ben atrás muchos IDE-s, pero yo como no lo conozco... Claramente, el hecho de tener centralizado todo en el mismo IDE, como el visor de BBDD, que sea Cross-Platform, hacen que WinDev sea potente. Pero, el Lazarus a mi me ha atraído porque es un IDE con muchísimos controles (visuales y no), es Cross-Platform y además Open Source, conteniendo los estándares y estrategias de desarrollo de software más comunes del momento. Que a lo mejor no es el mejor, ni el más moderno, estoy de acuerdo, pero que quede fuera de la actualidad (que justamente querría decir que queda anticuado), es en esto en lo que no lo estoy. ;) Hay una comunidad que lo mantiene y creo que con el tiempo se irá adaptando y mejorando los aspectos necesarios. Hay ya por lo visto bastante gente que se ha pasado o quiere pasar del Delphi al Lazarus porque los precios del Delphi, parece ser que han ido creciendo como las setas después de una buena lluvia. :D

Dasije 29 de diciembre de 2016 19:12

Visual-Basic y VBS, son dos versiones diferentes, comparten sentencias y principios, pero no tienen todo el potencial de uno al otro, el primero obviamente es más potente en posibilidades, el segundo es para hacer pequeños "batch" de procesos.

En Windev, se puede escribir código WLenguage dentro de un textbox y desde un botón con sentencias de ejecutar código fuente se puede ejecutar el código escrito que se encuentra dentro del textbox, e incluso calcular expresiones que provenga de variables definidas dentro del proyecto para realizar calculos, por ejemplo, calcular el margen de precios de ventas de manera configurable por el usuario, esto último recuerdo que se podía hacer también en Pascal.

El otro día probé de importar un proyecto que tenía guardado en Delphi desde Lazarus, y parece que no se entienden bien por tener diferentes controles, hay cosas que aún deben depurar, aún así no se importó el formulario del proyecto, solo código.

Kuk 30 de diciembre de 2016 08:13

Dasije, efectivamente, tanto Delphi como Lazarus son IDE-s con compiladores Object-Pascal, pero las bibliotecas no son las mismas (VCL para Delphi, y LCL para Lazarus), con lo cual es normal: Lazarus For Delphi Users - Lazarus wiki

Cita:

Lazarus is a Rapid Application Development (RAD) tool like Delphi. That means it comes with a visual component library and an Integrated Development Environment (IDE). The Lazarus component library (LCL) is very similar to Delphi's Visual Component Library (VCL). Most Lazarus units, classes and properties have the same name and functionality as their equivalents in Delphi. This makes porting Delphi applications to Lazarus relatively easy. Even though Lazarus is in many respects an open source Delphi clone, the compatibility is not 100%.

Dasije 30 de diciembre de 2016 20:04

Es un poco jodido tener que reprogramar las pantallas siendo el mismo lengauje, es como pasar de un fabricante a otro, un ejemplo de RMCOBOL a PowerCOBOL, se puede aprovechar las rutinas pero no las pantallas.


La franja horaria es GMT +1. Ahora son las 17:27.

Powered by: vBulletin, Versión 3.8.7
Derechos de Autor ©2000 - 2020, Jelsoft Enterprises Ltd.