Bonjour, Je voudrais votre avis sur une question. Vaut il mieux devoir déclarer explicitement qu’une variable est constante (comme en C) ou devoir déclarer explicitement qu’elle est mutable (comme en Rust) ?
Il vaut mieux qu’une variable soit immuable par défaut. Et donc déclarer une variable muable explicitement comme en Rust.
Pour les constantes, c’est toujours bien de le mettre malheureusement peu de langage font la distinction entre constante (à la compilation) et à l’exécution (variable immuable).
Telle que posée, cette question appelle juste les gens à décrire ce qui est fait dans leur langage préféré. Ce qui est totalement subjectif et sujet à la mode et aux avis de personnes pas nécessairement expertes en écriture de shaders, qui sont pourtant probablement ta cible.
À ta place, pour y répondre, je scrapperais le maximum possible de code de shaders que je pourrais trouver, et je regarderais quel est le cas le plus fréquent entre une variable qui reste constante tout le long de sa durée de vie et une variable qui est modifiée pendant sa durée de vie.
Le choix final serait celui qui pousserait à écrire un mot-clef de moins dans le cas le plus fréquemment rencontré.
Cette stratégie sera probablement biaisée par le fait que la plupart des langages de shaders existants ont des variables modifiables par défaut et donc que le style d’écriture avec ces langages s’en accommode. Peut être que ce choix est pertinent pour des shaders, peut être que c’est en fait une mauvaise idée mais qu’on s’en est pas encore rendu compte parce qu’il n’y a pas de langage sur le marché qui rend une approche différente utilisable.
Ce qui est évident, c’est que la mutabilité des variables vient toujours avec son lot de défauts pour raisonner sur le code et en particulier pour le rendre robuste face à la parallélisation (ou autre scénario où l’aliasing peut causer des erreurs de façon extrêmement subtile). D’un autre côté, la mutabilité est essentielle pour les performances lorsqu’on travaille sur de grosses matrices. La question est alors de trouver un modèle mémoire et de mutabilité qui d’une part réduit les risques de se prendre les pieds dans le tapis à cause des effets de bords qui clashent et d’autre part n’affecte pas les perfs. Et là, j’ai envie de dire que c’est pas scrapper les codes existants ni regarder ce que les langages à la mode font qui permettra de répondre de manière tranchée, il faut s’y connaitre à la fois sur les problématique rencontrées dans le monde des shaders et en design de langages.
Cette stratégie sera probablement biaisée par le fait que la plupart des langages de shaders existants ont des variables modifiables par défaut et donc que le style d’écriture avec ces langages s’en accommode
Biaisée en faveur du style de programmation employé par les êtres humains qui seront le plus certainement à même d’utiliser notre travail. Ce qui revient à aller dans leur sens plutôt qu’à les mépriser en leur imposant la façon dont ils devraient penser en exerçant un métier qui nous est étranger.
En l’absence de toute expertise sur le sujet qui me permettrait de me faire un avis et une opinion tranchés, j’assume totalement cette position et j’accueille ce biais à bras ouvert, comme celui qui maximise les chances d’avoir des utilisateurs tout court.
Effectivement je répondai dans le cas général. Pas du tout dans le cas particulier des langages de shader que je ne connais pas du tout.
Salut,
Le C n’est probablement pas un bon exemple de ce côté, parce que le mot clé const et sa sémantique sont assez peu utiles (pour ne pas dire inutile 
). Dans les faits, il est sous utilisé (parce que c’est chiant à employer, honnêtement).
Pour le reste, je dirai que ça dépend de ce que tu veux faire. Le choix de Rust est pertinent au vu du modèle qu’ils ont choisis, mais n’est pas un absolu. Le choix de Rust se base entre autres sur la problématique de la programmation concurrente (c’est plus facile d’avoir des garanties fortes si la plupart des variables sont immutables puisque cela élimine la possibilité qu’une variable soit par exemple modifiée par un thread pendant qu’un autre est en train de lire sa valeur). Maintenant, Go s’en sort aussi très bien sans pour autant avoir fait ce choix (avec un modèle et un contexte différent, on est bien d’accord, mais tout de même).
Il y a aussi la solution qui consiste à toujours déclarer explicitement la mutabilité, que la variable soit mutable ou non. Comme en Kotlin (var/val – oui, les opérateurs ont presque le même nom), en Swift (var/let) ou en JS moderne (let/const – on notera que let est une variable en JS mais une constante en Swift…).
À noter que, selon le langage, ça ne résous pas le problème de la distinction entre « variable immutable » et « constante connue et résolue par le compilateur » – qui sont deux choses très différentes – ni entre – « variable immutable y compris son contenu (variable immutable qui contient une structure immutable) » et « variable immutable au contenu mutable », un autre grand classique des incompréhensions de ce qu’est une variable immutable, et très important pour les performances et les problèmes de parallélisation.
Ça c’est dans le cas générique.
Dans le cas spécifique des langages de shader, c’est un contexte d’exécution avec des contraintes très spécifiques. Donc si le but est d’écrire un langage de shader, il faudrait s’assurer de bien comprendre ces contraintes et ce qu’elles impliquent sur la programmation, tant d’un point de vue technique (je pense aux performances, c’est des domaines où c’est souvent primordial) que d’un point de vue « utilisateur final » – les développeurs qui vont devoir utiliser le langage dans la réalité.
C’est très important (et hélas très compliqué) d’avoir les deux connaissances pour faire un langage efficace et que tu ne sois pas le seul à utiliser ; et honnêtement je ne pense pas que le code existant t’aide beaucoup à ce sujet. Notamment parce que les contraintes des langages existants impactent énormément leur usage. Par exemple en Java, les variables sont mutables par défaut, ce qui conduit à beaucoup de réutilisation non nécessaire de variables, qui sont donc réutilisées (avec une réaffectation dans le code) sans raison valable – pas exemple à cause de croyances sur les optimisations faites par le compilateur ou l’interpréteur.
Un exemple dans la vraie vie : dans les langages qui tournent sur la JVM et compatibles avec des bibliothèques Java, on trouve entre autres Scala et Kotlin. Scala est beaucoup plus « propre » selon la théorie des langages, mais sa lenteur atroce de compilation (partiellement corrigée) et sa syntaxe parfois difficile à lire font qu’il est sensiblement moins utilisé que Kotlin, un langage pensé par des développeurs, pour des développeurs, pour être le plus efficace possible dans leur contexte.
En résumé : sur ce point de détail, c’est pas très important et tu peux t’en sortir en bottant en touche (tout déclarer explicitement). Mais d’une façon générale, pour bien concevoir un langage qui ne soit pas un pur produit de recherche ou de développement, tu vas avoir besoin de beaucoup de connaissances sur l’utilisation souhaitée et sur les contraintes techniques d’exécution.
D’accord, je vais réfléchir plus profondément à ce qu’implique chaque solution (à noter que je compte aussi implémenter des constval pour faire comme les constexpr du c++ avec des variables et des conditions). Merci pour tous vos avis et vos conseils en tout cas 
Je précise un truc qui n’est pas clair dans mon message précédent : si ton but c’est de faire un langage pour apprendre à faire un langage (après tout tu n’a pas donné le contexte de cette question), prends ce qui te parait le mieux ou ce qui te simplifie la vie.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte