Aplicaciones delphi para Linux, excelente

[jlrbotella]

Gracias por la aclaración. Creí que cuando se instalaba el Rad Studio Server, instalaba el Interbase. Después ya podías conectarte con cualquier motor para implementar los servicios.

[Neftali [Germán.Estévez]]

Empezado por jlrbotella

Gracias por la aclaración. Creí que cuando se instalaba el Rad Studio Server, instalaba el Interbase. Después ya podías conectarte con cualquier motor para implementar los servicios.

Realmente no se si con la instalación lo instala o no. En todo caso la utilización es opcional.
El igual que cuando instalas Delphi o Builder, que durante la instalación te pregunta si quieres instalarlo o no, pero la decisión de instalarlo/utilizarlo es tuya.

[[AgustinOrtu]]

Lo "unico" que no tiene Delphi para Linux es un Framework para crear GUI (ie Vcl o FMX). NADA te impide llamar a las APIs de linux para lograrlo. Obviamente que es muchisimo mas comodo desarrollar usando un Framework y no directamente con la API. Por ej. se puede evitar completamente la Vcl y crear una aplicacion windows programando a pelo con la API, que no es ni mas ni menos que el trabajo que hace la Vcl internamente

A eso me referia con que el soporte es para "todo", lo que le falta es un Framework para generar interfaz grafica. Pero todo lo que sea codigo RTL + DataSnap es portable directamente. Lo unico que no anunciaron (o yo no me entere) es si el compilador es ARC o no. Si es ARC quiza se deba tener en cuenta algunos puntos a la hora de migrar

[[Al González]]

Que yo sepa ARC —Automatic Reference Counting— es y seguirá siendo sólo para dispositivos móviles. Aunque resulta tentador que lo fuera ya para todas las plataformas.

Casimiro: ¿Cómo es Lazarus en ese aspecto? ¿Los objetos usan contadores de referencias automáticos como lo hacen los valores String? ¿En qué plataformas? ¿Sólo en dispositivos móviles, igual que Delphi? Creo que sería interesante conocerlo.

Saludos.

[[AgustinOrtu]]

Empezado por Al González

Que yo sepa ARC —Automatic Reference Counting— es y seguirá siendo sólo para dispositivos móviles. Aunque resulta tentador que lo fuera ya para todas las plataformas

Embarcadero tiene dos problemas que impiden convertir los compiladores para Win32 y Win64 en compiladores ARC: el codigo existente que puede perder compatibilidad hacia atras; y problemas de performance. Performance sobre todo para servidores, en donde desde luego un manejo de la memoria "personalizado" seguro que es superior a uno "automatico"; sobre todo si eso implica usar operaciones thread-safe para ir incrementando y decrementando referencias, todo eso envuelto en un try-finally (lo cual genera mas y mas codigo maquina)

La unica razon por la cual el resto de los compiladores son ARC es porque los compraron asi

Yo tambien creo que lo mejor es que todos sigan el mismo esquema de memoria. Para el programador casual es inadvertido. Pero para los bibliotecarios es un problema. Basta con hurgar un poco en el propio codigo de la RTL, se ven bastantes condicionales {$IFDEF} ARC.

Y es que si bien es bastante transparente, a veces el modelo de memoria subyacente puede condicionar el codigo

[mamcx]

Empezado por AgustinOrtu

Embarcadero tiene dos problemas que impiden convertir los compiladores para Win32 y Win64 en compiladores ARC: el codigo existente que puede perder compatibilidad hacia atras; y problemas de performance. Performance sobre todo para servidores, en donde desde luego un manejo de la memoria "personalizado" seguro que es superior a uno "automático";

Lo del performance es falso. Es todo al revez.

Un recolector de basura es más eficiente para servidores que el reference counting o el manejo manual.

