SIMULER LA VISIBILITÉ PACKAGE (COMME EN JAVA)

Signaler
Messages postés
514
Date d'inscription
mercredi 19 mars 2003
Statut
Membre
Dernière intervention
1 mars 2009
-
Messages postés
202
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/43361-simuler-la-visibilite-package-comme-en-java

Messages postés
202
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

Pour ceux qui ne sont pas convaincus de ce que je vient de dire au sujet de l'intérêt majeur suscité par les VM, regardez ce qui se passe:
- du côté de la programmation massivement parallèle (sur le GPUs par exemple dans OpenGL et DirectX, qui deviennent programmebles de façon génériques avec des langages spécialisés)
- du côté des webservices et hébergements virtualisés (on parle de "thin client" et de "cloud computing"
- du côté du calcul distribué
- du coté des fondeurs de processeurs qui se sont lancés dans la bataille de la virtualisation.
- du côté de Microsoft qui défend encore sa voie .net et va tenter de l'imposer dans Windows 7 tout en promouvant sa plateforme VM ware (largement critiquée pour son surcoût exhorbitant en performance et son incapacité à supporter de nombreux coeurs ou le calcul massivement parallèle)
- les efforts faits par Sun et IBM pour créer un remplacement à son bytecode actuel pour Java (insuffisant et difficilement paralélisable et ne permettant pas de supporter tous les langages actuels ni d'offrir une interopérabilité totale avec dot.Net:

http://www.dotnetguru.org/modules.php?op=modload&name=News&file=article&sid=321&mode=thread&order=0&thold=0

(le but de ce projet est de créer une VM universelle)

Les compilateurs natifs sont en cours de tuning mais le but est bien de masquer l'architecture actuelle de la machine afin de rendre tous lesprogrammes et services déployables partout avec les performances optimales, et de permettre le support de toutes les architectures de virtualisation actuelles (qui seront émulées avec des performances excelentes et optimisées en fonction de la macjhien cible effectivement utilisée).
La virtualisation de tout le logiciel actuel, qu'il soit local ou un service réseau, avec un seul ou de nomberus utilisateurs, que ce soit pour des interfaces graphiques, des applis interactives, ou du calcul scientifique massif, avec une distribution automatique sur toutes les ressources de calcul disponibles dans un environnement hétérogène, constitiuent bien les voies suivies. On devrait aboutir en 2010 vers une version Beta de Java 7 sur cette architecture qui devrait aussi fonctioner comme un hyperviseur capable de supporter divers OS actuels (y compris Linux ou Windows). Du côté d'IBM, il planche avec AMD sur des accélélations matérielles de ce code VM qui deviendrait pris en charge de façon antive par les processeurs 32-bits et 64-bits actuels (il devrait aussi y avoir un support du code natif x86 ou x64 actuel par émulation dans cette VM future).
Evidamment derrière, il y a tout le marché futur des serveurs d'applications, et des services distribués, ou encore du logiciel hébergé comme un service et accessible depuis n'importe quel terminal connecté (du PC au téléphone mobile via les serveurs locaux d'entreprises), avec une échelonnabilité "à la demande".

Windows est clairement menacé, alors que Linux et Unix y voient leur planche de salut. Mais Microsoft prend désormais du retard et ne rient encre que par un marketing aggressif (il est probable qu'à l'avenir Windows deviendra gratuit, ce qui sera payant c'est l'offre de service en ligne pour l'hébergement ou l'interconnexion d'applications et de services). Dès l'année prochaine Java sera prêt alors que Microsoft en sera encore à tenter de mobiliser les entrerprises pour leur passage vers Windows 7 après avri raté l'étape de Vista.

Microsoft se trompe de guerre: l'OS n'est plus une ressources stratégique et ne se défend plus que par son "look" et son utilisabilité, des domaines où Linux et même Apple ont gagné des points, alors que maintenant d'autres plus gros encore que Microsoft se lancent dans la bataille: les FAI et les fournisseurs d'infrastructure réseau (et Google par exemple l'a bien compris); l'avenir ce n'est plus l'ordinateur et ce qu'il a "dans le ventre", mais le réseau, l'interopérabilité, l'accessibilité et l'échelonnabilité à la demande, une meilleure résistance aux pannes, et à un coût global largement inférieur et une administration unifiée et simplifiée), et pour les utilisateurs cela veut dire que l'effort est consenti envers une personnalisation facilitée.

Il faut reconnaitre que de moins en moins de monde s'intéressera à votre capacité à faire du code natif puisque c'est le compilateur intégré à la machine virtuelle qui offrira directement les meilleurs performances et de façon plus rapide et plus aisée à déployer, alors que votre code natif "fait maison" ne survivra pas à la demande de déploiement sur d'autres plateformes plus étendues et aura un cycle de vie de plus en plus court en comparaison du code managé qui verra son cycle de vie augmenter et plus intéressant à utiliser car déployable à plus grande échelle. Hormi les rares qui construisent du matériel (et ils sont de moins en moins nombreux à pouvoir le faire tant les coûts de recherche ont explosé), on aura moins intéret à faire de l'assembleur, du C, alors que le code managé sur VM (en C#/dot.net, Java, Python, ...) prend de plus en plus de valeur.

Note: Java a été porté en interne chez Sun sur plateforme VM .Net (au lieu des plateformes natives), mais c'est une étape intermédiaire pour porter le tout vers la VM universelle. Le débogage est en cours, et de nombreux JSR incluent le support des possibilités offertes par les futures VMs sur diverses plateformes; du côté applicatif, on s'oriente vers l'API unique, mais des implémentations plus nombreuses de la VM, masquant leurs diférences pour que le même code ou service soit accessible le plus possible depuis n'importe quel point même s'il n'est pas totalement exécuté localement.
Messages postés
202
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

Ici tu as une communauté pour le Python, mais pas pour le Ruby. Il me semble que la communauté Python est au contraire plus active que Ruby.

Evidemment il faut se faire à un léger changement de syntaxe: plus de point virgule pour séparer les instructions, mais une instruction par ligne (ou sinon un ":" pour indiquer que la suite de l'instriuction est formatée en bloc), plus d'accolades (les blocs sont indentés à la place, ce qui pousse au moins tous les programmeurs à indenter leur code correctement, rend le code lisible, et permet d'éviter les bogues relatifs aux mystérieux point-virgules ou accolades en trop ou mal appairés et corrigés ensuite de façon incorrecte.

Certains critiquent cette écriture, mais pour ceux qui veulent la syntaxe C/C++/Java classique, elle est possible dans une variante de Python compatible avec sa VM.

Le gros intéret de Python on écrit le code et on peut l'exécuter immédiatement, sans compilation préalable (la compilation est automatique, la VM compile juste ce qui est utilisé et maintient un cache dans des fichiers ".pyc"); il est même possible de modifier un source ".py" pendant son exécution (et forcer Python et relire une classe dès qu'elle cesse d'être utilisée).

Le démarrage de la VM Python est assez rapide, mais peut aussi consommer autant de mémoire que celle pour Java, il n'y a pas de vraie différence entre les deux à l'heure actuelle (la lourdeur apparente de Java tient au fait qu'on l'a trop vu utilisée pour exécuter des Applets web qui nécessitent un environnement assez lourd à initialiser, et de nombreuses librairies, alors qu'elles ne sont pas nécesaires absoluement à Java. Un script Java peut être aussi économe (mais il est dommage que la VM de Sun ne prenne pas en charge automatiquement la compilation des sources, ce que peuvent faire d'autres VM Java. De plus trop de gens ont connu Java du temps de Microsoft qui l'a rendu très lent et même incompatible, alors que depuis HotSpot dans Java 2, les performances n'ont plus rien à voir; aujourd'hui dans Java 5 on est loin de ce mauvais souvenir, Java est très rapide et bat pratiquement toujours .Net en performance comme en consommation de ressources mémoire, et en vitesse transactionnelle dans une contexte multithread ou multicoeur voire multiprocessus ou via des instances d'interfaces proxies de services réseaux); en performance brute sur des environnements hétérogènes, le même code obtient pratiquement les performances optimales de chaque architecture matérielle alors qu'un code compilé en C/C++ ou même C# ne se déploie de façon optimale que sur un nombre restreint de plateformes (aileurs les performances sont très mauvaises). Pour vous en convaincre, regardes la très grande lourdeur de l'interface graphique de Vista, toute en .Net, mal optimisée et qui consomme une grande quantité de ressources, et comparez à l'interface graphique de MacOSX qui contient une VM JAva presque invisible...

Le modèle de compilation dynamique à la demande (partiellement implanté dans Java qui demande une précompilation du bytecode, et dans Python à qui il manque encore le profilage à l'exécution pour la prédiction de branchement, pour l'allocation hiérarchisée des registres les plus rapides, et le regroupement relatif du code dans des pages mémoires plus localisées avec un meilleur taux de succès dans les caches matériels) est la solution d'avenir.

Il y aura encore du C ou du C++ voire de l'assembleur dans une partie des pilotes matériels du système hôte, mais de plus en plus de code sera virtualisé et optimisé localement à la demande selon le profil d'utilisation et de déploiement.

Il est même probable qu'une grande partie du code C ou C++ actuel sera compilé vers cette machine virtuelle (dans une forme modifiée, dite "managée") au lieu du code natif puisque cette dernière phase sera prise en charge séparément en fonction des capacités matérielles du système exécutant effectivement le code et qui peut être différent même de l’hôte du contrôleur général du système sur lequel l'application est installée, déployée ou utilisée.
Messages postés
514
Date d'inscription
mercredi 19 mars 2003
Statut
Membre
Dernière intervention
1 mars 2009

@Verdy_P: Pas grand chose à dire sur tes arguments : j'ai appris plein de trucs donc pour répéter aKheNathOn, bah merci d'avoir commenté mon petit morceau de code de manière aussi constructive. Pour info, cette source était vraiment expérimentale et ne pouvais en aucun cas être utilisée en pratique (trop lent et mal foutu). C'était juste une question que je me posais et je voulais montrer comment j'aurais résolu ce problème (si on m'avait demandé :P).

Tous les problèmes que tu énonces concernant le PHP, je ne m'en rendais pas compte avant : c'est depuis que je fais du JEE assez avancé que je me rends compte à quel point le PHP est un langage bancal. Mais il a comme énorme avantage d'être moins gourmand et il nécessite beaucoup moins de machinerie que le Java. Il me faut au moins 10min pour faire un Hello World! en JEE et moins de 10sec pour le PHP.

Du coup, tout comme toi, j'ai cherché une alternative entre le JEE et le PHP et c'est tout naturellement que je me suis intéresse au Ruby. Mais j'ai pas eu le temps de faire plus que de lire 2 ou 3 tutos et quelques comparatifs de derrières les fagots.

Mais tu viens de me convaincre pour le Python. Pas mal de gens disait que c'était vraiment puissant et bien fait, mais j'ai trouvé une communauté moins active que pour le Ruby (mais ai-je seulement bien cherché cette communauté :P).
Messages postés
202
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

Il n'y a toujours pas plus d'avantage significatif dans PHP5 qui reste toujours aussi préhistorique et dont la librairie de base a conservé toutes ses aberrations (notamment de typage).

Ayant découvert Python tardivement j'ai été surpris par la grande rapidité d'apprentissage de ce langage (même si j'en connaissais déjà de nombreux): je me suis plus vite mis à Python que de me remettre à PHP que je connaissais avant. Et Python reste dans la ligné de Java ou C++ en terme de philosophie générale et de modélisation objet.

Il me semble que comme langage de script il n'y aaujourd'hui pas mieux: c'est aussi rapide à développer que le PHP, aussi souple que le Javascript, aussi solide dans son typage que Java, la librairie de base est aussi riche que celle de Java (sans les multiples variantes incomplètes dans la librairie PHP de base), et s'enrichie plus vite dans ses extensions, sa syntaxe est légère (fini les "$" inutiles dans le code source PHP), et en plus son moteur est maintenant très rapide aussi avec sa machine virtuelle qui génère du bytecode précompilé (comme Java et .Net), mais aussi du code natif profilé à l'exécution (comme java aussi, mais pas encore .Net qui ne fait que du profilage à l'installation et manque de "mobilité").

J'ai bien essayé aussi Ruby, mais sans conviction: les améliorations sont inutilement compliquées, et il lui manque trop de choses dans ses librairies (Ruby est peut-être trop jeune, mais il prend du retard face à Python apparu pas si longtemps que ça avant).

Et Python est déjà près pour le parallélisme massif (le même langage peut servir de langage de kernel pour calcul sur GPUs divers ou sur nuage de coeurs de processeurs locaux ou distribués en réseau, comme sur des threads d'un monocoeur ou des taches sur des serveurs distincts, sans en faire dépendre la granularité arbitrairement par la structure et le découpage de l'application).

Il ne lui manque plus grand chose (dans son bytecode reconnu par sa VM) pour devenir un langage système à part entière: ce qui lui manque c'est un dispositif d'isolation et une architecture de sécurité (comparable à celle dans les ClassLoaders de Java, y compris en terme de vérifiabilité du bytecode et des contrats associés, puisque Python supporte aussi la réflection et une interface simple au code natif de l'hôte).
Afficher les 8 commentaires