Discussion :

[matthius]

Il est possible de créer des exécutables JAVA avec LAZARUS. Si vous utilisez LAZARUS vous pouvez faire du JAVA et créer des exécutables standards. Cela permet de rester compatible avec la plate-forme ANDROID utilisant JAVA.

Indéniablement le réseau LAZARUS manque encore de librairies concurrentes. Cependant, il existe toutes sortes de Composants Libres ou Open Source sur LAZARUS et DELPHI.

LAZARUS ce sont les atouts de JAVA, sans des contraintes de JAVA. LAZARUS optimise la création d'exécutables multi-plates-formes. Mis à part la taille de l'exécutable, nécessaire à la cross-compilation, votre logiciel sera optimisé pour les plates-formes allégées, grâce aux exécutables en code machine, aux Composants et à l'optimisation.

LAZARUS crée des interfaces propres à chaque environnement, ou, comme JAVA, une interface propre à l'outil avec FPGUI. LAZARUS a besoin de votre participation pour cette interface.

On peut se passer de JVM sous LAZARUS, ce moteur traduisant les exécutables JAVA en interfaces compréhensibles par l'utilisateur. Votre exécutable LAZARUS peut donc donc être plus rapide qu'un logiciel JAVA sous une JVM.

Un serveur de pages HTML peut fonctionner avec seulement 128 Mo de mémoire et un processeur à faible consommation. La puissance processeur nécessaire aux serveurs est donc due à la compilation du code sur le serveur. Il est donc absurde d'utiliser PYTHON ou JAVA sur un serveur.

Vous pouvez cependant créer des exécutables JAVA avec LAZARUS, qui seront exécutés dans la JVM. À ce propos la libraire ZEN GL permet de créer des applications graphiques à la fois pour ANDROID, iOS, LINUX, WIN-CE.

Votre exécutable LAZARUS est aussi suffisamment complet pour être indépendant de librairies. La plupart des librairies utilisées par LAZARUS ne sont pas nécessaires à votre exécutable. Votre exécutable devient rapide et autonome. Les Sources s'adaptent facilement. Votre logiciel se maintient aisément.

Vous ne connaissez peut-être pas les BEANS sous JAVA. La partie Composant des BEANS JAVA ne permet pas de gagner autant de temps que les Composants RAD. On appelle cela la LCL sur LAZARUS, pour Librairie de Composants LAZARUS. Dans LAZARUS, même les Composants non visuels sont dans cette librairie.

JAVA nécessite la réinvention d'un nouvel EDI afin de gagner du temps. Il faut à chaque fois changer d'EDI, les plus récents devant se réinventer pour gagner du temps. LAZARUS est déjà optimisé pour gagner du temps. Si on crée un deuxième EDI, on améliore LAZARUS pour arriver à ses fins.

L'inspecteur d'Objets permet de mettre en place rapidement tout Composant. Vous gagnez un temps précieux à créer des Composants, en Développement Rapide d'Applications, contrairement à JAVA. Des paquets de Composants peuvent être éludés, allégeant l'exécutable, ce que ne peut pas faire JAVA.

Dans LAZARUS ou DELPHI tout Composant est facilement remplaçable par un autre. Il suffit pour cela de changer le type du Composant dans le fichier PASCAL et dans la Source du formulaire. On peut ensuite créer un programme pour migrer.

La programmation par Objets permet de créer des interfaces proches de l'humain. Elle est au sein de JAVA et de LAZARUS. Contrairement à JAVA, LAZARUS permet d'utiliser une programmation proche de l'humain et une programmation proche de l'ordinateur, la programmation Procédurale. En effet une programmation proche de l'humain ralentit votre exécutable.

Je recherche toujours en JAVA la possibilité de facilement connaître le périmètre de mes Composants. En effet UML définit les Composants afin de permettre de gagner du temps. JAVA permet difficilement de définir des Composants réutilisables facilement.

[Laurent 1973]

Java est un langage semi-interprété (comme le .NET/mono) utilisant une virtual-machine (la JVM).
Un même binaire java peux être utilisé tel que sur un autre OS.
Avec les possibilités des serveurs d'applications, il est possible de réaliser en Java, des applications M2M ou web puissantes et complexes.

