Je pense qu'on va arriver à se mettre d'accord petit à petit, mais il reste encore quelques points à clarifier. Handmade Hero n'est pas un jeu 2D, il est en 3D avec illumination globale temps réel, depth peeling, il charge des assets dynamiquement de façon asynchrone, etc. Vous avez juste vu quelques extraits vite faits, ça ne suffit pas pour savoir ce qu'il y a derrière. Le jeu 2D c'était juste les 250 premiers épisodes.

Tu prend un Zelda, tu crois que tu vas réinitialisé à zero , a chaque fois ? Non ,tu dois savoir quel sont tes données persistante ( le Perso , le HUD , quelque autre data) , et ceux que tu vas changé souvent (map , ennemi). En soit , c'est pas ultra complexe , mais c'est pas forcément intéressant de se mettre ce genre de contrainte. (sauf comme dis ,si tu as quelque Mo en RAM , mais c'est pas ta contrainte si ? ).

J'ai pas dit qu'on réinitialisait tout à chaque fois, juste certains trucs, et comme vous dites c'est pas très compliqué de faire plusieurs "memory arenas" selon la durée de vie du truc (permanent, par frame, pour le niveau actuel, etc https://guide.handmadehero.org/code/day435/#10189). Et justement on peut très facilement mettre une limite maximale sur la taille mémoire et ainsi faire tourner le jeu "tant bien que mal" avec peu de mémoire. Ce n'est pas la principale préoccupation quand on est sur un PC à 4000€ avec 64 Go de ram + 2 To de nvme, je vous l'accorde, mais le jour où vous voulez porter votre truc sur mobile, vous serez bien content d'avoir ce genre de choses.

Et oui je suis complètement d'accord qu'on ne peut pas toujours organiser son code pour qu'il marche avec un allocateur FIFO, même Casey le dit que ça couvre que 99% des besoins (https://guide.handmadehero.org/code/day462/#857). Sa statistique sort peut être de null part mais en gros ça veut dire qu'on peut quand même souvent faire comme ça.

Car tu viens de comparer l'allocateur générique "qui pourrait échouer à n'importe quel moment" à un allocateur perso "qui pourrait ne jamais échouer" ??? Est-ce bien cela que je lis?

L'allocateur générique peut échouer à n'importe quel moment, car il n'y a peut être plus de mémoire disponible. Dans mon exemple d'allocateur il fait également une allocation dynamique si il n'y a plus assez de mémoire dans le bloc. Donc oui il pourrait "fail" lamentablement de la même manière. Quand je dis qu'il ne peut pas fail, c'est quand on sait que les allocations qu'on va faire rentrent entièrement dans le premier et seul bloc mémoire alloué au départ, autrement dit qu'on aura pas besoin d'allouer plus de mémoire. Je pense pas qu'on puisse avoir cette "garantie" quand on code une librairie, mais si on fait une appli/jeu ou un truc embarqué, on peut potentiellement savoir quelle est la taille maximale dont on a besoin, et ainsi effectivement être sûr que ça va marcher.

Dans l'exemple d'allocateur que j'ai fait vite fait, ça n'informe pas l'utilisateur de l'échec d'allocation, mais on pourrait facilement le rajouter, et ainsi permettre au code utilisateur de réagir en cas de manque de mémoire.

Pour revenir sur l'idée que les tableaux dynamiques sont superflus, d'autres personnes qui ont expérimenté cette façon de faire le remarquent aussi : https://youtu.be/izFHFYgRo1o?t=1045 

(et The Cherno (à droite) qui fait semblant d'avoir compris en disant "yeah" alors qu'il est à fond dans le C++ moderne ça me fait rire )

-
Edité par JadeSalina 29 mai 2022 à 16:36:47

Je pense qu'on va arriver à se mettre d'accord petit à petit, mais il reste encore quelques points à clarifier. Handmade Hero n'est pas un jeu 2D, il est en 3D avec illumination globale temps réel, depth peeling, il charge des assets dynamiquement de façon asynchrone, etc. Vous avez juste vu quelques extraits vite faits, ça ne suffit pas pour savoir ce qu'il y a derrière. Le jeu 2D c'était juste les 250 premiers épisodes.

Oui , ça reste juste un jeu en 3d , avec un gameplay , et un rendu vieux de 20 ans
C'est fort impressionnant dis donc , ça n'en fait aucun doute que ça déboîte un jeu AAA d'époque !
On est sensé prendre ce truc comme référence absolu ?

J'ai pas dit qu'on réinitialisait tout à chaque fois, juste certains trucs, et comme vous dites c'est pas très compliqué de faire plusieurs "memory arenas" selon la durée de vie du truc (permanent, par frame, pour le niveau actuel, etc https://guide.handmadehero.org/code/day435/#10189). Et justement on peut très facilement mettre une limite maximale sur la taille mémoire et ainsi faire tourner le jeu "tant bien que mal" avec peu de mémoire. Ce n'est pas la principale préoccupation quand on est sur un PC à 4000€ avec 64 Go de ram + 2 To de nvme, je vous l'accorde, mais le jour où vous voulez porter votre truc sur mobile, vous serez bien content d'avoir ce genre de choses.

Mais c'est que tu vas m’apprendre des choses dis donc !
Alors pour ta gouverne j'ai dev des jeux sur mobile , merci de m'apprendre mon métier !
J'ai aussi développer quelque demo sur PS2 et Dreamcast "from scrath" en tapant sur le hardware en asm  et qui tourne avec 16 et 32 Mo , ça va j'ai bon , j'ai le level ?
Ou je dois demander à Casey de m'apprendre des truc ?
Le pire, j'ai que je t'ai dit que j'en avait utilisé un (et entre autre j'en avais implémenté sur PS2 pour gérer les 4 Mo de VRAM) , et tu veux m’apprendre comment ça marche, c'est fou , c'est le monde qui marche sur la tête ?

Sinon arrête les "yakafokon" , "oui a qu'a faire des mémory arena , c'est pas compliqué ",et j'ai ce que j'ai dit ,c'est pas compliqué ,c'est juste chiant.
Parce que sauf si tu veux faire un jeux merdique oui , pas de soucis, mais quand tu veux exploiter une machine , ça reste très chiant comme méthode
Mais c'est ton principal soucis, t'as aucune expérience , dans le dev ou dans le jeux video , tu ne connais pas toute les difficultés que tu aura
Et Casey aussi , il a jamais fait un jeux complexe, donc son avis , je m'en cogne un peu.

Et oui je suis complètement d'accord qu'on ne peut pas toujours organiser son code pour qu'il marche avec un allocateur FIFO, même Casey le dit que ça couvre que 99% des besoins (https://guide.handmadehero.org/code/day462/#857). Sa statistique sort peut être de null part mais en gros ça veut dire qu'on peut quand même souvent faire comme ça.

C'est quoi cet argument bidon ?
Parce que tu dis "oui Casey dit un peu de la merde c'est pas 99% , allez je suis sympa , on coupe la poire en deux, on dit 50% ?"
Une grosse partie du dev n'est pas approprié pour du LIFO allocate.
De plus , a part pour faire une optimisation "pointu" pour rien , et comme dit Koala , l'optimisation ça se mesure , ça n'a aucune importance qu'un truc est "sous optimal" si y'a pas de réel gain a gagné dessus.

Je pense qu'on va arriver à se mettre d'accord petit à petit, mais il reste encore quelques points à clarifier.

Quand tu aura compris que ton réel problème , c'est ton fanatisme , oui là on aura fait un grand pas ,et on sera d'accord !

