Il y a plus de deux ans sortait The Witness sur PC et PS4. Plus tard le jeu est sorti sur XO, iOS, macOS et Nvidia Shield. Entre deux portages, Jonathan Blow bossait à mi-temps sur un nouveau langage de programmation, Jai. Il bosse désormais dessus à plein temps et compte même l'utiliser pour son prochain jeu. Il a expliqué sa démarche à Games Industry.

La raison pour laquelle Jonathan bosse sur Jai s'appelle C++. Le langage objet est un standard dans l'industrie du JV quand il s'agit de créer des moteurs de jeu, mais selon le créateur de Braid, c'est une vraie horreur. A la base, le C++ a été créé comme une extension du C mais n'a pas forcément été bien conçu. Puis au fur et à mesure des années ses créateurs ont tenté de réparer les dégats. Depuis 2011, une nouvelle version du C++ sort tous les trois ans. Du coup le C++ est devenu un joyeux bordel aussI bien à apprendre qu`à programmer.

Le but de Jai est de faciliter la vie des développeurs et d'augmenter la productivité. Blow mise sur un boost de 15% au début mais pense atteindre 50 à 80% de boost de productivité comparé à un jeu développé en C++. Une beta fermée du langage sera dispo à la fin de l'année. Pour ceux qui se posent la question : oui c'est compliqué d'écrire un langage mis à part si on le fait pour la déconne. Non seulement il faut créer le langage en lui-même mais aussi le compilateur. Au passage, le compilateur d'un langage est écrit dans le langage qu'il compile. Voilà qui devrait faire tourner les têtes des philosophes/théologistes/physiciens en herbe.

Comme le C++, Jai est fondé sur le C et sera interopérable avec ce dernier. La raison est simple : la majorité des SDKs modernes ont une API écrite en C y compris les API graphiques type OpenGL et Vulkan. En clair, on pourra coder en Jai tout en utilisant les mêmes outils. C'est assez logique : on voit mal le Khronos Group réécrire l'API de Vulkan en Jai rien que pour le plaisir du créateur de The Witness.

Lire la suite sur le site : Jai & Silent Blow Strike Back.

Modern C++, un joyeux bordel, oui et non. Il y a quand même pas mal de nouveautés qui simplifient grandement le code et/ou le rendent plus sûr (auto, range-based for loops, unique_ptr, <algorithm>, les lambda expressions, bon ok avis perso et orienté pour cette dernière ^^).

La force de Modern C++ c'est que tous ces apports restent optionnels au final (après tout Dice, et probablement pas mal de grosses boîtes, code encore en C++98). C'est aussi sa faiblesse c'est vrai puisqu'il faut se mettre à jour tous les 3 ans si on ne veut pas être - potentiellement - dépassé (tout dépend de la boîte au final).

Sinon, c'est intéressant ce qu'il dit sur l'esthétique d'un langage, bon forcément après quand tu mates le github, et qu'il nous a tout mis à l'envers... mouais... bonne chance à lui quand même.

(C'est son avis le coup du joyeux bordel)

J'avoue que le nom avant le type j'ai du mal. J'imagine qu'on s'y fait avec le temps mais après 45+ ans de C, l'industrie va avoir du mal à s'y faire.

Au fond on n'a pas besoin d'un nouveau langage. Blow est un iconoclaste qui aime prouver qu'il est le plus malin. Il rejette en bloc les alternatives à C++ (Go, Rust, Swift...) mais ses arguments sont assez subjectifs.

"Automatic memory management is a non-starter for game programmers who need direct control over their memory layouts. Any interpreted language will be too slow. Functional-only languages are pointlessly restricting. Object-oriented-only languages are overly complex."

Il se contradit aussi lui-même. Si tu veux être productif et t'amuser en programmant, les deux derniers trucs que tu veux faire sont micro-gérer la mémoire et compiler..

Pendant ce temps chez Unity.

Je comprend moi aussi assez mal ses arguments contre le c++.
Parfois tu as besoin de gérer la mémoire toi même, mais c'est finallement la beauté du C++ : T'as pas besoin de l'utiliser 100% du temps, tu peux utiliser du C si besoin.
Je prend c++ comme une série d'extensions au c++, et je picore dans ce qui m'arrange selon le projet.

Le C++ est un langage complètement bidon, c'est juste qu'on n'a pas le choix. Beaucoup de gens confondent aussi la flexibilité avec lisibilité/ergonomie.
Blow ne veut pas un langage moins flexible, au contraire il propose un langage beaucoup plus flexible que le C++. Il a même pointé, à raison, le manque d'ambition des gens du standard (par exemple sur le manque de généralisation des lambdas, mais sur plein d'autres sujets aussi).

Le C++ est un langage vraiment pété, le simple fait d'avoir à attendre une heure pour compiler est absurde (et pas la peine de dire modulaire, incrémental, gnagna. Quand on bosse dans une grosse structure, ça bloque complètement la possibilité d'itérer vite).

Ces propositions sont aussi très ingénieuses, viennent naturellement. Par exemple beaucoup répondent à des trucs qui m'ont toujours fait hurler (en fait la plupart) :
- Les imports. Non mais sans dec'. Un jour le C++ aura des imports. Après 45 ans ouais.
- Ne pas spawner un process par fichier pour la compilation. Au final il compile ses projets en moins d'une seconde (et vraiment moins d'une seconde).
- le code qui s'exécute au moment de la compilation. Pour enfin ne plus avoir à chercher des CMake, Premake à la con, ou passer son temps à mettre des constexpr, des templates et des macros partout.
- le SOA (mais enfin quoi, vraiment les gens qui font le C++ en ont rien à foutre des projets concrets).
- les noms avant les types. Bah oui, pourquoi mettre les types avant les noms dans une classe ? Quand on regarde une classe, on s'intéresse à la sémantique, pas aux types. Les types c'est secondaire. Et comme on s'intéresse à la sémantique, ben les programmeurs du monde entier s'amusent à aligner les noms avec des tabs, des espaces et le tout ressemble à rien. Là plus d'espace/tab, problème réglé.
- Etc. Je vais pas détailler tout.

Il y a énormément de bonnes choses dans ses propositions. La plupart me venaient à l'esprit avant de voir son Jai et je suis content de voir quelque chose se concrétiser.
Ensuite il me semble important de concevoir un langage dédié aux jeux vidéo. Ça me semble assez clair que les intéréts de notre industrie divergent des intérêts des autres industries (et des prestations folkoriques des gens du standard).

Ze_PilOt a écrit :
Je comprend moi aussi assez mal ses arguments contre le c++.
Parfois tu as besoin de gérer la mémoire toi même, mais c'est finallement la beauté du C++ : T'as pas besoin de l'utiliser 100% du temps, tu peux utiliser du C si besoin.

Il n'y aura pas de garbage collector, c'est l'essentiel. Le reste est en option, mais c'est bienvenu vu la liste de deletes habituelle dans chaque destructeur.

CBL a écrit :
Il se contradit aussi lui-même. Si tu veux être productif et t'amuser en programmant, les deux derniers trucs que tu veux faire sont micro-gérer la mémoire et compiler..

Gérer la mémoire n'est pas du tout un problème quand t'en as l'habitude. C'est un problème pour les débutants surtout. Par contre le garbage collector est un problème, y compris pour les utilisateurs avancés. Selon les implémentations, soit ça bouffe en perfs, soit ça t'oblige à structurer ton code d'une manière bizarre pour éviter les problèmes dans les parties critiques tout en perdant des perfs dans les autres endroits.

Un exemple très bête : dans Unity, je voulais faire un générateur de meshes procéduraux vite fait, en passant par des voxels. J'avais quelques millions de voxels. Le truc rigolo, c'est que le simple fait d'avoir des millions de trucs en mémoire, même si je ne les utilisais pas, faisaient des micro-freezes à cause du garbage collector. Juste le fait de devoir traverser tous les objets en mémoire pour compter leurs refs. Un truc qui ne serait jamais arrivé en C++. Bon bien sûr il y aurait certainement un moyen de structurer ça autrement, un buffer large non structuré. Mais déjà ça demande plus d'efforts qu'en C++ où "je ne paye pas pour ce que je ne fais pas".

Il suffit de voir à quel point les stagiaires ne sont pas du tout opérationnels sur le c++ pour se rendre compte du nombre de chemins détournés et de "bonnes pratiques" qu'il faut comprendre pour commencer à être efficace. On ne devrait pas passer une demi-journée à juste essayer de compiler des classes template ou avoir une pile de 500 tickets de refactoring qu'on ne fera jamais.

