Un langage impératif peut prendre des trucs dans le fonctionnel (comme les [ ] de smalltalk) et l'inverse (les do machin des langages fonctionnels stricts).
En fait la classification des langages est en général assez "molle", c'est plutôt une calssification par traits de caractère qui serait plus rigoureuse.
Quand à un rapprochement fonctionnel/impératif, tout le monde pique des trucs chez tout le monde.
Je maîtrise pas le Lisp donc je répondrait pas avec certitude sur la notion de typage fainéant (qui est une excellente traduction de lazy). Je pense qu'il s'agit du fait que les types ne sont vérifiés que si c'est nécessaire (donc à l'exécution). En lien avec le typage dynamique (c'est la même chose ?)
Lisp effectivement a la capacité de modifier lui-même son code source, ça veut dire que le compilateur est embarqué (donc c'est mieux d'avoir une grammaire simple) et que la machine virtuelle est capable d'intégrer du code nouveau (ou de modifier l'existant) en cours de route. Ceci permet de modifier le compilateur afin de lui faire comprendre des nouvelle choses, on peut le faire n'importe comment mais il existe un système qui permet de juste lui faire comprendre de nouveaux mots et de les traduire en Lisp (comme une macro en C mais version propre). C'est (il parraît) très puissant. Ceci influe aussi beaucoup (positivement) sur la correction des bugs, l'analyse du programme, et le cycle de développement en général.
Objective Caml n'embarque pas le compilateur mais l'extention de la syntaxe se fait par l'extérieur (camlP4). Hormis un truc douteux (dont je n'ai jamais entenu parler : recharger une bibliothèque partagée après l'avoir recompliée) on ne peut pas modifier du code compilé à la volée. Donc tout le débogage se fait depuis l'extérieur.
Ceci n'enlève rien à l'expressivité du langage, toute la puissance est là.
D'autre part, le typage fort statique permet d'améliorer la qualité du logiciel (il diminue les erreur connes), d'améliorer la vitesse (beaucoup plus de contexte est connu à l'avance) et aussi d'améliorer la lisibilité (par l'aspect annotation de la chose). Le compilateur sait lui-même (en général, sinon y'a un '_a qui va se trimbaler) reconnaitre les types des objets.
Caml parraît aussi moins repoussant par l'abscence d'arrêtes de poisson et une syntaxe plus conventionelle (il a pas à se trimballer le compilo en mémoire, donc on hésite pas sur les fioritures et le maquillage (list, array, lazy, etc.) :-).
Un aspect passionel est sous-jacent aussi.
Pour les outils graphiques, y'a mlglade et un truc en TK aussi mais c'est pas le point fort de ces langages. Peut-être un manque de recherche ? Quelqu'un connais des patterns fonctionnels pour les UI ?
Concernant l'INRIA, c'est le CNRS donc concours du CNRS.
[^] # Re: Quelques questions
Posté par Dugland Bob . En réponse à la dépêche Common LISP, un langage à (re)découvrir. Évalué à 3.
En fait la classification des langages est en général assez "molle", c'est plutôt une calssification par traits de caractère qui serait plus rigoureuse.
Quand à un rapprochement fonctionnel/impératif, tout le monde pique des trucs chez tout le monde.
Je maîtrise pas le Lisp donc je répondrait pas avec certitude sur la notion de typage fainéant (qui est une excellente traduction de lazy). Je pense qu'il s'agit du fait que les types ne sont vérifiés que si c'est nécessaire (donc à l'exécution). En lien avec le typage dynamique (c'est la même chose ?)
Lisp effectivement a la capacité de modifier lui-même son code source, ça veut dire que le compilateur est embarqué (donc c'est mieux d'avoir une grammaire simple) et que la machine virtuelle est capable d'intégrer du code nouveau (ou de modifier l'existant) en cours de route. Ceci permet de modifier le compilateur afin de lui faire comprendre des nouvelle choses, on peut le faire n'importe comment mais il existe un système qui permet de juste lui faire comprendre de nouveaux mots et de les traduire en Lisp (comme une macro en C mais version propre). C'est (il parraît) très puissant. Ceci influe aussi beaucoup (positivement) sur la correction des bugs, l'analyse du programme, et le cycle de développement en général.
Objective Caml n'embarque pas le compilateur mais l'extention de la syntaxe se fait par l'extérieur (camlP4). Hormis un truc douteux (dont je n'ai jamais entenu parler : recharger une bibliothèque partagée après l'avoir recompliée) on ne peut pas modifier du code compilé à la volée. Donc tout le débogage se fait depuis l'extérieur.
Ceci n'enlève rien à l'expressivité du langage, toute la puissance est là.
D'autre part, le typage fort statique permet d'améliorer la qualité du logiciel (il diminue les erreur connes), d'améliorer la vitesse (beaucoup plus de contexte est connu à l'avance) et aussi d'améliorer la lisibilité (par l'aspect annotation de la chose). Le compilateur sait lui-même (en général, sinon y'a un '_a qui va se trimbaler) reconnaitre les types des objets.
Caml parraît aussi moins repoussant par l'abscence d'arrêtes de poisson et une syntaxe plus conventionelle (il a pas à se trimballer le compilo en mémoire, donc on hésite pas sur les fioritures et le maquillage (list, array, lazy, etc.) :-).
Un aspect passionel est sous-jacent aussi.
Pour les outils graphiques, y'a mlglade et un truc en TK aussi mais c'est pas le point fort de ces langages. Peut-être un manque de recherche ? Quelqu'un connais des patterns fonctionnels pour les UI ?
Concernant l'INRIA, c'est le CNRS donc concours du CNRS.