Discussion :

[IrmatDen]

En quoi ça te choque ?

Ca me paraît au contraire totalement sensé et c'est une vérité pour tout développement : si tu connais parfaitement le langage et le projet, tu es plus efficace pour fixer le bug.

Avoir une vitesse aussi élevée que peut atteindre Git, ça ne se fait pas en écrivant un code si lisible qu'ils pourraient servir de tutoriel C. Ca se fait en poussant le langage et le compilateur dans ses derniers retranchements.
A partir de là, 2 possibilités pour l'utilisateur :
* il a un niveau d'expert en C ? très bien, il pourra peut-être débugger puis proposer un patch s'il prend le temps de comprendre comment tout ça fonctionne.
* il ne l'a pas ? Il remplit un bug s'il n'est pas déjà répertorié, et attends le fix.

Faire de l'open source, je considère pas ça comme faire du code que tout le monde peut toucher. Soit l'utilisateur prend le temps de comprendre à un niveau suffisant pour comprendre le projet puis comprendre le projet en lui-même, soit il ne le fait pas et faut pas s'étonner de ne pouvoir le patcher. En ceci, je trouve la remarque de Kakurin totalement déplacée.

[white_tentacle]

La base de l'open source, c'est qu'un utilisateur puisse modifier le logiciel s'il ne lui convient pas/veut l'améliorer. Dire que ce n'est pas à l'utilisateur de modifier le logiciel, c'est contraire à l'esprit de l'open source, c'est tout. Ca me choque donc d'entendre un développeur de projet open source dire une horreur telle comme une vérité absolue.

Après, on pourrait aussi discuter de en quoi une application comme git est critique et doit être ultra-optimisée, mais c'est un autre débat . Pour avoir bossé avec ClearCase, je peux comprendre qu'on en arrive à l'extrême inverse.

Avoir une vitesse aussi élevée que peut atteindre Git, ça ne se fait pas en écrivant un code si lisible qu'ils pourraient servir de tutoriel C. Ca se fait en poussant le langage et le compilateur dans ses derniers retranchements.

L'argument de lisibilité de code sacrifiée pour la performance pourrait tenir si le code de git était commenté en conséquence. Mais non, c'est un projet de hackerz élitistes, donc on va quand même pas documenter correctement le code, hein...

[Alp]

Par contre, y'a un truc qui me fait marrer.
Torvalds n'a pas défini une seule structure dans son code C ?
Et aucune fonction qui agit sur ces structures ?

Parce que ça, c'est déjà de l'abstraction. Tout comme une classe en C++.

[befalimpertinent]

En cherchant la description de Git je suis tomber sur cette phrase de Linus dans wikipedia

Le magazine PC World nous apprend que quand on lui a demandé pourquoi il avait appelé son logiciel "git", qui est à peu près l'équivalent de « connard » en argot anglais, Linus Torvalds a répondu « je ne suis qu'un égocentrique, donc j'appelle tous mes projets d'après ma propre personne. D'abord Linux, puis git. »

Linus, malgré sa mégalo, semble quand même avoir du recul sur lui même...

[IrmatDen]

La base de l'open source, c'est qu'un utilisateur puisse modifier le logiciel s'il ne lui convient pas/veut l'améliorer. Dire que ce n'est pas à l'utilisateur de modifier le logiciel, c'est contraire à l'esprit de l'open source, c'est tout. Ca me choque donc d'entendre un développeur de projet open source dire une horreur telle comme une vérité absolue.

Tu alors n'as pas compris les 2 mails en question. Kakukin dit que le fait que ce soit en C l'em%*£de quand il veut fixer quelque chose :

> My goal is to *use* Git. When something does not work *for me* I want
> to be able to fix it (and contribute the fix) in *shortest time
> possible* and with *minimal efforts*. As for me it's a diversion from
> my main activities.
> The fact that Git is written in C does not really contribute to that goal.

Ainsi que la réponse:

That's just it -- Git's goal isn't to make it as easy as possible for
Git _users_ to fix it (thought that is a nice thing to have). Git's
goal is to be a very good, very fast SCM. Bugs should be found and
fixed, but that can most effectively be done by the people who are
already knowledgeable about Git's codebase (i.e. its developers), not
its users.

Note les expressions:
* as easy as possible => les fix utilisateurs ne sont pas une prio
* (thought that is a nice thing to have) => les fix utilisateurs sont appréciés
* most effectively => ceux qui connaissent le code de git et le C sont les plus à même de faire les fix qui vont bien