Parce que la seule chose que tu devrais dire, vu ton expérience c'est "ok cette méthode est pas toujours viable , je vous crois" .
Pas de venir le dire avec aplomb que c'est la méthode miracle.
Et c'est là que ton comportement ressemble à une secte , t'es incapable d'accepter que personne ici a besoin de cette méthode.
Et surtout tu considère limite les gens ici comme des "débiles" qui ont besoin de ton savoir (enfin non  tu n'es que la parole de ton Dieu Casey) , pour informer au monde , des méthode qui ont 30 ans grosso modo ?
(Et inutile de répéter 20 fois les mêmes choses on a compris ).

Parce que limite tu dis a des dev qui ont quoi 10-20 ans de bouteille voir plus , "tenez utilisez une méthode ultra simpliste, vous n'y avez pas pensez hein ?".
Non non , ils ont pas pensé , ils avait -50 de QI excuse les , heureusement que Casey est là pour nous sauver et nous dire comment on dev y'a 30 ans !

-
Edité par HelbaSama 29 mai 2022 à 18:02:11

> (et The Cherno (à droite) qui fait semblant d'avoir compris en disant "yeah" alors qu'il est à fond dans le C++ moderne ça me fait rire )

Tu dis n'importe quoi (pour changer), il ne fait pas semblant de comprendre puisque c'est bête comme chou, ce que dit son interlocuteur.
Et std::array, ça te parle, et placement new, ça te parle ? (Pour te faire remarquer que le C++ moderne n'a rien à faire là dedans)
Et comme dit l'interlocuteur de The Cherno, tu peux avoir besoin d'allocations dynamiques, mais ils n'en ont pas de leur côté, c'est tout...

Dissonance cognitive, quand tu nous tiens...

-
Edité par dragonjoker 29 mai 2022 à 18:14:38

JadeSalina a écrit:

mais en fait quand on voit comment le programme est structuré, tout s'articule correctement, sans pour autant que ce soit difficile à maintenir ou autre.

D'accord...

Mais tu nous parle d'un projet de combien de lignes de code, là? 10 000 ? 20 000 ? Allez, mettons meme 100 000?

Mais, que dire d'un projet de 200 000 fichiers, et de  4 000 000 LOC au bas mot?

JadeSalina a écrit:

Le fait que vous disiez que c'est chiant c'est que vous ne savez pas de quoi il s'agit puisque c'est très simple à utiliser. Et les std::vector on une politique d'agrandissement pas forcément optimale en terme d'utilisation mémoire

Tout à fait, la politique d'augmentation de capacité de std::vector est souvent de doubler la capacité en cas de besoin.  Cela fini par utiliser beaucoup de mémoire juste pour pouvoir ajouter un élément.

D'un autre coté, cela nous permet de rajouter de plus en plus d'éléments entre deux augmentations de capacités, ce qui nous permet d'en limiter le nombre. Je sais pas toi, mais je trouve le deal plutôt sympa: un peu de mémoire (qui, au  mieux, sera de toutes manières utilisées) contre tout le temps qu'il faudrait passer à augmenter la capacité à  chaque ajout

Tu me diras que "cela consomme quand même pas mal de ressources pour rien".  Ouaip, t'as pas tord.... Mais dis moi, est-ce vraiment un problème à l'heure actuelle de perdre la taille de 65000 int (à peu près 230 ko) en RAM quand on en a déjà stocké 65000 et qu'on veut en rajouter un de plus?

Rappelle moi un peu... on dispose de combien de RAM ? Ah, oui, sur mon PC actuel, j'en ai seulement 16 Gb... à peine plus de 16 000 000 000 octets. Je dois vraiment veiller à ne pas perdre inutilement 230 000 octets... Mon système n'y résisterait pas

Attention, je ne prétend pas que cette politique d'augmentation de capacité est parfaite.  Je dis simplement que, tant Je dis juste que, tant que mon système et mon programme pourront supporter cette politique sans problème, elle me conviendra parfaitement.  Et que si problème il devait y avoir, à moins qu'il ne soit prouvé que cette politique est responsable du problème, je chercherai je chercherai en priorité à corriger les autres raisons possibles

Au passage, le lien que tu nous donnes ici traite des structures dynamiques du point de vue du  C et non du C++.  Et, pour ta gouverne, on n'est pas tout à fait idiots: ces structures, on les connait depuis belle lurette

JadeSalina a écrit:

Et dans Handmade Hero c'est même pas qu'il n'utilise pas de std::vector, c'est carrément qu'il n'y a aucun tableau dynamique, c'est à dire aucune structure permettant de push_back à gogo. Alors qu'on pourrait se dire à première vue que c'est impossible de s'en passer, mais quand on sait organiser son code comme le fait Casey, on se rend compte que dans la plupart des cas on peut s'en passer.

S'il peut se contenter d'une taille prédéterminée dans son projet, tant mieux pour lui!

Mais, au fait, sais tu que lorsque tu as besoin d'un nombre "connu à l'avance" d'éléments (comprends: avant même d'avoir commencé à remplir ton tableau) tu dispose de deux moyens différents de forcer la taille de ton tableau à correspondre à ce nombre d'éléments et que rien ne t'empêche d'utiliser par la suite ton tableau comme s'il était de taille fixe?

Allez, comme je ne suis pas vraiment du genre à parler sans preuves:

#include <vector>
#include <iostream>
int main(){
    /* je travaille avec des int, car je veux pas me casser 
     * la tête ici
     */
    // je sais que j'ai 123 élément à mettre dans mon tableau, 
    // ni plus ni moins:
    std::vector<int> tab(123);
    std::cout<<tab.size()<<"\n";
    for(size_t i = 0; i < tab.size(); ++i)
        tab[i]=i;
    
    for(auto val : tab)
        std::cout<<val<<"\n";
    std::cout<<"vector size = "<<tab.size()
             <<"  vector capacity = "<<tab.capacity()<<"\n";
}

ou

#include <vector>
#include <iostream>
int main(){
    /* je travaille avec des int, car je veux pas me casser 
     * la tête ici
     */
    // mettons que, pour n'importe quelle raison qui me soit
    // propre, je veuille déclarer mon tableau avant d'en
    // connaitre la taille
    std::vector<int> tab;
    // rien ne m'empêche de la définir par après
    tab.resize(123);
    for(size_t i = 0; i < tab.size(); ++i)
        tab[i]=i;
    
    for(auto val : tab)
        std::cout<<val<<"\n";
    std::cout<<"vector size = "<<tab.size()
             <<"  vector capacity = "<<tab.capacity()<<"\n";
}

Comme tu peux le constater, je n'ai pas utilisé le moindre push_back et pourtant, tu remarquera ==>ici<== et ==>ici<== que ces deux programmes fonctionnent parfaitement et que la capacité du tableau est toujours strictement égale au nombre d'éléments qu'ils contiennent

Au fait, peut on savoir ce que  tu reproche exactement à push_back? D'être une fonction membre de la classe, peut être?  Parce que ca, c'est une question de goûts et, effectivement, "les égouts et les couleuvres, ca se discute pas"

Mais pour le reste?

De devoir augmenter la taille du tableau à chaque fois que  l'on veut ajouter un élément peut-être? encore une fois, tu as tout faux.  Je t'ai expliqué plus haut la politique d'augmentation de capacité, mais, si tu ne me crois pas, voici un petit code qui te le prouvera:

#include <vector>
#include <iostream>
int main(){
     /* je pars d'un tableau  vide */
     std::vector<int> tab;
     /* assurons nous qu'il est bien vide */
     std::cout<<"at the begining, tab's size = "<<tab.size()<<"\n";
     /* comparons cela avec la capacité du tableau
      * (AKA : le nombre d'éléments à partir duquel il faut 
      * demander plus d'espace)
      */
     std::cout<<"                 tab's capacity = "<<tab.capacity()<<"\n";
     /* ajoutons un million d'éléments et voyons comment évoluent
      * la taille et la capacité
      */
      for(int i = 0; i< 1000000;i++){
          /* ce qui m'intéresse, ce n'est que 
           * le moment où la capacité du tableau
           * est modifiée, 
           * j'en prend donc capacité 
           * AVANT l'ajout, et je la compare à
           * la capacié APRES l'ajout
           */
          auto oldCap = tab.capacity();
          tab.push_back(i);
          if(tab.capacity() != oldCap){
              std::cout<<"capacity extended from "<<oldCap<<" to "
                       <<tab.capacity() 
                       <<" when added "<<tab.size()<<" th element\n";
          }
      }
}

et dont tu peux même voir l'exécution en directe ==>ici<==.

Comme je l'ai dit plus haut, ce n'est pas parfait, soit...  Mais tant que ce n'est pas la cause prouvée des problèmes, cela me conviendra dans la plupart des cas

JadeSalina a écrit:

Vous confirmez mon premier paragraphe, évidemment que si vous avez déjà fait des millions de lignes ça va pas être possible de revoir toute la structure, mais quand le concept d'avoir des allocateurs et de savoir d'où vient la mémoire etc est pensé dès le départ, on peut facilement changer les choses.

Il y a juste "quelques failles" dans ton raisonnement...

Lorsque tu dis "mais quand le concept d'avoir des allocateurs et de savoir d'où vient la mémoire etc est pensé dès le départ, on peut facilement changer les choses.", cela implique de partir d'une page blanche. A l'extrême limite, d'un projet dont la première ligne de code ne sera pas écrite avant que tu n'aie accepté de travailler dessus.

Cela ne vaut malheureusement que pour les projets persos que tu  décide de développer toute seule dans ton coin, car, dans "la vie de tous les jours", la majeure partie des projets sur lesquels tu devras travailler auront déjà été (largement) entamés lorsque tu arriveras dessus.

Que compte tu faire? arriver avec tes gros sabots et dire "tout ce que vous avez fait jusqu'à présent, ces de la merde, on efface tout et on recommence"?

Par contre, si tu utilises std::vector (ou n'importe quelle autre collection issue de la bibliothèque standard), si l'allocateur par défaut  ne te convient pas, tu as trente six solutions différentes pour le changer qui te demanderont un minimum d'effort et qui nécessiteront sommes toutes très peu de changements dans le code existant:

• Tu peux fournir des spécialisations totales de l'allocateur par défaut pour les types de données qui t'intéressent
• Tu peux utiliser une macro qui remplacera les opérateur new, new[], delete et delete[] par leur "version perso"
• Tu peux décider d'utiliser des alias pour  tes collections.  Alias que tu pourras améliorer en y ajoutant l'allocateur personnel que tu auras créé
• j'en passe, et de meilleures

Tout cela ne demandera qu'une seule chose au final: que tu mette en place le système qui permettra de gérer la mémoire.  Et le reste se fera "tout seul"

Seule la dernière solution envisagée demandera plus de modifications du code existant.

JadeSalina a écrit:

Handmade Hero n'est pas un jeu 2D, il est en 3D avec illumination globale temps réel, depth peeling, il charge des assets dynamiquement de façon asynchrone, etc. Vous avez juste vu quelques extraits vite faits, ça ne suffit pas pour savoir ce qu'il y a derrière.

Il est vrai que jusqu'à maintenant, on a critiqué le code (c'est du vieux code tout moisi), la personne (Casey est un con arrogant), mais pas trop le jeu en lui même. Regardons donc à quoi il ressemble au bout de 7 ans...

Jeu 3D ?

Le jeu est en fait constitué de gros cube 3D pour les murs, mais les personnes et les décors (arbres) sont en 2D (des simples billboards).

De plus, il n'y a que de l'animation sur la 2D, pas sur la 3D (pour ce que j'ai vu).

De l'illumination globale ?

Rien qui choque sur les lumières dans cette capture (la lumière verte vient du personnage) ?

Les murs qui sont opposés au personnage sont illuminés aussi. Aucun gestion des obstacles et des ombres.

Je n'ai pas regardé le code de son "illumination globale", mais je pense que soit c'est pas de l'illumination globale, soit il a merdé son code.

Même moi qui ne suis pas dev 3D, j'ai fait des tutos sur OpenGL avec Qt qui étaient mieux en termes de lumière. C'est du niveau débutant en 3D.

(Et il utilise de l'OpenGL 1, pour ce que j'ai vu).

Du depth peeling ?

Il y a effectivement des épisodes sur le sujet, mais j'ai rien vu dans le résultat final. Je sais pas où il fait ça.

Des assets dynamiquement de façon asynchrone ?

Euh... et on doit se rouler par terre pour ça ?

Les performances...

Depuis le début, Jade nous casse les pieds avec les performances. Regardons ça plus en détail.

Une scène avec quelques cubes 3D et des billboards, de taille pas très grande (une maison et un jardin). Dans une des dernières vidéos, on voit que le temps de rendu est entre 10 et 11 ms par frame, soit 100 FPS.

C'est ok, mais il n'y a pas non plus à se rouler par terre, pour une scène aussi simple. C'est objectivement pas un jeu performant : c'est juste un jeu qui n'a pas grand chose à afficher.

Mon point de vue sur ce jeu

C'est un jeu de débutant. Il utilise des techniques qui sont vieilles, qui sont visuellement bof, et qui ne sont pas performantes. Et tout ça en 7 ans, c'est lent.

On a des devs dans cette discussion (Lynix et DragonJoker) qui ont fait des jeux et/ou moteur de jeux 10 fois mieux, en étant tout seul aussi et en moins de temps.

Objectivement, c'est un "jeu" (un début de jeu, c'est même pas jouable au bout de 7 ans) qui est moisi. C'est le genre de projet qu'on attendrait d'un étudiant en école de jeux vidéo, comme projet scolaire. Pas plus.

Ce que raconte Jade est du vent. Elle nous sort ce projet en exemple, comme si c'était une référence, mais quand on creuse, on voit que aussi bien le jeu que le code sont moisis. Il n'y a rien a conserver dans HH.

-
Edité par gbdivers 29 mai 2022 à 19:55:52

Alors si vous prenez des extraits où il est en justement en train de débugger l'éclairage c'est normal que ça soit pas bon, attendons de voir le résultat final. Sinon oui ça fait pas beaucoup d'avancée pour 7 ans, si on ne compte pas le fait qu'il a codé le jeu en live (donc en pouvant moins bien réfléchir) et en 1 heure par jour du lundi au vendredi jusqu'à l'épisode 350 puis c'est passé à 2 heures le samedi et dimanche. Ca fait même pas 1000 heures de programmation, c'est ridiculeuseument peu... (et je passe aussi sur le fait qu'il fait tout à la main from scratch en perdant du temps à tout expliquer au blackboard...). Et les billboards 2.5D comme il fait c'est plus difficile à gérer que de la pure 3D.

Il utilise un renderer software jusqu'aux alentours de l'épisode 230, puis il passe à OpenGL 1.1, puis à OpenGL 3.3 vers l'épisode 368. Dans son vrai job il me semble qu'il est sur OpenGL 4.6 AZDO (et je vous épargne son avis sur Vulkan pour ne pas vous faire de mal).

Et il me tarde de voir ce que va donner son jeu 1935, fait dans de vrais conditions (pas en live) ou encore StarCodeGalaxy, pour lequel il a apparemment révolutionné le web (vous voulez savoir quelle techno backend il utilise pour son serveur ? https://twitter.com/cmuratori/status/1434423015068995589).

personne ici a besoin de cette méthode.

Là je vous accorde le point, effectivement on peut arriver à un bon résultat en utilisant les techniques modernes, les containers standards, etc, qu'on peut optionnellement optimiser avec un allocateur custom si besoin. J'avais vu une personne de la CppCon (je sais plus qui) dire que le C++ proposait des "reasonable defaults", et je suis d'accord. Si vous vous contentez de quelque chose de raisonnable et que vous manquez de temps ou autre pour optimiser au poil de c** le moindre truc, je comprends complètement. Moi j'aime bien chercher à atteindre de très bons résultats, pas simplement "raisonnables", mais je n'ai pas de contrainte de temps non plus. Donc selon les projets, je comprends qu'il y ait des compromis à faire et qu'on préfère atteindre rapidement un truc raisonnable, facilement reprennable par l'équipe suivante, etc, que de partir dans un truc sur mesure etc. Casey le dit lui même qu'il n'y a aucun problème à faire ça, du moment qu'on a conscience que c'est un compromis (https://guide.handmadehero.org/code/day500/#7528) (et donc pas la "solution la plus optimale", qui est peut être trop couteuse/inutile à mettre en oeuvre, je vous l'accorde).

Là où je suis moins d'accord, c'est quand vous dites que les devs qui ont 20 ans de bouteille connaissent complètement ce genre de chose. Vous savez ce que je vois, et que j'ai déjà reproché plusieurs fois ? Des gens en C qui font "n'importe quoi" et des gens en C++ qui disent "regardez c'est n'importe quoi en C faites le comme ça en C++ !". Un exemple tout simple, au niveau des allocations. En C on fait des malloc/free et en C++ on utilise (par ordre de préférence) des std::vector, std::unique_ptr, std::shared_ptr. Le C++ résout effectivement le problème en faisant en sorte qu'on ne puisse pas oublier de free, etc, je l'admet (pas forcément d'une façon aussi simple côté code machine, mais pourquoi pas).

Donc quand je disais que vous prenez toujours des exemples moisis en C pour illustrer les concepts C++, en faisant croire que seul le C++ permet d'apporter une solution (oui il apporte une solution c'est vrai), mais ce n'est pas la seule, et la preuve qu'on peut faire des trucs propres en C sans pour autant se retrouver à faire des malloc/free déguelasses à la main.

Au passage, le lien que tu nous donnes ici traite des structures dynamiques du point de vue du  C et non du C++.

Mais ce n'est pas la question ? Le langage n'est qu'un outil qui permet de produire plus facilement du code machine, ce n'est pas parce qu'on est dans un langage qu'on doit fermer les yeux sur toutes les autres approches. Et de plus le C++ ne propose qu'un nombre limité de structures de données, donc il faudra quand même se poser des questions à un moment donné, si on veut faire un truc qui n'est pas proposé de base dans le langage et sa bibliothèque standard (par exemple les ECS)

Cela ne vaut malheureusement que pour les projets persos que tu décide de développer toute seule dans ton coin, car, dans "la vie de tous les jours", la majeure partie des projets sur lesquels tu devras travailler auront déjà été (largement) entamés lorsque tu arriveras dessus.

Je suis complètement d'accord que si on doit récupérer un projet on va pas arriver et leur dire de tout recommencer, il faut partir de l'existant, et ça fait même plaisir quand les précédents programmeurs ont suivi des pratiques standards qui font qu'on a pas à perdre de temps à déchiffrer leur bizarrerie, je comprend très bien tout ceci !!!

Mais le truc c'est que je ne veux pas juste "rentrer plus tôt le soir" et "faire un truc raisonnable le plus rapidement possible", moi je préfère chercher à faire le meilleur truc possible pour le client. Je préfère avoir à réfléchir un peu plus (ça s'appelle être programmeur, on devrait y arriver) plutôt que le client ait à attendre que le programme réponde car les devs ont favorisé la "lisibilité" (windows terminal je pense à toi) ou encore d'attendre plusieurs minutes (!!!!!!!) que GTA Online charge car les équipes sont pas coordonnées et font n'importe quoi (https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/)

-
Edité par JadeSalina 30 mai 2022 à 22:56:05

Je ne suis pas du métier, contrairement à la plupart des intervenants ici. Mais j'ai du mal à comprendre l'agressivité de certains messages. Franchement, si cette méthode d'allocation a 30 ans, qu'elle n'est pas adaptée dans certains cas, qu'est-ce que ça peut faire ? Il me semble en plus que tout le monde en convient. Si le travail de Casey (que je ne connais pas) peut booster la créativité de ses followers et leur donner envie d'avancer sur des projets, c'est très bien, quand bien même il ne serait pas parfait. Une approche un peu décalée peut parfois ouvrir des perspectives même si elle n'est pas académique. Les normes industrielles et les projets à 5000000 de lignes de code ça ne fait pas forcément rêver tout le monde. Si jamais elle débarque dans le monde industriel (elle y travaille peut-être déjà, je n'en sais rien), elle semble assez douée pour s'adapter. Et au pire si c'est pour ses projets perso elle fait bien ce qu'elle veut.

Peut-être en plus que Jade a raison et que l'informatique de demain ressemblera à ça : des petits projets indépendants, avec peu de dépendances envers de grosses lib, avec un soucis de l'optimisation bas niveau. On peut très bien l'envisager dans un monde où le nombre d'être humains ne cessent croître et où la pression sur les ressources et l'environnement ne cessent d'augmenter. L'idée qu'on aura toujours chacun des machines de plus en plus puissantes et des projets de plus en plus gros avec des centaines de dev est certainement fausse. À quelle échéance ? Pas facile à dire, mais ça peut être assez rapide, à cause de déstabilisations géopolitiques, économiques, environnementales... qui sait? Je crois assez à un avenir low-tech, car dans un monde instable les systèmes qui possèdent le moins de dépendances sont les plus résilients, les plus simples à réparer, remplacer, maintenir. C'est un changement de paradigme qui s'annonce, et ce n'est pas nécessairement pour le pire : il y a tellement plus de satisfaction à faire les choses par soi même (même si c'est pour (re)faire comme les anciens) et d'être maître de son projet plutôt que de n'être qu'un rouage dans une immense machine.

Mais tout cela nous embraque un peu loin
Bonne nuit à tous !

-
Edité par Umbre37 29 mai 2022 à 23:16:13

Et ton client ne va pas vouloir attendre (et payer) 5 mois de plus juste pour ton optimisation au poil de cul, alors qu'il s'en contrefout parce qu'il n'en a pas besoin.

Alors tu fais simplement avec les outils de base fournis par le langage, et si besoin, tu customises, mais seulement au besoin.

Et ouais, dans la vraie vie l'argent fait aussi partie des contraintes.

Umbre37 a écrit:

Je ne suis pas du métier, contrairement à la plupart des intervenants ici. Mais j'ai du mal à comprendre l'agressivité de certains messages. Franchement, si cette méthode d'allocation a 30 ans, qu'elle n'est pas adaptée dans certains cas, qu'est-ce que ça peut faire ? Il me semble en plus que tout le monde en convient. Si le travail de Casey (que je ne connais pas) peut booster la créativité de ses followers et leur donner envie d'avancer sur des projets, c'est très bien, quand bien même il ne serait pas parfait. Une approche un peu décalée peut parfois ouvrir des perspectives même si elle n'est pas académique. Les normes industrielles et les projets à 5000000 de lignes de code ça ne fait pas forcément rêver tout le monde. Si jamais elle débarque dans le monde industriel (elle y travaille peut-être déjà, je n'en sais rien), elle semble assez douée pour s'adapter. Et au pire si c'est pour ses projets perso elle fait bien ce qu'elle veut.

