Je ne vais pas admettre un truc parce que tu en change en la définition.
Quelle définition est-ce que j'ai changée ? En regardant bien je ne voit qu'une chose que j'ai changer par rapport au debut : on est passer de "compiler" à "compiler en code natif". Donc le seul changement est a ton avantage, et si on revient à la formulation d'origine, il n'y a même plus a discuter.
Tu ne peux pas comparer la taille d'un runtime C avec celui de .NET.
Je ne compare pas et je m'en bas les couille de leur difference de taille. Ça ne change absolument rien au fait que le programme est compiler en code natif, que ce soit par NGen a partir de code .net, ou par GCJ a partir d'un code java intermediaire.
C'est pourtant pas compliqué, et le fait de ne pas etre le premier n'enleve rien a Lisaac. Plutot que de defendre un truc indéfendable et qui ne lui apporte rien, il serait beaucoup plus pertinent d'essayer de mettre en avant les vrai avantage du langage. Se serait bien plus efficace que du pseudo intégrissme a deux balles.
C'est facile pour n'importe quel jit de sauver les parties de binaires converti. Il reste tout de même une énorme part d'interprétation. C'est obligatoire par exemple pour garder fonctionnel tous les mécanismes de sécurité, si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut.
Tu n'a pas vraiment compris le modele de securite de .NET. Le principe c'est tu as un code que tu compile pour un machine virtuelle. Ton code est valide pour cette machine et ne peut pas faire de conneries. Ensuite tu as un compilateur auquel tu fait confiance qui traduit ce code en langage machine en respectant la semantique definie par la VM.
Donc tu garde ton modele de securite. En general tu difuse le code pour la VM, et l'utilisateur a un compilo auquel il fait confiance sur ca machine qui, al'instalation, va verifier le code et le compiler.
Tu as donc bien du code natif qui est aussi securiser que le code VM. Bien sur le compilo n'est pas infaible, mais une VM non plus.
[^] # Re: Surprise
Posté par beagf . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 4.
Quelle définition est-ce que j'ai changée ? En regardant bien je ne voit qu'une chose que j'ai changer par rapport au debut : on est passer de "compiler" à "compiler en code natif". Donc le seul changement est a ton avantage, et si on revient à la formulation d'origine, il n'y a même plus a discuter.
Tu ne peux pas comparer la taille d'un runtime C avec celui de .NET.
Je ne compare pas et je m'en bas les couille de leur difference de taille. Ça ne change absolument rien au fait que le programme est compiler en code natif, que ce soit par NGen a partir de code .net, ou par GCJ a partir d'un code java intermediaire.
C'est pourtant pas compliqué, et le fait de ne pas etre le premier n'enleve rien a Lisaac. Plutot que de defendre un truc indéfendable et qui ne lui apporte rien, il serait beaucoup plus pertinent d'essayer de mettre en avant les vrai avantage du langage. Se serait bien plus efficace que du pseudo intégrissme a deux balles.
C'est facile pour n'importe quel jit de sauver les parties de binaires converti. Il reste tout de même une énorme part d'interprétation. C'est obligatoire par exemple pour garder fonctionnel tous les mécanismes de sécurité, si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut.
Tu n'a pas vraiment compris le modele de securite de .NET. Le principe c'est tu as un code que tu compile pour un machine virtuelle. Ton code est valide pour cette machine et ne peut pas faire de conneries. Ensuite tu as un compilateur auquel tu fait confiance qui traduit ce code en langage machine en respectant la semantique definie par la VM.
Donc tu garde ton modele de securite. En general tu difuse le code pour la VM, et l'utilisateur a un compilo auquel il fait confiance sur ca machine qui, al'instalation, va verifier le code et le compiler.
Tu as donc bien du code natif qui est aussi securiser que le code VM. Bien sur le compilo n'est pas infaible, mais une VM non plus.