Lazarus - el hermano OpenSource de Delphi

[Dasije]

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]

@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.

[Dasije]

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]

@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

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]

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.