Discussion :

[Maniak]

pour qu'un programme .NET puisse executer sous Windows il faut bien pour l'instant installer le framework .NET de 20 Mo, ce qui m'a fait pensé au java Runtime de Sun...

C'est un peu pareil, mais ça ne s'appelle pas machine virtuelle :)
Détails tout ça :)

[Moonheart]

Houlalalalalala!!! C'est TRES TRES grave si vous pensez qu'un framework est la même chose qu'une machine virtuelle!!!

Un framework est un ensemble de bibliothèques qui permettent à un programme d'un language donné de fonctionner sur une machine.
Tout langage à un framework, que ce soit le Java (framework inclus dans le runtime de Sun), le C (où le framework est l'ensemble des primitives systèmes), ou même l'assembleur (où le framework est l'ensemble des interruptions de la machine)
La seule différence majeure, c'est que dans le cas de Java ou .net, les système n'incluent pas ce framework de base (quoique la prochaine version de Windows devrait inclure le framework .net)

Une machine virtuelle, elle, n'a rien à voir avec des bibliothèques de langage. Il s'agit d'un programme qui va interpreter la version semi-compilée du langage pour l'éxécuter...
Avantage: ca permet de prendre un programe compilé sur n'importe quoi et l'éxécuter sur n'importe qu'elle autre machine pourvu qu'elle aie la dite machine virtuelle.
Inconvénient: ca ralentit de beaucoup la vitesse d'éxécution (le java est 10 fois plus lent que le C++, par exemple... a cause du temps consommé par la machine virtuelle pour interpréter les instruction avant de les effectuer)


.net possède un framework, mais .net n'a pas de machine virtuelle et c'est un fait important car c'est ce qui permet à .net d'être 5 fois plus rapide que Java à l'éxécution.

Alors essayez de ne pas confondre les deux... en milieu professionnel ca vous ferait passer pour des clowns.

[Maniak]

Une machine virtuelle, elle, n'a rien à voir avec des bibliothèques de langage. Il s'agit d'un programme qui va interpreter la version semi-compilée du langage pour l'éxécuter...

Genre le 'just-in-time compiler' de .NET ki interprète la version semi-compilée en MSIL d'une appli pour l'exécuter ? :)

Avantage: ca permet de prendre un programe compilé sur n'importe quoi et l'éxécuter sur n'importe qu'elle autre machine pourvu qu'elle aie la dite machine virtuelle.

Vivi, comme .NET :)

.net possède un framework, mais .net n'a pas de machine virtuelle et c'est un fait important car c'est ce qui permet à .net d'être 5 fois plus rapide que Java à l'éxécution.

Oui et non. L'avantage de .NET sur Java est ke la version complètement compilée est conservée dans un coin. Le premier lancement est plus lent le temps ke la compilation se fasse, mais ensuite ça tourne plein pot :)

(particulièrement visiblement avec les applis ASP.NET, pour leskelles le premier chargement de chake page rame à mort, et k'ensuite ça galope :)

Alors essayez de ne pas confondre les deux... en milieu professionnel ca vous ferait passer pour des clowns.

Ce serait dommage :)

Mais pour autant ke je sache, personne n'a dit ke le framework de .NET était une machine virtuelle (ce serait difficile :)
Il faut installer le framework .NET pour pouvoir faire tourner les applis .NET, le petit détail à ne pas rater est ke l'installation du framework installe aussi le compilo ki joue le même rôle ke la machine virtuelle Java. C'est pas la même chose, mais c'est dans le même pack :)

[Moonheart]

Une machine virtuelle, elle, n'a rien à voir avec des bibliothèques de langage. Il s'agit d'un programme qui va interpreter la version semi-compilée du langage pour l'éxécuter...

Genre le 'just-in-time compiler' de .NET ki interprète la version semi-compilée en MSIL d'une appli pour l'exécuter ?

Non justement, il ne l'interprete pas... une compilation et une interprétation sont deux choses différentes:
- la compilation d'une commande se fait en une fois
- l'interpretation d'une commande se fait a chaque éxécution de cette commande

Par exemple, admettons que vous ayez une boucle:

"Répéter 10 fois: imprimer <bonjour> sur l'imporimante par défaut"