Après, je ne suis pas convaincu que le blow++ puisse s'imposer. Mais c'est pas déconnant que des gens passent du temps à essayer de passer à autre chose.

Au passage, le compilateur d'un langage est écrit dans le langage qu'il compile.

C'est faux. Premièrement, pour faire la première version d'un compilateur (appelé le bootstrapping) c'est impossible (soit on utilise un autre language, soit on code directement la première version en code machine).

Deuxièmement, même si c'est "assez" souvent fait, il existe un nombre important de langages compilés dont le compilateur n'est pas écrit dans ce même langage.

Ceci dit, c'est vrai que ça peut faire tourner les têtes des philosophes. Surtout que quand tu réalises que la VN d'un compilateur a été compilé avec la VN-1 et et que la VN-1 a été compilé avec la VN-2 et ainsi de suite. La ou ça devient intéressant c'est que si une faille intentionnel a été introduit dès le début elle peut persister à jamais sans être visible dans le code.

Sinon c'est bizarre cet article sur un site comme Factornews, sachant que Jai est vraiment en mode prototype et qu'il me semble que l'on a pas eu de News sur Rust ou D qui sont des alternatives à C++ beaucoup plus mature (mais c'est pas une critique hein, j'aime bien les articles sur les langages de programmation)

(Je simplifie pour le néophyte... Ca m'a fait tripper de lire le code de GCC et de réaliser les implications philosophiques)

Le C++11 n'avait pas introduit l'exécution à la compilation?

MrPapillon a écrit :
Ensuite il me semble important de concevoir un langage dédié aux jeux vidéo. Ça me semble assez clair que les intéréts de notre industrie divergent des intérêts des autres industries (et des prestations folkoriques des gens du standard).

C'est bien là où je veux en venir. Vouloir remplacer le C++ est une initiative louable mais les développeurs de jeu qui utilisent vraiment le C++ sont assez rares. Même Minecraft a été écrit en Java...

Unreal Engine 4 a inversé la tendance mais le C++ d'Unreal est tellement managé et blindé de macros qu'on dirait presque du script.

Factor, c'est un peu le bric à brac du JV : la plupart du temps ça parle de JV mais des fois ça parle de ciné, de jeux de table ou même de cette relique du passé qui s'appelle le livre...
C'est un site pluridisciplinaire en fait.

Disons que le cas de Jai est unique. De mémoire c'est la première fois qu'un langage de programmation est écrit par un développeur de jeu.

CBL > si constexpr, et d'ailleurs l'exemple sur le compile-time execution sur son github, ça se fait aussi en une ligne avec constexpr en C++ (et on peut même un paquet de trucs qui servent à rien mais qui sont juste meta-physiquement beau, par exemple un jeu "joué" par le compilateur -> https://www.youtube.com/watch?v=XV1lXtB3sqg)

LordKraken a écrit :
Sinon, c'est intéressant ce qu'il dit sur l'esthétique d'un langage, bon forcément après quand tu mates le github, et qu'il nous a tout mis à l'envers... mouais... bonne chance à lui quand même.

Le github en lien dans la news est fait par un mec random qui a essayé de compiler les features du langage.

Mais il tient ses infos de J. Blow via ses vidéos sur Jai.

C'était simplement pour expliquer que le github désordonné n'était pas le fait de Jonathan Blow.

CBL a écrit :
Le C++11 n'avait pas introduit l'exécution à la compilation?

Non, pas exactement, on y arrivait que grâce à la méta programmation avec les template. On pouvait juste calculer des données constantes. Mais c'est encore pire que de lire des macros si on veut faire autre chose que récupérer un entier en utilisant de la récursivité.
Depuis le C++14 on a les fonction constexpr mais c'est pas la joie non plus (pas évident de constuire des std::string constexpr qui font des allocation...).

Ce que Jai propose c'est d’exécuter du code (via un interpréteur dans le compilo) avant/pendant la compilation, et de pouvoir directement utiliser les valeurs retournées. Dans une de ces vidéo il execute/interprète un Space Invader avant de compiler le dit Space Invader en changeant des variables en rapport avec le score qu'il a obtenu dans le run du Space Unvader interprété.

C'est bien là où je veux en venir. Vouloir remplacer le C++ est une initiative louable mais les développeurs de jeu qui utilisent vraiment le C++ sont assez rares. Même Minecraft a été écrit en Java...

Wtf, c'est quoi cet argument falacieux ? "Regardez le jeu le plus vendu du monde (ça fait un seul jeu) n'est pas écrit en C++, le C++ n'est donc pas très utilisé".

La majeure partie des jeux AAA ne verraient pas le jour s'il n'y avait pas une énorme brique en C/C++ en dessous. Personnes n'aime les templates, personnes n'aiment les macro. On utilisent le C++ parce qu'on a pas moins pire.
Sinon, bien que Jai ait été orienté "joy of programming for video game maker" ça veut pas dire qu'il sera pas utilisable pour autre chose. Faut plutôt le voir comme une alternative qui intéressera potentiellement tous les utilisateurs du C++.

Unreal Engine 4 a inversé la tendance mais le C++ d'Unreal est tellement managé et blindé de macros qu'on dirait presque du script.

Devine quel langage n'aura pas de macro moche ? Jai

Sinon Jonathan Blow a lui même dit que le compilateur ne sera pas bootstrappé, il ne compte pour le moment pas réecrire le compilateur (qui est écrit en C++) en Jai.

Par contre pour Jai il y a quelque chose qui me chagrine sur cette histoire de code qui s’exécute à la compilation. Le C++ avec les templates est déjà Turing complete et les compilos arrêtent de les évaluer passé une certaine limite car le code peut ne pas terminer. Sauf que les templates soient Turing complete c'est un accident et il est relativement difficile de coder naturellement quelque chose qui ne termine pas. Mais la avec Jai, ca à l'air d'être nettement beaucoup plus facile et ca me semble être une mauvaise idée sur le papier.

codec-abc a écrit :
Sauf que les templates soient Turing complete c'est un accident et il est relativement difficile de coder naturellement quelque chose qui ne termine pas. Mais la avec Jai, ca à l'air d'être nettement beaucoup plus facile et ca me semble être une mauvaise idée sur le papier.

Tu veux dire que c'est une mauvaise idée parce qu'on peut faire des infinite loop ou des stack overflow ?

Tu veux dire qu'on devrait arrêter tous les langages de programmation ?

Je comprends pas où est la mauvaise idée. Si tu veux exécuter du code à la compilation, t'as intérêt à ce qu'il ait exactement le même comportement qu'au run-time, ça serait absurde dans le cas contraire.

Muchacho a écrit :
Wtf, c'est quoi cet argument falacieux ? "Regardez le jeu le plus vendu du monde (ça fait un seul jeu) n'est pas écrit en C++, le C++ n'est donc pas très utilisé".

La majeure partie des jeux AAA ne verraient pas le jour s'il n'y avait pas une énorme brique en C/C++ en dessous.

Je ne dis pas cela. J'explique juste qu'une fois que les moteurs et les outils sont créés, la majorité des devs codent soit en utilisant des langages de script (Lua, JS, Python, Blueprints...) soit en utilisant des langages managés (C#).

Le fait que Minecraft ait été programmé en java ne fait pas parti de ses points positifs. C'est plus "eh regardez ce jeu a été un gros succès MALGRÉ le fait qu'il a été programmé en Java" (et sans inclure les ports qui ont été traduits). Un peu comme rollercoaster tycoon l'un des derniers gros jeux à être programmé en assembleur, ou les jeux Naughty Dog en Lisp ou Hotline Miami dans Gamemaker. Ces choses n'ont pas empêché leur succès mais ce n'est pas forcément ce que l'on recommenderait à un studio de faire (peser le pour et le contre toujours).

Pareil les moteurs sont programmés dans un langage (souvent C++) et ils proposent un autre langage plus simple pour les designers qui ne peuvent pas apprendre les subtilités du langage. (Et de ce qu'on en a vu Jai ne sera pas ce langage plus simple. JBlow veut les programmeurs qui savent programmer en C++ sur ses projets et il peut se le permettre).

Et pourtant en partant sur du Java, cela a permis à Notch de sortir rapidement un proto et d'iterer dessus bien plus vite qu'avec un moteur en C++. Accessoirement Java offre de base une couche réseau et une couche d'interface graphique alors que la std ne propose rien à ce niveau.

Quand tu vois les progrès de fou accomplis en un an entre la première version publique et la première alpha, tu te dis que le bonhomme savait un peu ce qu'il faisait.

Par la suite Java a effectivement été problématique pour porter le jeu sur iOS et consoles mais ça n'enlève rien à la prouesse des débuts.