Oui Notch arrive à itérer très vite quand il bosse en Java.
Mais comme je disais au début, cette facilité n'implique pas qu'un langage doit être mou à l'exécution. On est actuellement bloqué entre soit un langage performant mais pénible à utiliser, soit des langages ergonomiques mais mous.

Les nouveaux langages (Go, Swift, Rust, etc) ont aussi leurs propres problèmes.

Le Jai sera un bon point de départ pour de nouvelles réflexions. Je pense que ça peut avoir un petit succès chez les indés. Et si ça dure, dans plein d'années, quelques studios AAA commenceront à le considérer comme langage de script. Et dans 15-20 ans, ils commenceront une migration vers ce langage. Après il faut trouver les défauts de ce langage, et du coup j'attends avec impatience la beta ouverte pour enfin voir tout ça remonter. Et si ce n'est pas Jai, ça sera un autre langage qui aura construit dessus. Ou alors un autre nouveau langage totalement indépendant mais qui arrivera à cocher toutes les bonnes cases.

Muchacho a écrit :

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 ?

Hein ? J'ai jamais dit ça. J'ai dit qu'avoir un langage (ou une sous partie du langage) qui est Turing complete à la compilation est une mauvaise idée. A l’exécution tu ne peux pas faire grand chose d'intéressant sans langage Turing complete.

Muchacho a écrit :
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.

Parce que ton environnement de débogage pour le code qui s’exécute à la compilation risque d'être mauvais. Debugger du code de template un tant sot peu complexe c'est rarement un parcours de santé et la ça s'annonce encore pire.

J'ai arrêté de développer il y a bien trop longtemps pour suivre votre discussion, mais les arguments avancés me poussent a penser que le plus proche de la vérité, c'est le comic de XKDC.

bah il faut pas se leurrer, tous les studios de dev vont pas se tourner vers le Jai du jour au lendemain.
Mais après, si des jeux arrivent à voir le jour plus vite ou avec plus de fluidité qu'aujourd'hui, peut-être qu'un mouvement s'amorcera.
Même si chaque boite fera toujours suivant ses envies/besoins/habitudes.