(Free) Pascal est un langage compilé, produisant du code natif (comme le C++).
Pour l'utiliser sur des OS différents, il est nécessaire de faire de la cross-compilation et de diffusé alors des binaires différents.
Avec l'intégration de bibliothèques graphiques puissantes, il facile de réaliser des interfaces "lourdes" bien optimisées quelque soit l'OS cible.

Pour ces deux environnements, des IDEs modernes et performants existent (Lazarus et Eclipse/NetBeans).

Les besoins et les contraintes de ces 2 environnements ne sont pas les mêmes.
Je ne comprend pas bien cet article qui veux comparer 2 environnements si différents.

[matthius]

La réponse est que LAZARUS permet de créer du byte-code JAVA.

Pour la partie serveur, les défenseurs de JAVA et PYTHON n'arrivent pas à me répondre pour la nécessité d'avoir des serveurs puissants afin de compiler (à la place de terminer, labsus) du code semi-compilé ou interprété.

Pourquoi faire des jeux en JAVA alors qu'il existe Zen GL ?
http://zengl.org

[Laurent 1973]

Oui, faire du byte-code Java en Pascal, ça peux en effet avoir certain intérêt.
Je comprend mieux l'idée de l'article alors.

Zen Gl a l'aire intéressant.
A essayer en effet.

De là a ce que le Pascal redevienne à la mode, il y a encore un pas.

Mais je connais bien ce langage alors si le "marché" des développeurs Pascal reviens, je suis pour

[nnovic]

C'est de la pub pour lazarus ou quoi ?
(pardon, je voulais dire "LAZARUS")

[matthius]

J'ai écrit un livre sur LAZARUS.
Seulement c'est DELPHI qui fait de la pub.
Je défend LAZARUS, le projet qui a sauvé DELPHI et qui peut de nouveau surpasser DELPHI avec LINUX.

[DonQuiche]

Java est un langage semi-interprété (comme le .NET/mono)

Dotnet n'a jamais été interprété. La compilation JIT n'est pas de l'interprété et c'est bien un code natif qui s'exécute en fin de compte. Quant à la "VM" (terme qui n'est pas utilisé sous dotnet), une fois le code compilé il n'en reste que le poids habituel d'une bibliothèque faisant l'interface avec les API natives, ainsi que le poids du ramasse-miettes (dont très peu de personnes se plaindront).

Mis à part la taille de l'exécutable, nécessaire à la cross-compilation, votre logiciel sera optimisé pour les plates-formes allégées, grâce aux exécutables en code machine, aux Composants et à l'optimisation.

De tels compilateurs (dits ahead-of-time, AOT) existent en Java. Les binaires produits sont très compacts grâce à l'élagage (code pruning) et ne demandent aucune dépendance.

Votre exécutable LAZARUS peut donc donc être plus rapide qu'un logiciel JAVA sous une JVM.

Affirmation gratuite qui est loin d'être si simple si l'on compare avec un bon compilateur AOT.

D'abord le pascal moderne met en œuvre un comptage de références (ARC), qui est un mécanisme aussi lourd que le GC rencontré sous Java. En fait l'ARC a l'avantage d'être déterministe et continu mais il est globalement plus lent (throughput - débit) que les GC par copie. Au passage notons que l'ARC conduit à des fuites mémoires dans le cas de références cycliques (et les références faibles ne sont une solution que pour certains cas). A moins d'utiliser les mêmes techniques que les GC traçant, ce qui cumule le poids des deux systèmes. Les GC sont aussi moins sujets à la fragmentation de la mémoire à long terme - un facteur important sur serveur.

Par ailleurs la sécurité de types dans Java et l'absence d'arithmétique de pointeurs offrent au compilateur davantage d'opportunités d'optimisation. Un bon compilateur Java doit pouvoir faire mieux sur bien des plans qu'un bon compilateur Pascal.

La seul surcoût incontournable pour Java en comparaison d'un système natif à base d'ARC ce sont les vérifications liées à la sécurité (bornes des tableaux, références nulles, etc). Mais c'est un avantage en termes de sécurité pour un coût très raisonnable. Entre un petit gain de performances et la garantie de l'absence de buffer overflow, le choix DOIT se porter sur le second pour la très grande majorité des applications.