Tu connais mal/pas le langage utilisé pour un projet ? T'y touches pas, mais surtout tu ne dis pas que le langage choisi ne va pas dans un pseudo objectif où tout le monde peut toucher le code. C'est faux, ce n'est pas l'objectif de l'open source, c'est pas la fête du slip
Il y aura toujours quelqu'un qui ne comprendra pas le langage d'un projet (ou même la façon dont un langage est utilisé, puisqu'on est dans la section C++, on devrait tous le savoir), donc ce n'est pas une remarque à faire.

[Alp]

Mais de toute manière tu ne dis pas
*YOU* are full of bullshit
à quelqu'un qui vient poster sur la ML de ton projet. Tu peux argumenter pour le choix du langage & co, mais tu l'insultes pas.

Par contre, il ne peut pas demander aux développeurs de migrer le projet vers un nouveau langage, c'est mal venu
Imaginez un programmeur Java qui va voir les développeurs de Boost (ou wxWidgets, ou tout autre grand projet en C++ qui n'a pas de binding Java) pour qu'ils migrent le projet vers Java... Il faut lui rappeler que toute la base de code est pas en Java et qu'ils ne vont pas _juste pour ses beaux yeux_ migrer vers Java.

[IrmatDen]

Mais de toute manière tu ne dis pas
*YOU* are full of bullshit
à quelqu'un qui vient poster sur la ML de ton projet. Tu peux argumenter pour le choix du langage & co, mais tu l'insultes pas.

Je ne défends absolument pas ça bien sûr Et la personne qui répond n'est pas Linus dans cette partie de l'échange

[epsilon68]

Par contre, il ne peut pas demander aux développeurs de migrer le projet vers un nouveau langage, c'est mal venu

le gars en question avait simplement demandé d'introduire C++ pour la gestion des chaines de characters et plus generalement pour faciliter la gestion memoire avec le RAII

[IrmatDen]

le gars en question avait simplement demandé d'introduire C++ pour la gestion des chaines de characters et plus generalement pour faciliter la gestion memoire avec le RAII

Je ne connais pas le système de build de git, mais ça demande à passer à un compilo C++ ce qui peut potentiellement casser la compil d'autres sections du code (parce que ça m'étonnerait qu'ils compilent en mode C++ ).

[Alp]

le gars en question avait simplement demandé d'introduire C++ pour la gestion des chaines de characters et plus generalement pour faciliter la gestion memoire avec le RAII

C'est pas moi qui refuserait, ne t'inquiètes pas
M'enfin Torvalds ne pense pas pareil...

[koala01]

le gars en question avait simplement demandé d'introduire C++ pour la gestion des chaines de characters et plus generalement pour faciliter la gestion memoire avec le RAII

Mais, là, tu crée la quadrature du cercle:

L'un voudrait introduire son "langage préféré" pour des raisons de "facilité" (selon lui), dans un projet sur lequel d'autres ont un autre "langage préféré", ce qui relance l'éternel débat du choix du langage

Et le fait est que c'est un peu comme la boite de pandore...:

Si tu ouvre cette porte pour un point bien précis, il sera difficile de justifier le refus si, pour des raisons identiques, quelqu'un vient un jour à proposer, par exemple, l'utilisation de map, de set ou de shared_ptr.

En un mot, si tu mets le doigt dans cet engrenage, où cela va-t-il s'arrêter

Il est donc cohérent, une fois le langage choisi pour un projet, de refuser d'en introduire d'autres, même s'ils sont plus ou moins compatibles

[EDIT]Ceci dit, rien n'empêche (c'est ca aussi l'esprit GPL) quiconque de créer un "fork" d'un projet existant, dans le cas présent qui aurait pour objectif à terme de porter le projet pour qu'il soit intégralement écrit en C++, avec tous les avantages que les "C++iens" peuvent trouver à ce langage

[epsilon68]

Je ne connais pas le système de build de git, mais ça demande à passer à un compilo C++ ce qui peut potentiellement casser la compil d'autres sections du code (parce que ça m'étonnerait qu'ils compilent en mode C++ ).

il pourrait compiler uniquement cette fonction (deplacée dans un fichier à part) pour etre compilé en C++ avec un extern "C".

non?

J'imagine que c'est comme ca qu'on migre un projet, pas toujours drole de passer par des phases intermediaires.

[epsilon68]

Mais, là, tu crée la quadrature du cercle:
L'un voudrait introduire son "langage préféré" pour des raisons de "facilité" (selon lui), dans un projet sur lequel d'autres ont un autre "langage préféré", ce qui relance l'éternel débat du choix du langage

oui c'est vrai que si la communauté existante ne veut pas introduire C++, alors on ne peut pas, puis c'est vrai que la suite pourrait surprendre par l'introduction de plus en plus de C++ (stl boost etc)

en meme temps, ils peuvent partir sur la simple definition de
C++ = C with class + RAII

Aussi, si Linus Torvalds dit que ce n'est pas bien alors mieux vaut rester en C. Je pense qu'il sait mieux que nous pourquoi C est meilleur dans ce cas.

Je ne peux pourtant pas m'y resigner pour mes projets :-/
mais je respecte leurs choix (pas le vocabulaire)

[epsilon68]

Ceci dit, rien n'empêche (c'est ca aussi l'esprit GPL) quiconque de créer un "fork" d'un projet existant, dans le cas présent qui aurait pour objectif à terme de porter le projet pour qu'il soit intégralement écrit en C++, avec tous les avantages que les "C++iens" peuvent trouver à ce langage

un fork = duplication des efforts + une incomprehension des utilisateurs.

ca serait vraiment une perte d'energie totale.

[koala01]

un fork = duplication des efforts + une incomprehension des utilisateurs.

ca serait vraiment une perte d'energie totale.

Ca, c'est la vision pessimiste des forks

Un fork peut, tout simplement, être du à un point de vue différent, et peut parfaitement mener à des projets tout à fait viables

Un des exemples les plus flagrants (même si le choix du langage n'était pas la cause), est carrément la distribution Ubuntu, qui n'est à la base qu'un fork de Debian, simplement, la philosophie de préférer du stable à du récent n'était pas vraiment du gouts de ceux qui ont lancé ubuntu