Concernant l'intérêt des interpréteurs, je n'ai rien n'a ajouter de plus de ce que dit Backus dans son papier The IBM Speedcoding system (Journal of the ACM, Volume 1, Issue 1, Janv 1954, pp. 4-6). Leur intérêt est évident. Et ils existent depuis plus longtemps que le premier langage de programmation jamais commercialisé par la même équipe du susdit.
Cependant, malgré leur indéniable (et irremplaçable) utilité, les interpréteurs ont leurs limites. Car si une fonction est codable en soft, elle est tout aussi parfaitement codable en hard dans un CPU. Et là, la question des performances se pose. L'équipe qui a créé Speedcoding est la même qui a créé peu après Fortran : la technologie ayant permis de coder en dur une unité de calcul sur les flottants, il n'y avait plus de raison de continuer avec un interpréteur. Pour ceux qui ont connu les premiers PC d'avant les Pentium, ils étaient livrés avec un coprocesseur optionnel. Ceux qui n'avaient pas les sous choisissaient le modèle sans qui faisait tout aussi bien mais plus lentement car passant par un émulateur.
Pour donner un exemple vécu et que j'ai développé sur ce site au travers plusieurs journaux : le cas d'un générateur de pages HTML pour un blog statique. Il en existe une multitude mais presque tous codés sous interpréteur. Quand on arrive à une certain nombre de billets de blog, le logiciel rame. La seule issue est de coder en natif. Donc, à un moment, il faut bien mettre les mains dans le cambouis. L'alternative existe : vous prenez WordPress, vous installez une base de donnée qu'il vous faudra maintenir, vous mettez PHP qu'il faudra bien mettre à jour de temps à autre et vous croisez les doigts pour que vous ne fassiez pas pirater. Personnellement, je me suis mis au Fortran pour la seule nécessité de développer un moteur de blog statique. Il est capable de générer une centaine de pages HTML là où WordPress en génère une seule pour le même laps de temps. Et mon moteur de blog n'est pas hackable car il ne réside pas sur le site Web. Et je n'ai pas besoin d'ingurgiter une dose massive de SQL et PHP pour savoir comment marche le bousin. Tout ça par la seule grâce d'un langage compilé. Mais j'aurais pu tout aussi bien opter pour ADA car mon passé en Basic me permettait un auto apprentissage des langages "verbeux". Je précise qu'à l'époque je ne connaissais pas de compilo Basic sous Linux et que je ne voulais plus entendre parler de Windows ni utiliser de Basic en mode interpréteur. Sur ce dernier point, j'ai été échaudé par le fait que l'interpréteur rattrapant assez facilement des erreurs d'écriture logicielle, et même fournissant des avertissements (cas du QBasic de MS) là où un compilo natif refuserait d'aller plus loin, on n'est pas assez rigoureux dans son codage. En natif, les erreurs détectées sont implacables ! Même si on ne les voit pas toutes de prime abord.
À bon escient, les interpréteurs ont leur utilité. Là où il y a une dérive, c'est quand une organisation humaine (typiquement une université ou un industriel du logiciel) fait la promotion d'une nouvelle-machine-virtuelle-qui-va-bouleverser-la-planète c'est qu'elle entraîne dans ses filets une multitude de gens qui deviennent comme les adeptes d'une nouvelle religion. Le nombre de ces miroirs aux alouettes brisés ou encore scintillants est inouï.
Concernant la distinction entre développement et programmation, elle me semble évidente ! Dans un cas on assemble des composants logiciels écrits par d'autres, dans l'autre on tape avec ses petits doigts sur le clavier pour fabriquer un par un lesdits composants. C'est la même différence qu'entre ouvrir une boite de conserve de petits pois et les réchauffer en 3 minutes ou les prendre à l'état cru, les écosser et attendre 3/4 d'heure que ça cuise. Au quotidien, j'opte pour la conserve. Mais je sais aussi le faire à l'ancienne ! Et je sais même aussi les faire pousser !
Selon quels critères qualifies-tu un langage d'impasse
Il est vrai que les langages interprétés sont au moins aussi fiables que ceux compilés. Mais, en "mode parano", leur avenir est suspendu au bon vouloir de soit un très petit comité (pas toujours ouvert sur la communauté), soit d'un industriel qui peut mettre la clé sous la porte du jour au lendemain. Et le miroir aux alouettes est alors brisé.
Dans le cas d'un langage compilé le risque est mieux réparti. D'une part parce que tant que le CPU et la plateforme continue d'exister, la maintenance est possible même si son fournisseur disparaît. Et dans la mesure où il normalisé, il devient légal de créer un compilateur substitutif. Si une machine virtuelle, breveté ou sous licence, a une faille de sécu et qu'elle n'est plus maintenue c'est la mort du petit cheval.
C'est, pour moi une première impasse. La seconde concerne la création de nouveaux composants logiciel en assemblant des composants de base. j'ai évoqué le cas du processeur de texte LaTeX où l'on l'empilement de macros peut produire des effets indésirables. Ah, j'aimerai avoir une connaissance a minima du JavaScript pour donner d'autres exemples illustrant les inconvénients de la stratification logicielle...
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 1.
Concernant l'intérêt des interpréteurs, je n'ai rien n'a ajouter de plus de ce que dit Backus dans son papier The IBM Speedcoding system (Journal of the ACM, Volume 1, Issue 1, Janv 1954, pp. 4-6). Leur intérêt est évident. Et ils existent depuis plus longtemps que le premier langage de programmation jamais commercialisé par la même équipe du susdit.
Cependant, malgré leur indéniable (et irremplaçable) utilité, les interpréteurs ont leurs limites. Car si une fonction est codable en soft, elle est tout aussi parfaitement codable en hard dans un CPU. Et là, la question des performances se pose. L'équipe qui a créé Speedcoding est la même qui a créé peu après Fortran : la technologie ayant permis de coder en dur une unité de calcul sur les flottants, il n'y avait plus de raison de continuer avec un interpréteur. Pour ceux qui ont connu les premiers PC d'avant les Pentium, ils étaient livrés avec un coprocesseur optionnel. Ceux qui n'avaient pas les sous choisissaient le modèle sans qui faisait tout aussi bien mais plus lentement car passant par un émulateur.
Pour donner un exemple vécu et que j'ai développé sur ce site au travers plusieurs journaux : le cas d'un générateur de pages HTML pour un blog statique. Il en existe une multitude mais presque tous codés sous interpréteur. Quand on arrive à une certain nombre de billets de blog, le logiciel rame. La seule issue est de coder en natif. Donc, à un moment, il faut bien mettre les mains dans le cambouis. L'alternative existe : vous prenez WordPress, vous installez une base de donnée qu'il vous faudra maintenir, vous mettez PHP qu'il faudra bien mettre à jour de temps à autre et vous croisez les doigts pour que vous ne fassiez pas pirater. Personnellement, je me suis mis au Fortran pour la seule nécessité de développer un moteur de blog statique. Il est capable de générer une centaine de pages HTML là où WordPress en génère une seule pour le même laps de temps. Et mon moteur de blog n'est pas hackable car il ne réside pas sur le site Web. Et je n'ai pas besoin d'ingurgiter une dose massive de SQL et PHP pour savoir comment marche le bousin. Tout ça par la seule grâce d'un langage compilé. Mais j'aurais pu tout aussi bien opter pour ADA car mon passé en Basic me permettait un auto apprentissage des langages "verbeux". Je précise qu'à l'époque je ne connaissais pas de compilo Basic sous Linux et que je ne voulais plus entendre parler de Windows ni utiliser de Basic en mode interpréteur. Sur ce dernier point, j'ai été échaudé par le fait que l'interpréteur rattrapant assez facilement des erreurs d'écriture logicielle, et même fournissant des avertissements (cas du QBasic de MS) là où un compilo natif refuserait d'aller plus loin, on n'est pas assez rigoureux dans son codage. En natif, les erreurs détectées sont implacables ! Même si on ne les voit pas toutes de prime abord.
À bon escient, les interpréteurs ont leur utilité. Là où il y a une dérive, c'est quand une organisation humaine (typiquement une université ou un industriel du logiciel) fait la promotion d'une nouvelle-machine-virtuelle-qui-va-bouleverser-la-planète c'est qu'elle entraîne dans ses filets une multitude de gens qui deviennent comme les adeptes d'une nouvelle religion. Le nombre de ces miroirs aux alouettes brisés ou encore scintillants est inouï.
Concernant la distinction entre développement et programmation, elle me semble évidente ! Dans un cas on assemble des composants logiciels écrits par d'autres, dans l'autre on tape avec ses petits doigts sur le clavier pour fabriquer un par un lesdits composants. C'est la même différence qu'entre ouvrir une boite de conserve de petits pois et les réchauffer en 3 minutes ou les prendre à l'état cru, les écosser et attendre 3/4 d'heure que ça cuise. Au quotidien, j'opte pour la conserve. Mais je sais aussi le faire à l'ancienne ! Et je sais même aussi les faire pousser !
Il est vrai que les langages interprétés sont au moins aussi fiables que ceux compilés. Mais, en "mode parano", leur avenir est suspendu au bon vouloir de soit un très petit comité (pas toujours ouvert sur la communauté), soit d'un industriel qui peut mettre la clé sous la porte du jour au lendemain. Et le miroir aux alouettes est alors brisé.
Dans le cas d'un langage compilé le risque est mieux réparti. D'une part parce que tant que le CPU et la plateforme continue d'exister, la maintenance est possible même si son fournisseur disparaît. Et dans la mesure où il normalisé, il devient légal de créer un compilateur substitutif. Si une machine virtuelle, breveté ou sous licence, a une faille de sécu et qu'elle n'est plus maintenue c'est la mort du petit cheval.
C'est, pour moi une première impasse. La seconde concerne la création de nouveaux composants logiciel en assemblant des composants de base. j'ai évoqué le cas du processeur de texte LaTeX où l'on l'empilement de macros peut produire des effets indésirables. Ah, j'aimerai avoir une connaissance a minima du JavaScript pour donner d'autres exemples illustrant les inconvénients de la stratification logicielle...