Enfin notons que Java dispose de nombreux compilateurs très optimisés pour toutes les plateformes grâce à un écosystème très riche. Je doute que le compilateur Pascal ait fait l'objet de tant d'attentions.

Un serveur de pages HTML peut fonctionner avec seulement 128 Mo de mémoire et un processeur à faible consommation. La puissance processeur nécessaire aux serveurs est donc due à la compilation du code sur le serveur. Il est donc absurde d'utiliser PYTHON ou JAVA sur un serveur.

Ce qui est absurde et même criminel c'est d'utiliser sur serveur un langage permettant des buffer overflows et propice par nature à des failles de sécurité en pagaille.

Et il y a bien d'autres absurdités dans cette phrase. Et dans tout le reste.

À ce propos la libraire ZEN GL permet de créer des applications graphiques à la fois pour ANDROID, iOS, LINUX, WIN-CE.

Il existe de très nombreuses petites bibliothèques 3D comme celles-ci pour faire mumuse dans tous les langages.

Mais les pros, eux, utilisent UE4 / Unity / Cryengine / CocOS / etc. On est très loin de ton jouet.

Votre exécutable LAZARUS est aussi suffisamment complet pour être indépendant de librairies.

Ben voyons : peu importe le manque de bibliothèques puisque vous n'en aurez pas besoin !.

Dans la réalité le runtime Java est le plus fourni au monde et pourtant il ne dispense pas les développeurs d'avoir recours à de nombreuses bibliothèques tierces. Qui existent, elles.

JAVA nécessite la réinvention d'un nouvel EDI afin de gagner du temps.

C'est bien connu, sous Java tout le monde développe son IDE. Tu en as d'autres de ce genre ?

Contrairement à JAVA, LAZARUS permet d'utiliser une programmation proche de l'humain et une programmation proche de l'ordinateur, la programmation Procédurale.

Ma précédente question vient de trouver sa réponse !


Et vanter les mérites de Pascal par rapport à Java, quelles foutaises !
* Un langage vieux d'un demi-siècle avec un modèle de compilation obsolète : lent, déclarations préliminaires redondantes, ordre de lecture imposé par la machine et à l'opposé de celui nécessaire à l'humain, etc.
* Des pratiques désuètes et nuisibles : inutilement verbeux, déclarations des variables en haut plutôt qu'au plus près de leur usage, taille des tableaux faisant partie des types et compliquant l'écriture du code, et beaucoup d'autres.
* Un écosystème éclaté entre plusieurs versions incompatibles du langage.
* Pas de support des fonctionnalités récemment acquises par les autres langages (séquences fainéantes, opérations fonctionnelles sur celles-ci, séquences asynchrones, introspection, etc, etc, etc).

Remballons ça dans la naphtaline et rangeons-le dans le grenier de pépé. Tout ça pue la dette technique.

[Laurent 1973]

....
Dotnet n'a jamais été interprété. La compilation JIT n'est pas de l'interprété et c'est bien un code natif qui s'exécute en fin de compte. Quant à la "VM" (terme qui n'est pas utilisé sous dotnet), une fois le code compilé il n'en reste que le poids habituel d'une bibliothèque faisant l'interface avec les API natives, ainsi que le poids du ramasse-miettes (dont très peu de personnes se plaindront).
...

https://msdn.microsoft.com/fr-fr/lib...vs.110%29.aspx :

Le .NET Framework fournit un environnement d'exécution, appelé le Common Language Runtime, qui exécute le code et offre des services qui simplifient le processus de développement.
...
Le code que vous développez à l'aide d'un compilateur de langage ciblant le runtime est appelé code managé

Un environnement d'exécution qui exécute du code, pour moi, j'appele ça une VM.
Si un programme .NET était natif, on ne l’appellerait pas "code managé" et il n'en n'aurait pas besoin d'une VM ou alors on a pas la même définition de "code natif".
De plus, si .NET produisait du natif, la portabilité via Mono ne serait pas possible.
Mais en effet, Microsoft a l'hypocrisie de ne jamais dire que le CLR est un Virtual Machine .NET sûrement pour ce distinguer de Java.