Peut-être en plus que Jade a raison et que l'informatique de demain ressemblera à ça : des petits projets indépendants, avec peu de dépendances envers de grosses lib, avec un soucis de l'optimisation bas niveau. On peut très bien l'envisager dans un monde où le nombre d'être humains ne cessent croître et où la pression sur les ressources et l'environnement ne cessent d'augmenter. L'idée qu'on aura toujours chacun des machines de plus en plus puissantes et des projets de plus en plus gros avec des centaines de dev est certainement fausse. À quelle échéance ? Pas facile à dire, mais ça peut être assez rapide, à cause de déstabilisations géopolitiques, économiques, environnementales... qui sait? Je crois assez à un avenir low-tech, car dans un monde instable les systèmes qui possèdent le moins de dépendances sont les plus résilients, les plus simples à réparer, remplacer, maintenir. C'est un changement de paradigme qui s'annonce, et ce n'est pas nécessairement pour le pire : il y a tellement plus de satisfaction à faire les choses par soi même (même si c'est pour (re)faire comme les anciens) et d'être maître de son projet plutôt que de n'être qu'un rouage dans une immense machine.

Mais tout cela nous embraque un peu loin
Bonne nuit à tous !

-
Edité par Umbre37 il y a 2 minutes

Le fait est l'approche décalé dont tu parles n'est rien d'innovant et rien d'inconnu si ce n'est pas utilisé c'est en connaissance de cause. J'ajoute que je n'ai vu aucune réponse "agressive" juste des réponses pour faire passer un message à quelqu'un qui est là pour convaincre et non échanger. 

>Les normes industrielles et les projets à 5000000 de lignes de code ça ne fait pas forcément rêver tout le monde. Si jamais elle débarque dans le monde industriel (elle y travaille peut-être déjà, je n'en sais rien), elle semble assez douée pour s'adapter. Et au pire si c'est pour ses projets perso elle fait bien ce qu'elle veut.

S'il y a autant de lignes de code c'est que c'est nécessaire, peut être en connais tu mais je connais personne qui rêve de. le jour où il y en aura moins c'est que derriere il y a eu encore plus de lignes de codes pour condenser tout ça, personne ne dis qu' elle ne fait pas ce qu'elle veux de ses projets perso mais encore une fois ce n'est pas le sujet. Et je ne pense que quelqu'un ici remet en cause sa connaissance des fonctionnalité proposer par le langage, ce qui est mis en cause c'est le manque de pour ma part je dirai bon sens. 

>Peut-être en plus que Jade a raison et que l'informatique de demain ressemblera à ça : des petits projets indépendants, avec peu de dépendances envers de grosses lib, avec un soucis de l'optimisation bas niveau

Donc en bref revenir 15 ans en arrière ? ou alors j'ai mal compris

>et d'être maître de son projet plutôt que de n'être qu'un rouage dans une immense machine.

> Chaque développeur est maitre de ce qu'il utilise ou non, personne ne va charger une librairie pour faire 1+1. Surtout que personne n'a dis ici ou en tous cas je n'en ai pas vu qu'il est interdit de reprendre certaines partie fait main (mais seulement si plus adapté) 

Umbre37 a écrit:

Je ne suis pas du métier, contrairement à la plupart des intervenants ici. Mais j'ai du mal à comprendre l'agressivité de certains messages. Franchement, si cette méthode d'allocation a 30 ans, qu'elle n'est pas adaptée dans certains cas, qu'est-ce que ça peut faire ?

Ben justement c'est ça le problème , je crois que tout le monde s'en fout que JadeSalina et Casey utilise une technique vielle de 30 ans.
Par contre ce qui plus dérangeant ,c'est quand elle vient pour nous expliquer que c'est bien et que c'est utilisable à 99% des projets.
Donc oui , on en a rien à faire , elle fait ce qu’elle veut et Casey aussi.

avec peu de dépendances envers de grosses lib, avec un soucis de l'optimisation bas niveau.

Alors faudra pas me trigged trop avec "bas niveau" , y'a rien de bas niveau que j'ai pu voir ici pour le moment.
Et sinon , non je ne crois pas qu'on reviendra en arrière avec "l'optimisation bas niveau" , la PS3 a été un bon exemple que c'est impossible de faire ça en jeux AAA , tellement que la PS3 est une des causes que les Jeux video Japonais s'est complètement écroulé entre 2005 et 2015...

Et pour un indé ce genre d’optimisation est un peu overkill.
Personnellement je sais optimiser , mais j'ai jamais vu l’intérêt parce que en faisant des petit jeux sur PC (meme avec un peu de la 3D ) , ben mon jeu utilise juste quelque % CPU et peu de RAM


Un moment on parlait de programmation assembleur , dans les années 80 c'était encore possible d'optimiser de l'asm à la mano, les processeurs était simpliste, vers les années 90 , c'est devenu bien plus complexe (et en 2000 et + n'en parlant pas).
(Parce que oui , les machines se sont sacrément complexifié avec le temps).
Parce que autant ça demande aucune réel expertise d'optimiser un vieux M68000 , autant optimiser un x86 moderne ou un Itanium ou un Cell , ça demande un expert du domaine et donc qu'un particulier ne pourra pas faire (sauf s'il devient expert du dit truc , mais du coup tu développe moins de compétence dans d'autre domaine).

Si vous vous contentez de quelque chose de raisonnable et que vous manquez de temps ou autre pour optimiser au poil de c** le moindre truc, je comprends complètement. Moi j'aime bien chercher à atteindre de très bons résultats, pas simplement "raisonnables", mais je n'ai pas de contrainte de temps non plus. Donc selon les projets, je comprends qu'il y ait des compromis à faire et qu'on préfère atteindre rapidement un truc raisonnable, facilement reprennable par l'équipe suivante, etc, que de partir dans un truc sur mesure etc.

Justement même en partant from scratch , Casey dit beaucoup de bêtise.
Sinon faut vraiment arrêter avec "Casey optimiser un poil de c**" ", Casey ne sait pas optimiser clairement.
On l'a démontré de nombreuse fois ici.
Surtout que optimiser pourquoi faire, quels sont les vrai gain ici ?
Son jeu tourne à 100 FPS , bah sans ces méthodes on serait arriver aussi (et je dirais qu'on pourrai faire largement plus vu les graphismes qu'il fait ....) !
Son jeux utilise peu de RAM ? ça semble pas forcément le cas, enfin rien de plus que avec une autre méthode plus classique.

Non seulement je doute de l'optimisation qu'il fait , mais aussi de l’intérêt de l'optimisation ici , parce que même si un jeux prend 10Mo en plus que nécessaire,  c'est gravissime ? sur PC (et même sur Mobile ) , non en aucun cas.

-
Edité par HelbaSama 30 mai 2022 à 0:19:59

>Donc en bref revenir 15 ans en arrière ? ou alors j'ai mal compris

J'en sais rien, les prévisions donnent 9 milliards d'être humain sur terre en 2040. Chacun avec un smartphone 2^(2040-2022) = 260000 fois plus puissant qu'aujourd'hui (Loi de Moore) ? + tablette + PC + voiture autonome + domotique etc... Qui y croit ? Pas moi, pas sur une planète Terre de taille finie avec des limites d'énergie et de ressources (métaux, terres rares...). L'évolution actuelle du secteur est provisoire et va certainement finir par s'inverser, et donc oui, cela implique un retour en arrière (sauf effondrement tellement brutal qu'il n'y ait plus d'électronique du tout, ce dont je doute). Dans notre monde physique il n'y a pas de croissance infinie, dans aucun domaine, il n'y a que des systèmes qui reviennent à l'équilibre. Ça vaut aussi pour la high-tech. Enfin si quelqu'un a un autre point de vue sur le sujet cela m'intéresse.

-
Edité par Umbre37 30 mai 2022 à 0:03:50

Umbre37 a écrit:

J'en sais rien, les prévisions donnent 9 milliards d'être humain sur terre en 2040. Chacun avec un smartphone 2^(2040-2022) = 260000 fois plus puissant qu'aujourd'hui (Loi de Moore) ? + tablette + PC + voiture autonome + domotique etc... Qui y croit ? Pas moi, pas sur une planète Terre de taille finie avec des limites d'énergie et de ressources (métaux, terres rares...). L'évolution actuelle du secteur est provisoire et va certainement finir par s'inverser, et donc oui, cela implique un retour en arrière (sauf effondrement tellement brutal qu'il n'y ait plus d'électronique du tout, ce dont je doute). Dans notre monde physique il n'y a pas de croissance infinie, dans aucun domaine, il n'y a que des systèmes qui reviennent à l'équilibre. Ça vaut aussi pour la high-tech. Enfin si quelqu'un a un autre point de vue sur le sujet cela m'intéresse.

