Outils pour utilisateurs

Outils du site


langages_dynamiques

Les langages dynamiques sont des langages qui offrent au runtime des possibilités qui sont dans d'autres langages gérées lors de la compilation. Il est difficile de définir avec précision ce type de langage, toutefois on peut observer plusieurs langages existants et tenter d'en tirer une compréhension. Ici seront considérés des langages comme python, lua ou ruby.

Soulignons d'abord la possibilité offerte nativement par ces langages de modifier le code (fonctions, classes, ajout de variables dans des objets existants, etc.) pendant l'exécution, ce qui permet une grande souplesse. Cela les rend interactifs et permet par exemple non seulement de débugger facilement, mais aussi de patcher et modifier le comportement de, mettons, un serveur permanent, en live et sans downtime ni déploiement. Globalement, le temps d'obtention de feedback, le temps de compilation, le temps de déploiement, tout peut être ainsi réduit à 0.

Il est notamment aisé d'ajouter de nouvelles variables à l'intérieur de classes existantes juste en écrivant leur nom, sans autre forme de perte de temps, gardant ainsi un style précis, plus court que la majorité des autres langages. Cela entraine au passage que les vérifications de noms ne se font pas préalablement au runtime, mais bien entendu, ce n'est guère important dans l'esprit des langages dynamiques, puisque le but primaire est de gagner en expressivité, en puissance et en concision. Pourtant, croire que les vérifications de code statique puissent être exhaustives reste une illusion répandue, et combien de projets auraient pu mettre à profit le temps de développement passé à expliquer la vie au compilateur en l'affectant plutôt à (par exemple) de solides batteries de tests.

Ces langages dynamiques doivent finalement être considérés plus comme des structures runtime dans laquelle le code évolue autant et aussi naturellement qu'il évoluerait, dans des langages/environnements différents, à la compilation lors d'une phase d'écriture séparée (on séparerait ainsi arbitrairement le développement de l'exécution, un peu comme certains séparent l'écriture des specs de l'écoute des besoins client).

Pour ce qui est des performances, les optimiseurs dynamiques (comme psyco pour python) font des merveilles toujours en progrès, et permettent d'obtenir les performances nécessaires quand il le faut. Après tout, la règle numéro 1 des performances est de ne pas optimiser prématurément ; pourquoi pas donc au runtime, quand on connait le mieux les informations non plus prévues mais réelles sur l'exécution.

Considérons à présent une feature dont on entend peu parler et qui est assez peu utilisée hors des langages qui en ont besoin : la récursion terminale. Comme dans la majorité des langages (sauf les langages fonctionnels, qui utilisent la récursion pour faire tout et n'importe quoi), les langages dynamiques dont il est question ici utilisent une implémentation avec une stack pour gérer la pile d'appel. Toutefois, comme les cas d'utilisation de la récursion sont marginaux et ont des profondeurs maitrisées (jamais de récursion infinie par exemple), toute considération d'optimisations importantes dans les langages fonctionnels sont ici complètement hors-sujet.

Enfin, certains langages, comme Lua en particulier, ont des objectifs de performance poussés, et ceci par design, tout simplement parce qu'ils sont conçus pour être utilisés dans certains environnement particuliers (scripting embarqué dans des jeux vidéos). Ces contraintes expliquent souvent pourquoi certaines considérations habituelles des langages plus généralistes ont pu être ignorées car inappropriées. Qui se soucierait d'avoir des types constants, du vrai objet, ou d'autres fonctionnalités avancées alors que l'objectif est une simple représentation souvent déclarative et souple d'informations au runtime.

Il est évident que, pour tout langage A et langage préféré B, A n'a pas les 'avantages' de B, puisque l'intérêt principal d'avoir plusieurs langages réside dans la possibilité d'aborder des problèmes très différents avec des approches distinctes et plus ou moins adaptées. En conclusion, il est conseillé d'arrêter d'enfoncer des clous avec des tournevis et de tenter d'utiliser chaque outil un peu plus dans l'optique dans laquelle il a été conçu, sans toujours critiquer chaque point. :)

langages_dynamiques.txt · Dernière modification: 2013/05/06 14:18 (modification externe)