Guillaume Laurent a écrit 1148 commentaires

Desolé d'insister, mais ton gagnant ne sera gagnant que dans un domaine. Peut-etre qu'au final Java ou QT sera LE toolkit pour 90% des applis, mais il restera toujours des cas ou les "petits" toolkits, les "perdants", seront largement supérieurs.

Lesquels ? Cite-moi un cas actuellement ou une toolkit autre que Qt soit plus adaptée.

Et surtout, est-ce que le fait d'avoir plusieurs toolkits, avec tout ce que ça implique (applis peu ou pas integrés, UI non uniforme, encombrement mémoire supplémentaire, difficulté supplémentaires pour le développeur) vaut vraiment la peine ?

Ca ne rend pas les autres inutiles pour autant.

La seule raison d'exister pour C, c'est lorsque tu n'as pas de bon compilo C++ pour la plateforme que tu vises. Entre C++ et Java par contre, oui, C++ garde toujours une utilité dès que les perfs sont cruciales, où qu'on veut faire du bas niveau (drivers, etc...). Mais sinon, il n'a plus aucun interêt.

Il reste bien sur aussi le cas du code existant, qu'il faut maintenir, mais en dehors de ces cas, je ne vois pas.

un peu evangéliste par moment. Limite tendance casse couille d'après mes collèges

Soit un peu plus nuancé, ça aide à faire passer les idées :-).

ou un front-end pour rsync

Ah, bonne idée ça. Ce machin a une telle panouille d'options que ça aiderait bien d'avoir une GUI dessus (pitié, prends Qt :-).

Je comprends pas vraiment pourquoi tu es aussi aggresif dans ton poste

Désolé, ça n'était pas voulu.

Faut pas vraiment etre tres fort pour voir que l'interface de MSWin est actuellement bien loin de GTk/Qt [du point de vue user, je me répete].

Fait un sondage, tu verra que ça n'est pas si évident. J'ai vu beaucoup de Windowsiens "de base" (ie simple utilisateurs, pas fans) trouver Gnome ou KDE très moches et pas simple du tout à utiliser.

Et je doute que le toolkit choisi par C# soit digne de GTK/QT..

Il n'en ont pas choisi une, ça appelle Windows directement. Enfin, je connais pas trop cette partie là.

Je trouve que ca va assez à l'encontre de ce que .NET essaie d'etre, d'unifier tout ca.

Plus bas tu trouve un commentaire de moi ou j'explique que le coté multi-langage de .NET sers surtout à pouvoir récuperer facilement du code existant, pas à permettre de développer une appli de zero avec n'importe quel langage.

Et il y a fort à parier que le toolkit MS ne supportera pas pleins de trucs essentiels [oui, je sais, un windozeur ne considère essentiel que les fioritures que MSWin fait, pas les autres. Mais ne nous leurrons pas !]

Disposes-tu d'arguments concrets, ou simplement d'a priori ?

Bref, je suis pas aussi convaincu que toi qu'un toolkit soit meilleur que les autres [...]

Tu n'es pas convaincu, ou bien est-ce simplement quelque chose qui ne te fait pas plaisir à entendre ?

Je vois pas ce que a de plus compliqué

Fait un sondage autour de toi... Pour ceux qui lisent, est-ce que vous trouvez ça plus compliqué ou pas ?

Au passage, je te signale qu'avec ton code on est obligé de penser à effacer chaque complex crée, y compris le résultat de complex_mul. Et d'ailleurs, tu te fais chier pour rien avec des malloc(), dans le cas d'une struct comme celle-là tu peux rester en semantique par valeur.

Pour l'exemple sur les chaines, je te laisse également voir autour de toi si c'est "aussi simple". Et note que rien qu'avec une operation aussi triviale, tu es obligé de faire de la gestion mémoire (liberer le resultat).

J'attends toujours la State Pattern.
Tiens, sinon y a ça aussi :

module Profiler__
Start = Float(Time.times[0])
top = "toplevel".intern
Stack = [[0, 0, top]]
MAP = {"#toplevel" => [1, 0, 0, "#toplevel"]}