Quel rapport avec la prog ?

-
Edité par HelbaSama 30 mai 2022 à 0:22:07

J'en ai un différent.

Il n'y a pas de croissance infini ? Je ne pense pas, dans le sens propre du terme évidemment qu'il y a forcément une fin mais tu te bases sur ce qu'on voit aujourd'hui pour prévoir demain. Dans nombre de cas ce n'est pas une manière bête de procéder mais non avec l'évolution.

Je vais prendre un exemple pas mal tordu car le rapport sera peut etre dur a visualiser mais en bref

On vient de decouvrir le feux, on a appris a faire de plus en plus de choses avec mais on crains qu'a force d'en utiliser de plus en plus il n'y ait plus de bois pour tenir ce feu et donc on reviendrait à notre vie sans feu, ça illustre ta phrase.

Mais vient l'ectricite qui diminue l'utilisation du feu ou mieux l'optimise. Vient de le soucis qu'on peut etre à cours de cette ressource aussi, qu'est ce qui te garantis que ne viendra pas une nouvelle "électricité"?

C'est pour répondre à ta phrase du l'évolution de ne peut pas etre infini.

mais si on en reviens à notre domaine et ta phrase du dessus tu disais que les machines sont voué à être de plus en plus puissantes donc on aurait a moins ce soucier de l'optimisation de nos codes la machine pouvant rendre le même resultat, mais tu ne penses pas que le resultat sera meilleur si le code à la base est optimiser ?

Et quand au fait que l'évolution a un frein naturel qui est les ressources disponibles je ne dis pas le contraire car c'est partiellement vrai mais si cette même évolution permet de générer les ressources nécessaires ce qu'on a encore du mal à faire aujourd'hui, alors problème résolu. L'évolution a permis par exemple d'aller voir ailleurs que sur les limites finies de la terre s'il n'y a pas de nouvelles ressources alors dire que forcément arrivé un moment on serait obligé de regresser j'en doutes, je dirai plutôt qu'on serait forcé à trouver meilleure manière d'y arriver

On s'ecarte du sujet original qui est "il ne faut pas écouter tout ce qui est dit" quand l'auteur même n'applique pas ce conseil 

-
Edité par zvheer 30 mai 2022 à 0:27:32

JadeSalina a écrit:

Alors si vous prenez des extraits où il est en justement en train de débugger l'éclairage c'est normal que ça soit pas bon, attendons de voir le résultat final. 

J'ai pris des extraits des dernières vidéos. Et il a juste augmenter l'intensité de la lumière pour mieux voir, mais les problèmes que je signale sont visible dans n'importe quelle vidéo.

Donc non, c'est juste moisi.

JadeSalina a écrit:

Moi j'aime bien chercher à atteindre de très bons résultats, pas simplement "raisonnables", mais je n'ai pas de contrainte de temps non plus.

moi je préfère chercher à faire le meilleur truc possible pour le client.

Va chercher du boulot au lieu de parler dans le vide.

Umbre37 a écrit:

Je ne suis pas du métier

Du coup, comment peux tu avoir la moindre idée de comment les méthodes de producteurs des logiciels vont évoluer ?

Et même si ce que tu décris se réalise, c'est pas du tout l'approche old school de Casey qu'on utilisera, c'est même l'inverse : moins on a de ressources, plus on veut être efficace. On privilégiera encore plus la réutilisabilité du code et des libs, on fera encore moins de from scratch.

Casey n'utilise pas cette approche parce qu'elle est plus efficace, mais parce qu'il est incompétent. Et parce qu'il peut se le permettre : il n'est pas payé en fonction du logiciel qu'il développe, mais en fonction de son blabla.

Et donc :

Umbre37 a écrit:

Si le travail de Casey (que je ne connais pas) peut booster la créativité de ses followers et leur donner envie d'avancer sur des projets, c'est très bien, quand bien même il ne serait pas parfait.

Justement parce que cette approche n'est pas viable en développement pro et que si ceux qui le suivent font la même chose, ils ne seront pas payé comme dev (comme c'est le cas de Jade).

C'est en cela que c'est juste du vent : c'est pas du dev que présente Casey, c'est du divertissement vidéo.

-
Edité par gbdivers 30 mai 2022 à 0:56:05

@Lynix

 J'essaye juste de retrouver l'équilibre dans la Force.

@gbdivers

>Du coup, comment peux tu avoir la moindre idée de comment les méthodes de producteurs des logiciels vont évoluer ?

Parce que ces producteurs sont en dépendance de choses qui les dépassent totalement (et moi aussi d'ailleurs) mais du coup on peut tous avoir un avis dessus : la fin de la croissance économique et du mythe du progrès matériel infini. Fin qui n'est peut-être pas si lointaine. Si on admet l'hypothèse, la question que je pourrais poser à quelqu'un du métier serait alors : "À quoi pourraient ressembler les méthodes de prog dans un monde où la capacité de production d'électronique par habitant décroit (inversion de la loi de Moore) ?" Question très difficile, tellement de paramètres et d'inconnues, mais on peut imaginer des hypothèses.

@HelbaSama

>Quel rapport avec la prog ?

Les logiciels conçus en prog sont destinés à des ordinateurs fabriqués à partir de ressources naturelles. Si on peut faire travailler des armées de codeurs sur des logiciels de millions de lignes de code c'est parce que DE PLUS EN PLUS de gens ont des machines DE PLUS EN PLUS puissantes pour utiliser ces logiciels.

@zvheer

>Mais vient l'ectricite

Ok pour l'analogie, mais de quoi parle-t-on ? Si une technologie miracle peut empêcher une décroissance subie en raison du manque de ressources, du désastre écologique et ses conséquences (économiques, sociales, géopolitiques) ça m'intéresse. On parle parfois de la fusion nucléaire, il paraît que les chinois progressent mais on est encore loin je crois...

Tout cela nous éloigne du sujet.

@All

De toute façon sur le plan technique, je suis moins bon que le moins bon d'entre vous. Je ne peux pas juger de tel ou tel détail d'implémentation dans tel ou tel contexte. Pour toutes les questions d'efficacité de développement avec les outils existants, je fais confiance aux pros du forum les yeux fermés.

Mais indépendamment de tel ou tel point particulier, je crois avoir remarqué une certaine constance dans la démarche de Jade (sans vouloir parler à sa place, elle me corrigera si je me trompe). C'est cette orientation globale qui m'a tout de suite frappé, interrogé.

intérêt pour :

-faire les choses soi-même

-se passer des dépendances, autant que possible

-comprendre vraiment ce qu'on fait (difficile s'il y a trop de couches entre nous et la machine)

-optimisation

-beauté du code

-simplicité de conception

-critiques des pratiques admises dans l'industrie

-conceptions "artisanales"/retro

Tout cela fait sens pour moi dans une perspective plus large, notamment pour les raisons que j'ai indiquées (raisons qu'elle ne partage peut-être pas du tout, je n'en sais rien).

Par ailleurs, certains de ces points sont aussi des raisons pour lesquelles beaucoup de gens prennent plaisir à coder, indépendamment de tout objectif, lorsqu'ils ont la chance de ne pas être soumis aux impératifs de productivité (impératifs qui existent dans le monde pro et c'est bien normal). Mais l'univers du développement est plus large que le monde pro. Beaucoup de gens codent par passion (Cf tous les projets open sources) il y a des situations intermédiaires qui combinent passion et obligations. Vous tous sur ce forum, êtes ici par passion pour le domaine et non par obligation professionnelle. Si vous êtes prêts à passer du temps pour discuter de c++ sans intérêt pro, pourquoi ne pas accepter que d'autres aient un usage du c++ non aligné avec les normes du secteur pro ? Ces personnes cherchent autre chose voilà tout. Il y a l'informatique de l'industrie et l'informatique qu'on aime pratiquer gratuitement. Les deux ne se recoupent pas forcément. (Et encore une fois rien ne dit que les pratiques industrielles actuelles soient l'avenir)

Lynix lui-même qui critique Jade n'en est pourtant pas si éloigné. Passer des années à faire tout seul par soi-même un moteur qui fera moins bien et trop tard ce que les cadors du secteur font mieux et plus tôt : il y a un peu de l'esprit Handmade Hero là-dedans non ? Et encore une fois, je n'ai rien contre. Il y a de la beauté dans tout cela, de la passion et du talent !

-
Edité par Umbre37 30 mai 2022 à 3:07:19

Umbre37 a écrit:

"À quoi pourraient ressembler les méthodes de prog dans un monde où la capacité de production d'électronique par habitant décroit (inversion de la loi de Moore) ?" Question très difficile, tellement de paramètres et d'inconnues, mais on peut imaginer des hypothèses.

Et bien je t'ai donné mon avis : moins on a de ressources, plus on essaie d'être efficace. Et donc pas réinventer la roue. Ton "hypothèse" ne s'appuie sur rien de concret.

La démarche de Casey et Jade est très éloignée de la réalité du développement pro. Présent et futur.

Umbre37 a écrit:

une certaine constance dans la démarche de Jade (...) la chance de ne pas être soumis aux impératifs de productivité (...) Beaucoup de gens codent par passion 

Lynix lui-même qui critique Jade n'en est pourtant pas si éloigné.

Le fait que tu mets les 2 en parallèle montre bien que tu n'as pas compris le fond du problème.

Pourquoi Lynix, qui fait un projet en solo depuis des années sans contrainte du monde pro est complètement opposé à ce que dit Jade et Casey ? Et idem pour tous les projets perso que font les devs expérimentés ici ?

Si on pensait sincèrement que c'était mieux, on utiliserait ce genre d'approche pour nos projets perso, non ?

Pourquoi Lynix et Peuk par exemple, qui sont très critique envers le C++, ne se mettent pas du côté de Casey quand il critique le C++ ?

Pourquoi Helba, qui a fait du jeu vidéo sur console, n'est pas a fond derrière Casey ?

Pourquoi crois tu que je passe du temps a regarder les vidéos que Jade donne ?

La démarche de Casey et Jade est fondamentalement mauvaise. Même pour des projets perso. Les arguments qu'ils donnent sont avant tout de l'incompétence, des fausses idées. On le voit avec Jade qui est complètement fermé aux arguments. Et Casey est pire comme con arrogant.

La différence entre Casey et Lynix est justement ce comportement. Lynix sait que les choix qu'il fait à un moment donné pour un projet en particulier ne sont pas des vérités absolues extrapolables a n'importe quel projet. Lynix ne va pas sur le forum C pour leur dire que leur langage est moisi et qu'il faut qu'ils fassent du C++. Lynix est passionné et curieux et c'est pour ca qu'il discute, apporte des arguments et peut être convaincu qu'il a tort. Et c'est pour ça que Lynix continue d'apprendre alors que Casey et Jade font du code vient de 20 ans en pensant que c'est une nouveauté.

Il y a juste un gouffre entre Casey et Lynix.

Umbre37 a écrit:

C'est cette orientation globale qui m'a tout de suite frappé, interrogé.

intérêt pour :

-faire les choses soi-même

-se passer des dépendances, autant que possible

-comprendre vraiment ce qu'on fait (difficile s'il y a trop de couches entre nous et la machine)

