Discussion :

[rmaker]

Bonjour,

J'ai assisté avec beaucoup d'intérêt à la conférence de Bertrand Meyer sur le langage Eiffel (qu'il a inventé). Il a notamment développé l'idée qu'Eiffel était compilé en C ou en MSIL (le langage de la VM liée au .Net).

Je trouve l'idée de compiler en C super intéressante:
- le code est indépendant de la plateforme à condition qu'on sorte du C standard
- le C est un des langages des plus rapides
- Contrairement à une VM qui prend plusieurs Mo dès son lancement, l'exécutable C peut rester très compact.

Donc, mes questions sont les suivantes:
- Pensez vous que la méthode de machine virtuelle soit un choix de facilité pour être OS indépendant?
- Confirmez vous que l'idée de compiler en C est une excellente solution pour la vitesse et l'indépendance par rapport à l'OS? (ou pas, si non, pourquoi)?

Merci pour vos réponses!

[Médinoc]

Ça dépend ce qu'Eiffel est supposé permettre. Si ça permet quoi que ce fut que le C standard (allez, on va être gentil, le C POSIX.1) ne permet pas (Interface graphique, etc.) alors ce n'est pas platform-independent de toute façon: Ça dépendra de bibliothèques et il faudra que la platforme de destination ait une implémentation de ces bibliothèques...

[rmaker]

Ça dépend ce qu'Eiffel est supposé permettre. Si ça permet quoi que ce fut que le C standard (allez, on va être gentil, le C POSIX.1) ne permet pas (Interface graphique, etc.) alors ce n'est pas platform-independent de toute façon: Ça dépendra de bibliothèques et il faudra que la platforme de destination ait une implémentation de ces bibliothèques...

Très bonne réponse, merci. Donc, pour toi, une VM te garantit surtout d'avoir toutes les fonctionnalités "de base" pour la programmation sérieuse: accès aux interfaces graphiques, au réseau, au système, etc...

Merci, c'est résolu!

[souviron34]

euh...

Tu mélanges 2 choses : une application et sa présentation.


Pour une application, le C est sans doute le plus portable et le plus peformant

Pour du GUI, sans doute du Java, ou du Web


Il n'y a rien d'autre qui peut être indépendant de la plateforme (et même là, à part Java et son bytecode, tout le reste est dépendant - les compilos ont des flags pour telle ou telle machine)

Une VM est destinée à faire tourner un OS sur un autre OS. Ce n'est donc pas indépendant..


On peut dire que le bytecode de Java est un OS, pouiqu'il lui faut une VM pour le faire tourner..

Il faudrait donc que tu précises ce que tu entend par "indépendant de la plateforme", et ce que tu entends par "machine virtuelle"

[SpiceGuid]

J'ai assisté avec beaucoup d'intérêt à la conférence de Bertrand Meyer sur le langage Eiffel (qu'il a inventé). Il a notamment développé l'idée qu'Eiffel était compilé en C ou en MSIL (le langage de la VM liée au .Net).

Hé bien s'il l'a inventé alors il doit connaître le Eiffel standard :

The Standard does not specify:

• The requirements that a computing environment must meet to support the translation, execution and other handling of Eiffel texts;
• The semantic properties of an Eiffel text if it or its data exceed the capacity of a particular computing environment;
• The mechanisms for translating Eiffel texts into a form that can be executed in a computing environment;
• The mechanisms for starting the execution of the result of such a translation;
• Other mechanisms for handling Eiffel texts and interacting with users of the language.

[rmaker]

euh...

Tu mélanges 2 choses : une application et sa présentation.


Pour une application, le C est sans doute le plus portable et le plus peformant

Pour du GUI, sans doute du Java, ou du Web


Il n'y a rien d'autre qui peut être indépendant de la plateforme (et même là, à part Java et son bytecode, tout le reste est dépendant - les compilos ont des flags pour telle ou telle machine)

Je ne suis pas d'accord avec toi.
En C++ ou C, disons, si tu veux coder une application graphique, tu passes par une librairie tierce (Qt, disons), ou en utilisant les possibilités que t'offrent ton système d'exploitation (au sens large, par exemple KDE).

En Java, tu as la possibilité d'utiliser une API standard, swing ou awt. Tu peux donc coder ton application avec une couche de présentation fournie avec un JDK.

Par conséquent, quand je dis que le code est indépendant de la plateforme, je suis d'accord, c'est inexact:
- le C normalisé l'est, au sens où le même code se compile sans changement (du code) sur plusieurs OS pourvu qu'on ait un compilateur C.
- MAIS si je compile en C, si je veux l'équivalent d'une JFrame, je suis bien , je n'ai pas çà fourni "de base", il me faut une librairie de plus.

Etait ce çà que tu avais en tête?

Une VM est destinée à faire tourner un OS sur un autre OS. Ce n'est donc pas indépendant..


On peut dire que le bytecode de Java est un OS, pouiqu'il lui faut une VM pour le faire tourner..

Il faudrait donc que tu précises ce que tu entend par "indépendant de la plateforme", et ce que tu entends par "machine virtuelle"

Machine virtuelle:
outil entre ton application et ton OS qui te permet d'exécuter le même code exactement sur toutes les plateformes, sans le changer. Pour cela, ta VM va lire ton code et l'exécuter elle même, indépendamment de ton OS ou ta plateforme. Le point clé, c'est qu'elle l'exécute elle même, donc que, par essence, çà va te prendre du temps et de la resource.

Indépendant de la plateforme:
Au sens où le même code est exécuté ou compilé de la même manière, sur tous les OS, et sans faire appel à une librairie spécifique et séparée du langage.

Donc, pour moi c'est clair, compiler en C ne permet pas d'écrire une application graphique comme java l'offre avec swing ou awt. Cà n'est pas alors un problème de machine virtuelle directement. Enfin, si puisqu'il faut pouvoir avoir une couche intermédiaire qui te cache les détails d'accès au réseau, au système de fichier, et à la couche présentation.

[souviron34]

Je ne suis pas d'accord avec toi.
En C++ ou C, disons, si tu veux coder une application graphique, tu passes par une librairie tierce (Qt, disons), ou en utilisant les possibilités que t'offrent ton système d'exploitation (au sens large, par exemple KDE).

En Java, tu as la possibilité d'utiliser une API standard, swing ou awt. Tu peux donc coder ton application avec une couche de présentation fournie avec un JDK.

Euh.. Et c'est quoi selon toi, swing ou awt ?

Des librairies externes - certes non tierces parties - mais cependant séparant bien l'IHM du reste..

Les notions de widgets, frames, windows, label, push-button, etc, ne sont que des notions d'IHM.

Il existe par exemple en graphique des API standards comme X11, ou comme GKS pour le tracé de vecteurs, pour être lié à des graphiques via des langages comme C, Fortran, .. (KDE est basé sur X11, comme l'est Gnome, et la plupart des autres)

Il se trouve simplement que Java est né de l'impossibilité de faire entrer X11 sur Windows (alors qu'il fonctionnait sous toutes les autres machines), avant l'apparition de cygwin, et que Java a été la réponse pour avoir des graphiques portables.

La séparation Java-calcul / Java graphique est relativement artificielle, le but de Java ayant été justement d'unfiier les graphismes. Ce qui en fait un outil relativement peu pratique pour les gros calculs (ce n'est pas son but).

Par contre, la solution trouvée, en l'occurence le bytecode et la JVM, sont les seuls garantissant la portabilité. A CONDITION d'installer la bonne version de la JVM sur le bon OS.

Et donc on est aussi dépendant de la plateforme... Ce n'est plus le programme, mais la JVM qui l'est.

Comme l'est l'implantation du protocole X11 et la Xlib...

La défintiion de l'API est standard. La réalisation est machine-dépendante.

Un programme X11, comme un programme Java, s'affichera partout de la même manière (d'où l'intérêt du X11 et sa construction pour s'afficher sur un réseau hétérogène), juste parce que le serveur X tournant sur la machine destination a été compilé pour la bonne architecture. MAIS il comprend et correspond à l'API standard.

