Quand tu écris un programme en SmallTalk ou Eiffel(avec les notions de contrats) (voire Java) tu es obligé d'écrire du code réellement Objet.
Et en quoi est-ce que ça garantit que ton code soit meilleur ?
Le paradigme objet n'est pas universel. Il y a des choses qui se représentent très bien en procédural de base, et les représenter en Objet va juste compliquer le code inutilement.
Sauf que c'est dur de considerer qu'une API puisse faire partie d'un langage.
Essaie, tu vas voir ça vient tout seul.
Ce qui compte c'est ce que tu as à ta disposition en standard pour développer une fois que tu as installé le langage.
Après, chipoter sur "ça c'est dans le langage, ça c'est dans la lib", juste pour pouvoir dire "ah mais oui mais évidemment C c'est aussi facile que Java y a qu'a prendre les bonnes libs", c'est bien pour faire le neuneu sur linuxfr mais ça fait pas avancer ton code quand tu dois vraiment faire un truc qui marche.
Si on dit "tel langage est meilleur parce que son API de base est plus complète" on est bien mal barrés...
La grande leçon de C++, c'est précisément qu'un langage doit avoir une librairie standard aussi complète que possible. Si C++ avait eu tout de suite la lib standard qu'il a maintenant, ça aurait évité énormément de merdes.
C'est bien pour ça que Java et C# ont été designé dès le départ avec des libs standard très complètes.
Donc oui, bien évidemment, un langage est meilleur si son API de base est plus complète.
qui font exactement la même chose, en standard, et pour n'importe quel sexp (donc pas seulement les parenthèses, mais aussi les {}, etc... selon la syntaxe du langage).
Ça serait bien de retirer ce genre d'"astuce" qui n'en est pas.
Pour faire tourner dans les même conditions des serveurs avec les EJBs, il faudra des serveurs plus gros (et souvent ça n'est pas trop un problème)
Ça n'est même pratiquement jamais un problème : les machines continuent d'augmenter en puissance, donc prendre de plus gros serveurs c'est une dépense relativement faible (sauf pour les très gros sites), facile à chiffrer, et sans trop d'influence sur les délais.
Alors que la dépense en temps de développement pour rendre ton serveur en C aussi fiable qu'en Java et avec les mêmes features... bon courage.
C'est la même boite qui gère free.fr. Ils n'ont pas beacoup d'options dispo, mais leur qualité de service est irréprochable, et leur tarifs tout à fait abordables (30euros par an pour 100Mo d'espace disque).
Ah oui, c'est vrai, ils sont tellement communs que je les avais oubliés ceux-là :-). Je pensais à des templates dans les libs KDE uniquement.
Enfin bon, c'est pas le manque de 'export' qui change quelque chose. Peut-être que le gars voulait parler des header précompilés, ça oui c'est un truc qu'on aimerait bien avoir pour compiler plus vite. Et puis la recompil à la volée pendant l'execution comme sous MSVC, tant qu'on y est :-).
Personnelementje ne trouve pas que les libs gnome ou GTK+ soient particulièrement lourdes.
Je ne parle pas de l'utilisation, je parle de développement.
... pour se rendre compte que c'est possible.
Je ne dis pas que c'est impossible, je dis que c'est beaucoup plus facile avec Qt/KDE.
De plus avec libglade ca va plutôt vite pour faire l'interface...
Vraiment ? Essaye. Pour commencer, essaye de creér un widget et de l'integrer dans libglade.
mais je pense qu'il y a un fond de vérité dans ce qui ce dit.
Autrement dit, tu veux bien le croire. Les "on dit" en info sont le plus souvent des clichés sans fondement technique, rapportés par des gens qui ne savent absolument pas de quoi ils parlent. C'est particulièrement vrai pour C++.
D'ailleurs d'après un programmeur C++ avec qui j'ai discuté il faut environs 8h pour recompiler KDE3 sur un pIII à cause de certaines fonctionnalités non supportées par g++ qui pourraient réduire fortement le travail ...
Lesquelles, précisément ? La seule chose du standard C++ que g++ ne supporte pas encore, c'est le mot clé "export" qui sert (si je me souviens bien) à éviter d'avoir à inclure des définitions de templates. Aucun compilateur ne le supporte de toute façon (ah si, sur /. j'ai vu qu'un venait tout juste de sortir), personne ne l'utilise, et il n'est pas essentiel. Par ailleurs il n'y a pratiquement pas de templates dans KDE.
KDE3 prend 8h à compiler parce qu'il y a un paquet de code, c'est tout. Et g++ est un compilateur lent, c'est connu, mais qui génère du code tout à fait correct.
Si tu recroises ton "programmeur C++", dis-lui de venir ici expliquer clairement ce qu'il veut dire.
Tu reproches quoi aux libs gnome par exemple ? Et à l'API de GTK+ ?
D'être très, très, très lourd.
mais honnetement je vois pas où est la difficulté
Essaye. Fait une grosse appli avec. Pas une démo de 500 lignes, une vrai appli, qui fait quelque chose d'utile pour de vrais utilisateurs. Package-là, distribue-là.
Et perso je fais pas de C++, mais d'après ce que j'ai entendu au niveau performances g++ c'est pas super ...
Non, il se défend même bien (par rapport à MSVC et Borland, sous Linux spécifiquement il n'y a pas vraiment de concurrent, à part le compilo d'Intel dont l'utilisation est encore assez restreinte), et est courramment utilisé dans l'industrie (c'est le cas de plein de clients de ma boite, qui sont des gens très sérieux en général, vu le prix de nos produits :-).
Fais ton expérience, au lieu de "croire" et d'"entendre dire".
Le C à coté ca prend beaucoup moins de temps à assimiler.
Oui mais ça fait moins de choses. Pour faire en C ce que tu fais facilement en C++, tu va en chier bien plus que si tu devais apprendre C++.
C'est comme le vélo et la voiture. C'est plus facile d'apprendre à faire du vélo que d'apprendre à conduire, mais t'ira pas aussi loin.
Le seul hic à mon avis de Qt, c'est la société Trolltech qui décide principalement de son évolution
C'est bien ce qui fait la qualité du truc. Ils connaissent leur boulot, et écoutent leur clients, pas des neuneux à peine sorti de la fac qui se prennent pour des kadors du clavier. C'est pareil pour GTK+, d'ailleurs, et tout les projets qui tiennent un peu la route. Peu de contributeurs, mais des bons. La communauté, elle est bonne pour tester et debugger, pas pour développer. Ça c'est une affaire de petit groupe, autrement ça part très vite en couille.
Essaie de développer une appli sous Gnome et KDE, tu verra à quel point tu te trompes.
Pour toutes les applis que tu cites, tu oublies de comparer les ressources qu'il a fallu pour les sortir, et depuis combien de temps elles sont développées : Nautilus vs. Konq, Evolution vs. KMail, AbiWord vs. KWord, Gnumeric vs. KSpread.
Et aussi, comme tout le monde l'a souligné, le fait que beaucoup de ces applis ne sont pas à l'origine des applis Gnome (Mozilla, AbiWord, Gnucash...).
A propos de la "plus grande cohésion" de la communauté Gnome :
Regarde les autres threads. Gnome 2 a plus d'un an de retard, et ça n'a pas l'air d'affoler grand monde. Il y a même une discussion sur l'éventuel report en septembre de la release.
KDE a sorti KDE3 simplement pour suivre Qt3. C'est juste une question de version de l'API. Le portage de KDE2 à KDE3 est en général trivial à faire (ça a été le cas pour mon appli).
Sun est la seule boite "extérieure" à soutenir encore Gnome (Ximian ayant été crée expressément pour ça), et il ne sont là que pour avoir un remplaçant pas trop cher pour CDE. Sun fabrique des serveurs, de préférence pour faire tourner Java dessus. C'est là qu'est leur business, le desktop ils s'en tamponnent complètement. Note que les developpeurs Sun ne développent pas d'applis pour Gnome.
Tant pis pour toi. C'est un métier où les réactions du genre "je veux pas apprendre parce que ça me plait pas" ne mènent pas loin. Enfin si, tu peux devenir manager :-).
[^] # Re: OCM 2002
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 10.
Et en quoi est-ce que ça garantit que ton code soit meilleur ?
Le paradigme objet n'est pas universel. Il y a des choses qui se représentent très bien en procédural de base, et les représenter en Objet va juste compliquer le code inutilement.
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 0.
Essaie, tu vas voir ça vient tout seul.
Ce qui compte c'est ce que tu as à ta disposition en standard pour développer une fois que tu as installé le langage.
Après, chipoter sur "ça c'est dans le langage, ça c'est dans la lib", juste pour pouvoir dire "ah mais oui mais évidemment C c'est aussi facile que Java y a qu'a prendre les bonnes libs", c'est bien pour faire le neuneu sur linuxfr mais ça fait pas avancer ton code quand tu dois vraiment faire un truc qui marche.
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 2.
Vas-y, fais voir le code.
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 10.
La grande leçon de C++, c'est précisément qu'un langage doit avoir une librairie standard aussi complète que possible. Si C++ avait eu tout de suite la lib standard qu'il a maintenant, ça aurait évité énormément de merdes.
C'est bien pour ça que Java et C# ont été designé dès le départ avec des libs standard très complètes.
Donc oui, bien évidemment, un langage est meilleur si son API de base est plus complète.
# C-M-f et C-M-b
Posté par Guillaume Laurent (site web personnel) . En réponse au message [Éditeur/Emacs] Le % de vi !. Évalué à 1.
[^] # Re: Evenement majeur !
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Mozilla 1.0 is out !. Évalué à 10.
Non.
Après le premier lancement ça va beaucoup plus vite si on le ferme/relance.
Parce que les fichiers sont dans le cache disque.
[^] # Re: La Javanaise en question
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Pourquoi faut-il choisir des frameworks Java opensource ?. Évalué à 2.
Ça n'est même pratiquement jamais un problème : les machines continuent d'augmenter en puissance, donc prendre de plus gros serveurs c'est une dépense relativement faible (sauf pour les très gros sites), facile à chiffrer, et sans trop d'influence sur les délais.
Alors que la dépense en temps de développement pour rendre ton serveur en C aussi fiable qu'en Java et avec les mêmes features... bon courage.
[^] # Re: Linux est pauvre dans ce domaine
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Logiciels de musique. Évalué à 0.
http://www.google.com/search?hl=en&lr=&q=gainsbourg+laideur(...)
Y en a quand même un qui l'attribue a Hallier :
http://www.google.com/search?hl=en&lr=&q=laideur+sup%E9rieu(...)
Mais je veux bien te croire, il y a d'autres citations que tout le monde attribue à une personne et qui en fait sont d'une autre.
[^] # Re: Linux est pauvre dans ce domaine
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Logiciels de musique. Évalué à 0.
Il me semble que c'est de Gainsbourg.
[^] # Re: online.net
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Où crécher mon site WEB ?. Évalué à 2.
En plus ils sont sous Linux :-).
# online.net
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Où crécher mon site WEB ?. Évalué à 3.
C'est la même boite qui gère free.fr. Ils n'ont pas beacoup d'options dispo, mais leur qualité de service est irréprochable, et leur tarifs tout à fait abordables (30euros par an pour 100Mo d'espace disque).
[^] # Re: Developpement
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 1.
Enfin bon, c'est pas le manque de 'export' qui change quelque chose. Peut-être que le gars voulait parler des header précompilés, ça oui c'est un truc qu'on aimerait bien avoir pour compiler plus vite. Et puis la recompil à la volée pendant l'execution comme sous MSVC, tant qu'on y est :-).
[^] # Re: Developpement
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 2.
Je ne parle pas de l'utilisation, je parle de développement.
... pour se rendre compte que c'est possible.
Je ne dis pas que c'est impossible, je dis que c'est beaucoup plus facile avec Qt/KDE.
De plus avec libglade ca va plutôt vite pour faire l'interface...
Vraiment ? Essaye. Pour commencer, essaye de creér un widget et de l'integrer dans libglade.
mais je pense qu'il y a un fond de vérité dans ce qui ce dit.
Autrement dit, tu veux bien le croire. Les "on dit" en info sont le plus souvent des clichés sans fondement technique, rapportés par des gens qui ne savent absolument pas de quoi ils parlent. C'est particulièrement vrai pour C++.
D'ailleurs d'après un programmeur C++ avec qui j'ai discuté il faut environs 8h pour recompiler KDE3 sur un pIII à cause de certaines fonctionnalités non supportées par g++ qui pourraient réduire fortement le travail ...
Lesquelles, précisément ? La seule chose du standard C++ que g++ ne supporte pas encore, c'est le mot clé "export" qui sert (si je me souviens bien) à éviter d'avoir à inclure des définitions de templates. Aucun compilateur ne le supporte de toute façon (ah si, sur /. j'ai vu qu'un venait tout juste de sortir), personne ne l'utilise, et il n'est pas essentiel. Par ailleurs il n'y a pratiquement pas de templates dans KDE.
KDE3 prend 8h à compiler parce qu'il y a un paquet de code, c'est tout. Et g++ est un compilateur lent, c'est connu, mais qui génère du code tout à fait correct.
Si tu recroises ton "programmeur C++", dis-lui de venir ici expliquer clairement ce qu'il veut dire.
[^] # Re: Developpement
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 3.
D'être très, très, très lourd.
mais honnetement je vois pas où est la difficulté
Essaye. Fait une grosse appli avec. Pas une démo de 500 lignes, une vrai appli, qui fait quelque chose d'utile pour de vrais utilisateurs. Package-là, distribue-là.
Et perso je fais pas de C++, mais d'après ce que j'ai entendu au niveau performances g++ c'est pas super ...
Non, il se défend même bien (par rapport à MSVC et Borland, sous Linux spécifiquement il n'y a pas vraiment de concurrent, à part le compilo d'Intel dont l'utilisation est encore assez restreinte), et est courramment utilisé dans l'industrie (c'est le cas de plein de clients de ma boite, qui sont des gens très sérieux en général, vu le prix de nos produits :-).
Fais ton expérience, au lieu de "croire" et d'"entendre dire".
[^] # Re: Developpement
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 1.
Possible, oui. Facile ? Essaye...
Et le C (et donc GTK+) a également l'avantage de disposer d'un compilateur plutôt correct
g++ se porte bien, merci.
[^] # Re: Developpement
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 3.
Oui mais ça fait moins de choses. Pour faire en C ce que tu fais facilement en C++, tu va en chier bien plus que si tu devais apprendre C++.
C'est comme le vélo et la voiture. C'est plus facile d'apprendre à faire du vélo que d'apprendre à conduire, mais t'ira pas aussi loin.
Le seul hic à mon avis de Qt, c'est la société Trolltech qui décide principalement de son évolution
C'est bien ce qui fait la qualité du truc. Ils connaissent leur boulot, et écoutent leur clients, pas des neuneux à peine sorti de la fac qui se prennent pour des kadors du clavier. C'est pareil pour GTK+, d'ailleurs, et tout les projets qui tiennent un peu la route. Peu de contributeurs, mais des bons. La communauté, elle est bonne pour tester et debugger, pas pour développer. Ça c'est une affaire de petit groupe, autrement ça part très vite en couille.
[^] # Re: Guerre de desktop pas forcément guerre d'applis
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 3.
Ah bon, là d'accord. Tant que tu réponds pas "je veux pas apprendre" à ton chef, ça va :-).
[^] # Re: Guerre de desktop pas forcment guerre d'applis
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 3.
(note bien, je n'utilisais pas Glade et je n'utilise pas non plus Qt Designer).
Comme le souligne tanguy_k, ce genre d'outil est bien pour prototyper, mais ça montre vite ses limites.
# Developpement
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 5.
Pour toutes les applis que tu cites, tu oublies de comparer les ressources qu'il a fallu pour les sortir, et depuis combien de temps elles sont développées : Nautilus vs. Konq, Evolution vs. KMail, AbiWord vs. KWord, Gnumeric vs. KSpread.
Et aussi, comme tout le monde l'a souligné, le fait que beaucoup de ces applis ne sont pas à l'origine des applis Gnome (Mozilla, AbiWord, Gnucash...).
A propos de la "plus grande cohésion" de la communauté Gnome :
http://mail.gnome.org/archives/gnome-hackers/2002-April/msg00251.ht(...)
http://mail.gnome.org/archives/gnome-hackers/2002-March/msg00269.ht(...)
http://mail.gnome.org/archives/gnome-hackers/2002-March/msg00258.ht(...)
Regarde les autres threads. Gnome 2 a plus d'un an de retard, et ça n'a pas l'air d'affoler grand monde. Il y a même une discussion sur l'éventuel report en septembre de la release.
KDE a sorti KDE3 simplement pour suivre Qt3. C'est juste une question de version de l'API. Le portage de KDE2 à KDE3 est en général trivial à faire (ça a été le cas pour mon appli).
Sun est la seule boite "extérieure" à soutenir encore Gnome (Ximian ayant été crée expressément pour ça), et il ne sont là que pour avoir un remplaçant pas trop cher pour CDE. Sun fabrique des serveurs, de préférence pour faire tourner Java dessus. C'est là qu'est leur business, le desktop ils s'en tamponnent complètement. Note que les developpeurs Sun ne développent pas d'applis pour Gnome.
[^] # Re: Guerre de desktop pas forcément guerre d'applis
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à -2.
Tant pis pour toi. C'est un métier où les réactions du genre "je veux pas apprendre parce que ça me plait pas" ne mènent pas loin. Enfin si, tu peux devenir manager :-).
[^] # Re: Guerre de desktop pas forcment guerre d'applis
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 2.
Non, c'est tout à fait cohérent avec le reste, et indiqué dans la doc.
De telles choses n'arrivent pas avec GTK+
J'ai pratiqué les deux (GTK+ et Qt), et y a pas photo : tu vas 2 à 3 fois plus vite avec Qt.
[^] # Re: Guerre de desktop pas forcément guerre d'applis
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 1.
Tu ne comptes pas bosser un jour dans l'informatique, j'espère ? :-)
[^] # Re: En avant marche.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche OpenOffice.org 1.0 est sorti !. Évalué à 0.
[^] # Re: Hop... deuxieme gui scriptable
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Qt Script for Application. Évalué à 3.
Non. DCOP n'a rien à voir avec xml-rpc, par contre il existe un bridge dcop<->xml-rpc.
[^] # Re: Intéressant mais très incomplet
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Sortie de AbiWord 1.0. Évalué à 8.