Si vous la compilez, vous allez faire le travail de traduction language source -> language machine de la commande "imprimer <bonjour>" 1 fois, et l'éxécuter 10. Si vous l'interprétez, vous allez la traduire 10 fois. (bon en fait c'est un peu plus compliqué que ca car les interpréteurs intelligent compilent certaines parties du code, mais ca vous donne une idée générale)

Autre chose: toute compilation se fait en 3 étapes:
- analyse syntaxique
- analyse gramaticale
- analyse sémantique

L'analyse syntaxique consiste à identifier chaque mot exemple:
i = i + 1 ;
sera identifié comme
<variable "i"> <assignation> <variable "i"> <operateuraddition> <constante "1">
par l'analyse syntaxique... c'est l'analyse syntaxique qui renvoie des erreurs comme:
"nom de variable ou de fonction inconnue"

L'analyse gramaticale consiste à vérifier que l'ensemble s'articule bien, c'est à dire si vous employez les différents éléments selon une organisation qui à un sens.
C'est cette partie qui fera la différence entre:
i+1 = 1;
et
i = i+1;
dans les deux cas les "mots" employés sont corrects, mais pas forcément agancés correctement. L'analyse gramaticale le détecte et renvoie le cas échéant des erreurs du style:
"impossible d'assigner une valeur à une constante"

L'analyse sémantique, enfin, traduit l'ensemble dans un autre langage. C'est là que ressortiront des erreurs du genre: "attention, la variable "i" peux ne pas avoir été initialisée à cet endroit"


Lors d'une interprétation ou d'une compilation complète, les 3 étapes sont réalisées... mais dans le cas de la compilation "just-in-time" de .net les 2 premières étapes ont DEJA été faites par la compilation en langage intermédiaire, la compilation "just-in-time" ne réalise donc que l'analyse sématique, contre l'intéprétation java qui fait les 3.


Résultat: la compilation just-in-time et non seulement très différente d'une interprétation, mais aussi beaucoup plus rapide.

Avantage: ca permet de prendre un programe compilé sur n'importe quoi et l'éxécuter sur n'importe qu'elle autre machine pourvu qu'elle aie la dite machine virtuelle.

Vivi, comme .NET

Pas du tout, car dans le cas de .net la compilation finale est faite SUR la machine ou le programme est éxécuté.
C'est très différent de Java qui ne recompile pas.

.net possède un framework, mais .net n'a pas de machine virtuelle et c'est un fait important car c'est ce qui permet à .net d'être 5 fois plus rapide que Java à l'éxécution.

Oui et non. L'avantage de .NET sur Java est ke la version complètement compilée est conservée dans un coin. Le premier lancement est plus lent le temps ke la compilation se fasse, mais ensuite ça tourne plein pot

4-5 fois plus long au démarrage et ensuite 10 fois plus rapide en cours de route. Oui donc globalement, statiquement ca va bien 5 fois plus vite...

pour autant ke je sache, personne n'a dit ke le framework de .NET était une machine virtuelle (ce serait difficile

On en est quand même pas passé loin:
"C'est un peu pareil, mais ça ne s'appelle pas machine virtuelle" - Maniak

Or le problème c'est que ce n'est pas du tout la même chose!
Le principe de fonctionnement est extrèmement différent et en matière de programation avancée, ca fait toute la différence...

Optimiser par exemple la vitesse d'éxécution en java se fait par une simplification sémantique pour aider la machine virtuelle a interpréter plus rapidement alors que sur .net cela passe par une modularisation permettant le minimum de recompilation lors du déploiement d'une nouvelle version.

Ensuite les principes de la machine virtuelle en terme de sécurité sont totalement différents des principes sur une version compilée (voir tous les fichiers de sécurité à mettre à jour directement sur la machine d'installation afin que la machine virtuelle démarre avec les bonnes "options" de sécurité alors que dans un programme compilé, la sécurité est elle entièrement paramétrée en dur dans le code même du programme)

Etc etc, je pourrais continuer comme ca longtemps: les différences entre une machine virtuelle java et une compilation just-in-time .net sont aussi nombreuses que les étoiles visibles dans un ciel nocturne. (enfin celui d'une ville moyenne, pas celui de la rase campagne, n'éxagérons rien )


Donc: NON, il n'y a pas de machine virtuelle sur .net, ni même quoique ce soit qui lui ressemble.
Prétendre le contraire c'est sous-entendre que .net à des défauts dont justement il est exempt.

[Maniak]

Non justement, il ne l'interprete pas... une compilation et une interprétation sont deux choses différentes:
- la compilation d'une commande se fait en une fois
- l'interpretation d'une commande se fait a chaque éxécution de cette commande

Tu aimes jouer sur les mots et couper les cheveux en 4 ? :)
.NET compile, et a donc besoin d'interpréter le MSIL avant. Java interprète, et a donc besoin de compiler en cours de route (même si c'est juste une instruction ou petit groupe d'inscriptions après l'autre, ça finit toujours en langage machine).

