- Parce que le chef a dit
Tiens, comme Fortran dans le cas d'applications scientifiques, ou bien C++ (toujours dans le même cas), où tout a été tellement surchargé qu'au final on se retrouve à faire des machins horribles de type tab(i) plutôt que tab[i].
Honnêtement, j'adore le C, je tripatouille l'asm toute la journée, mais les gens ne voient pas à quel point MS a été intelligent avec .Net.
On a C#, certes, mais aussi VB (pour les masochistes), et F# (pour les adeptes de Caml), IronPython, IronRuby (bon OK pour ces derniers, les implémentations restent du domaine de l'expérimental), et tout se retrouve dans une seule et même VM. C'est ça le gros intérêt de .Net. Rien n'empêche ensuite de passer à du JIT (ah ben tiens, la VM le fait déjà), et même de demander une génération directement en binaire si vraiment on en a besoin -- mais souvent les justifications sont fumeuses, car pour continuer à bénéficier de la sûreté des types et autres joyeusetés, on se retrouve à devoir générer les garde-fous qui vont bien et les insérer dans le binaire résultat, et au final on ne va pas spécialement plus vite que VM+compilation JIT.
De plus, là où en embarqué les ressources sont extrêmement rares/limitées (le problème est similaire dans le calcul haute-performance), dans le cas de l'informatique "généraliste", c'est rarement le cas. C'est en faisant entre autres ce constat que des compilateurs très intéressants tels que LLVM sont arrivés, avec un mode "VM-qui-se-spécialise" (et aussi tout le côté "je génère du code pseudo-asm bas-niveau mais avec des références aux CFG/DDG de la représentation intermédiaire) pour ceux qui peuvent attendre, et un mode "compilé-comme-les-grands" pour ceux qui veulent un résultat tout de suite, potentiellement moins bon que s'ils avaient accepté d'avoir une appli un peu plus lente au départ (mais bon, après tout dépend des impératifs).
[^] # Re: Pourquoi Mono ?
Posté par lasher . En réponse au journal Utiliser Mono sans peur. Évalué à 5.
Tiens, comme Fortran dans le cas d'applications scientifiques, ou bien C++ (toujours dans le même cas), où tout a été tellement surchargé qu'au final on se retrouve à faire des machins horribles de type tab(i) plutôt que tab[i].
Honnêtement, j'adore le C, je tripatouille l'asm toute la journée, mais les gens ne voient pas à quel point MS a été intelligent avec .Net.
On a C#, certes, mais aussi VB (pour les masochistes), et F# (pour les adeptes de Caml), IronPython, IronRuby (bon OK pour ces derniers, les implémentations restent du domaine de l'expérimental), et tout se retrouve dans une seule et même VM. C'est ça le gros intérêt de .Net. Rien n'empêche ensuite de passer à du JIT (ah ben tiens, la VM le fait déjà), et même de demander une génération directement en binaire si vraiment on en a besoin -- mais souvent les justifications sont fumeuses, car pour continuer à bénéficier de la sûreté des types et autres joyeusetés, on se retrouve à devoir générer les garde-fous qui vont bien et les insérer dans le binaire résultat, et au final on ne va pas spécialement plus vite que VM+compilation JIT.
De plus, là où en embarqué les ressources sont extrêmement rares/limitées (le problème est similaire dans le calcul haute-performance), dans le cas de l'informatique "généraliste", c'est rarement le cas. C'est en faisant entre autres ce constat que des compilateurs très intéressants tels que LLVM sont arrivés, avec un mode "VM-qui-se-spécialise" (et aussi tout le côté "je génère du code pseudo-asm bas-niveau mais avec des références aux CFG/DDG de la représentation intermédiaire) pour ceux qui peuvent attendre, et un mode "compilé-comme-les-grands" pour ceux qui veulent un résultat tout de suite, potentiellement moins bon que s'ils avaient accepté d'avoir une appli un peu plus lente au départ (mais bon, après tout dépend des impératifs).