-optimisation

-beauté du code

-simplicité de conception

-critiques des pratiques admises dans l'industrie

-conceptions "artisanales"/retro

Tout cela fait sens pour moi dans une perspective plus large

Sans le vouloir, tu reprends en fait un idée de Jade, qui est complètement fausse : que les intervenant ici ne savent pas de quoi ils parlent.

- faire les choses soi-même

C'est juste une illusion. Casey utilise win32 comme lib de base. En quoi utiliser une fonction getMessage + BN_CLICKED serait plus "faire les choses soit même" que d'utiliser un event Button clicked dans une lib ? En quoi utiliser un malloc serait plus "faire les choses soit même" qu'un std::make_unique ?

-se passer des dépendances, autant que possible

Beaucoup d'entre nous savent écrire un make_unique à partir d'un new, réécrire std::list ou std::vector. Et pleins d'autres structures. Si on ne le fait pas dans les projets, c'est pas par manque d'envie de faire les choses par nous même.

La grosse particularité de Casey, c'est son arrogance. Il ne choisit pas de ne pas utiliser des libs parce que c'est mieux, mais parce que ca flatte son ego, en mode "regardez, c'est moi qui l'ai fait". Un peu comme un enfant qui aurait fait un dessin tout moche, mais qui est fière, parce qu'il l'a fait lui même.

-comprendre vraiment ce qu'on fait (difficile s'il y a trop de couches entre nous et la machine)

Même en utilisant win32 comme le fait Casey, il y a 1000 couches entre son code et le matériel. C'est juste une illusion de croire que l'on sait mieux qu'on fait quand on fait un malloc plutôt qu'un new ou un make_unique. Même avec un "simple" malloc, il y a beaucoup de couches avec le matériel.

On comprend ce qu'on fait parce qu'on a étudié et écouté ceux qui savent. Pas en prétendant tout refaire soit même.

- optimisation

Dit et redis, les codes qu'on a vu sont loin d'être optimisé.

Et le problème n'est pas juste le code, mais la démarche complète. Mauvaise démarche d'optimisation = mauvaise optimisation au final.

Encore une fois, c'est surtout l'ego de Casey qui parle : en faisant 2-3 optimisations, il donne l'impression d'avoir une démarche globale d'optimisation, mais c'est que du vent au final.

Regarde l'extrait vidéo donné par Jade où Casey "optimise" le code : c'est de la micro optimisation et il ne comprend même pas ce qu'il se passe. Et au final, son jeu à des ralentissements, alors que c'est un jeu ultra simpliste. Ca montre une optimisation globale complètement moisie.

-beauté du code

C'est très subjectif, mais pour moi, un code inutilement complexe, comme ceux montré par Jade et Casey, sont loin d'être beaux.

-simplicité de conception

J'en ai déjà parlé, mais la conception n'est pas simple, elle est simpliste. Elle n'est possible que parce qu'il bosse sur des mini projets et que moins il y a de code, moins les problèmes de conception poseront problème.

Sa conception n'est pas du tout scalable. Plus le projet grossit, plus les coûts de la dette technique feront qu'il mettra de plus en plus de temps à implémenter les choses et corriger les bugs.

Regarde les discussions passé sur le forum sans Jade. On passe notre temps a discuter de conception, à essayer de comprendre les impacts a court terme et a long terme des choix qui sont fait. Casey, en bossant sur des mini projets, peut faire de la conception moisie, ca n'aura pas trop d'impact.

-critiques des pratiques admises dans l'industrie

On passe notre temps a critiquer les méthodes, le C++, la conception, l'enseignement, etc. Ce qui se fait, ce qui s'est fait, les idées proposées. Regarde les anciennes discussions, on passe notre temps a critiquer.

Mais la différence avec Jade et Casey, c'est que c'est notre boulot. On sait de quoi on parle, parce que c'est des choses qu'on a pratiqué, qu'on pratique ou qu'on expérimente.

C'est pour cela qu'on connaissait déjà ces approches. D'ailleurs, pour info, j'utilise ces approches aussi au boulot. Et pour être plus concret, puisque tu parles de Entt dans un autre post : j'utilise cette lib au boulot.

-conceptions "artisanales"/retro

Ce point, je te le concède. Mais cela explique le résultat amateur qu'il obtient.

Ce que fait Casey et Jade, c'est loin d'être une approche globale et une perspective plus large. C'est même l'inverse : une espèce de centrisme sur leur propres idées, complètement fermées aux autres idées et incapable de mettre dans une perspective plus large.

---------------------------------------------------------

(Un commentaire important peut être, si tu te pose la question : quand on conseille aux débutants de suivre les méthodes utilisées dans le milieu pro, c'est complètement inutile pour les mini projets qu'ils font. On conseille ça pour des raisons pédagogiques : c'est mieux de commencer à apprendre les choses correctement dès le début, plutôt que découvrir ces choses sur des vrais projets pro)

-
Edité par gbdivers 30 mai 2022 à 5:35:47

Umbre37 a écrit:

Les logiciels conçus en prog sont destinés à des ordinateurs fabriqués à partir de ressources naturelles. Si on peut faire travailler des armées de codeurs sur des logiciels de millions de lignes de code c'est parce que DE PLUS EN PLUS de gens ont des machines DE PLUS EN PLUS puissantes pour utiliser ces logiciels.

Alors :
1) En terme de silicium , on n'utilise pas plus de surface qu'il y'a 10 ans (voir 20 ans pour les gros proc) et c'est pareil pour la RAM , 8 Go ne prend pas 8 fois plus de siclicium que 1 Go d'époque !
2) Le silicium est en abondance sur Terre , bien plus que le pétrole,  et on utilise qu'une fraction de ce silicium , alors avant qu'on tombe en panne de sable sur Terre , y'a de la marge...
3)millions de ligne de code != puissance de calcul.
Linux possède des millions de ligne de code et marche sur des ordi de 20 ans !
Firefox possède des millions de ligne de code et marche sur des ordi d'il y'a 10 ans voir plus.
Bref ça n'a aucun rapport entre le nombre de ligne de code et l’optimisation ou la demande de puissance de la machine.


Après le reste GBdivers à mieux dit que moi !
Et comme JadeSalina ,tu dis des choses "bateaux" , oui on est pas idiot et on connaît bine plus de méthode , je pense qu'un phrase est importante :

" Lynix sait que les choix qu'il fait à un moment donné pour un projet en particulier ne sont pas des vérités absolues extrapolables a n'importe quel projet."

L'importance c'est pas Lynix XD
Non mais , c'est ça ton erreur , de croire que des méthodes sont des vérités absolu et celle d'il y'a 30 ans parce que ça marchais sur une machine "peu puissante".
Pourquoi on codant sur de vielle machine , je me dis pas "ouaw on devrait faire tous pareil" , parce que ce sont pas des vérité absolue , parce que ce sont pas des solutions miracles,  qu'elle ne résout qu'une partie des problèmes ,et que pas mal d'ancienne technique était de la "triche".
Franchement , je pourrais te passer des heures à t'expliquer comment tel jeux utilisait tel technique d'optimisation , pourquoi , il pouvait afficher autant avec tel CPU et tel RAM limité,  mais tu serais aussi étonné non seulement des contraintes de conception , que la solution proposé est tres spécifique (et souvent le gameplay tournait autour de ces contraintes), mais aussi de la non flexibilité du truc.
Je suis pas sur que sur des programmes plus complexe , on n'est envie de faire ça , non mais tu imagine toi utilisé GIMP ou Photoshop avec des contrainte du genre "pas plus de 8 layer et pas d'image au dessus de 1024x1024 ?" Par exemple ?
Alors que GIMP marche sur tout les ordis vendu ,et même sur des machines ancienne ?
Moi j'ai rien contre qu'on se met des contraintes,  mais sur des logiciels dans le genre , on s’en tape un peu , même si ça prendrait un peu plus que la "normal".

Et si tu veux mon avis , même si on devrait programmer avec des ressources "limité" (enfin on reviendra jamais à quelque Mo de RAM hein ) , je ne pense clairement pas que la méthode de Casey soit la bonne.
Arduino est une bon exemple , avant on programmé en asm un microcontrôleur , maintenant on utilise du C++ (assez léger , mais ça reste du C++).

-
Edité par HelbaSama 30 mai 2022 à 8:19:17

J'ai lu un peu en diagonale, donc il y aura peut être des redites. Cependant je voulais quand même revenir sur ceci :

Umbre37 a écrit:

Peut-être en plus que Jade a raison et que l'informatique de demain ressemblera à ça : des petits projets indépendants, avec peu de dépendances envers de grosses lib, avec un soucis de l'optimisation bas niveau. [...] Je crois assez à un avenir low-tech, car dans un monde instable les systèmes qui possèdent le moins de dépendances sont les plus résilients, les plus simples à réparer, remplacer, maintenir.

On va commencer par évacuer un argument qui est sorti plus haut et qui crucial pour tout le reste. "Je n'ai pas de contrainte de temps". Un projet sans contrainte de temps, ça n'existe pas, nulle part, même pour du perso. A minima, on a la contrainte de temps suivante : un jour, on meurt. Mais au delà de ça, il y a des trucs beaucoup plus terre à terre, il y a que 24h dans une journée, plus un projet dure plus la motivation peut diminuer (et merci de ne pas débarquer avec l'ultra naïf "je sais que je ne perdrais pas ma motivation"), plus le temps passe plus les chances que votre projet soit subsumé par un autre augmente, etc. Et si on se place dans le cadre où on souhaite produire pour des utilisateurs (parce qu'à l'heure où on veut être frugal, c'est peut être pas malin de dépenser de l'énergie à produire des trucs pour personne), il y a un truc encore plus simple : l'utilisateur ne peut pas (n'a pas la capacité à) attendre 30 ans que votre outil soit disponible.

Partant de ce point, on va déjà essayer de voir si l'argument tient avec comme seul objectif/contrainte que l'on soit aussi économe que possible en termes d'énergies et de performances. Et il n'est déjà pas très compliqué de voir que ça va coincer si on veut être aussi économe que possible. Est ce que c'est bien raisonnable de penser que refaire à chaque nouveau projet toutes les bibliothèques qu'on pourrait simplement importer (donc leur conception, développement, debug, optimisation) va permettre d'être plus efficace à la fin ? Entre :