On ne va pas se prendre la tête là-dessus 3000 ans (surtout ke c'est pas du tout le sujet du thread) : .NET comme Java ont une phase de compilation/interprétation avant l'exécution, l'avantage de .NET étant ke la version compilée est conservée dans un coin pour être rappelée rapidement ensuite.

On oublie les termes, on s'en tient aux définitions, ce sera plus simple :)

4-5 fois plus long au démarrage et ensuite 10 fois plus rapide en cours de route. Oui donc globalement, statiquement ca va bien 5 fois plus vite... ;)

Je sais pas pourkoi, j'ai l'impression ke tu es soit ingénieur, soit avec un gros background en maths :)

pour autant ke je sache, personne n'a dit ke le framework de .NET était une machine virtuelle (ce serait difficile :)

On en est quand même pas passé loin:
"C'est un peu pareil, mais ça ne s'appelle pas machine virtuelle" - Maniak

Vi, un peu pareil. Code semi-compilé -> langage machine au moment de l'exécution. Une seule fois dans un cas (enfin... ouais on va dire ça pour simplifier, sinon on n'en finira jamais :), chake fois pour l'autre. Y a juste embrouille parce ke ça parlait du framework .NET et ke je pensais au compilo ki s'installe en même temps :)

Optimiser par exemple la vitesse d'éxécution en java se fait par une simplification sémantique pour aider la machine virtuelle a interpréter plus rapidement alors que sur .net cela passe par une modularisation permettant le minimum de recompilation lors du déploiement d'une nouvelle version.

Oui non mais le sujet d'origine n'allait pas dans ces détails hein, je rappelle k'on est dans un thread VB.NET vs C#, ki n'a pas pour mission de partir dans une comparaison optimisation Java vs optimisation .NET :)

Dans le cas présent, le sujet se limite à : avec .NET comme avec Java, le code passe par une moulinette intermédiaire avant d'être exécuté. Pour rentrer dans les détails, mieux vaut créer un nouveau thread (aukel je ne pourrai pas participer vu ke je ne fais pas de Java :). Celui-là est déjà bien assez long sans être en plus alourdi par ça :)

Etc etc, je pourrais continuer comme ca longtemps

Justement, c'est pas le propos ici :)

[Moonheart]

.NET compile, et a donc besoin d'interpréter le MSIL avant. Java interprète, et a donc besoin de compiler en cours de route (même si c'est juste une instruction ou petit groupe d'inscriptions après l'autre, ça finit toujours en langage machine).

Tu ne comprends décidément pas du tout qu'une compilation n'interprete pas...
Bon je vais essayer de te ré-expliquer:

D'où vient le terme "machine virtuelle", en premier lieu?
Et bien tout simplement parce qu'il existe vraiment une machine (c'est à dire un ordinateur) virtuelle à l'intérieur de l'ordinateur réel quand tu utilise Java

Ton programme semi-compilé ne peux pas s'éxécuter sur la machine réelle seulement sur la machine virtuelle. Par exemple s'il contient la commande "ecrit BLABLA a l'écran", la machine virtuelle va tout d'abord envoyer la commande a son processeur virtuel (seul capable de comprendre le langage) qui va ensuite écrire BLABLA sur son écran, virtuel lui aussi.

Ceci fait, la machine virtuelle fait une "interpretation" du résultat virtuel pour le retranscrire en vrai, c'est a dire recopier le contenu de l'écran virtuel sur l'écran réel.