p = proc{|event, file, line, id, binding, klass|
case event
when "call", "c-call"
now = Float(Time.times[0])
Stack.push [now, 0.0, id]
when "return", "c-return"
now = Float(Time.times[0])
tick = Stack.pop
name = klass.to_s
if name.nil? then name = '' end
if klass.kind_of? Class
name += "#"
else
name += "."
end
name += id.id2name
data = MAP[name]
unless data
data = [0.0, 0.0, 0.0, name]
MAP[name] = data
end
data[0] += 1
cost = now - tick[0]
data[1] += cost
data[2] += cost - tick[1]
Stack[-1][1] += cost
end
}
END {
set_trace_func nil
total = Float(Time.times[0]) - Start
if total == 0 then total = 0.01 end
MAP["#toplevel"][1] = total
# f = open("./rmon.out", "w")
f = STDERR
data = MAP.values.sort!{|a,b| b[2] <=> a[2]}
sum = 0
f.printf " %% cumulative self self total\n"
f.printf " time seconds seconds calls ms/call ms/call name\n"
for d in data
sum += d[2]
f.printf "%6.2f %8.2f %8.2f %8d ", d[2]/total*100, sum, d[2], d[0]
f.printf "%8.2f %8.2f %s\n", d[2]*1000/d[0], d[1]*1000/d[0], d[3]
end
f.close
}
set_trace_func p
end


C'est le profiler standard de Ruby. L'équivalent de gprof, en 55 lignes a peine. C'est pas bien indenté, mais tu dois l'avoir sur ton linux (locate profile.rb).

Tout dépend du niveau d'encombrement de l'axe de circulation... ;-)

C'est bien ce que je dis : c'est vrai pour le cas général, tu peux avoir des cas particuliers.

Pour faire vite-fait une couche graphique sur un petit outil systeme (par exemple), gtk est tout indiqué (de même que c'était tk il y'a encore peu de temps)

C'est toujours Tk, ou alors GTK+ a travers un langage de script. Ou même Qt à travers un langage de script, mais en tout cas pas avec C.

C'est la même chose pour les toolkits graphiques et les langages: y'a pas UN bon toolkit et des mauvais: ils ont chacun leur specificité, et leur domaine d'application propre.

Bof, j'y ai cru aussi mais finalement non. Tu as toujours un gagnant clair qui se détache. Actuellement, c'est Qt, et si les perfs de Java continuent de s'améliorer ça sera Swing.

Amusant, j'ai fait connaissance avec Unix à la même période que toi (91, à la fac aussi) et installé Linux sur mon PC (acheté exprès pour, je n'ai jamais eu Windows) en 95 aussi. Et c'était le kernel 1.2.8 aussi, tiens. Les bons vieux pack 4CDs Infomagic...

Il semble juste que tu ais un tout petit peu "enjolivé" l'histoire d'Unix :-).

PS : installe VisualStudio.Net et lit les articles MS. T'as le profil.

Argh. L'insulte suprême. Oh là là, je suis vexé. Bon, puisque tu m'as expédié ton "CV" avec ton passé d'Unixien, voici les miennes :

http://www.advogato.org/person/Guillaume/(...)
http://www.all-day-breakfast.com/rosegarden/authors.html(...)
http://gtkmm.sourceforge.net/developers.html(...)

Tu peux aussi jeter un coup d'oeil dans le "About->Authors" de KMail et konsole, et grepper 'glaurent' dans le func-menu.el d'Emacs.

Et j'ai un clavier qwerty, l'azerty pour coder c'est vraiment trop pénible :-).

Parce que tu trouves ça complexe comme traitement de chaines de caractères ? Concatener 2 strings avec un separateur ? Et tu as lu ma réponse ou je te disais que C et Unix était historiquement fait pour traiter du texte ? Trouve un équivalent des fonctions str*() en Cobol, Fortran ou Pascal pour voir.

Bon, on va faire plus simple pour le monsieur alors :

class Complex
{
public:
Complex(double r, double i);
Complex operator*(double c);

double re() { return _re; }
double im() { reutnr _im; }

protected:
double _re;
double _im;
};

Complex::Complex(double r, double i)
: _re(r), _im(i)
{}

Complex Complex::operator*(double c)
{
Complex res = *this;
res._re *= c;
res._im *= c;

return res;
}

ostream& operator<<(Complex& c)
{
*this << c.re() << "," << c.im()
return *this;
}


int main()
{
Complex a(12, 12);

Complex b = a * 2;

std::cout << "b = " << b << std::endl;
}

(pas sur que ça compile tel quel, mais bon, tu saura surement corriger toi-même).

