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.

[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

[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]

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 ?

Tant que ca compile en bytecode, les performances sont celles de l'environnement d'exécution. Peu importe le langage utilisé à la base.
Sur le pourquoi utiliser Lazarus (ou pourquoi compiler en bytecode Java), la réponse est toute simple : s'interfacer avec du code Java et pouvoir déployer le même exécutable partout il existe une JVM.

Lazarus compile parfaitement pour les ARM, avec un RPi 2 ça passe nickel.

Cela peut paraître anodin mais selon les cas d'utilisation ce n'est pas le cas : il faut générer un artefact (compiler) pour chaque plateforme (couple processeur / système d'exploitation).

l'installation de LibreOffice sur mon Raspberry Pi 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.

1. C'est quoi le rapport avec la plateforme Java ?
2. LibreOffice utilise très peu de Java et en utilise de moins en moins.

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

Le choix d'une technologie pour un produit appartient à celui qui réalise le produit. Je répondrais simplement que si beaucoup de personne utilise/vise ce socle technologique, c'est que pour beaucoup c'est une cible idéale.
Par exemple, le choix de Google d'utiliser le langage Java pour sa plateforme Android ...

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

S'il y a "intérprétation" d'un jeu d'instruction, j'appelle cela un interpréteur... Le processus que tu décris est le fonctionnement de la plupart des "interpréteurs" (Java, Python, Ruby, "asm.js").

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.

Sauf qu'avec la VM Oracle/OpenJDK, un même morceau de bytecode peut faire l'objet de plusieurs compilations JIT car il sera optimisé en fonction de son utilisation (inlining de certains appels, pruning des branches non convertes, allocation sur la pile plutôt que le tas, etc.).

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.

C'est une affirmation un peu gratuite je pense. La popularité d'une technologie ne fait pas sa qualité bien qu'elle y contribue.

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.

Je dirai que cela rend l'exécution du code plus prédictive. Quand à l'âge, c'est un argument fallacieux, car qu'elle est l'âge réel de "Java" ? Si on prend sa grande source d'inspiration (SmallTalk), il est aussi vieux que Pascal.

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.

Ca tombe bien l'une des grandes critiques de Java c'est sa verbosité ... Sinon, ce n'est pas toi qui pronait la sécurité du modèle Java ?

Un écosystème éclaté entre plusieurs versions incompatibles du langage.

Tu veux parler d'Android, J2ME ou autre ?

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

Rien à voir avec le langage mais avec une API/bibliothèque quelconque. Je suppose que rien ne l'empêche ?

Un environnement d'exécution qui exécute du code, pour moi, j'appele ça une VM.
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.

Sur la page de présentation du CLR, il est indiqué :

runtime environment (the virtual execution system)

. Après ce ne sont que des mots, tant qu'on est d'accord sur ce qui se cache derrière ...

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.

Même s'il est compilé à la volée, les instructions qu'il contient font appel à un système virtualisé (gestion de la mémoire, vérification des signatures, chargement des dépendances, contrôles d'accès, etc.). Ce n'est pas pour rien qu'on appelle cela un environnement d'exécution et pas simplement un "interpréteur".

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.

Je serais curieux de savoir pourquoi MS n'associe jamais les termes VM et .Net. Si jamais tu as une source à citer, ma curiosité t'en sera grandement reconnaissante

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.

Concept intéressant, je connaissais pas.

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.

Node.js, Rails, Django, CICS ?

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

La bonne pratique c'est celle qui convient à l'équipe. point.

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

Je pense que l'inverse est également vrai, déployer des choses complexes en CICS alors qu'elles pourraient être faites en "nouvelle technologie". Comme tout choix architecteraux, il y a des compromis et des choix à faire. Reste à voir sur le longtemps ce qui est gagnant ...

Ici, l'exécution sur les silos CICS est facturé très cher et sur une moyenne mensuelle fortement pondéré sur les pics. Du coup pour seulement quelques heures de fortes sollicitations, cela représente des k€ de facture alors que la moyenne globale est raisonnable. Sans compter les prix des licences du système et tous les logiciels qui gravitent autour (ex: DB2).

Aujourd'hui je m'en fais plus pour le coup de l'infrastructure que le "surcoût" en termes de développement logiciel. Surtout qu'avec l'avènement des micro-architectures, on est aujourd'hui capable de mettre en place des solutions qui permettent de combiner beaucoup d'avantages ; là où auparavant il est fallait faire des compromis.

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.

Je reconnais que le Cobol est très puissant dans le traitement de fichier texte. D'ailleurs le support natif des fichiers séquentiels indexés (VSAM) permet d'organiser des données sans avoir recours à une vraie base de données.

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.

Il ne faut pas oublier les JCLs et les utilitaires Z/OS (ex : CA7) ! Tout cela forme un écosystème permettant de gérer des flux de données avec beaucoup de puissance et "d'élégance".

[DonQuiche]

Sauf qu'avec la VM Oracle/OpenJDK, un même morceau de bytecode peut faire l'objet de plusieurs compilations JIT car il sera optimisé en fonction de son utilisation (inlining de certains appels, pruning des branches non convertes, allocation sur la pile plutôt que le tas, etc.).

Les mêmes problèmes se posent à n'importe quel compilateur natif : code compilé plusieurs fois et différemment selon le site d'appel.

Un compilo JIT dispose simplement de moins de temps qu'un compilo AOT (analyse superficielle) mais s'appuie sur des informations empiriques qui ne sont pas disponibles en AOT (sauf via profilage a priori : profile guided optimization). Là aussi le problème est identique pour les compilos C++ : tu peux choisir une compilation rapide et sans PGO ou une compilation lente avec ou sans PGO.

S'il y a "intérprétation" d'un jeu d'instruction, j'appelle cela un interpréteur... Le processus que tu décris est le fonctionnement de la plupart des "interpréteurs" (Java, Python, Ruby, "asm.js").

Plutôt que de plonger dans un débat sémantique, ce qui importe est qu'à temps égal de compilation égal un code Java compilé en JIT produira un code asm équivalent à celui d'un programme C++ équivalent, à l'exception des différences intrinsèques au langage (gestion de la mémoire et vérifications de sécurité propres à Java - test de nullité, test des bornes du tableau, etc).

Et tu ne peux pas comparer la "compilation" d'un langage dynamique avec un langage statique. Dans le cas du langage dynamique la résolution des noms demeure l'affaire du runtime dans la majorité des cas. Même lorsque l'analyseur dynamique est capable de créer un type et de compiler une méthode spécifiquement pour ce type il doit conserver de nombreux surcoûts : le type devra conserver une table dynamique pour l'interopérabilité avec le reste du code, la fonction devra souvent vérifier le type de ses arguments en appel (dispatch multiple), etc.

C'est une affirmation un peu gratuite je pense. La popularité d'une technologie ne fait pas sa qualité bien qu'elle y contribue.

Les ressources humaines ne sont pas illimitées. Quant tu vois la richesses des compilateurs Java, qui jouit de compilos AOT, JIT, de compilos adaptatifs, etc, et de pelletées de ramasse-miettes, je doute que l'éditeur de Pascal ait les moyens de consacrer autant de ressources à l'optimisation de son compilateur.

Ca tombe bien l'une des grandes critiques de Java c'est sa verbosité ... Sinon, ce n'est pas toi qui pronait la sécurité du modèle Java ?

Java est verbeux mais pas autant que Pascal, loin s'en faut, et pas de la même façon. Quant au lien entre verbosité et sécurité il est ténu et compliqué.

La verbosité de Java est avant tout dû à son refus de syntaxes ambiguës (pas de conversion automatique de null en bool par exemple, ce qui évite en général le fameux bug du "if a == b" qui devient "if a = b"). C'est ennuyeux à l'écriture mais il y a au moins un bénéfice clair. Le langage est tout de même inutilement verbeux par moments mais en général ça ne touche que quelques lignes.

La verbosité de Pascal est quant à elle due à des préconceptions de l'époque sur ce qui pourrait favoriser l'apprentissage. Hypothèses que des études empiriques ont largement invalidé depuis. Or écrire "begin" et "end" plutôt que des accolades ne contribue pas à la sécurité. En revanche Pascal accepte des syntaxes ambiguës.

Tu veux parler d'Android, J2ME ou autre ?

De ce que j'en sais une bibliothèque Java pour des fonctonalités indépendantes de toute plateforme fonctionnera de façon identique sur toutes les plateformes. Alors qu'une bibliothèque Pascal écrite en 2000 ne pourra pas être utilisée aujourd'hui parce que la gestion de la mémoire n'est plus la même (utilisation d'ARC).

Rien à voir avec le langage mais avec une API/bibliothèque quelconque. Je suppose que rien ne l'empêche ?

Non, de nombreuses fonctionnalités nécessitent une intégration dans le langage lui-même ou au moins à travers toutes leurs bibliothèques.

En C# / Java toutes les séquences (itérateurs / énumérables) sont fainéantes, c'est un mécanisme omniprésent. Donc toute extension fonctionnelle pour ces séquences peut être utilisée partout. Les mêmes outils en pascal ne pourraient être appelés nulle part. Et on ne peut pas introduire ces changements sans briser le code existant.

Quant aux séquences asynchrones (async / await), elles imposent une profonde transformation du code environnant à la compilation. Seul le compilateur peut le faire.

Même s'il est compilé à la volée, les instructions qu'il contient font appel à un système virtualisé (gestion de la mémoire, vérification des signatures, chargement des dépendances, contrôles d'accès, etc.). Ce n'est pas pour rien qu'on appelle cela un environnement d'exécution et pas simplement un "interpréteur".

La mémoire ou le système de fichiers ne sont pas plus plus virtualisées en C# qu'en C++. Par exemple un new en C# est beaucoup plus léger qu'un new en C++. Quant à la vérification des dépendances c'est simplement quelques lignes de plus dans le code de chargement dynamique qu'on trouve déjà dans les biblios C++ utilisant des dll.

Le seul surcoût qui demeure c'est celui des différences propres au langage : les mécanismes de sécurité. Quand ceux-ci ne sont pas éliminés par le compilateur.

Je serais curieux de savoir pourquoi MS n'associe jamais les termes VM et .Net. Si jamais tu as une source à citer, ma curiosité t'en sera grandement reconnaissante

MS avait publié aux débuts de C# un article dans MSDN Magazine où ils rejetaient explicitement le terme de VM et argumentaient contre lui mais une recherche rapide ne m'a pas permis de la retrouver.

Node.js, Rails, Django, CICS ?

Non, désolé. Il y a des choses très intéressantes dans le monde JS aujourd'hui, notamment en ce qui concerne la réactivité et le "responsive design".

Mais un code à typage dynamique (et faible) n'est pas adapté aux moyens et grands projets (d'où l'adoption rapide de typescript & co).

Par ailleurs JS souffre encore de bien des limitations : le support de la concurrence est aujourd'hui très limité et les API standard demeurent conçues pour une jolie petite sandbox où l'on cherche à entraver le code pour protéger l'utilisateur.

La bonne pratique c'est celle qui convient à l'équipe. point.

Si l'équipe décide que ne faire aucun test et n'avoir aucune équipe de QA leur convient, ça devient une bonne pratique ?

Cobol, c'est l'exemple type du langage de niche : très fort dedans, bon à jeter aux chiens dès qu'il en sort.

Et j'en suis en fait conscient.

Mais j'en rajoute volontairement parce que pour une personne comme toi qui est capable de jeter un regard éclairé sur ces vieilles solutions on a par ailleurs des hordes de types qui viennent nous soutenir que ces solutions sont très bien comme ça et que tout ce qui a été fait depuis est inutile ou pas très important. En gros que "tous ces satellites et ces ordinateurs ça sert à rien et ça donne le cancer".

Par ailleurs le cas du Pascal est différent car il a toujours voulu se battre sur le terrain généraliste.

Certaines solutions techniques sont simplement dépassées, il n'y a pas une loi de la nature promettant qu'il y a du bon à prendre partout. Au mieux on peut argumenter en faveur de la qualité de telle ou telle bibliothèque ou outil qui serait propre à Pascal.

[Logan Mauzaize]

Les mêmes problèmes se posent à n'importe quel compilateur natif : code compilé plusieurs fois et différemment selon le site d'appel.

Tout ce qui fait l'objet d'un lien dynamique (DLL, méthode virtuelle) ne peut faire l'objet d'une telle optimisation. Par exemple, supprimer tous les tests de nullité explicites (if (variable == null)) et implicite (variable.getAttribut()) si une valeur n'est jamais nulle.
Bon après la gestion du null en Java, c'est un gros défaut de conception de la plateforme.

Un compilo JIT dispose simplement de moins de temps qu'un compilo AOT (analyse superficielle) mais s'appuie sur des informations empiriques qui ne sont pas disponibles en AOT (sauf via profilage a priori : profile guided optimization). Là aussi le problème est identique pour les compilos C++ : tu peux choisir une compilation rapide et sans PGO ou une compilation lente avec ou sans PGO.

Cela explique certainement la stratégie adopté pour Hotspot (entre autres) de compiler en plusieurs passes afin d'avoir un temps total de compilation beaucoup plus long. Un autre avantage du JIT c'est qu'il permet de limiter la taille du "code cache" en ne traitant pas les blocs de code facile à "interpréteur" et rarement appelé.

Je ne connaissais pas la PGO. Concept intéressant mais peut-être difficilement exploitable dans le cas de librairies dynamiques ?

Plutôt que de plonger dans un débat sémantique, ce qui importe est qu'à temps égal de compilation égal un code Java compilé en JIT produira un code asm équivalent à celui d'un programme C++ équivalent, à l'exception des différences intrinsèques au langage (gestion de la mémoire et vérifications de sécurité propres à Java - test de nullité, test des bornes du tableau, etc).

Je dirais que ce qui importe, c'est d'avoir des perf acceptables par rapport au besoin. Et avoir des perf excellentes (sur le long terme) peut également être un besoin. Tandis qu'un temps de démarrage peut être un autre besoin.

Et tu ne peux pas comparer la "compilation" d'un langage dynamique avec un langage statique. Dans le cas du langage dynamique la résolution des noms demeure l'affaire du runtime dans la majorité des cas. Même lorsque l'analyseur dynamique est capable de créer un type et de compiler une méthode spécifiquement pour ce type il doit conserver de nombreux surcoûts : le type devra conserver une table dynamique pour l'interopérabilité avec le reste du code, la fonction devra souvent vérifier le type de ses arguments en appel (dispatch multiple), etc.

Sur le principe ils fonctionnent tous de la même manière. La seule chose qui change vraiment c'est le moment où sont réalisés les différentes étapes. Après les différences qui restent sont les caractérisitiques de la plateforme (type checking, null safety, overflow protection, method dispatch, etc.)

Les ressources humaines ne sont pas illimitées. Quant tu vois la richesses des compilateurs Java, qui jouit de compilos AOT, JIT, de compilos adaptatifs, etc, et de pelletées de ramasse-miettes, je doute que l'éditeur de Pascal ait les moyens de consacrer autant de ressources à l'optimisation de son compilateur.

Si on prend l'exemple de TeX (ou même de Mono et certainement de nombreuses autres projets), il n'y a pas besoin de milliers de "bras cassés" pour faire un bon produit.

Java est verbeux mais pas autant que Pascal, loin s'en faut, et pas de la même façon. Quant au lien entre verbosité et sécurité il est ténu et compliqué.

Pour la sécurité je faisais mention à la taille des tableaux qui font partie du type. Après je connais pas Pascal, mais dans le cadre de Java, il y a souvent beaucoup de verbosité mais cela tend à diminuer avec le temps. La plateforme Java a en revanche l'avantage de pouvoir proposer de très nombreux langages alternatifs.

Le langage est tout de même inutilement verbeux par moments mais en général ça ne touche que quelques lignes.

Ca dépend pas mal de ce que l'on veut faire. Pour tout ce qui est API réactive/asynchrone (ex: listeners, Swing) ou fonctionnelle, c'est une plaie à la limite de l'utilisable ; tout du moins jusqu'à Java 8 qui permet de faire directement référence à des méthodes.

En C# / Java toutes les séquences (itérateurs / énumérables) sont fainéantes

Qu'est-ce que tu entends exactement par "fainéant" ?

Quant aux séquences asynchrones (async / await), elles imposent une profonde transformation du code environnant à la compilation. Seul le compilateur peut le faire.

En Java on a pas de mécanisme similaire en natif et cela n'empêche pas de faire de la programmation asynchrone. Ou faire de la programmation "fonctionnelle" avant l'arrivée de Java 8.

La mémoire ou le système de fichiers ne sont pas plus plus virtualisées en C# qu'en C++. Par exemple un new en C# est beaucoup plus léger qu'un new en C++. Quant à la vérification des dépendances c'est simplement quelques lignes de plus dans le code de chargement dynamique qu'on trouve déjà dans les biblios C++ utilisant des dll.
Le seul surcoût qui demeure c'est celui des différences propres au langage : les mécanismes de sécurité. Quand ceux-ci ne sont pas éliminés par le compilateur.

Je connais pas C# pour répondre mais en Java, chaque classe est chargée dynamiquement au besoin. Ce qui impose que le code machine s'appuie sur une API pour interagir avec l'environnement d'exécution. Idem pour tout ce qui concerne la résolution de méthode (sauf si inliné), le type checking, etc.
Il existe donc bien un socle technique sur lequel repose le code machine pour s'exécuter.

Non, désolé. Il y a des choses très intéressantes dans le monde JS aujourd'hui, notamment en ce qui concerne la réactivité et le "responsive design".
Mais un code à typage dynamique (et faible) n'est pas adapté aux moyens et grands projets (d'où l'adoption rapide de typescript & co).

Ouais enfin ca transpile en Typescript&co transpilent en JS. Peu importe le "bytecode" (l'annonce des WebAssembly en est la preuve). Tu peux écrire ton application Node.js dans le langage que tu veux, l'environnement d'exécution sera toujours le même.
Donc il existe bel et bien des alternatives.

Par ailleurs JS souffre encore de bien des limitations : le support de la concurrence est aujourd'hui très limité et les API standard demeurent conçues pour une jolie petite sandbox où l'on cherche à entraver le code pour protéger l'utilisateur.

En fait la gestion de la concurrence en JS suit aujourd'hui les standards : à savoir l'éviter (pipelining, clusterisation des données, divide&conquer, etc.).
Concernant les problèmes de sécurité, ils affectent toutes les plateformes y compris Java. Dès lors que tu récupères du code distant, comment garantir l'intégrité des librairies, la confiance de "l'éditeur", etc.

Si l'équipe décide que ne faire aucun test et n'avoir aucune équipe de QA leur convient, ça devient une bonne pratique ?

Je n'ai que deux mots à dire : culture d'équipe.

[el_slapper]

(.../...)Je pense que l'inverse est également vrai, déployer des choses complexes en CICS alors qu'elles pourraient être faites en "nouvelle technologie". Comme tout choix architecteraux, il y a des compromis et des choix à faire. Reste à voir sur le longtemps ce qui est gagnant ...

Ici, l'exécution sur les silos CICS est facturé très cher et sur une moyenne mensuelle fortement pondéré sur les pics. Du coup pour seulement quelques heures de fortes sollicitations, cela représente des k€ de facture alors que la moyenne globale est raisonnable. Sans compter les prix des licences du système et tous les logiciels qui gravitent autour (ex: DB2).

Aujourd'hui je m'en fais plus pour le coup de l'infrastructure que le "surcoût" en termes de développement logiciel. Surtout qu'avec l'avènement des micro-architectures, on est aujourd'hui capable de mettre en place des solutions qui permettent de combiner beaucoup d'avantages ; là où auparavant il est fallait faire des compromis.

Je reconnais que le Cobol est très puissant dans le traitement de fichier texte. D'ailleurs le support natif des fichiers séquentiels indexés (VSAM) permet d'organiser des données sans avoir recours à une vraie base de données.

Il ne faut pas oublier les JCLs et les utilitaires Z/OS (ex : CA7) ! Tout cela forme un écosystème permettant de gérer des flux de données avec beaucoup de puissance et "d'élégance".

Oui, j'ai bien parlé des batches comptables, pas du transactionnel; qui petit à petit est remplacé par des solutions plus efficaces - j'ai vu beaucoup de Java et un peu de Delphi, d'ailleurs... Chez les gens rationnels, on garde COBOL pour le noyau et on fait tourner du Java(ou équivalent, mais c'est du java la plupart du temps) autour.

Mais j'en rajoute volontairement parce que pour une personne comme toi qui est capable de jeter un regard éclairé sur ces vieilles solutions on a par ailleurs des hordes de types qui viennent nous soutenir que ces solutions sont très bien comme ça et que tout ce qui a été fait depuis est inutile ou pas très important. En gros que "tous ces satellites et ces ordinateurs ça sert à rien et ça donne le cancer".

Par ailleurs le cas du Pascal est différent car il a toujours voulu se battre sur le terrain généraliste.

Certaines solutions techniques sont simplement dépassées, il n'y a pas une loi de la nature promettant qu'il y a du bon à prendre partout. Au mieux on peut argumenter en faveur de la qualité de telle ou telle bibliothèque ou outil qui serait propre à Pascal.

Non, mais l'évolution veut que ce qui est dépassé partout disparaisse partout - à terme. Ce que je ne sais pas, c'est quelle durée il faut pour arriver "à terme". Tant que des gens trouvent leur compte avec des solutions inférieures(en admettant que tu aie raison, ce dont je n'ai aucune idée), notamment parce qu'ils connaissent par cœur cette solution et que tout leur existant est codé dessus, ça risque de survivre très longtemps. Ca ne peut disparaitre que si la boite disparait - et donc que c'est un désavantage concurrentiel suffisamment massif pour plomber la boite. Spécialement chez les gens qui ne sont pas éditeurs de logiciels, ça demande quand même un sacré différentiel technologique.

Ce que je crois comprendre, c'est que Java a des avantages. Pour autant, si ceux-ci peuvent être importants pour un éditeur de logiciels, pour un fabriquant de béton qui a tout qui fonctionne bien en Delphi, quelle est la valeur ajoutée à passer à Java? La portabilité? pour une boite qui n'utilise que Windows? Plus de bibliothèques? Pour une boite qui n'a pas spécialement besoin de toute cette puissance de feu? Moi, il ne me semble pas que ces avantages soient suffisants pour que l'évolution naturelle élimine le Pascal et ses dérivés.

[DonQuiche]

...

Globalement, ce qu'il est important de comprendre, c'est que la distinction VM/natif n'est pas pertinente en termes de performances car la VM peut très bien avoir un coût équivalent à celui de n'importe quelle bibliothèque.

C'est la distinction "sécurisé" contre "insécurisé" qui importe. C'est une affaire de sécurité contre une affaire de performances et rien que cela. C'est seulement dans ce sens que le choix du langage importe, en tenant compte non seulement des mécanismes propres du langage mais aussi des biblios dispos.


Maintenant :
* Que ce soit en natif ou en Java, tu choisis ton compilateur et ses options selon tes besoins : portabilité, vitesse de compilation, vitesse d'exécution, etc. Les choix et problèmes sont les mêmes dans les deux cas.

* Que ce soit en natif ou en Java, les frontières inter-bibliothèques ne sont en général pas optimisées. Mais on peut le faire, c'est du "whole program optimization et c'est plus commun en Java.

* Que ce soit en natif ou en Java, on peut avoir un compilateur adaptatif comme Hotspot. Ce qui a un vrai intérêt en termes de portabilité et de performances (PGO intégrée). Mais c'est un sacré effort d’ingénierie si tu vises l'excellence.

* Que ce soit en natif ou en Java, tu peux parfois dé-virtualiser des méthodes, tout comme tu peux parfois analyser qu'une référence ne sera jamais nulle ou que deux variables distingueront toujours deux cases mémoires distinctes.

* Que ce soit en natif ou en Java, le code d'une dll est par défaut chargé dynamiquement au besoin (dynamic linking), ce qui nécessite toute une plomberie (MAJ d'une table de sauts pour y inscrire les adresses des fonctions à appeler et remappage des pointeurs d'appels du code chargé en mémoire). Et dans les deux cas on peut faire du static linking à la place.

Je ne connaissais pas la PGO. Concept intéressant mais peut-être difficilement exploitable dans le cas de librairies dynamiques ?

Bof. Au contraire, automatiser le profilage de cas typiques est plus facile pour une bibliothèque que pour une interface graphique. Pour une appli on aura tendance à faire ça à la main avec un succès mitigé.

Sur le principe ils fonctionnent tous de la même manière. La seule chose qui change vraiment c'est le moment où sont réalisés les différentes étapes.

Non, les langages à typage dynamique sont vraiment d'une autre espèce, très différents à compiler.

Théoriquement tu penses peut-être qu'il suffit d'ajouter une étape de reconstruction d'un système de types puis de remplacer les appels dynamiques de membres (parcours de la table des membres pour trouver un champ ou une méthode) par des usages statiques (une simple addition de pointeurs).

Sauf qu'en pratique tu vas te heurter au code généré à la volée et à tel mécanisme fondamentalement dynamique (par exemple une biblio qui stocke une clé dynamiquement générée sur chacun de tes objets). Il va donc te falloir une analyse statique poussée (très lourde, très lente, très imparfaite).

Et à cause de ça tu vas devoir être pessimiste et parsemer tout le code généré de vérifications de types, d'appels virtuels à dispatch multiple et ajouter à la plupart de tes objets un gros surpoids pour beaucoup d'objets (la table des membres). Les problèmes de ce genre tendent à se propager et à contaminer le code.



En vrac :
* Mono a quand même pas mal de pb, et leur IDE laisse plus qu'à désirer. On sent le manque de moyens.

* Le fait que la taille des tableaux fasse partie des types en Pascal ne dispense pas de vérifier les bornes. Or celles-ci ne sont pas vérifiées automatiquement. Par ailleurs cela encourage de nombreuses mauvaises pratiques (utilisation de tableaux jugés suffisamment grands - qui ne le seront pas - et copier-coller).

* En Java/C#/Python si tu retournes un itérateur/énumérable/générateur, la collection elle-même n'est pas évaluée. Elle ne le sera que progressivement lors des appels à "Next". Cela permet par exemple de retourner des séquences infinies et de créer des opérateurs fonctionnels très commodes (map / filter / reduce / select / where) qui étaient auparavant l'apanage des langages fonctionnels. La notion d'itérateur de ce genre n'est pas si récente: absente en C et en C++ tu dois fournir deux objets représentant la fin et le début, et l'itération se poursuit tant que fin != début.

* Si tu penses que la concurrence était lourdingue en Java, essaye donc d'en faire en C. C'est vraiment à pleurer tant tu te bats avec la portabilité et le bas niveau des primitives !

* Pour les séquences asynchrones je parlais de async/await que l'on trouve en C#/Scala : le code est réécrit sous formes de continuations enchaînées les unes aux autres.

Ouais enfin ca transpile en Typescript&co transpilent en JS. Peu importe le "bytecode" (l'annonce des WebAssembly en est la preuve). Tu peux écrire ton application Node.js dans le langage que tu veux, l'environnement d'exécution sera toujours le même. Donc il existe bel et bien des alternatives.

Ok, admettons. Et tu penses qu'aujourd'hui une solution typescript peut constituer le socle d'un projet à cent millions imposant de consommer des bases de données de dix SGBD différents, des formats de fichiers dans tous les sens, d’instrumentaliser Office ou d'autres applications, et de servir de réseau d'entreprises ?

Je doute qu'on en soit là, tant sur la technique que la pérennité detypescript.

Par contre ça permet sans doute de faire un bon gros site web.

En fait la gestion de la concurrence en JS suit aujourd'hui les standards : à savoir l'éviter (pipelining, clusterisation des données, divide&conquer, etc.).

Plus maintenant : ils vont désormais aller vers un multithreading complet avec mémoire partagée et UI asynchrone (layout et rendu dans des threads spécifiques sans code JS).

Par ailleurs si JS a longtemps été monothread c'était simplement un héritage du passé compliqué à modifier. Par la suite ils ont tenté un modèle sans mémoire partagée au nom de la sécurité, avant de se rendre compte que de toute façon ça n'avait pas d'intérêt et que la sécurité est obtenue en isolant chaque page dans un processus distinct. D'où webasm et un vrai multithreading avec barrières mémoire et compagnie.

[DonQuiche]

Ce que je crois comprendre, c'est que Java a des avantages. Pour autant, si ceux-ci peuvent être importants pour un éditeur de logiciels, pour un fabriquant de béton qui a tout qui fonctionne bien en Delphi, quelle est la valeur ajoutée à passer à Java? La portabilité? pour une boite qui n'utilise que Windows? Plus de bibliothèques? Pour une boite qui n'a pas spécialement besoin de toute cette puissance de feu? Moi, il ne me semble pas que ces avantages soient suffisants pour que l'évolution naturelle élimine le Pascal et ses dérivés.

Tu as une vision statique du problème mais elle est trompeuse : toute solution doit constamment être modifiée pour les raisons suivantes.

a) Les coûts d'opération vont augmenter à mesure que le matériel et l'écosystème logiciel sur lesquels tu t'appuies vont devenir plus rares et coûteux, seulement utilisés par une poignée de clients. Jusqu'à leur disparition.

b) Toute solution logicielle réclame des mises à jour, pour de nouvelles fonctionnalités ou pour l'interopérabilité. Or plus le temps passe plus ces besoins sont ambitieux et complexes, si bien que de vieilles solutions improductives coûtent très cher, non seulement à cause de leurs lacunes propres mais aussi de l'absence de nouveaux outils et bibliothèques pour ce langage.

Tout cela aboutit à l'accumulation d'une dette technique, qui elle-même conduit à la faillite technique : le moment où toute modification ou acte de maintenance coûtera plus cher que ce que l'entreprise en retirera.