Je pense que ça va faire un bide, et peu importe que Jai soit bien ou non. Se baser un langage fait par une seule personne (qui n'a pas de background en compilateur) c'est hyper risqué. Quid de Jai si -malheureusement- Jonathan Blow disparait ? Combien de temps les bugs dans le compilo/génération de code vont faire perdre avant que le code et les bibliothèques principales soient hyper robustes. Quant on voit le mal que Rust et D ont a décollé dans le domaine (qui pourtant sont bien plus mature et dispose d'une plus grande communauté) on ne peut-être que sceptique vis à vis du succès de Jai. Néanmoins plus d'alternatives n'a jamais fait de mal. Alors bon courage et bonne chance à Mr Blow pour essayer de faire bouger les choses.

Pour la plupart des langages, c'est souvent une seule personne à la base (Stroustrup pour le C++, Ritchie pour le C...) puis une équipe vient se greffer dessus.

Blow reçoit déjà de l'aide justement pour le compilo qui sera à base d'LLVM.

"Néanmoins plus d'alternatives n'a jamais fait de mal" -> cf la vignette d'intro :D

Plus sérieusement, je pense qu'on a aujourd'hui un langage bien établi (je parle de C++ évidemment) avec un standard (C++17, bon ok C++14 pour ceux qui bossent sur mobile) qui a rattrapé pas mal de son retard. Certes il va falloir attendre encore un peu pour les modules (C++ 20 peut-être) mais rien n'empêche de participer aux discussions du comité. A noter l'initiative de Stroustrup qui semble en léger désaccord avec la marche en avant de ce même comité et qui plaide depuis quelques années pour une simplification du standard (à voir notamment sa présentation sur comment apprendre/enseigner C++: https://www.youtube.com/watch?v=fX2W3nNjJIo)

Aujourd'hui c'est vrai qu'il y a beaucoup (trop?) à assimiler et C++ n'est définitivement plus (l'a t'il déjà été ?) un langage à la portée du développeur lambda (ahah). Mais qui développe encore ses jeux entièrement en C++ ? On a le moteur, le backend éventuellement, mais tout ce qui est game logic, si on veux itérer rapidement on a en général un langage de script X ou Y par dessus. (bon ok chez King on faisait absolument tout en C++ et ok j'avoues ça craignait un peu quand même).

Pour finir, ce qui me dérange le plus dans la critique de Blow sur C++, c'est que son angle d'attaque part d'un cas bien particulier. Or dans la pratique, il ne doit plus avoir beaucoup de gens qui développent leur jeu intégralement en C++. Et là ou il me perd un peu (pour le moment) c'est quand le github mentionne que "Game programmers are not afraid of pointers and manual memory management.". C'est vrai on n'a tellement pas peur que bam les memory leak et les buffer overflow.

Perso, unique_ptr est mon nouvel ami :)

"Mais qui développe encore ses jeux entièrement en C++ ?"

C'est justement pourquoi cette discussion est totalement schizophrène, d'un on reproche au C++ d'être trop compliqué pour le programmeur lambda. Mais JBlow veut remplacer ce langage compliqué par un autre langage compliqué sans concessions aux débutants qui ont du mal avec les pointeurs etc. Et oui, ses projets sont programmés par des vétérans de l'industrie en tout petit comité et sur des années parce que ça marche pour lui.

LordKraken : vous n'utilisez pas Defold chez King?

CBL a écrit :
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.

Bah non, y'a Haxe de Nicolas Canasse, utilisé par Motion Twin, Shiro Games, Headbang Club, EA... Et c'est même sorti du jeu vidéo, c'est beaucoup utilisé par TiVo aussi. Y'a aussi les dérivés de lisp, GOOL et GOAL, utilisés par naughty dog pour les crash bandicoot et les jak & daxter. Les uncharteds étaient leurs premiers jeux en C++ (mais quand même scriptés en lisp)

Et si on compte les langages de scripts, j'ai pas un bras assez long tellement la liste est longue.

J'ignorais pour Haxe mais pour les langages de script les développeurs partent rarement de zéro. Ils implémentent souvent une version d'ECMAScript ou modifient Lua. Mais tu as raison.

CBL > A ma connaissance le seul jeu utilisant Defold est Blossom Blast Saga. Tous les autres projets ont été canés à un moment ou un autre (pas à cause du moteur ceci dit - qui est d'ailleurs un contre-exemple parfait de ce qu'assume Blow). Les autres jeux utilisent un moteur maison 100% C++ très "old school" pour être gentil, mais qui avait l'énorme (le seul?) avantage d'être multiplateformes en 2012 (et non public - le management est carrément parano). Beaucoup de nouveaux projets utilisent aussi Unity maintenant (dont le COD). Ca commence à être un peu schizophrène mais ce n'est plus vraiment mon soucis en fait (j'attends la fin de mon "non-compete" pour rejoindre un nouveau studio à Stockhom qui va bosser sur un truc avec des bonhommes bleus :D ).

codec-abc a écrit :
Je pense que ça va faire un bide, et peu importe que Jai soit bien ou non. Se baser un langage fait par une seule personne (qui n'a pas de background en compilateur) c'est hyper risqué. Quid de Jai si -malheureusement- Jonathan Blow disparait ? Combien de temps les bugs dans le compilo/génération de code vont faire perdre avant que le code et les bibliothèques principales soient hyper robustes. Quant on voit le mal que Rust et D ont a décollé dans le domaine (qui pourtant sont bien plus mature et dispose d'une plus grande communauté) on ne peut-être que sceptique vis à vis du succès de Jai. Néanmoins plus d'alternatives n'a jamais fait de mal. Alors bon courage et bonne chance à Mr Blow pour essayer de faire bouger les choses.

Si mes souvenirs sont bons ils sont maintenant 3 à temps plein à bosser dessus.

Statistiquement il y a de grande chance que ça se vautre comme les milliers de langages qui se sont vautrés auparavant, c'est évidement.

Mais je pense que ça vaut largement le coup d'essayer. Il y a assez de "nouvelles features (intéressantes)" pour que ce soit pas juste un langage de plus comme le Go, Rust ou Swift que je vois surtout comme des langages avec plus de sucres syntaxiques (et des meilleurs bibliothèques standards !), et beaucoup d'autres limitations (des fois on peut pas avoir d'allocateur custom..., pas de variadic template, un langage de macro à peine mieux que celui du C/C++), et on se retrouve aussi frustré qu'avant parce qu'on a même des pertes de features.

CBL a écrit :

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#).

Ah oui effectivement le C++ c'est aujourd'hui surtout pour faire les moteurs ou certaines briques du moteurs. Après ça reste ultra important d'avoir un langage performant pour faire ses briques.

Je suis très curieux de voir naitre Jai simplement parce que je veux utiliser autre chose que le C++ pour mes programmes perso, tout en conservant les "bons" paradigmes relatif au C/C++.

Muchacho a écrit :
Si mes souvenirs sont bons ils sont maintenant 3 à temps plein à bosser dessus.

3 ça fait pas énorme. J'espère aussi qu'ils ont prévu d'être assez ouvert pour qu'une communauté puisse se former et avoir plus de ressources. Aussi, qui finance ces personnes ?

Ca fait longtemps que je n'ai plus fait de C++ (et C) mais le D n'était pas là pour améliorer le C++ ?

Sinon le C# (F#...) c'est pas bien?

C'était un peu l'idée oui, avoir la puissance du C++ sans sa complexité. Mais le langage n'a jamais vraiment décollé, la faute entre autres à une approche "le cul entre 2 chaises" pour la gestion de la mémoire. Il y a un garbage collector de base dont on peut/veut se passer, sauf que c'est compliqué, et que ça va à l'encontre du principe de simplicité à la base du langage. Rien que ça (y a d'autres soucis) n'en font probablement pas le langage de choix pour le jeu vidéo. Un des fondateurs du langage (ou contributeur principal je ne suis pas sûr) - andrei alexandrescu - est assez réaliste, voir amer, sur les forces et les défauts de "son" langage.

Quand à C# perso j'aime bien, mais je le vois plus comme un langage de tools. Après avec Unity ça fonctionne relativement bien, même si j'imagine que la encore la "garbage collection" doit être un problème sur les gros projets (je fais juste du prototyping avec Unity).

codec-abc a écrit :

Muchacho a écrit :
Si mes souvenirs sont bons ils sont maintenant 3 à temps plein à bosser dessus.

3 ça fait pas énorme. J'espère aussi qu'ils ont prévu d'être assez ouvert pour qu'une communauté puisse se former et avoir plus de ressources. Aussi, qui finance ces personnes ?

Le langage est encore en chantier, 3 personnes à temps plein c'est pas mal à ce stade pour faire naître un projet à but non lucratif (voir un projet qui sera mort né).

A terme tout sera censé être open source quand se sera suffisamment "figé" évidemment avec des décideurs, une communauté, une documentation et des démos.
D'ailleurs on sait pas du tout sous quelle forme/licence, J. Blow ne veut pas qu'il puisse y avoir un Embrace, Extend and Extinguish, à cause d'une grosse entreprise.

Ils se financent eux mêmes (Thekla, le "studio" de Braid et The Witness).

LordKraken a écrit :
Quand à C# perso j'aime bien, mais je le vois plus comme un langage de tools. Après avec Unity ça fonctionne relativement bien, même si j'imagine que la encore la "garbage collection" doit être un problème sur les gros projets.

Pas uniquement sur les gros projets (même si plus le truc est gros, plus ça coince).

En gros : éviter le plus possible les allocations sur la boucle principale. C'est pas toujours évident parce qu'il faut savoir ce que le langage va traiter comme une allocation (donc plus niveau intermédiaire que ultra débutant). Et ça nécessite des choses comme des pools d'objets (https://unity3d.com/learn/tutorials/topics/scripting/object-pooling). Le pire ce serait par exemple une allocation (cachée à première vue) par mise à jour d'une particule..

Sinon en modifiant la façon dont on écrit le code :
https://www.youtube.com/watch?v=tGmnZdY5Y-E