c'est pas ça le problème, c'est qu'il est plus facil d'écrire des conneries en C qu'en beaucoup d'autre langages (tous sauf asm et Forth à ma connaissance).
Il faut utiliser son intelligence sur d'autres trucs que sur des indices de tableaux et autres conneries d'allocation (sur avec les pb d'allocation explicite d'on j'ai déjà discuté ailleur) et même d'implémentation.
Etre trop proche du métal fait réfléchir localement au lieu de prendre de la hauteur (genre optimiser les structures de données au lien de schéma général).
Quand je parle d'Ocaml, c'est un nouveau défit, mélanger classes et modules, rien qu'en restant imprératif c'est déjà autre chose que de préfixer ces noms de fonctions par le nom de la biblothèque et se taper des macro #define super dangereuses quand ça se complique.
L'important c'est la facilité avec laquelle on évite le bug, se cracher violement sur une exception est déjà plus saint que de corrompre le tas ou la pile. Surtout si ça crache systématiquement.
Il est d'autre part important de limiter les effets de bords, ils obligent à une réflexion permanente à l'état dans lequel on va retrouver un bout de mémoire à l'entrée dans une fonction.
D'autre part, il y a une culture "élitiste" qui veut que programmer en C soit le top et qu'en plus ce soit difficile. Alors qu'apprendre au plus tôt des langages modernes et variés ferait avancer beaucoup plus vite l'informatique. Le C est un langage quasiment inutile à l'informatique, les codeurs de noyeaux et autres drivers sont marginaux et devraient utiliser ADA.
L'histoire de coder un SGBD en C est à mon sens une vaste connerie (ça vaut des millions les données qu'il y a dedans, autant éviter q'une erreur conne foute tout en l'air).
Bon j'arrête là parce que siono y'en a pour 10 pages et j'ai parlé que de caml comme alternative.
[^] # Re: Mort de rire
Posté par Dugland Bob . En réponse à la dépêche wu-imapd. Évalué à 3.
Il faut utiliser son intelligence sur d'autres trucs que sur des indices de tableaux et autres conneries d'allocation (sur avec les pb d'allocation explicite d'on j'ai déjà discuté ailleur) et même d'implémentation.
Etre trop proche du métal fait réfléchir localement au lieu de prendre de la hauteur (genre optimiser les structures de données au lien de schéma général).
Quand je parle d'Ocaml, c'est un nouveau défit, mélanger classes et modules, rien qu'en restant imprératif c'est déjà autre chose que de préfixer ces noms de fonctions par le nom de la biblothèque et se taper des macro #define super dangereuses quand ça se complique.
L'important c'est la facilité avec laquelle on évite le bug, se cracher violement sur une exception est déjà plus saint que de corrompre le tas ou la pile. Surtout si ça crache systématiquement.
Il est d'autre part important de limiter les effets de bords, ils obligent à une réflexion permanente à l'état dans lequel on va retrouver un bout de mémoire à l'entrée dans une fonction.
D'autre part, il y a une culture "élitiste" qui veut que programmer en C soit le top et qu'en plus ce soit difficile. Alors qu'apprendre au plus tôt des langages modernes et variés ferait avancer beaucoup plus vite l'informatique. Le C est un langage quasiment inutile à l'informatique, les codeurs de noyeaux et autres drivers sont marginaux et devraient utiliser ADA.
L'histoire de coder un SGBD en C est à mon sens une vaste connerie (ça vaut des millions les données qu'il y a dedans, autant éviter q'une erreur conne foute tout en l'air).
Bon j'arrête là parce que siono y'en a pour 10 pages et j'ai parlé que de caml comme alternative.