commande java ----(execution sur machine virtuelle)----> résultat virtuel
résultat virtuel ----(interprétation de la machine virtuelle)---> résultat réel



Une compilation est différente... elle n'utilise aucun ordinateur virtuel, elle transforme juste le code semi-compilé en un code capable de produire un résultat réel sans passer par un intermédiaire

commande java ---(compilation)---> commande machine
commande machine ---(éxécution sur la machine réelle)---> résultat réel



Interpréter = traduire un résultat virtuel en un résultat réel
Compiler = traduire une commande semi-compilée en une commande machine

Tu n'interpretes rien quand tu compiles... parce que tu ne peux qu'interpreter des résultats et que la compilation se fait AVANT l'apparition d'un tel résultat.

Tu compiles par contre parfois quand tu interpretes... disons que si la machine virtuelle est très maligne, il peux transformer les commandes les plus simples en des commandes machines sans passer par un résultat virtuel, hélàs les commandes assez simples pour ca sont ultra-rares (GetChar() par exemple)... mais dans ce cas là, il faudrait plutot dire que l'on interrompt l'interpretation au profit d'une courte compilation.

.NET comme Java ont une phase de compilation/interprétation avant l'exécution, l'avantage de .NET étant ke la version compilée est conservée dans un coin pour être rappelée rapidement ensuite.

C'est pour les raisons ci-dessus que ce que tu dis là est faux: Java ne compile pas avant l'éxécution. Et .net n'interprète rien (et surtout même s'il le faisait ca ne serait certainement pas AVANT l'éxécution mais après).

[Maniak]

Bon, j'ai ni le temps ni l'envie de continuer à jouer sur les mots (surtout k'à la longue, ça finit par lourder un peu), donc on va faire simple :

T'as raison.

Une compilation n'interprète rien, elle prend du code (semi-compilé ou non) et pond du binaire, comme ça, sans l'interpréter en cours de route, c'est magike.

Une interprétation ne compile rien, elle prend du code (semi-compilé ou non) et pond du binaire, comme ça, sans le compiler en cours de route, c'est magike.

Les histoires de "mais dans un cas ça passe par une vraie machine virtuelle ki fait plein de trucs dans son coin et dans l'autre ça fait tout directement", on s'en cogne, c'est pas la kestion. Dans les deux cas on a du code semi-compilé et on doit passer par un intermédiaire (compilo ou machine virtuelle) pour ke ça marche. Rien à battre des détails technikes, du fait k'une version soit plus directe/rapide/optimisable/whatever et ke l'autre fasse plein de traitements lourdingues à chake fois. C'est du pinaillage technike ki n'a pas sa place dans ce thread.

Maintenant si tu veux continuer de décortiker le traitement de chake côté, à ta guise, mais ça va continuer à polluer ce thread pour rien, et ce sera sans moi :)


Y a pas kelk'un dans le coin pour parler des avantages de VB.NET par rapport au C# plutôt ? Pas ke c'est le sujet du thread, mais kand même, si :)

[Moonheart]

Une compilation n'interprète rien, elle prend du code (semi-compilé ou non) et pond du binaire, comme ça, sans l'interpréter en cours de route, c'est magike.

Il faudrait que tu comprennes un peu que le terme "interpreter" n'a pas le même sens en informatique que le sens commun.
Et dans le sens informatique, une compilation n'interprete pas.

Il est important de s'attacher au sens des mots, comme tu le faisais remarquer toi-même un peu plus tôt.

Une interprétation ne compile rien, elle prend du code (semi-compilé ou non) et pond du binaire, comme ça, sans le compiler en cours de route, c'est magike.

Toute chose logicielle sur un ordinateur est forcément binaire, je suppose donc que tu voulais dire plutot "code machine"...?

Mais justement, une interprétation ne pond AUCUN code (qu'il soit machine ou non).

Dans les deux cas on a du code semi-compilé et on doit passer par un intermédiaire (compilo ou machine virtuelle) pour ke ça marche.

Si je suis d'accord avec ce nouveau propos (normal vu que c'est une affirmation valable pour la totalité des code softwares, y compris le code machine lui-même), notes quand même que c'est totalement différent que d'affirmer que .net utilise un principe "presque pareil" à la machine virtuelle Java comme tu l'as fait au départ.