El problema de los GC es que (tal vez, depende del tipo que se use) introducen pausas y que consumen más memoria. Por eso, el modelo de ARC es ideal para móviles: No introduce pausas (que sería más notable en un equipo que casi en su totalidad funciona como interface de usuario) y consume menos memoria (que se traduce en mayor longevidad en la batería y economía de recursos).

Pero los GC son más eficientes en un entorno de servidor porque pueden operar en "batch" sobre un mayor rango de memoria (por ejemplo, sobre .NET), e incluso puede delegarse a un hilo aparte.

Esto conduce a la idea contra-intuitiva que Java arrasa en desempeño a otros entornos (osea, en workloads de servidor), porque tiene uno de los VM/GC mejor tuneados de la industria.

Esto es GC 101:
http://www.iecc.com/gclist/GC-faq.ht...on%20questions

http://www.memorymanagement.org/

----

Tengan en cuenta que un VM/GC vs manual es similar a un lenguaje alto nivel vs. assembler:

Asi como es posible que un humano escriba el mejor assembler posible, pero esto seria un humano MUY ESCASO y que en la realidad la *mayoria* seran derrotados por el assembler de un compilador decente <- porque este compilador decente a sido escrito por *ese tipo de humanos escasos*.

Entonces, un GC/VM derrota al promedio de los humanos a la hora de manejar la memoria. Mientras es posible escribir un código superior, hacerlo todo el tiempo correctamente es MUY dificil y escaso.

Ademas, aunque Delphi es mas de alto nivel que C/C++ sin perder su capacidad de ser eficiente tiene el problema de que carece de un protocolo/idioma universal como el RIIA, dejando en manos del programador promedio todo el proceso.

[juniorSoft]

Lo "unico" que no tiene Delphi para Linux es un Framework para crear GUI (ie Vcl o FMX). NADA te impide llamar a las APIs de linux para lograrlo. Obviamente que es muchisimo mas comodo desarrollar usando un Framework y no directamente con la API. Por ej. se puede evitar completamente la Vcl y crear una aplicacion windows programando a pelo con la API, que no es ni mas ni menos que el trabajo que hace la Vcl internamente

Exacto, se puede desarrollar utilizando las APIs de Linux pero de lo que se trata es del desarrollo RAD y que abarque la mayor cantidad de plataformas y dispositivos por lo que un Framework para abstraer las plataformas sin tantas directivas de compilación (De eso debería encargarse el framework) es lo ideal. Mi opinion es que Firemonkey y delphi tienen futuro a largo plazo solo si los dueños se concentran y enfocan los recursos en diseñarlo como si fuera un gran edificio aunque solo se puedan construir dos o tres plantas inicialmente como hizo Microsoft en su tiempo con .net Framework. con la ventaja de que Firemonkey ya contiene una buena cantidad de código que puede utilizarse para dicho Framework y separar la interfaz visual para que invoque las funciones de dicho framework ademas de matar dos pájaros de un mismo tiro con los servidores. Quizás eso suene costoso y es a lo que le temen.

Considero que Delphi, debería tomarse más en serio la plataforma de .Net Core de Microsoft que es Open Source, así como corregir los bugs y mejorar la VCL, e intentar migrar el FireMonkey para que funcione con .Net Core.

Es cierto que Idera puede utilizar el framework de Microsoft pero esto se trata de negocios y confiar mucho en la competencia no conviene tanto. ademas de lo ligero que puede ser dicho framework ya que solo tendría lo necesario, .net Core es mucho mas ligero que su antecesor pero siempre hay algo que se puede mejorar. La funcionalidad y rapidez siempre son bienvenidas y desde mi punto de vista es un camino viable.

[[Al González]]

Empezado por mamcx

[...] porque este compilador decente a sido escrito por *ese tipo de humanos escasos*.

Empezado por juniorSoft

Delphi siempre a tenido la aceptación por ser un lenguaje [...] C# a tenido éxito por ser un lenguaje [...]

Hablando de lenguajes, ha, del verbo haber (hacer clic en el botón Conjugar).