....
Et vanter les mérites de Pascal par rapport à Java, quelles foutaises !
* Un langage vieux d'un demi-siècle avec un modèle de compilation obsolète : lent, déclarations préliminaires redondantes, ordre de lecture imposé par la machine et à l'opposé de celui nécessaire à l'humain, etc.
* Des pratiques désuètes et nuisibles : inutilement verbeux, déclarations des variables en haut plutôt qu'au plus près de leur usage, taille des tableaux faisant partie des types et compliquant l'écriture du code, et beaucoup d'autres.
* Un écosystème éclaté entre plusieurs versions incompatibles du langage.
* Pas de support des fonctionnalités récemment acquises par les autres langages (séquences fainéantes, opérations fonctionnelles sur celles-ci, séquences asynchrones, introspection, etc, etc, etc).
Remballons ça dans la naphtaline et rangeons-le dans le grenier de pépé. Tout ça pue la dette technique.

Bon, c'est dit, tu exècres Pascal et tu ne jures que par Java.
Chacun est libre de son (mauvais) goût, ça ne se discute pas.

Par contre, je ne suis absolument pas d'accord avec ta conclusion:

• Un langage vieux d'un demi-siècle.
  Déjà, je ne chipoterais pas sur l'age (1970 = 45 ans pas 50) mais je te fait remarqué que si on prenait la règle: langage de plus de 20 ans = poubelle (Java est né en 1996), on ne ferait plus grand chose en informatique.
  Notons aussi que le Pascal de 1970 et celui de 2015 n'a plus grand chose à voir.
• Des pratiques désuètes et nuisibles.
  Et bien au contraire, je trouve que certaines règles dont de devoir rassembler l'ensemble des déclaration de variables au même endroit est une bonne chose pour la lisibilité/maintenabilité.
  Pour information, en JavaScript (un langage qui pue la naphtaline sûrement), l'outil de contrôle syntaxique jslint impose que toutes les déclarations de variables d'une fonction soit sur la même ligne.
• Un écosystème éclaté entre plusieurs versions incompatibles du langage.
  Il me semble que l'on retrouve se problème entre tout les langages.
  Essaye de faire compiler un vieux code en Java 1.2 (~10 ans) avec un JDK actuel et je pense que tu aura un grand nombre de souci de fonctions obsolètes.
  Et je ne parle même pas d'Android qui est pourtant plus récent.
• Pas de support des fonctionnalités récemment acquises par les autres langages.
  Là, je pense que tu méconnais Pascal.
  Il y a 10 ans, quand je faisait du Delphi, j'utilisais déjà l'introspection de classe et objet.
  Cela ne m'étonnerai pas que certaines nouvelles spécificité du langage permette pas forcement de réaliser ce que tu cites, mais d'obtenir une solution élégante à un problème autrement et facilement.

Je ne suis ni contre Java ou Pascal, ni pour non plus.
Je pense que c'est deux langage/environnement qui ont des avantages et des inconvénients.
On lancerait plusieurs même défis informatiques à des spécialistes Pascal ou Java, je pense que les résultats et les performances seront différents suivant les défis.
Ce serait même intéressant pour savoir les points forts de chacun

Tout langage nécessite une adaptation de l'esprit et à penser autrement afin de réaliser son besoin.
Les informaticiens qui ont cette capacité à s'adapter feront de grand chose et justement irons choisir le meilleur "outil" informatique pour réaliser au mieux le besoin de leur client.
Les autres se cantonnerons à du mono-langage toute leur vie, pisserons du code sans aucune vison produit et finirons leur vie professionnelle dans le grenier de pépé.

[DonQuiche]

Un environnement d'exécution qui exécute du code, pour moi, j'appele ça une VM.

Il l'exécute en le compilant au préalable, voilà tout. C'est une simple question de choix de mots. Je te garantis qu'il est compilé à la volée.

Si un programme .NET était natif, on ne l’appellerait pas "code managé" et il n'en n'aurait pas besoin d'une VM ou alors on a pas la même définition de "code natif".

Managé veut simplement dire que la mémoire est gérée. Tu peux très bien faire un langage natif managé.

Et si MS n'a jamais employé le terme de VM, c'est parce que le terme est mal compris par les dévs qui ont l'impression comme toi que le code est interprété ou le système d'exploitation, de fichiers ou le matériel sont virtualisés. J'approuve leur choix, Java devrait en faire de même.