Maintenant si tu veux continuer de décortiker le traitement de chake côté, à ta guise, mais ça va continuer à polluer ce thread pour rien, et ce sera sans moi

Je ne fais que corriger des affirmations erronées marquées ici qui pourraient induire en erreur les lecteurs de ce thread. Ce n'est pas moi qui ait lancé le sujet sur Java et ce n'est pas moi non plus qui ait pondu une affirmation comme quoi le framework .net était "presque pareil" qu'une machine virtuelle Java.
Ceci étant un propos qui, s'il était vrai, serait lourd de conséquences du point de vue informatique... (tant sur le point de la compréhension de la plateforme, que sur les principes de programation avancée, l'optimisation des performances ou les choix techniques qu'il peux y avoir à faire dans une entreprise)

Après que tu prennes cela à la légère la différence entre les deux pour ton l'usage que tu fais de .net c'est ton droit, tu n'as peut-être pas besoin d'informations foncièrement exactes pour réaliser ton travail...
Mais il peut y avoir des gens ici pour qui la différence pourrait s'avérer importante.
Si ce n'est par souci d'éxactitude, je pense au moins que lorsque qu'on poste sur un forum publique ont doit se soucier de ne pas mettre d'idées préconcues et érrones dans la tête des gens au risque que ca leur nuise plus tard.
Un jeune diplomé en informatique qui lirait ton propos et aurait le malheur de le ressortir en entretien d'embauche pour une place de développeur .net devant une personne s'y connaissant un peu, par exemple, perdrait toute chance d'acquérir le poste pour lequel il postule...

Comme tu le vois, un propos erroné rendu publique, même si l'erreur te semble indigne d'être relevée de ton point du vue, peut avoir de bien plus grandes conséquences pour ses lecteurs... je ne trouves donc pas qu'il soit si excessif de ma part de chercher à ne pas laisser trainer ici des idées fausses fut-elles même simplement issues d'une mauvaise formulation de départ.

[bidou]

Comme tu le vois, un propos erroné rendu publique, même si l'erreur te semble indigne d'être relevée de ton point du vue, peut avoir de bien plus grandes conséquences pour ses lecteurs... je ne trouves donc pas qu'il soit si excessif de ma part de chercher à ne pas laisser trainer ici des idées fausses fut-elles même simplement issues d'une mauvaise formulation de départ.

Je ne peux qu'abonder dans ce sens.
Pour les sujets généraux comme pour les sujets techniques, une information erronée se doit d'être corrigée dans le sujet ou elle a été fournie. Je vous rappelle que le niveau technique des membres est très divers, aussi convient-il de préciser un maximum de points pour l'information correcte de tous.

[venom]

c# et vb.net ne possedent pas les memes facultes. C# est mieux integre au framework, et le sera problement toujours mieux.

vb.net comblera ses lacunes mais sera toujours limité (deja il ne pourra jamais faire de code marqué unsafe)

dans l'ensemble, hormis quelques differences (relativement importantes) au niveau de l'edi (code completion, edit & continue) qui font de vb un outil un peu plus productif (dans la prochaine version whidbey), il n'en demeure pas moins qu'il est aussi complique (ou aussi facile, c'est selon) que c# tout en n'ayant pas un acces total au framework et en etant quand meme tres verbeux (trop)... Finalement, en subissant les inconvenients du framework (il est quand meme compliqué le framework), il ne permet pas d'en tirer le meilleur partie (c'est donc un mauvais investissement a terme). quelque part (en ironisant), vb.net est au framework ce que vb6 est a l'api win32. C'est a dire un gadget qui peut devenir rapidement complexe si l'on doit utiliser des fonctionnalités de l'api qui ne sont incorrectement, ou pas prises charge par le language