• une équipe dédiée au développement conjoint d'une bibliothèque + la mutualisation des efforts de tous ses utilisateurs pour trouver les bugs et soucis de performances,
• une équipe qui doit faire ce même développement (voir, allez, disons qu'elle redéveloppe quoi, 10% de la lib) en plus du logiciel qui va l'utiliser.

Laquelle est susceptible d'obtenir les meilleurs résultats à la fin ? Désolé, mais il n'est pas raisonnable de penser que c'est la seconde. Si une équipe est dédiée au développement de quelque chose 100% de son temps, elle n'a besoin d'avoir que des spécialistes du domaine en question et elle a la capacité à prendre en compte énormément de retours utilisateur. La seconde équipe ne peut pas avoir que des spécialistes du domaine, simplement parce que dans son projet, elle fera sans aucun doute d'autres choses impliquant d'autre domaine (et plus il y a des libs différentes, plus ça devient vrai). Des spécialistes en tout, ça n'existe que dans les films.

Et là, on avait qu'une seule contrainte : les performances. Maintenant, on peut analyser une autre contrainte qui a été évacuée un peu trop rapidement : la sûreté et la sécurité. Parce que clairement s'il y a un autre truc qui est déjà en train de frapper très fort dans le monde informatique (on n'est pas sur un truc hypothétique du tout, c'est déjà là), c'est bien cette contrainte là. Aujourd'hui très loin de se diriger vers de l'artisanal, on professionnalise au contraire au maximum et on améliore à fond les méthodologies de développement et de vérification parce que tout ce qui nous entoure utilise du logiciel et tous nos logiciels prennent des attaques plein de la gueule. Donc maintenant les équipes dédiées au développement des libs, elles n'ont pas juste des gens qui visent à maximiser les performances mais aussi des gens qui doivent s'assurer que c'est fiable. Et encore une fois, dans un groupe de développeur, c'est encore raisonnable d'imaginer d'avoir un tiers ou la moitié des effectifs qui soient des spécialistes en V&V dans le domaine cible. Sur un projet qui n'aurait pas que ce domaine là, on en est à s'imaginer qu'on peut avoir des gens spécialistes sur les plans optimisation/sûreté sur plusieurs domaines différents. C'est plus raisonnable du tout.

En particulier :

car dans un monde instable les systèmes qui possèdent le moins de dépendances sont les plus résilients, les plus simples à réparer, remplacer, maintenir.

Sources ? En particulier pour la maintenance, je suis assez curieux de voir comment maintenir plus de code soi-même peut être plus résilient que permettre une délégation de la maintenance au moins une partie du temps. Je dis ça aussi parce que quand on analyse les CVEs en général, on constate plutôt l'inverse. L'exemple le plus agaçant c'est "nous, on a redéveloppé notre couche crypto from scratch pour être plus rapide et plus sûr". Immanquablement à la fin :

• c'est pas plus rapide (ou tellement peu que ça vaut pas la peine d'en parler),
• si on en entend parler c'est parce que le truc s'est mangé une attaque qui l'a foutu par terre.

Encore une fois, ces considérations sont bien plus facilement réglées en spécialisant des gens pour créer des bibliothèques dédiées. Ça permet :

• de mutualiser les efforts de développement (notamment de choisir chaque fois le langage le plus adapté pour la tâche *),
• de mutualiser les efforts d'optimisation,
• de mutualiser les efforts de vérification.

Bref, de s'assurer que tout le monde bénéficie de ce travail. (* Ben oui, parce que c'est pareil, si on a une équipe de dév qui doit pondre des libs en plus de son projet, on va pas demander à ces devs d'être des spécialistes de 14 langages différents, c'est pas très raisonnable).

@gbdivers

>Sans le vouloir, tu reprends en fait un idée de Jade, qui est complètement fausse : que les intervenant ici ne savent pas de quoi ils parlent.

Attention ! Je n'ai jamais écrit ou pensé une chose pareille. J'ai juste dit que j'avais repéré des idées qui revenaient dans la démarche de @JadeSalina (si ça se trouve elle ne serait même pas d'accord avec la synthèse que j'en propose). J'essaye de comprendre cette démarche, c'est tout.

J'essayais juste de distinguer les bonnes pratiques dans le contexte pro actuel (je fais à 100% confiance aux intervenants du forum pour ça), et la façon dont certains aiment coder, "pour la beauté du geste". Pour moi c'est un peu comme si quelqu'un voulait faire une armoire lui-même et qu'on lui disait "mais non ça ne sert à rien, va chez Ikéa, c'est moins cher, plus fiable, plus résistant, plus efficace, plus rapide, et avec tes vieilles méthodes tu ne pourras jamais monter une usine et faire des milliers de meubles..." Ok, c'est sûrement vrai, mais le mec qui fait lui-même son armoire, même si elle est moins bien finie, plus chère, il peut avoir la satisfaction de l'avoir produite de ses mains, d'en avoir conçu tous les détails (ok, il n'a pas fait pousser les arbres - Cf il y a des couches d'OS, de matériel, dont on ne peut pas se passer et dont on dépend toujours). Et il a peut être appris davantage en faisant cela, sur la menuiserie en général et sur lui-même.

D'accord ce serait abusé que ce type là aille chez Ikéa donner des leçons. Mais ici on est ni dans une usine Ikéa, ni dans le garage d'un particulier, on est à un endroit où des gens qui aiment faire des meubles échangent des infos et s'entre-aident, c'est tout.

Ok l'analogie a surement des limites, et encore une fois je ne suis ni d'un côté ni de l'autre. C'est l'agressivité que je ne comprends pas. Je n'ai jamais traité personne d'incompétent ici (@JadeSalina non plus de ce que j'ai pu lire) et ça ne me viendrait jamais à l'esprit. En revanche dans l'autre sens...
Je préfèrerais juste que tout le monde s'entende, même si les démarches ne sont pas les mêmes.

-
Edité par Umbre37 30 mai 2022 à 11:48:20

Alors il te faut relire plusieurs passages

remettre en cause les connaissances de personnes qui ont passé des années à travailler sur leur domaine parce qu'un gars sur youtube a dis que ce qu'il se faisait il y a 20 ans est meilleur revient à la même chose.

Même si ici pour moi ce n'est pas tant casey le soucis, car peut importe à quelle point quelqu'un peut dire n'importe quoi en face ou dire des choses intelligente si tu as du bon sens tu en tireras tes conclusions, là ici c'est ça le soucis il/elle n'en tire pas ses conclusions il/elle conserve celle qui lui ont été dîtes et se base sur des arguments pas mal bancales. 

C'est totalement faux mais personne ne s'est contenté de dire c'est "faux" quasiment à chaque fois un argumentaire lui a été apporté avec, argumentaire dans lequel il/elle prend une partie qui lui porte, et repart sur une nouvelle chose.

Que tout le monde s'entende je dirai que ce n'est pas trop possible car malgré la partie du bon sens, chacun à sa maniere de faire un peu les choses mais s'il y a bien des choses sur lesquels rien que le bon sens ne te permet pas de dire le contraire comme de refaire une lib, 

-
Edité par zvheer 30 mai 2022 à 11:50:47

Umbre37 a écrit:

J'essayais juste de distinguer les bonnes pratiques dans le contexte pro actuel (je fais à 100% confiance aux intervenants du forum pour ça), et la façon dont certains aiment coder, "pour la beauté du geste". Pour moi c'est un peu comme si quelqu'un voulait faire une armoire lui-même et qu'on lui disait "mais non ça ne sert à rien, va chez Ikéa, c'est moins cher, plus fiable, plus résistant, plus efficace, plus rapide, et avec tes vieilles méthodes tu ne pourras jamais monter une usine et faire des milliers de meubles..." Ok, c'est sûrement vrai, mais le mec qui fait lui-même son armoire, même si elle est moins bien finie, plus chère, il peut avoir la satisfaction de l'avoir produite de ses mains, d'en avoir conçu tous les détails (ok, il n'a pas fait pousser les arbres - Cf il y a des couches d'OS, de matériel, dont on ne peut pas se passer et dont on dépend toujours). Et il a peut être appris davantage en faisant cela, sur la menuiserie en général et sur lui-même.

Ton analogie est fausse , parce que même si on parle "d'artisanat" , les pratiques de Casey (ou de JadeSalina) sont mauvaise.
Faire son propre meuble, c'est aussi une expertise , et pas sur que si tu fais n'importe quoi , sur un forum de menuiserie les mecs te diront rien , ils te diront  que tu fais n'importe quoi et que même en particulier, tu peux faire les choses correctement et de façon propre.

Quand on parle de technique d'il y'a 30 ans, je dis pas qu’elle est mauvaise , c'est que cette technique est connu (que j'utilise dans certain cas particulier), donc inutile de soûler tout le monde avec ça.
Le second point c'est que Jade (et casey ) , dise que c'est la meilleur technique , alors qu’elle comme toute technique des points fort et des points faible.
Et le pire c'est que Jade insiste qu'on devrait l'utiliser , utilise des arguments autorité (Casey /Hanmade Hero), alors que non , tout le monde est assez intelligent pour savoir si cette technique est approprié ou pas à ces besoins.

Pour faire simple , sur le Discord de Lynix , il y'a des personnes qui veulent faire du Jeux video , on leur conseille Unity ou UE , mais si vraiment quelqu'un veut faire tout de lui même chaqu'un proposera des méthodes , avec les avantages /inconvénients.
Pourquoi je dis ça ?
Parce que ce n'est pas la démarche de Jade , sa démarche ,c'est pas d'avoir un échange,  mais juste (comme elle le dit) , de passer le message de Casey.
Je cite ce qu'elle dit :
"
Je veux juste propager la puissance de Casey

je ne voulais pas garder cette découverte magique pour moi"

Tu comprend le soucis de la discussion ?

-
Edité par HelbaSama 30 mai 2022 à 13:19:47

Umbre37 a écrit:

J'essayais juste de distinguer les bonnes pratiques dans le contexte pro actuel (je fais à 100% confiance aux intervenants du forum pour ça), et la façon dont certains aiment coder, "pour la beauté du geste". Pour moi c'est un peu comme si quelqu'un voulait faire une armoire lui-même et qu'on lui disait "mais non ça ne sert à rien, va chez Ikéa, c'est moins cher, plus fiable, plus résistant, plus efficace, plus rapide, et avec tes vieilles méthodes tu ne pourras jamais monter une usine et faire des milliers de meubles..." Ok, c'est sûrement vrai, mais le mec qui fait lui-même son armoire, même si elle est moins bien finie, plus chère, il peut avoir la satisfaction de l'avoir produite de ses mains, d'en avoir conçu tous les détails (ok, il n'a pas fait pousser les arbres - Cf il y a des couches d'OS, de matériel, dont on ne peut pas se passer et dont on dépend toujours). Et il a peut être appris davantage en faisant cela, sur la menuiserie en général et sur lui-même.

Ah, j'adore cet exemple...

Car, savais tu  que j'ai une formation de menuiserie / ébénisterie à  la base? Et comme je suis aussi développeur informatique, spécialisé en C++, je crois être pour le moins qualifié pour faire la comparaison

Commençons par nous mettre d'accord sur le style de meuble que nous voudrions créer.  Mettons que ce soit une armoire "simple": une seule porte, 200 cm de haut, 80 cm de large, 60 cm de profondeur (des mesures finalement classique) trois planches intérieures.

Première question: bois massif ou panneaux? 

Le bois massif aura l'avantage d'être plus résistant: si tu t'y prends correctement, tes (arrières) petits enfants pourront en hériter, même si tu  la fait  en sapin.  L'inconvénient, c'est qu'il te faudra un outillage beaucoup plus spécifique pour pouvoir le faire, surtout si tu pars sur l'idée de partir du bois brut. Et le prix du bois est excessivement cher.

En effet, à partir du bois brut, et une fois que tu a "débité" tes pièces (il te faudra, pour y arriver, ce que l'on appelle une scie à  bande : on en trouve à 150€ qui devraient pouvoir faire l'affaire ), il faudra

les "dégauchir" : créer au moins deux faces plane et perpendiculaire

les "raboter" : obtenir rendre les deux autres faces plane et parallèles aux deux premières

les "usiner" en fonction de leur utilisation, à savoir:

• (peut être, si tu veux faire vraiment les choses très bien) créer un ensemble de rainure et de languette pour assembler ce qui sera des "panneaux"
• créer des rainures dans lesquelles viendront s'insérer les panneaux dans les montants et les traverses
• creuser une mortaise dans les montant pour chaque traverse qui viendra se fixer dessus
• créer un tenon à chaque extrémité de chaque traverse pour le fixer aux montants équivalent (dans les mortaises)
• éventuelllement, mais c'est surtout esthétique, moulurer le coté "intérieur" des montants et des traverse, ce qui implique la création d'un onglet à chaque extrémité, pour  que la moulure du montant "s'emboite" correctement à la moulure des traverses

Voilà, de manière simplifiée, le travail auquel tu dois t'attendre si tu décides un jour de fabriquer ta propre armoire.

Pour y arriver, tu as le choix des outils entre ce genre d'outils:

et  une machine comme celle-là:

