Posté par anaseto .
En réponse au journal Plonk.
Évalué à 2.
Tu as du loupé le jour où ils ont réinventé les macros.
Oui, ils utilisent parfois (pas si souvent) la génération de code, comme une version limitée de macros, de la même façon que des choses comme yacc l'ont fait depuis longtemps pour des cas spécifiques, et sont utilisés aussi de cette même façon externe dans d'autres langages, même parfois s'ils ont des macros. Ceci dit, la méthode de go ne vise même pas à réimplémenter le préprocesseur C, car c'est plus externe : à la fin, les fichiers sont tous des fichiers pur go sans macros, ce qui a l'avantage de ne pas compliquer l'analyse par analyse statique, en particulier utile pour les éditeurs. Ces « macros » ne font pas partie du langage : il se trouve juste que, pour faciliter l'utilisation, des annotations dans les commentaires sont reconnues par des programmes externes (mais ça reste des commentaires, contrairement au C, où le fichier qu'on édite n'est pas en soit une version « finale »). Et je ne dis pas qu'une méthode ou l'autre est meilleure, juste que les propriétés qui en découlent sont différentes.
Après, si tu écris un programme où tu sens que tu vas passer ton temps à faire de la génération de code, go n'est évidemment pas le langage à utiliser. Mais avec juste la syntaxe et fonctionnalités de base d'un langage, on peut en général s'en sortir très bien pour les domaine de prédilection du langage. Il faut juste accepter que, parfois, il faut utiliser un autre langage (quand je veux faire un script, je fais du Perl, quand je veux des perfs et typage statique, mais rien de trop compliqué, j'utilise go, quand je veux manipuler un AST, je fais du OCaml, etc.).
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.—Greenspun's tenth rule of programming
On peut à notre époque remplacer C et fortran par bien des langages.
Je connais la citation, et je suis en partie d'accord avec. Je trouve juste que c'est pas toujours si simple et que plein de critères entrent en compte, et les compilateurs Common Lisp ne sont pas exempts de défauts : par exemple avec sbcl, produire une image exécutable est lent et donne un gros binaire énorme ; du moins quand j'avais essayé, c'est l'impression que j'en avais eu. Analyser statiquement du code Common Lisp semble pas évident non plus. En pratique, la seule façon de démêler des macros est, que je sache, d'utiliser l'interpréteur, ce qui limite la création de programmes qui traitent du code Common Lisp.
[^] # Re: Fonction
Posté par anaseto . En réponse au journal Plonk. Évalué à 2.
Oui, ils utilisent parfois (pas si souvent) la génération de code, comme une version limitée de macros, de la même façon que des choses comme yacc l'ont fait depuis longtemps pour des cas spécifiques, et sont utilisés aussi de cette même façon externe dans d'autres langages, même parfois s'ils ont des macros. Ceci dit, la méthode de go ne vise même pas à réimplémenter le préprocesseur C, car c'est plus externe : à la fin, les fichiers sont tous des fichiers pur go sans macros, ce qui a l'avantage de ne pas compliquer l'analyse par analyse statique, en particulier utile pour les éditeurs. Ces « macros » ne font pas partie du langage : il se trouve juste que, pour faciliter l'utilisation, des annotations dans les commentaires sont reconnues par des programmes externes (mais ça reste des commentaires, contrairement au C, où le fichier qu'on édite n'est pas en soit une version « finale »). Et je ne dis pas qu'une méthode ou l'autre est meilleure, juste que les propriétés qui en découlent sont différentes.
Après, si tu écris un programme où tu sens que tu vas passer ton temps à faire de la génération de code, go n'est évidemment pas le langage à utiliser. Mais avec juste la syntaxe et fonctionnalités de base d'un langage, on peut en général s'en sortir très bien pour les domaine de prédilection du langage. Il faut juste accepter que, parfois, il faut utiliser un autre langage (quand je veux faire un script, je fais du Perl, quand je veux des perfs et typage statique, mais rien de trop compliqué, j'utilise go, quand je veux manipuler un AST, je fais du OCaml, etc.).
Je connais la citation, et je suis en partie d'accord avec. Je trouve juste que c'est pas toujours si simple et que plein de critères entrent en compte, et les compilateurs Common Lisp ne sont pas exempts de défauts : par exemple avec sbcl, produire une image exécutable est lent et donne un gros binaire énorme ; du moins quand j'avais essayé, c'est l'impression que j'en avais eu. Analyser statiquement du code Common Lisp semble pas évident non plus. En pratique, la seule façon de démêler des macros est, que je sache, d'utiliser l'interpréteur, ce qui limite la création de programmes qui traitent du code Common Lisp.