vu comme ca, moi je dis que vb c'est pas bien. pourtant j'ai 10 ans de vb derriere moi et je suis passé a borland c++ quand j'ai vu la cata.vb.net. j'aurais peut etre du m'interesser a c# avant... mais bon, ce qui est fait est fait et je ne le regrette pas. Ce serait d'ailleurs interessant de faire un debat sur le best of des languages (c#, vb, delphi, eiffeil, c++, smalltalk, etc)

je crois qu'effeil s'en tirerait plutot bien. probablement serait il elu meilleur language d'apres ce que j'ai pu lire a droite ou a gauche et sur la façon qu'il a de resoudre les problemes liés a l'heritage multiple, par exemple..
mais bon, il n'a pas des millions d'ocx ou de vcl et c'est un autre debat.

lol

[Moonheart]

Il est vrai que vb. net ne reprend pas toutes les fonctionalités du framework (quoique je me demande l'utilité réelle des codes "unsafe" si quelqu'un a une explication montrant une situation ou il serait bon de faire un tel code, il peux me l'envoyer par PM ca m'interesse...) mais comme je l'ai dit, vb est plus un langage adapté aux petits développement d'après moi.

Il est certes très verbeux, mais bénéficie d'un support IHM plus avancé que le C# et ses limitations n'ont pas de raisons de se faire sentir dans un développement à très courte portée. Il est aussi un meilleur outil dans ce sens pour les informaticiens de gestion qui n'ont que peu l'occasion de développer et donc pas forcément des réflexes de programmation très rodés.... par exemple alors qu'un programmeur a temps plein sera très à l'aise avec les casts et les remontées d'erreurs à la compilation seulement, un développeur occasionnel lui sera heureux d'avoir la possibilité de laisser le code en cast implicite et de bénéficier de la remontée d'erreurs en live de l'éditeur vb.net, et ce toujours en ayant probablement nul besoin pour les fonctionnalités du framework que vb.net ne supporte pas.

Bref, j'ai beau ne pas être un très grand fan de vb, il me semble que le langage possède encore quelques petits atouts... maintennt je dis pas, il suffirait qu'un groupe se décide à faire un éditeur/compilateur C# aussi poussé que celui de vb.net et peut-être que vb.net serait définitivement entérré.

[bidou]

Je serais assez enclin à partager ton analyse. Pour un développeur VB6 expérimenté, il est assez aisé de passer à VB.NET. Celui-ci va rester dans un environnement familier et le seul effort d'apprentissage à faire portera sur les différences de concept qui sont loin d'être insurmontables. Migrer vers C# représentent sûrement un effort beaucoup plus grand. De plus dans les explications des avantages de C# sur VB.NET, je ne vois rien de tellement primordial qui pousse un développeur VB6 vers C#.

[Moonheart]

Je précise quand même que je parles uniquement des petits développement informatique a courte durée de vie... comme dit précédement pour les projets à grande durée de vie, le formalisme de C# est un avantage non négligeable quand même.

[olrt]

Il existe un mot clé extrêmement pratique en C# dont je ne connais
pas d'équivalent en VB.NET :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
using(variable=new Type())
{
    // code...
 
}
 
/*
 A la sortie du bloc using(...)
 {
  ...
 }
 variable.Dispose() est appelé automatiquement.
*/

[neo.51]

il n'y a malheureusement pas d'équivalent en VB.NET

[Moonheart]

Je ne suis pas sur que ce mot-clef soit une fonctionalité à part entière... a vue d'oeil ca m'a plutot l'air qu'une macro.

[neo.51]

On peu considérer ça comme un 'racourcis'

N'empèche que c'est bien pratique ce using

[Moonheart]

On peu considérer ça comme un 'racourcis'

Ben je crois que c'est la définition même d'une macro.... non?

[neo.51]

autant pour moi j'avais zappé ton post

[Maniak]

Je ne suis pas sur que ce mot-clef soit une fonctionalité à part entière... a vue d'oeil ca m'a plutot l'air qu'une macro.

Pas vraiment. L'équivalent en VB.NET serait un truc du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Try
  Dim toto As tutu
  blah blah blah
Finally
  toto.Dispose()
End Try

et il y a une bonne chance pour que le using de C# ne se trimballe pas l'overhead d'un try/catch, vu qu'une fois sorti du contexte 100% géré par le GC (ce que le compilo peut faire), on peut obtenir cette fonctionnalité très facilement.

Donc j'aurais tendance à dire que c'est une fonctionnalité à part entière du C# qui permet de retrouver un bout de fonctionnalité qu'on perd par rapport au C/C++ avec l'intervention du GC (la prévisibilité de l'instant de destruction des objets).