Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.
Je ... hein ? Un compilateur fait bien plus que ce que tu sembles croire.
La vérification des types, et la garantie de leur sûreté fait partie du rôle du compilateur... Quand la norme/le standard/la spécification du langage le permet. Par exemple en C, faire une vérification de type fiable est difficile, car le langage est faiblement typé. En Java, du moment qu'on exclut les types primitifs (donc pour tout le reste qui nous intéresse déjà beaucoup plus, à savoir les objets), il y a du lambda calcul un peu partout, avec une garantie de « type safety ».
Un compilateur sert aussi de « prouveur » -- même si le plus souvent les preuves ne sont que « partielles ». Je veux dire par là que le compilateur, en démontrant que des bouts de ton programme satisfont certaines propriétés -- par exemple, si tu fais une boucle dont l'en-tête est
M = 1000;
... // pas de réécriture de M
N = M
for (i = 0; i < N; ++i)
le compilateur devrait être capable d'inférer la borne de la boucle for, et du coup de déterminer certaines propriétés liées à ladite boucle. Bref, le compilateur est aussi là pour garantir certaines propriétés au programmeur concernant son programme. Après, la somme des propriétés dépend des objectifs du langage.
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.
Ben non. Plus tu peux déterminer de « fautes » en amont (je mets entre guillemets, parce que parfois soit on fait un truc « crade » mais qui va vite, soit on perd 10 à 20% de perfs, ou plus), et moins ton code risquera d'avoir de bugs. Plus exactement, en C, il est facile de compiler un code, « sans erreur », et que celui-ci plante, ou pire, donne un résultat inexact. En Java, ou encore « pire », en OCaml, certains types d'erreur (comme celles dues au transtypage, ou aux types en règle générale) sont totalement évitées car détectées à la compilation. Je ne vois pas ce que tu peux reprocher à ce comportement. Et oui, c'est clairement le rôle du compilateur de faire tout ça, car de son point de vue (et des specs du langage), il s'agit bien d'une erreur du programmeur.
Concernant l'inutilité de l'étape de compilation, je serais d'accord avec toi si les compilateurs étaient de bêtes traducteurs « code source » => « code machine », mais c'est très loin d'être le cas. Il y a bien sûr la partie front-end qui fait les analyses lexicales et grammaticales (et si je ne me trompe pas, une partie des analyses sur les types se fait à ce moment), mais juste après il y aussi le middle-end qui se charge de transformer le code pour l'optimiser, puis le back-end qui génère le code. Sans parler du fait que middle-end et back-end ont besoin de communiquer pour générer efficacement du code, etc.
Au final, un bytecode (bien) compilé, avec en plus du JIT pour les parties « chaudes » du programme peut permettre de gros gains de perfs au lancement de l'application.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 5.
Je ... hein ? Un compilateur fait bien plus que ce que tu sembles croire.
La vérification des types, et la garantie de leur sûreté fait partie du rôle du compilateur... Quand la norme/le standard/la spécification du langage le permet. Par exemple en C, faire une vérification de type fiable est difficile, car le langage est faiblement typé. En Java, du moment qu'on exclut les types primitifs (donc pour tout le reste qui nous intéresse déjà beaucoup plus, à savoir les objets), il y a du lambda calcul un peu partout, avec une garantie de « type safety ».
Un compilateur sert aussi de « prouveur » -- même si le plus souvent les preuves ne sont que « partielles ». Je veux dire par là que le compilateur, en démontrant que des bouts de ton programme satisfont certaines propriétés -- par exemple, si tu fais une boucle dont l'en-tête est
M = 1000;
... // pas de réécriture de M
N = M
for (i = 0; i < N; ++i)
le compilateur devrait être capable d'inférer la borne de la boucle for, et du coup de déterminer certaines propriétés liées à ladite boucle. Bref, le compilateur est aussi là pour garantir certaines propriétés au programmeur concernant son programme. Après, la somme des propriétés dépend des objectifs du langage.
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.
Ben non. Plus tu peux déterminer de « fautes » en amont (je mets entre guillemets, parce que parfois soit on fait un truc « crade » mais qui va vite, soit on perd 10 à 20% de perfs, ou plus), et moins ton code risquera d'avoir de bugs. Plus exactement, en C, il est facile de compiler un code, « sans erreur », et que celui-ci plante, ou pire, donne un résultat inexact. En Java, ou encore « pire », en OCaml, certains types d'erreur (comme celles dues au transtypage, ou aux types en règle générale) sont totalement évitées car détectées à la compilation. Je ne vois pas ce que tu peux reprocher à ce comportement. Et oui, c'est clairement le rôle du compilateur de faire tout ça, car de son point de vue (et des specs du langage), il s'agit bien d'une erreur du programmeur.
Concernant l'inutilité de l'étape de compilation, je serais d'accord avec toi si les compilateurs étaient de bêtes traducteurs « code source » => « code machine », mais c'est très loin d'être le cas. Il y a bien sûr la partie front-end qui fait les analyses lexicales et grammaticales (et si je ne me trompe pas, une partie des analyses sur les types se fait à ce moment), mais juste après il y aussi le middle-end qui se charge de transformer le code pour l'optimiser, puis le back-end qui génère le code. Sans parler du fait que middle-end et back-end ont besoin de communiquer pour générer efficacement du code, etc.
Au final, un bytecode (bien) compilé, avec en plus du JIT pour les parties « chaudes » du programme peut permettre de gros gains de perfs au lancement de l'application.