Il n'y a donc pas de différences fondamentales entre la JVM et X11.

C'est en ça que je pense que tu mélanges les choses : une VM toute seule n'est rien : elle simule un environnement/OS commun. Cependant, elle s'exécute sur une certaine achitecture, et pour se faire elle a des versions suivant chaque architecture..

Donc, pour moi c'est clair, compiler en C ne permet pas d'écrire une application graphique comme java l'offre avec swing ou awt. Cà n'est pas alors un problème de machine virtuelle directement. Enfin, si puisqu'il faut pouvoir avoir une couche intermédiaire qui te cache les détails d'accès au réseau, au système de fichier, et à la couche présentation.

CQFD.

D'une part tu ne mentionnais pas graphique au départ, mais simplement VM.

D'autre part, comme dis ci-dessus, tu peux cacher les choses à un certain niveau, il n'empêche que dans le fond tu dois avoir quelque chose dépendant de la plateforme.

La seule chose indépendante totalement est un protocole comme HTML (c'est son but), un protocole ASCII, ou quelque chose comme un bytecode, un fichier de commandes, etc etc..

Cependant, pour chacun de ses éléments, il lui faudra à un moment ou à un autre un "traducteur" en fonction de la plateforme.. (un navigateur, une VM, une sur-couche comme un shell...)

Je repose donc ma question par rapport à tes 2 questions intiiales :

Quel est le fond de tes questions ???

[rmaker]

Quel est le fond de tes questions ???

Déjà, merci pour ta réponse.

Je constate que SmartEiffel propose de compiler du Eiffel en C. L'idée me parait pertinente pour gagner en vitesse sans perdre en portabilité. J'extrapole en me demandant si une telle chose n'est pas possible en général.

Je prends donc l'exemple de Java qui utilise une VM. Pourquoi est elle nécessaire?

Tu me dis que c'est une solution parmi d'autres pour que le code java soit portable. MAIS que, piège dans lequel je tombe depuis le début, il existe des librairies séparées pour faire du graphique. Coïncidence en Java: elle est fournie avec le JDK.

Je ne nie pas qu'à un moment, il te faut un "truc" spécifique pour exécuter ton code sur ta machine. Je me demande juste s'il y a des solutions autre qu'une VM. Oui, compiler dans un autre langage. Et, enfin, j'ai compris que la question de la librairie est sans rapport avec la question de la portabilité du langage.

Merci bien, c'est résolu.

[souviron34]

Déjà, merci pour ta réponse.

De rien

sans rapport avec la question de la portabilité du langage.

Disons que là aussi tu as une légère imprécision : ce n'est pas le langage qu'il est difficile de faire pour toutes machines : la plupart des langages le sont sauf l'assembleur. C'est l'exécution...

Un script ou un fichier HTML est tout à fait portable, c'est du texte.. Par contre, que ce soit l"éditeur de texte, le navigateur, ou le shell, il y a forcément une interaction avec la machine quelque part..

Ce que je mentionnais à propos de Java, c'est que la JVM est comme un OS "indépendant". Elle a sa propre architecture, et elle comprend le bytecode. ça ressemble fortement à un Windows ou à un MacOS ou à un Linux, qui ont leur propre architecture et comprennent leurs "machinecode"..

Son avantage est qu'un programme compilé pour elle s'excutera sur toutes les versions sans rien changer : cela l'isole. Son inconvénient est qu'il faut installer cet "OS" sur l'OS sur lequel tu travailles : on fait une "surcouche" (d'où d'ailleurs les problèmes de ressources associées , mémoire et autres)).