Quelques remarques générales
Bonjour à tous,
Je me permets de me joindre à la discussion et espère pouvoir contribuer dans la maigre mesure de mes moyens.
Je partage le diagnostic du bon docteur Genolini sur les limites du langage R et, surtout, de son environnement. Mais, avant de me lancer sur le forum, j'aimerai faire une remarque d'ordre général sur l(a|es) finalité(s) du projet. En effet, l'ampleur du chantier implique, me semble-t-il, d'établir quelques principes liminaires permettant de définir la direction prise par les travaux. Ce n'est sans doute pas très "agile" dirons certains mais nécessaire pour arriver à des prises de décisions collectives qui impacteront tous les aspects du projet et qu'il sera difficile (voir impossible) de changer par la suite.
Je pense qu'il est par exemple nécessaire de clairement définir ce qui doit être changé et ce qui doit rester intangible par rapport à R.
De mon point de vue, les changements sont de différents ordres : l'environnement, l’implémentation et le langage proprement dit.
- l'environnement : comme cela a déjà été remarqué, absence d'un support natif du parallélisme, traitement de gros volumes de données, prévalence d'une sémantique du passage de valeurs...
- l'implémentation : absence d'homogénéité des signatures de fonction, casts inappropriés (comme celui des matrices en vecteur),...
- le langage : OO ajouté après la conception du langage avec deux systèmes différents devant cohabiter, scope (portée) des variables...
Note : Les différents niveaux sont bien évidemment liés. Ainsi, l'intégration du parallélisme implicite et explicite influera sur la conception du langage (et donc sa grammaire). De même, la copie quasi systématique des arguments est liée à la dimension fonctionnelle du langage.
Si le langage apparaît en dernier dans la liste, c'est que j'estime que les changements à apporter découlent plus de l'environnement que du langage en lui-même. Plus généralement, il me semble que les changements du langage devraient être réduits au strict nécessaire (ce qui n'exclue pas qu'ils puissent être conséquents) et déterminés par des principes explicites comme le parallélisme ou la robustesse des programmes.
Rester le plus proche possible de R me semble nécessaire pour favoriser l'adoption. De plus, nul besoin de casser ce qui fonctionne.
De nombreuses propositions intéressantes de modifications me semblent être ressorties des échanges. En vrac et de façon non exhaustive :
- le typage des données : limitation des ambiguïtés et des interprétations à l’exécution, robustesse
- l'inférence de type lorsqu'il n'y a pas d'ambiguïtés (cf. 1 == integer, 1.0? == double, "1" == string) : pas besoin d'être verbeux lorsque ce n'est pas nécessaire
- la refonte du modèle OO : modèle plus "intuitif" (càd ne pas chercher à se distinguer à tout prix des implémentations les plus rependues -ie : c++, java) et possibilité d'introduire d'autres aspects de la programmation OO comme la définition de contrats et de tests pour valider les opérations sur les objets
- l'utilisation de références : efficacité (mais problématique dans un environnement parralèle)
- la compilation avant l'éxecution (par une VM ?) : efficacité
- les commentaires multiligne (yes!) : commodité
Par contre, de façon plus marginale, différentes propositions ne me semblent pas nécessaires :
- la substitution de '{}' dans les expressions <op>(<arg>){<body>}' par des mots ('do'-'endfor'...)
- faire commencer les types par une majuscule et les variables par des minuscules.
Voici donc la proposition que je soumets à la discussion.
Avant de vraiment de se lancer dans le dur, il serait nécessaire de procéder à une analyse approfondie de R et de son implémentation pour en caractériser les différents aspects et définir ce qui doit être maintenu, modifié ou supprimé afin de définir des orientations dans les différents chantiers. Cette phase permettrait de capitaliser près de vingt années de développements.
Bien évidemment, cela n'est en rien contradictoire avec la réflexion et les propositions quant aux atours du nouveau langage.
Ce travail devrait de plus être mené en parallèle (!) avec les discussions sur les entrailles du futur système. J'ai une petite expérience de la programmation multicœur (principalement avec pthreads et un peu fork()) et ce qui apparaît dans la littérature est juste : il s'agit d'un véritable changement paradigmatique impliquant de réviser complètement son approche de la programmation. Il me semble d'ailleurs que c'est le chantier le plus important dont beaucoup de choses dépendent directement comme la VM ou la manipulation de gros volumes de données (dont l'efficacité est directement liée à l'utilisation de méthodes parallélisées) mais aussi certains aspects de la grammaire du langage.
Bon, je m'arrêtes là.
Dites-moi quoi !
Bonne journée,
Thomas