Et figure-toi que les applis MS sur le Windows Store sont compilées en natif sur serveur. Le compilateur est dispo pour ceux qui souhaitent compiler en offline. D'ailleurs tu peux aussi forcer une compilation à l'installation du logiciel.

Bon, c'est dit, tu exècres Pascal et tu ne jures que par Java.

A vrai dire j'ai très peu programmé en Java et dotnet me tape sur le système après plus de dix ans de convolage. Mais ils ont des forces indéniables (contrairement à d'autres) et aucune vraie solution rivale dans la création d'applications lourdes.

Et bien au contraire, je trouve que certaines règles dont de devoir rassembler l'ensemble des déclaration de variables au même endroit est une bonne chose pour la lisibilité/maintenabilité.
Pour information, en JavaScript (un langage qui pue la naphtaline sûrement), l'outil de contrôle syntaxique jslint impose que toutes les déclarations de variables d'une fonction soit sur la même ligne.

Et je soutiens que c'est une mauvaise pratique sans aucun intérêt. La bonne pratique est de déclarer au plus près de l'usage, point barre. Le fait que JSlint ait adopté cette pratique me fait dire que c'est un mauvais outil (que je ne connais pas par ailleurs).

Tout langage nécessite une adaptation de l'esprit et à penser autrement afin de réaliser son besoin.

Oui il faut des outils différents selon les besoins, différentes approches, etc.
Mais on n'a pas besoin d'outils obsolètes.
Parle-moi de Scala, Rust ou Clojure, pas de Pascal et Cobol.

[el_slapper]

(.../...)
Oui il faut des outils différents selon les besoins, différentes approches, etc.
Mais on n'a pas besoin d'outils obsolètes.
Parle-moi de Scala, Rust ou Clojure, pas de Pascal et Cobol.

Ce snobisme imbécile à couté 100M€ à un grand compte Français qui a voulu remplacer tout son parc cobol par du Java.

Cobol, c'est l'exemple type du langage de niche : très fort dedans, bon à jeter aux chiens dès qu'il en sort. Il est naturellement sécurisé : quand toute la mémoire à allouée est définie dès la compilation, fatalement, les fuites mémoire, connait pas. Même pas besoin de vérifier : si on essaye d'aller plus loin, ça plante proprement(erreur 0C4), et ça ne va pas empêcher les petits camarades de bosser.

