FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
|||
|
|||
Cita:
Cita:
|
#22
|
||||
|
||||
Cita:
.NET Core no pinta nada aqui, entre otras cosas porque asume un GC. Ademas ya estan usando LLVM, que es una mejor opcion para el tipo de lenguaje que es Delphi
__________________
El malabarista. |
#23
|
|||
|
|||
Cita:
|
#24
|
|||
|
|||
LLVM tiene sus ventajas, pero podrá ser sostenible con los tantos cambios que van surgiendo en este sector?.
|
#25
|
||||
|
||||
¡Ojalá! Porque Embarcadero le está apostando mucho a esa cosa.
|
#26
|
||||
|
||||
Cita:
LLVM es prácticamente un estándar de la industria (junto a GCC). Lo dificil es para cualquier otro alcanzarlo! De hecho, es seguro que es un compilador mas eficiente, capaz y potente que el de delphi. Es inevitable que lo sea: Todo el mundo le mete la mano para lograrlo. Quizas solo GCC le da batalla. De todas maneras hay que entender que uno de los atractivos de Delphi/Pascal es su velocidad de compilacion, y usar cualquier otro backend tiene implicaciones no solo en esto sino en la semantica del codigo. Hacer estos cambios son muy problemáticos, porque la mayoria esperaria que se conserve toda la semantica del código legado, lo que surge entonces: Para que hacer nuevo algo, para que tenga que emular lo viejo que ya esta resuelto con lo viejo? Si se meten en un proyecto asi, es para hacer algo radical. Sino, no tiene sentido.
__________________
El malabarista. |
#27
|
|||
|
|||
Cita:
Mi opinión es que con un framework ligero bien pensado cualquier cambio que surja no afectaría tanto el esquema del lenguaje mas bien el framework, claro los programadores de aplicaciones tendrían una curva de aprendizaje inicial, pero con Firemonkey he visto muchas cosas nuevas y de hecho muchas cosas que parecen similares a vcl y funcionan distinto, dejando fuera lo que tiene que ver con dispositivos móviles. |
#28
|
|||
|
|||
Cita:
|
#29
|
||||
|
||||
Cita:
Cita:
|
#30
|
|||
|
|||
Gracias por la corrección Al González
|
#31
|
||||
|
||||
De nada. Todo sea para que estos foros no se degraden como sucedió con Facebook.
|
#32
|
||||
|
||||
Cita:
El "back-end", como LLVM o un bytecode de .NET/Java/etc no necesariamente están amarrados al "front-end" de un lenguaje. Son una especificación de bajo nivel. El caso de LLVM esta diseñado para ser el back-end de cualquier tipo de lenguaje, aunque tiene bias para los que son tipo C/C++/Pascal. En el caso de los bytecodes que corren en .NET/Java estos tienen un bias muy alto hacia lenguajes con GC y mas costo al interfazar con codigo nativo, asi que son menos optimos para algo como Delphi (osea, es *posible* pero no *practico*). Delphi no debe tener nada de problema, excepto el que deban hacer la implementacion de esta hacia LLVM. Si estudias como implementar un lenguaje, veras que lo mas pesado esta en el back-end. Y LLVM es muy bueno. No hay nada de donde se pueda suponer que LLVM es un problema, e incorporarlo es menos dificil que tener que replicar lo que hace. O podrias aclarar que es lo que propones?
__________________
El malabarista. |
#33
|
|||
|
|||
Cita:
OK creo que me confundí un poco con LLVM, pero a lo que me refiero es si embarcadero podría de forma más rápida ir reduciendo la cantidad de bugs que pueden surgir atendiendo a muchas plataformas a la vez, sin dividir el código que esta detrás en más capas de responsabilidades que creo es lo que hace el framework, por favor me corriges si estoy confundido para así ir dejando el código más limpio en el tiempo, si luego aparecen mil tipos de dispositivos con otras plataformas más con la estructura que ellos han realizado podrán anticiparse mas a posibles bugs? |
#34
|
||||
|
||||
Primero, no es tanto el # de dispositivos sino sus arquitecturas.
No hay nada en el horizonte cercano que sea más allá de ARM, Intel/AMD y soporte a GPUS (Cuda, Vulcan) que no esta ahora presente. Incluso en embeidos prácticamente ARM es la plataforma dominante a futuro, y lo que sea con rasperry & similares pues no es el mercado de Delphi. Hay algunas cosas que podrian surgir, como los NVMe y otras cosas un poco esotericas, pero igual no es el mercado de Delphi e igualmente LLVM se porta a esas cosas si hay interes real. Lo que realmente es un problema no es tanto los procesadores y sus arquitecturas, sino el adaptarse a los OS y en especial a los toolkits graficos. Eso es un problema que las maquinas virtuales NO RESUELVEN, y es engorroso sea como sea. COn todo si Delphi ya esta en iOS/Android no hay otro toolkit que se vislumbre en el futuro que valga la pena. --- El problema de fondo aquí es más de enfoque de Embarcadero en calidad vs. nuevas características que en si el compilador. Aun si fuera mas abierto (open source) igual al ser un nicho no tendría el caudal de apoyo necesario, a menos que otro participante (como por ejemplo MS) le diera por meterle mano. Y sin embargo, no veo que se puede hacer con el problema de la multiplataforma. Es que la parte no-visual es "trivial" en comparación con el acceso a la GUI/Apis nativas, y no se me ocurre que exista una forma eficaz de resolver el tema aparte de "sudor, lagrimas & mucho esfuerzo". --- En resumen: Delphi ya esta a medio paso usando LLVM. Mejor back-end para *Delphi* es improbable que exista. El hacer una capa que simplifique portar es "trivial" si ignoramos la parte visual, el acceso a APIs nativas y el entramaje de apis de terceros de esas plataformas y solo estamos hablando del lenguaje como si. Pero NO HAY solucion para mas alla de la compatibilidad basica de los lenguajes.
__________________
El malabarista. |
#35
|
|||
|
|||
Cita:
Cita:
|
#36
|
||||
|
||||
¿Nadie ha nombrado GTK+?
|
#37
|
||||
|
||||
Ahora mismo consultando qué es eso. Lo he visto escrito varias veces, pero con el nombrecito que tiene me había dado algo de pereza investigar.
|
#38
|
|||
|
|||
Cita:
https://www.systeminside.net/por-que...fa-escritorio/ Observando esa libreria GTK+ es una muy buena iniciativa pero en este mundo donde hay tantos intereses es difícil hacer un mundo mejor. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
UNIGUI--Excelente Alternativa aplicaciones WEB | ASAPLTDA | Delphi para la web | 31 | 19-05-2023 04:45:02 |
Excelente frontend para MySQL | AzidRain | MySQL | 1 | 18-04-2010 19:28:25 |
Excelente manual de c/c++ para los que se inician | chico_bds | C++ Builder | 0 | 02-04-2007 01:40:39 |
Excelente noticia para los borrachines en sus salidas nocturnas | Zeta | La Taberna | 1 | 23-11-2006 05:58:31 |
Aplicaciones para Linux con Delphi | fidel | Linux | 9 | 05-05-2005 00:04:59 |
|