Alors tu devrais la relire parce que ça raconte exactement ce que je dis :

- Unix est né chez ATT, parce que Multics était trop lourd et non parce qu'il était propriétaire

- ATT vendait des licenses pour pas cher aux universités (Unix version 6 gratuit, version 7 pour $100, contre $21,000 pour une entreprise)

- Fin 70, ATT s'arrête de filer des licenses, et BSD démarre (l'université de Berkeley avait une license Unix ATT).

Hum hum... ça doit faire plus de 5 ans que je passe mes journées à coder, je sais un peu de quoi je parle quand même.

Comme quoi, l'expérience dans le monde réel y a que ça de vrai :-).

Alors prends un autre exemple, et pas de problème.

using std::string;

string addString(string a, string b)
{
a += " - ";
a += b;
return a;
}

int main()
{
cout << addString("Hello", "World");
return 0;
}

Autre exercice, plus amusant : implémente un exemple de State Pattern en C.

1 - tes references c'est att et forcement, ils vont dire qu'il ont invente Unix.

Et pour cause, c'est vrai.

Je sais qu'Unix est proprietaire. Je dis qu'au debut il ne l'etait pas.

Faux, il l'était dès le début, c'était un produit ATT.

La license GPL (qui interdit le changement de license) a ete pense entre autre suite a cet episode.

Encore faux : http://www.gnu.org/gnu/gnu-history.html(...)

Toujours pas c'est ATT.