Cobol, c'est surtout efficace pour faire un nombre invraisemblable de petits trucs simples, qui mis bout à bout deviennent complexes. Et pour bouffer du fichier plat en pagaille. En bref, pour faire du batch comptable ou apparenté dans un grand compte. En dehors de ça, d'accord, poubelle. Mais dans cette niche, non seulement il est performant(vitesse d'exécution, sécurité des données, fiabilité), mais en plus il est rapide à coder et facile à maintenir. Car il a été conçu pour être lisible par un non-programmeur. Vœu pieux, certes, mais quand on ressort du code qui a 36 ans d'âge(ça m'est arrivé), même codé avec les pieds, on s'en sort quand même. Le dernier projet un peu important que j'ai mené comme programmeur en Cobol, c'était un batch qui traitait des données marketing, et transformait les données pour donner à chaque agent bancaire les clients à harcelerappeler pendant le mois. J'ai chiffré à 120 jours, et on en a consommé 125. Les gens du Java avaient chiffré à plus de 250(et ils avaient tendance à dépasser de plus de 10%). Parce que Java n'est pas optimisé pour ce genre de choses, et que la logique objet est une contrainte plus qu'une liberté dans ce genre d'applications. Cobol, lui, est taillé sur mesure. Procédural, bête, méchant, linéaire, efficace, rapide comme l'éclair. Les gens du Java, eux, ont fait l'interface pour les agents : là, c'était le bon outil.

Et je suppose que Pascal aussi a sa niche. Simplement, je ne la connais pas. Mais l'écarter d'un revers de la main juste parce qu'il est plus vieux de 2 ans que ce vieux programme cobol que j'ai refondu? Non. L'âge n'est pas un argument. Seul compte l'utilité. Je n'utiliserait pour rien au monde le Cobol si on me demandait de calculer l'influence de Jupiter sur la trajectoire des satellites. Mon cousin a utilisé Fortran, et il en a été tout à fait ravi. On s'en fout si ça a l'âge de son père. Il a torché ça en moins d'une semaine. Que demande le peuple?

[Logan Mauzaize]

Il est possible de créer des exécutables JAVA avec LAZARUS. [...]

Je vois ni question, ni réellement d'argumentaire. Juste une simple liste d'énonciation ... Tu veux en venir où ?

Pour la partie serveur, les défenseurs de JAVA et PYTHON n'arrivent pas à me répondre pour la nécessité d'avoir des serveurs puissants afin de terminer du code semi-compilé ou interprété.

Cette phrase n'a pas beaucoup de sens ... Ca veut dire quoi "terminer" du code ?
La nécessité d'utiliser des serveurs puissants est lié aux besoins en ressources qui dépendent des algorithmes et des technologies retenues. On peut faire de grosses ou petites applications aussi bien en Java qu'en Python ou autre.

Pourquoi faire des jeux en JAVA alors qu'il existe Zen GL ?
http://zengl.org

Pour exploiter la puissance de Java (ressources, communauté, multi-plateforme, mémoire "auto-gérée", écosystème, langages alternatifs, etc.) ?

[matthius]

Je vois ni question, ni réellement d'argumentaire. Juste une simple liste d'énonciation ... Tu veux en venir où ?

J'argumente au contraire. Ceux qui philosophent comprennent cela. Il ne s'agit que de comparer.

Cette phrase n'a pas beaucoup de sens ... Ca veut dire quoi "terminer" du code ?
La nécessité d'utiliser des serveurs puissants est lié aux besoins en ressources qui dépendent des algorithmes et des technologies retenues. On peut faire de grosses ou petites applications aussi bien en Java qu'en Python ou autre.

J'ai corrigé la phrase dans l'article : Compiler à la place de terminer.

Pour exploiter la puissance de Java (ressources, communauté, multi-plateforme, mémoire "auto-gérée", écosystème, langages alternatifs, etc.) ?

Le multi-plateforme semble pour moi plus intéressant avec Lazarus.
La seule utilité de Java est selon moi Android. Je ne recommande pas de mettre une JVM sur un serveur. Une application JAVA ne me semble utile que pour les processeurs ARM.

[Michel]

J
La seule utilité de Java est selon moi Android. Je ne recommande pas de mettre une JVM sur un serveur. Une application JAVA ne me semble utile que pour les processeurs ARM.

Je nesuis pas un spécialiste java mais cet argument me parait un peu court !
On trouve du java dans de nombreuses applications industrielles et même dans openoffice et libreoffice.
Pour le reste, je découvre une possibilité de LAZARUS que je ne connaissait pas et à à ce tire je t'en remercie, Matthius.

[e-ric]

Le post est mal intitulé et sans doute un peu racoleur mais bon l'information peut être intéressante. Le fait de compiler en byte code Java est sans doute intéressant si cela permet de développer facilement pour Androïd ou si cela apporte un surcroît de performance mais dans ce cas pourquoi utiliser Lazarus ?
Lazarus compile parfaitement pour les ARM, avec un RPi 2 ça passe nickel.

On trouve du java dans de nombreuses applications industrielles et même dans openoffice et libreoffice.

Oui et ce n'est pas une bénédiction, l'installation de LibreOffice sur mon Raspberry Pi (j'en suis content d'ailleurs même si j'ai quelques galères avec) a pourri ma configuration, je n'avais plus accès à la barre de menu. Je ne sais pas pourquoi l'installeur bidouille la configuration en loucédé. J'ai pu récupéré le coup mais cela m'a pris un temps que j'aurais bien consacré à autre chose.

Ce serait bien si on pouvait désactiver Java dans LibreOffice, Java devient aussi viral que .Net dans Windows (bon là, j'exagère un peu, ce n'est pas réellement comparable)
Complainte personnelle (j'insiste sur ce dernier adjectif): Je ne vois pas pourquoi un logiciel appartenant à Oracle est systématiquement imposé dans des environnements libres surtout quand on n'en veut pas. Si quelqu'un peut me répondre sans troller...

Tchüss