Tu devrais t'en sortir pour sans doute à peine plus de 100€ avec la première série d'outils, alors qu'il faudra compter sans doute 3000€ minimum pour la machine en occasion.

Seulement, si tu décide de le faire à la main, tu dois compter que tu en as au moins pour un à deux mois, cinq jour sur sept, huit heures par jour, pour avoir ton armoire. Surtout si tu sais pas trop comment t'y prendre.

Avec la machine, en une semaine, hors temps de collage, tu devrais avoir fini.

Les panneaux (de particules, de fibres ou "multiplex" on l'avantage d'être "beaucoup plus abordables" par leur prix. Leur principal inconvénient est de supporter beaucoup moins bien les contraintes (déplacement, démontage, et autres), même si toutes les techniques "pro" sont utilisées.

Pour faire ton armoire en panneaux, tu utiliseras sans doute ce genre d'outils:

Et si tu prend le temps de réfléchir et d'organiser correctement ton travail, en un à deux jours, elle pourra être finie

Dans les deux cas, il ne faudra pourtant pas oublier d'acheter les charnières, une poignée, et idéalement un loquet quelconque, pour pouvoir ouvrir et / ou verrouiller la porte

Mais, as tu remarqué que, après les matériaux et la manière de s'y prendre, la première chose dont j'ai parlée c'était ... les outils?

Car il ne te viendrait pas  à l'idée d'entreprendre n'importe quel travail de menuiserie ou d'ébénisterie sans "un minimum d'outillage" ou sans le matériau qui te permettra de faire le meuble dont tu rêve, n'est-ce pas?

Dis toi bien qu'il en va exactement de même en informatique, et qu'il n'y a aucune raison pour qu'il en aille différemment. La seule chose, c'est que les matériaux et les outils sont plus "abstraits", et pour cause, vu qu'il se résument tous au final à une succession de bits:

Tes outils, ce seront ton compilateur et les bibliothèques qui permettent de ne pas "perdre inutilement ton temps" à ... faire comprendre certains aspects que tu  ne maîtrise pas forcément. Tes matériaux seront les (structures de) données que tu utiliseras, et la "méthode de travail" seront les algorithmes que tu implémentera ou que tu récupéra des bibliothèques externes.

Ce à quoi je voulais en venir c'est ceci: bien que l'informatique soit "abstraite" par nature, tu as toujours besoin de "matériaux" et de "matériel" pour pouvoir programme.

Si tu ne va pas à la forge pour fabriquer ton bédane ou que tu ne décide pas de construire ton propre maillet, pourquoi voudrais tu décider de mettre en place ton propre allocateur (par exemple), alors que celui dont tu dispose "dans ta boite à outil" fait correctement le travail?

Et ton client ne va pas vouloir attendre (et payer) 5 mois de plus juste pour ton optimisation au poil de cul, alors qu'il s'en contrefout parce qu'il n'en a pas besoin.

Oui je dit pas le contraire, si on en a pas besoin. Mais on voit bien que ce n'est pas le cas, c'est extremement pénible toutes les lenteurs qu'on se prend dans tous les logiciels. Quand on veut renommer une variable et qu'on attend plusieurs dizaines de secondes vous trouvez ça normal ? Vous vous sentez pas débiles d'être là à attendre avec un PC qui peut faire des dizaines de milliards de calculs par seconde ? Pour l'exemple de GTA Online vous pouvez rien dire, c'était effectivement codé comme de la m**** et Rockstar a sorti un patch et a filé 10k$ à la personne qui a signalé le problème (https://support.rockstargames.com/articles/360061161574/GTAV-Title-Update-1-53-Notes-PS4-Xbox-One-PC)

S'il y a autant de lignes de code c'est que c'est nécessaire

Et dans Windows avoir 10 sliders différents pour controler le volume et tout autant de menus contextuels différents c'était nécessaire ? Non ils ont juste rapatrié les vieux trucs et en on refait de nouveaux par dessus (c'est ça que je voulais dire quand je disais qu'il y avait trop de lignes par rapport au problème à résoudre en lui même, c'est pas par rapport à la couverture de code).

Va chercher du boulot au lieu de parler dans le vide.

Bof non ça prend trop de temps dans la semaine c'est nul, je préfère jouer au loto

moins on a de ressources, plus on veut être efficace.

 Oui

On privilégiera encore plus la réutilisabilité du code et des libs, on fera encore moins de from scratch. 

Oui ça c'est "efficace" dans le sens "temps passé", mais c'est pas vraiment efficace en terme de code qui tourne sur la machine réelle. Ou alors les libs en question c'est que des single headers qui font un truc et un seul de la façon la plus minimale possible, mais absolument pas des gros trucs qui essayent d'être le plus générique possible, sinon c'est ce qu'on aurait fait à l'époque où on avait de vrais contraintes.

Lynix ne va pas sur le forum C pour leur dire que leur langage est moisi et qu'il faut qu'ils fassent du C++

Aha je suis sure que ça démange certains d'entre vous de vous retenir de faire ça 

En quoi utiliser une fonction getMessage + BN_CLICKED serait plus "faire les choses soit même" que d'utiliser un event Button clicked dans une lib ? En quoi utiliser un malloc serait plus "faire les choses soit même" qu'un std::make_unique

Bah plus on est proche du métal, plus on fait les choses soi même, si on peut directement utiliser l'OS pour faire ce qu'on veut plutôt que de passer par une lib qui finira par contacter l'OS de la même manière, c'est plus "direct". Même si je reconnais que on peut avoir envie de juste se reposer sur une lib qui gère ces détails là pour pas avoir à se demander pourquoi depuis telle mise à jour tel truc ne marche plus, mais ça reste moins "from scratch". Et Casey n'utilise pas malloc qui est bien trop haut niveau par rapport à ce dont il a besoin.

Et vous dites qu'il faut réutiliser le plus possible, mais ça vient aussi avec son lot d'emmerdes, ce n'est pas la solution ultime qu'il faut absolument viser. Si on passe au final plus de temps à comprendre/intégrer/mettre à jour la lib alors qu'on aurait pu directement faire ce qu'on voulait, c'est pas très malin (pour reprendre l'exemple extrême de faire 1+1). Autre exemple, si on a pas de libs externes, on a pas le problème de la gestion des dépendances, qui est très très chiante en C++ et qui oblige à utiliser encore d'autres outils qui peuvent également foirer, ou ne pas supporter telle ou telle version, et au final à se retrouver à passer plus de temps à configurer le build system qu'à résoudre le problème initial (oui Lynix il faut que je teste xmake)

Même avec un "simple" malloc, il y a beaucoup de couches avec le matériel