Ah, donc Dennis Ritchie est un menteur ? (tu as bien noté, je suppose, que l'une des URL était un document sur la homepage de Ritchie ?) Et le gars sur Wanadoo est payé par ATT aussi ?

Tu es en train de nier un truc archi-célèbre, que n'importe quel programmeur Unix connait par coeur.

mais Unix etait une reponse a Multics qui etait proprietaire.

Non. Unix était propriétaire aussi.

L'absence des sources de Multics en a enerve
plus d'un et Unix et parti sur l'impulsion de Thompson et Ritchie.

Non, multics ne tenait pas la route, il fallait faire plus simple :

http://www.bell-labs.com/history/unix/chaos.html(...)

Unix avais une license de type BSD.

Non, il avait une license propriétaire. Mais si je me souviens bien les sources étaient dispo pour pas cher si tu les demandait.

Desole mais la source que tu donnes n'est pas assez precise...

OK, et celles-là ?

http://cm.bell-labs.com/cm/cs/who/dmr/hist.html(...)

http://www.bell-labs.com/history/unix/(...)

http://perso.wanadoo.fr/levenez/unix/(...)

Non, tu es jeune donc tu manques d'expérience.

Et je t'ai donné d'autres arguments. J'attends toujours la réecriture d'un script Perl en C. Compare le nombre de lignes, le nombre de bugs, le temps que tu mets pour y arriver.

J'oubliais :

Super comme argument ! L'industrie est donc la référence ultime, et le logiciel libre un ramassi d'amateurs qui ne savent pas réellement programmer ?

Non, mais l'Open Source n'est pas non plus un reservoir de petits génies (loin de là), ni l'industrie peuplée que de cons.

Après il y a quelques raisons historiques qui font qu'on utilise encore C dans l'Open Source (vieux débat), mais le fait est que si tu regardes l'ensemble du monde de la programmation, Open Source et industrie, tu arrives vite à la conclusion que C n'est plus très utilisé, et encore plus rarement pour de nouveaux projets (heureusement, y a quand même un peu de progrès de fait :-).

Un GC ça ne change vraiment pas grand chose, avec un peu d'habitude la gestion de la mémoire en C ce n'est pas si compliqué...

Pour le reste, les pointers de fonction c'est élégant, très pratique et extrêment puissant, et je ne vois pas ce qu'on peut faire de mieux.

Je vais faire le voyant et te faire une prédiction : si dans 5 ans tu relis ces phrases, tu te dira "bon sang qu'est-ce que j'étais bête à cet âge là".

Tu ne veux pas attendre d'avoir un tout petit peu plus d'expérience avant d'établir ce genre de certitudes ?

(tu va surement répondre non, et que tu sais très bien de quoi tu parles, mais bon...)

Les regexps en C ça existe, et j'ai déjà dit que la manipulation de chaines était *le* point faible du C.

En fait, historiquement C était justement fait pour processer du texte (et Unix aussi, cf. toutes les commandes cut, paste, column, awk, etc...)

Et j'insiste, prends un exemple Ruby, ou même Perl, re-écris le en C et dis-moi si ça ne change "pas grand chose". Un truc simple, un tout petit parseur, genre un truc qui me compte le nombre de mots différents dans un texte.

et pour le reste du programme, le langage ne change pas grand chose.

Entre gerer la mémoire soi-même et avoir un GC, ça ne change pas grand chose ? Entre avoir un framework objet ou l'émuler à coup de pointeur de fonctions et se souvenir de bien appeler les ctor/dtors, ça ne change pas grand chose ? Entre avoir des classes de conteneurs standard et devoir refaire les siennes à chaque fois, ça ne change pas grand chose ? Avoir des regexps ou pas pour manipuler du texte, ça ne change pas grand chose ?

Prends un exemple en Ruby, reécris-le en C, et voit si "ça ne change pas grand chose".

en utilisant un langage fortement typé comme Ada ou Java

Java n'est pas fortement typé :-).

La preuve : le C est encore largement utilisé même pour les nouveaux projets...

Dans l'Open Source oui, dans l'industrie non.

UNIX a ete cree en Universite puis "volee" par des boites commercial (c'est ATT qui a commence).

Faux, c'est Thompson et Ritchie qui l'ont inventé chez AT&T :

http://www.dimi.uniud.it/~miculan/Didattica/unix-history.html(...)

C'est quoi la suivante, que le langage C a été inventé par des moines tibétains ?

Ah d'accord, ca ne m'était pas venu à l'idée d'utiliser un toolkit propre à C#.

Ben si tu fais tu Tcl, tu vas utiliser Tk, si tu fais du Java, tu vas utiliser AWT ou Swing, et si tu fais du C# tu vas utiliser WinForms (merci google pour m'avoir aidé à trouver le nom).

Mais lors, ca me gene un peu de prétendre qu'un developpement va plus vite sous la condition qu'on utilise pas ce que l'on veut (ici, des widgets GTK)

Tu peux préférer faire du vélo à conduire une voiture, c'est pas ça qui te fera aller plus vite en vélo qu'en voiture :-).

On pourrait faire le meme raisonnement avec n'importe quel langage (ex: Tcl/Tk)

Tout à fait. Si tu veux utiliser autre chose que Tk avec Tcl, tu vas très probablement perdre beaucoup de temps.

Toujours est-il que dans le cas interessant (celui ou le programmeur utilise ses widgets préférés et leur api)

C'est justement ce cas là qui n'est pas interessant. Ça n'est pas parce que tu utilises ton outil préféré que c'est le meilleur outil possible. Tu peux adorer GTK+ et être super-bon avec, ça n'arrange rien au fait que n'importe qui de pas trop mauvais utilisant C++/Qt ou Java/Swing ira beaucoup plus vite que toi pour développer une appli.

(et oui, je sais, Swing c'est lourd, etc... mais dans le cas général le problème ne se pose pas en ces termes, cf. la discussion récurrent sur le succès de Java parce qu'il raccourci les temps de dev, et donc au final coute moins cher même si il faut des machines plus puissantes).

Dire "on développe plus vite en Java/C#/... qu'en C" ce n'est pas vrai du tout

Bien sur que c'est vrai. A moins d'être une brêle complète en Java ou C#, ou d'y mettre vraiment de la mauvaise volonté, et encore. C'est vrai aussi pour C++ par rapport à C, d'ailleurs.

Quand je bossais pour Gtk--, j'ai ré-ecrit plusieurs des exemples de GTK+ en C++/Gtk--. En moyenne, l'exemple converti faisait 2 à 3 fois moins de lignes. Depuis que je suis passé à Qt/KDE, je pense pouvoir dire que le gain par rapport à C/GTK+ est au moins équivalent (2 à 3 fois), sinon supérieur.

Maintenant je n'espère pas t'en convaincre, j'ai déjà eu cette discussion plusieurs fois, et le problème est toujours le même : la personne qui me soutient le point de vue contraire aime bien C et GTK+, s'y est habitué, et n'arrive plus à voir tout les problèmes qui sont liés à cette plateforme.

Personne n'aime entendre dire qu'il y a mieux que les outils qu'il aime utiliser. Il y a aussi plein de programmeurs C++ qui vont te soutenir que tu n'ira pas plus vite en Java, et te citer plein de contre-exemples très particuliers etc... en oubliant complètement le cas général.

Une preuve est que je ne vois pas de raison vraiment valable

Ça c'est une preuve. :-)

Tu as mal lu. Je ne parle pas de C# pour programmer en GTK+, mais de C# par rapport a C et GTK+ (et tout le bazar de Gnome). C#, comme Java, a une toolkit graphique dans sa lib.

(evidemment, si on implémente C# sous Linux il est peut-être possible d'implémenter sa toolkit graphique avec GTK+, ce qui complexifie un peu le problème, mais bon... :-)

Bref, pour résumer, si d'un coté tu prends C# et de l'autre tu prends C/GTK+/etc... et tu cherches à développer la même appli, tu ira beaucoup plus vite avec C#.

Oui, et il faut bien reconnaitre que c'est vrai, par rapport à C++ qui était le concurrent direct. Statistiquement, développer en Java est 2 à 3 fois plus rapide que C++, ce qui n'a rien de vraiment surprenant (déjà rien que le fait d'avoir un GC, plus une lib bien complète...)

Le gain de C# par rapport à Java sera surement moindre, mais je pense qu'il y en aura un.

Et sinon, entre C# et C/GLib/GTK+/Bonobo/etc..., là y a pas vraiment photo :-).

Miguel est trop optimiste quand il parle du coté multi-langage de .NET. Il n'est pas fait pour développer des applis, mais plutôt pour récuperer relativement facilement du code existant (ce qui est très bien aussi).

L'exemple le plus flagrant est Managed C++, la verison ".NET" de C++, très éloignée du C++ standard :

http://www.gotdotnet.com/team/cplusplus/(...)

(désolé, les articles sont en Word mais konq arrive bien à les relire, star office aussi sans doute).

J'ai eu une courte présentation dessus à ma boite, et il est tout à fait clair que ça ne sert qu'a faire le pont avec du code C++ existant (en gros, on wrappe du C++ avec du Managed C++ pour obtenir une appli .NET). Mais il faudrait être totalement maso pour développer une appli entière avec. C'est la même chose pour Eiffel# (la version .NET d'Eiffel). Pour les autres langages disponibles, je ne sais pas.

Bref, il est assez clair que le langage de développement pour .NET est C#, et pas "n'importe quel langage". C'est ce qu'explique aussi l'article sur Javalobby. Et ça n'est pas plus mal, c'est un très bon langage, il n'y a aucune raison de vouloir continuer à faire du C ou du C++ quand on a C#.

Maintenant, puisqu'il dit que son but est de fournir un meilleur environnement de dev que Gnome actuellement (cf. la partie sur les 2 ans et 17 developpeurs d'Evolution) afin que Linux gagne le marché du desktop, on peut se demander si refaire .NET est la voie la plus rapide et la plus garantie d'avoir un bon résultat, alors que KDE semble ne pas trop mal marcher (Aethera est loin d'avoir toutes les features d'Evolution, mais il n'y a qu'une seule personne qui travaille dessus...)

Par contre je vois de bonnes raisons de rejeter .Net, et ce n'est pas lié au fait que ce soit MS, mais que MS soit en situation de monopole.

Là aussi, je suis d'accord. Il y a une bonne part de "hype", et MS n'est pas un enfant de choeur. Mais si les idées sont bonnes, et je pense qu'elles le sont (au moins, C# est vraiment un bon langage), tenter d'en faire une implémentation libre est une bonne chose. Je dirais même que c'est presque necessaire, afin d'établir une forme de "contre-pouvoir". Le libre ne pourra pas lutter contre .Net en proposant des wrappers python autour de libs C.

D'ailleurs ce qui est surprenant avec MS c'est la piètre qualité de certaines implémentations

En fait MS ne fait pas forcément pire que la plupart des autres boites, et même globalement je pense qu'ils font souvent mieux, si tu prends en compte la taille de leurs produits. Simplement leur position de leader fait que tout le monde est au courant de leurs merdes, et leur pratiques commerciales n'arrangent pas les choses.

OK, on est d'accord.

Tu sera d'accord aussi pour dire que rejeter une plateforme simplement parce qu'elle vient de MS n'est pas forcément une bonne chose, non ? MS peut aussi avoir de bonnes idées, ils n'embauchent pas que des cons, loin de là.