Oui, mais il y en a quand même moins (et il n'utilise pas malloc).

Un autre exemple très intéressant de ce que ça peut couter d'utiliser des libs au lieu de le faire soi même : le truc est bugué pendant plusieurs années, tant pis pour ce que ça dérange ils ont qu'à attendre ces sagouins (https://developercommunity.visualstudio.com/t/bogus-stdthis-threadsleep-for-implementation/58530) 

Tout ce foin alors qu'ils auraient pu faire

void sleep(const std::chrono::duration& d)
{
#if WINDOWS
 Sleep(std::chrono::duration_cast<std::chrono::milliseconds>(d));
#elif UNIX
  usleep(std::chrono::duration_cast<std::chrono::microseconds>(d));
#else
  #error Unimplemented sleep
#endif
}

Pas forcément d'une manière aussi simpliste, mais vous voyez l'idée. Et oui pourquoi pas aussi utiliser std::chrono, même si la syntaxe est un peu verbeuse, je met pas ce genre d'utilitaires au même rang que d'autres trucs de la lib standard.

Mais dans le premier code, ce que je vois, c'est toute la m*** qu'il y a derrière que fait la lib standard, à aller allouer le truc, le détruire, etc. Alors que c'est géré tout aussi automatiquement avec la seconde méthode, mais d'une manière beaucoup plus rapide, et déterministe (car oui les compilateurs ont chacun leur version de la STL, c'est pourquoi même Lynix préfère utiliser d'autres containers que ceux de la STL). Et cerise sur le pompon, avec la seconde méthode, on peut trivialement suivre toutes les allocations faites dans le programme, puisque c'est explicite (on a pas une vue aussi fine de sa mémoire juste en redéfinissant operator new/delete)

Après là je critique std::vector, mais c'est le deuxième container le plus simple de la STL, et donc qui dit simple, dit difficile de foirer l'implémentation du truc, je dirais même que de toute la STL, c'est le truc qui a le plus de chance d'être efficace et de bien fonctionner. Mais d'une manière générale je préfère avoir un meilleur contrôle sur ce qui se passe.

Sa conception n'est pas du tout scalable. Plus le projet grossit, plus les coûts de la dette technique feront qu'il mettra de plus en plus de temps à implémenter les choses et corriger les bugs.

 Vous auriez un exemple de chose qu'on voudrait rajouter par exemple dans Handmade Hero et qui serait difficile à implémenter, de par la conception de son code ? Lui en tout cas, de toute la série, il a pas vraiment eu de mal à faire ce qu'il voulait.

Si cette façon est plus efficace pour lui, il vaut mieux qu'il le fasse comme ça non ? Chaque personne/équipe doit faire les choses d'une manière qui leur facilitera le travail je pense, même si ça sort de ce que d'autres auraient pu faire.

Après peut être que Casey est spécial et que pour lui ce genre de code est très lisible car il a commencé à coder à 7 ans (si bien qu'il avait du mal en math car il comprenait pas que "=" c'était une égalité et non une affectation https://guide.handmadehero.org/intro-to-c/day2/#2235 et https://guide.handmadehero.org/code/day609/#7032)

Mais cela explique le résultat amateur qu'il obtient.

 Cela fait peut être amateur de tout refaire from scratch (je rappelle que c'est une série Twitch où le but c'est de le faire à la main et pas un vrai projet), mais si je télécharge Unreal Engine 5 et que j'obtient en 5 min un résultat plus impressionnant que Casey, ça veut pas dire que je sais mieux le faire que lui, puisque j'aurais juste utilisé un truc tout fait. C'est peut être ce qu'il faut faire dans un vrai projet où on a pas le temps etc (d'ailleurs CDProjekt abandonnent leur moteur maison au profit d'UE5 https://twitter.com/UnrealEngine/status/1511368056005709826) mais le résultat c'est la personne qui utilise un truc tout fait passe à côté de l'occasion de savoir comment ça marche, et donc de progresser, et éventuellement devenir un expert du domaine (vous croyez que les innovations d'UE5 c'est des mecs qui ont juste réutilisé des trucs existants ?)

Lynix sait que les choix qu'il fait à un moment donné pour un projet en particulier ne sont pas des vérités absolues extrapolables a n'importe quel projet.

J'ai jamais dit que les trucs de Casey étaient des solutions miracles bulletproof, bien entendu qu'il y a des circonstances plus ou moins adaptées, etc. Mais quand je vois des gens faire n'importe quoi pendant X mois et finir tant bien que mal par se rapprocher d'une solution à la Casey après confirmation du problème par profiling, c'est juste un peu ridicule, alors qu'ils auraient pu faire un truc mieux direct. Et je vais peut être encore vous perdre, mais j'ai pas dit qu'il fallait à tout prix optimiser , comme vous dites, c'est probablement pas nécessaire sur des machines modernes, etc. Mais ce que je veux surtout dire, c'est qu'il ne faut pas pessimiser . C'est trop long à expliquer https://www.youtube.com/watch?v=7YpFGkG-u1w 

J'ai juste dit que j'avais repéré des idées qui revenaient dans la démarche de @JadeSalina

Oui c'est bien ça c'est un bon résumé

parce qu'un gars sur youtube a dis que

Youtube ou autre c'est juste l'endroit où la personne exprime ses idées, il y a même de grosses personnalités sur Twitch (au pif Stephen Wolfram) Et je suis pas sure que "un gars sur openclassrooms" sonnerait plus crédible (on parle du site initialement sorti de la tête d'une personne de 13 ans qui veut rendre les cours fun parce que olala c'est chiant de réfléchir il faut s'amuser lel)

s'il y a bien des choses sur lesquels rien que le bon sens ne te permet pas de dire le contraire comme de refaire une lib,

 Et bien vous savez quoi ? Casey est d'accord !!!! à condition que la lib soit bonne (c'est peut être là que la définition de "bonne" n'est pas la même pour vous)

"If all libraries were as good as stb headers, Handmade Hero would be called "let's use a ton of libs to make our game"" https://guide.handmadehero.org/code/day163/#1470 

Et je trouve aussi qu'il est un peu extrême parfois, personnellement je pense qu'il y a quand même de bonnes libs qui font bien leur taf (comme entt, dear imgui, ...)

Le second point c'est que Jade (et casey ) , dise que c'est la meilleur technique , alors qu’elle comme toute technique des points fort et des points faible.

 Casey je ne sais pas jusqu'où il peut prouver que ses techniques fonctionnent partout (d'après lui c'est souvent), il ne finit pas de m'étonner à chaque fois qu'il fait un truc à sa manière, mais moi je reconnais que ça reste une technique comme une autre et que à ce titre elle a des avantages/inconvénients. Le problème c'est surtout que je l'ai vu strictement nul part ailleurs. En C++ je comprends, vous avez d'autres façons qui peuvent imiter le truc tout en étant propre, mais en C je vois encore des gens faire des malloc/free n'importe où alors qu'un allocateur pile aurait pu faire le taf en plus performant, safe (pas d'oubli de free) et lisible (peut être que je devrais parler de Casey à mes amis du forum C ). Du coup vous avez bien jugé que ça ne permettait pas de faire ce que vous vouliez, ou alors c'est une technique qui vous est trop étrangère (je parle surtout en C) ? Moi aussi au début de Handmade Hero je comprenais rien, ni comment il pouvait se passer de tableaux dynamique mais la preuve que si. Et vous dites "tant mieux si il en a pas besoin" mais je pense que vous sous estimez les possibilités, parce que vous auriez plutôt pensé le truc "intuitivement" tel qu'on l'apprend à l'école, à avoir une liste d'éléments, qu'on crée, détruit, etc, et pas de cette façon, qui est plus "globale" et automatique.

Par rapport à l'avenir du domaine, je ne sais pas ce qui va se passer, on verra bien, mais sachez qu'il n'y a pas que Casey qui défend ce genre de choses, il y a par exemple https://handmade.network/ (vous pouvez lire leur "manifesto") et c'est un projet qui n'est pas directement lié à Casey (ça vient pas de lui et il ne suit pas ce qui se passe). Une hypothèse intéressante que j'ai, serai qu'au bout d'un moment, il y aurait un "stop" général dans l'empilement de code comme on fait aujourd'hui, et qu'on repartirai de zéro, mais en ayant les connaissances acquises depuis toutes ces décennies (car oui, l'informatique n'a même pas 1 siècle d'existence, c'est ridicule par rapport aux maths qu'on faisait déjà 2000 ans avant JC). Vous le dites vous même que c'est chiant de se trainer des vieilleries du C dans le C++, bah comme ça on pourrait tout reprendre "proprement" de zéro, ça serait cool non ? Evidemment ça serait un projet titanesque, et si vous voulez mon avis je pense si ça doit se faire, ça sera fait progressivement, comme ce qu'on voit un peu aujourd'hui avec de nouveaux langages qui apparaissent comme Rust.

Plus on empile des trucs tous fait, moins on a le contrôle global sur le truc final (évidemment), mais on perd aussi en compétences sur le long terme, ce qui pourrait provoquer un "collapse" de la civilisation (https://www.youtube.com/watch?v=pW-SOdj4Kkk)

Car, savais tu que j'ai une formation de menuiserie / ébénisterie à la base?

mdrrrr tant de rebondissements sur ce forum 

pourquoi voudrais tu décider de mettre en place ton propre allocateur (par exemple), alors que celui dont tu dispose "dans ta boite à outil" fait correctement le travail?

Oui bien sûr que si on a dans les mains un truc qui fait le taf il parait difficilement justifiable de perdre du temps à aller en faire un autre, je ne dis pas le contraire (attention toutefois à ne pas finir comme dans Wall-E où tout le monde est devenu des gros lards qui ne savent plus rien faire car les robots font tout, chose qui va aussi arriver chez nous je l'espère, vous croyez pas que je vais me lever tous les matins pour aller bosser sur des trucs chiants). Mais uniquement si ça fait le taf, par exemple Lynix voulait streamer des GIFs, chose qui n'est pas proposée par les libs existantes, donc il a fallu le faire soi même, ou alors des fois ça "fait le taf" mais pas super bien, ou alors c'est chiant à utiliser ou autre.

-
Edité par JadeSalina 30 mai 2022 à 22:58:49

J'ai les oreilles qui sifflent.

Je pense que c'est une perte de temps de chercher à convaincre JadeSalina de quoi que ce soit. Le débat pourrait réellement être intéressant mais il est stérile, cependant je voudrais quand même rebondir sur les quelques vingt fois où j'ai été cité rien que sur la page 5 du topic.

Umbre37 a écrit:

Lynix lui-même qui critique Jade n'en est pourtant pas si éloigné. Passer des années à faire tout seul par soi-même un moteur qui fera moins bien et trop tard ce que les cadors du secteur font mieux et plus tôt : il y a un peu de l'esprit Handmade Hero là-dedans non ? Et encore une fois, je n'ai rien contre. Il y a de la beauté dans tout cela, de la passion et du talent !

Petit rappel de pourquoi je fais Nazara. La grosse différence entre moi et Casey c'est que je ne recommande pas à d'autres de suivre la même voie que moi, car je pense que j'aurai pu être incroyablement plus efficace dans mon apprentissage autrement. Et je ne vais pas fanfaronner en stream ou sur les forums sur à quel point mes techniques sont meilleures, car quand bien même j'ai tendance à tout refaire moi-même, je fini souvent par réinventer quelque chose qui existe déjà. (Le fameux allocateur dont tu parles JadeSalina par exemple, il est à la base de toutes mes allocations destinées au GPU, et évidemment que c'est connu depuis des lustres, mais ça n'a pas que des avantages).

Évidemment que les solutions sont à adapter selon les problèmes, évidemment que les solutions de la STL sont génériques et donc imparfaites dans 100% des cas, mais on ne cherche pas à atteindre la perfection (ou même l'excellence) dans 100% du code, parce que ce n'est pas possible.

HelbaSama a écrit:

L'importance c'est pas Lynix XD

 Allons allons, n'allons pas vers de tels extrêmes. 

JadeSalina a écrit:

Aha je suis sure que ça démange certains d'entre vous de vous retenir de faire ça 

 On est pas assez puérils pour ça. (Faites du Rust !)

JadeSalina a écrit:

 c'est pourquoi même Lynix préfère utiliser d'autres containers que ceux de la STL).

Ah bon ? Mince alors, il faudrait que je me mette au courant.

JadeSalina a écrit:

(peut être que je devrais parler de Casey à mes amis du forum C ).

Si ça te fait passer moins de temps sur le forum C++, n'hésite surtout pas.

-
Edité par Lynix 30 mai 2022 à 15:39:09

C'est dommage que ce Casey se la pète autant, et que Jade l'idolâtre aussi aveuglément, parce que moi les screenshots montrés ci dessus sur le jeu de labyrinthe, j'aime bien !

J'aime bien tout ce qui est rétrogaming, vieux algos pour faire des choses (même dépassés), vieilles techniques, anciennes optimisations, etc... 

Et dans un autre contexte, je trouverais ça chouette d'échanger sur toutes ces techniques proposées.

Mais voila, la on est face à un mec qui se prend pour un gourou et ne tolère que ce qu'il fait lui même (un nuisible dans une boîte de prog), et franchement Jade... normalement à un certain age on a passé l'age d'être une groupie non ? On dirait une fan de Claude François la ! Hhhhhhiiiiiiiii !!!! Cloclo !!!!!! 

On peut trouver quelqu'un de très intéressant sans en faire une divinité non ? parce que tu nous le vends très très mal ton Casey ! 

Je ne sais pas si l'un d'entre vous a encore la force d'argumenter mais courage à lui, ce n'est réellement plus la peine. 

>Aha je suis sure que ça démange certains d'entre vous de vous retenir de faire ça  ( sur la phrase le Langage C c'est de la merde)

Le nombre de choses que tu utilises basés sur du C, le C++ n'est pas sorti de nulle part non plus mais bon la bêtise fait dire des choses vraiment.....

Il y a mieux mais le " c'est de la merde" c'est n'importe quoi.

Le fait est que dans beaucoup de tes argumentations tu melanges l'incompétence du développeur et les fonctionnalités du langages. Si tu es nulle en C ou ne souhaites pas prendre les précautions qu'il exige dans son code c'est TOI et non le C le soucis. Tu ne vas pas dire que nodejs c'est de la merde parce que tu es nulle dans la gestion de asynchrone.

En bref je suis bien d'accord qu'il y a mieux, que certaines cjoses sont mal foutues mais bon.

Ps: j'adore le parler de casey à mes amis du forum C.

Si c'est pour dépité les mêmes choses je doute qu'on soit tes amis. 

-
Edité par zvheer 30 mai 2022 à 16:44:38

Moi, je vote pour que Jade aille sur le forum C !

Fvirtman a écrit:

J'aime bien tout ce qui est rétrogaming, vieux algos pour faire des choses (même dépassés), vieilles techniques, anciennes optimisations, etc... 

Je trouve pas que ça fasse rétro gaming. Pour les éléments 2D, peut etre, mais le style général du jeu, bof.

Cette discussion s'éternise et ne fait que remonter sur le forum rendant pénible le suivi des autres questions.

J'ai compté elle à cité 13 fois Casey , et elle a fait toute une biographie , et c'est que des superlatif (il comprend, il dit ça, il a fait ça ) , outch c'est violent autant de fanatisme ,et comme je l'ai dit , c'est le premier truc à régler chez elle , à la limite apprendre la prog C++ c'est vraiment secondaire dans son cas...

J'aime bien tout ce qui est rétrogaming, vieux algos pour faire des choses (même dépassés), vieilles techniques, anciennes optimisations, etc... Et dans un autre contexte, je trouverais ça chouette d'échanger sur toutes ces techniques proposées.

Alors j'aime bien parlé retrogaming, et j'ai même créer une communauté de dev retro francophone qui échange pas mal de technique sur les vielles machines.
De même que pas mal programme sur ces vieux coucou
Après j'ai jamais eu l'idée de faire ça sur le forum , ça pourrait intéressait peut être des gens , mais bon à voir , j'ai toujours l'impression un peu d'ennuyer du monde en expliquant comment on faisait à l'époque .
D'ailleurs on a découvert pas mal de "fausse légende" grâce à ça , certain jeux avait des légendes urbaine :
-super aleste était réputé que le processeur sonore aidait pour le jeu , mais quand tu code sur SNES, tu découvre que c'est impossible, la communication entre les deux est tellement lente que ça semble impossible que le processeur sonore puisse faire quoique ce soit (surtout que le processeur sonore et le processeur principal ,ne partage aucune donnée , y'a qu'un bus de communication).
-encore sur SNES , Street Fighter alpha (2 je crois) , a un temps de latence au début du combat (genre 2-3 secondes ) , pas mal disait que c'était la décompression des data.
Mais c'est probablement encore le taux de transfert processeur sonore <-> CPU qui est long , parce que le jeux commence avec une voix qui fait commencer le combat  , mais il doit prendre une certaine place dans la RAM sonore,  donc il ne peut pas stocker les effet sonore, donc pendant le début du jeu , il font un transfert des effets sonore , (qui est sûrement assez long ) et qui freeze le jeu.

Pour cela que ça me trigged un peu quand je lis "Casey et optimisation" , le mec est à mille lieux de savoir optimiser ou de faire du bas niveau.
Quand tu connais bien ces deux choses Casey , c'est un petit rigolo.

Et c'est aussi ce que je trouve "dommage" , parce que forcément y'a quelque technique intéressante à faire (si on veut faire un jeux vidéo from scrath rapidement , tout en ayant un bon résultat)  , si Umbre37 ou JadeSalina veut apprendre d'ancienne technique , moi je suis ouvert , y'a pas de soucis
Mais bon pour JadeSalina , ça sera difficile, parce que je crois que j'ai assez entendu de "Casey" pour toute ma vie ^^'

-
Edité par HelbaSama 30 mai 2022 à 17:16:22