Guillaume Laurent a écrit 1148 commentaires

C'est de la mauvaise foi juste pour le plaisir de dénigrer ?



Oui, là, je suis un gros vilain troll qui aime rien qu'a dire du mal du gentil Emacs. Ça te va comme ça ?

Arf, pour avoir mal compris à ce point là, faut vraiment que tu connaisses mal Emacs



Tu n'as pas du lire le post dans lequel je dis que j'utilise Emacs ou XEmacs depuis à peu près 10 ans. J'ai même contribué du code à l'un de ces modules dont on parle, func-menu :



Cherche "glaurent" dans cette page, tu trouvera mon ancienne adresse sur worldnet :



http://www.mit.edu/afs/athena/contrib/xemacs/lib/xemacs/xemacs-pack(...))



Crois-tu vraiment que je "connais mal Emacs" ?

Ah, et parce que si ils doivent taper eux-mêmes la méthode, ils vont magiquement apprendre quand et pourquoi mettre un destructeur virtuel ?

Mais avoir une arborescence de classes, des méthodes, cliquer sur le nom de l'une d'entre elles et voir sa définition dans une fenetre pendant qu'on code dans une autre, c'est pas une fonctionnalité de base d'un éditeur de texte

Non, mais c'est une fonctionalité de base d'un IDE, et, pour la N-eme fois, contrairement à ce que tu soutiens, XEmacs n'est pas un IDE. Content de voir que tu arrives enfin à assimiler ce concept.

Mais Emacs + modules qui vont bien, en est un

Non. Ou alors un vraiment très mauvais. Y a pas de project builder, pas de gestion des options passés au compilo et au link, pas de bon browser de code, pas de complétion intelligente, pas d'info dynamique pour avoir le proto de la méthode dont tu viens de taper le nom, etc...

Bon, je laisse tomber, ça devient vraiment puéril.

et que dans les cas simples, il vaut mieux utiliser les ide

Non, je dis que dans tous les cas je préfèrerais utiliser un IDE. Hélas en pratique ça n'est pas possible.

L'intérêt d'une IDE m'a toujours paru très limité

Tant pis pour toi, mais ça n'est pas mon cas ni celui de beaucoup d'autres. Ça fait un peu plus de 10 ans que j'utilise Emacs ou XEmacs, je commence à savoir m'en servir. Et pourtant y a plein de trucs que font les IDE que je trouve très bien et qui manquent à emacs.

Quand je vois que certains vont jusqu'à prétendre qu'(x)emacs n'est pas un IDE (c'est le point sur lequel je répondais), c'est clair qu'ils n'ont pas l'intention de discuter.

XEmacs est un très bon éditeur de texte et je suis d'accord pour dire qu'aucun IDE, à ma connaissance, ne dispose d'un editeur aussi puissant qu'XEmacs. Mais ça n'est pas un IDE. Il manque beaucoup trop de choses pour ça.

Comme je l'ai dit, ton exemple n'est pas propre à VC++. J'ai un collègue qui a ça sous Emacs quand il fait du Java.

Oui, il y a bien quelques modules (x)emacs qui font ça plus ou moins bien, mais ça reste très en dessous d'un bon IDE. En plus, comme tu le soulignes ces modes ne sont que pour Java. Pour C++ il n'y a rien, à par speedbar qui n'est pas vraiment comparable (normal, le langage est beaucoup plus dur à parser).

Mais bon, est-ce bien la peine de discuter...

Oui, mais le top c'est un IDE avec de bonnes libs, nanèreuh.

C'est quand même curieux a quel point chaque fois qu'on parle d'un truc ou Linux n'est pas champion, il y en a toujours qui se mettent la tête dans le sable et cherchent tous les arguments possible pour ne pas avoir à admettre le problème.

Très bien, maintenant parlons d'un truc que ton IDE ne peut pas faire. Je change les paramètres de la méthode bidule, ah merde, il faut changer tous les fichiers là où la méthode est appelée.

Ce que la plupart des IDEs avec de bonnes features de refactoring savent très bien faire, on en a testé quelques uns avec des potes au boulot il y a deux jours :

http://www.refactoring.com/#tools(...)

Et y a bien un mode emacs qui aide un peu pour ça, mais c'est pas exactement ce qu'il y a de plus commode.

Hop, un petit grep (voire un sed dans les cas simples), et c'est tout bon.

Euh, tu as vraiment déjà appliqué ce dont tu parles ? :-)

Comme le souligne pasBillGates qui a parfaitement raison pour le reste, grep ne va pas beaucoup t'aider pour modifier un texte. sed un peu plus, mais pour "changer les paramètres" d'une fonction dans du code, tu peux t'accrocher. Pour faire ça de manière fiable il faut sortir un vrai parser, pas un truc "line oriented".

Il n'y a pas un langage dont tu ne trouvera pas une implémentation avec des bugs stupides. Java ne fait pas exception, d'autant moins qu'il est assez jeune. Il n'empèche que globalement, ça marche.

Parce que les outils de dev de Windows permettent de générer des projets portables ?

Hélas non, je n'ai pas dit le contraire.

Je suis pas sur que VC++ (par exemple) s'en tire aussi bien dès qu'on sort des sentiers battus

Si, tu peux customiser assez facilement les projets, ajouter des pré et post commandes, etc...

Ta tendance à prendre les gens pour des cons est assez irritante. C'est pas parceque t'as jamais été copain avec les Makefiles qu'il faut prendre ton cas pour une généralité.

Il n'y a que naf que je prends gentiment pour un con, parce qu'un mec qui manifestement n'a jamais vraiment fait de makefiles "sérieux" vienne me dire "c'est tout simple, y a qu'a lire la doc", c'est un brin agaçant.

Et oui, mon cas est une généralité. Je n'ai jamais bossé dans un projet ou le système de build ne soit pas, à un moment où à un autre, une sources de problèmes.

Les problèmes que tu décris ne sont pas liés aux Makefiles en eux-mêmes. Ils sont plutot dû au fait que chaque environnement a son propre compilo avec ses propres outils[...]

C'est exactement ce que je dis, et pour résoudre tout ses problèmes il faut faire des makefiles complexes, ce qui prend du temps, et qu'il faut debugger et maintenir, ce qui prend encore plus de temps. Après tu peux couper les cheveux en 4 et dire "c'est pas la fautes des makefiles", le fait est que c'est là dessus qu'on passe du temps.

Donc dire que les makefiles c'est tout simple et avec l'expérience on trouve ça mieux qu'un IDE, c'est faux.

Après, oui, bien sur, tu as raison, il n'y a que les makefiles pour résoudre certains problèmes, en particulier la portabilité. Pas moyen d'y échapper. Là non plus, je ne dis pas le contraire, je dis simplement que ça n'est pas une chose simple et que si je pouvais m'en passer et avoir un IDE qui me gère tout ça à ma place, ça serait beaucoup mieux.

Ca ne constitue en rien une excuse pour mettre du code n'importe où.

Ben si, puisque ça n'est plus toi qui t'occupe de savoir où se trouve le code.

Moi j'aimais bien le concept des petits fichiers textes tout bêtes.

Moi aussi, mais c'est pas pour ça qu'il n'y a pas de meilleures solutions.

Je ne sais pas exactement, j'ai jamais vu passer de stats sur cette question là, mais oui, je suppose qu'on code plus vite en Python qu'en Java en moyenne. Et encore plus vite en Ruby sans doute.

Le problème, c'est qu'aucun des deux n'a derrière lui le quart du support qu'a Java (doc, extensions, etc...).

Gnome, bien qu'écrit en C, n'a rien à envier à KDE, je trouve

Essaie de développer une appli pour les deux, tu verra si tu restes du même avis.

alors, c'est si pourri que ça le C ?

Non, c'est juste que c'est vraiment pas dur de trouver mieux.

Franchement, faut être psychopathe pour faire du Java. Si au moins ça marchait correctement.

Ça marche correctement (moins sous Linux, où on n'a pas vraiment de bonnes implémentations), et les stats montrent que tu développes 3 fois plus vite avec qu'en C++.

j'écris les Makefile

Et ils sont portables sur combien de plateformes tes makefiles ? Est-ce qu'il faut les éditer à la main ou est-ce qu'il y a un script genre configure pour les générer ? Est-ce qu'ils gèrent bien les dépendences ?

Les Makefile, c'est comme Unix et pas mal d'outils comme sed, awk, vi...: quand on ne cherche pas à comprendre, on ne comprend pas, et une fois qu'on comprend, on se rend compte que c'est hyper simple!!

Tu as surement raison. J'ai pratiqué les makefile "fait maison", les Imakefiles, autoconf, tmake, qmake, automake+autoconf, et à chaque fois j'ai complètement loupé à quel point c'était hyper-simple. Et manifestement ça a échappé aussi aux mecs qui ont écrit tous ces outils pour faciliter la génération de makefiles. Ça s'est vachement amélioré le niveau de la fac maintenant, il en sort de vrais génies qui résolvent d'un coup un problème qui fait chier toute l'industrie depuis des années. Je suis impressioné.

Enfin peut-être pas, quand je suis sorti de fac je croyais aussi être très doué et que tout était simple. :-)

Quand il y a un outil pour naviguer rapidement dans les classes, on a tendance à ne pas s'embêter à organiser les sources

La notion de fichier source n'a rien à voir avec la programmation en soi, il y a des langages qui ignorent ce concept, et la tendance des IDE est précisément de t'en abstraire. Ou même tu as carrément des langages comme Java ou la structure des fichiers est définie par le nommage des classes.

J'ai ecris <<Visual C++ est mauvais pour le C Ansi.>>

Oui, et :

- c'est pas son boulot, c'est un compilo C++, et C99 n'est plus du tout aussi "compatible" avec C++ que ne l'était C89.

- je ne connais que gcc qui implémente C99, et encore partiellement :

http://gcc.gnu.org/c99status.html(...)

Mais bon, si ça peut te faire plaisir, oui, VC++ est un vilain méchant compilateur. Là.

D'autre part, je ne mettrais pas ma main au feu que "les VLA ne font pas parties du c++" (a verifier !).

Ils en font partie, simplement on ne le déclare pas comme ça :

int* foo = new int[n];

Ou plutôt std::vector<int> foo(n);

C'est quand même assez basique comme question C++, y a pas à chercher très loin pour trouver la réponse.

Tiens, juste un petit lien trouve au hasard sur les defailances de VC++:

Oh, surprise, y a des bugs dans VC++. Ben ça alors, je m'en serais jamais douté.

(pour info, je bosse sous Linux/g++).

Il ne compile pas !

Sans blague :

gcc -pedantic -ansi foo.c
foo.c: In function `main':
foo.c:5: warning: ISO C89 forbids variable-size array `foo'

C'est légal en C99, mais toujours pas en C++.

VC++ implémente la norme C++, pas la norme C. Il a tout a fait raison, ce code est illégal.

Avec l'expérience, tu apprends à générer ce genre de fichier en quelques minutes, et de façon durable (ne pas avoir à tout revérifier à chaque fois).

Ah bon, alors tu dois être beaucoup plus doué que moi et la totalité (je dis bien la totalité, et ça fait du monde) des gens que je connais développant ou ayant développé sous Unix en général et Linux en particulier. Ça fait 8 ans que je code sous Unix, et les makefiles restent toujours un problème. Je peux aussi te dire qu'ils sont toujours un problème pour les gens de Gnome et de KDE, ainsi que pour tous les développeurs dans toutes les boites où j'ai pu bosser (entre autres IBM, Lucent, Parasoft).

Un browser de méthodes/fonctions ne remplacera jamais une méthode de travail claire et rapidement compréhensible par d'autres

Personne n'a jamais dit le contraire, et d'ailleurs ça n'a pas grand chose à voir. Mais par rapport à 'find | xargs grep' ou ctags, ça fait quand même gagner un temps fou.

et n'a rien a envier au C++

Même pas un standard ISO, ou de quoi faire de la POO ?

Pascal est mort. Delphi je veux bien, mais Pascal...

mais avec l'expérience, on est bien content de pouvoir se faire son propre environnement à base de makefiles...

Non, c'est plutôt le contraire. Avec l'expérience tu en as un peu marre de perdre du temps avec ces conneries de makefiles et autres autoconf, de ne pas avoir de bon source browser, etc... :-)

Par exemple, autant des outils comme gdb ou gprof sont techniquement au niveau de VC++

Pour gprof je ne sais pas, je n'ai jamais fait de profiling sous VC++, mais pour gdb désolé, c'est une daube moisie pour le C++. C'est pas seulement une question d'interface au dessus, le support du C++ est pathétique.

Pour le reste, tu as tout à fait raison. Linux est hélas très loin derrière Windows pour les outils de dev.

Je ne te parle même pas des problèmes liés à Direct X, à l'interface graphique à porter de MFC --> GTK ...

Et le son, aussi. T'as oublié le son. Un cauchemard à supporter sous Linux.

mais l'idée peut etre trop ambitieuse pour les moyens de l'époque (les années 60 et 70)

De ce que tu en décris, j'ai plutôt l'impression du contraire : c'est un système qui date des années 60-70, où la mémoire et la place disque coutait très cher. Maintenant ça ne coute plus rien, et n'avoir qu'une seule copie d'un document ne présente aucun avantage. Au contraire, en ces temps de censure et de remises en question de certaines libertés, c'est même un sacré inconvénient.

maintenant j'imagine que Xanadu redevient interessant parce que mis en opensource, que l'opensource commence à etre a la mode et que suite aux limites du Web, on en revient à penser à un systeme à la Xanadu

Je n'y crois absolument pas. Surtout, tu parles des "limites" du Web alors que son coté hypertexte n'est plus le point essentiel. Le Web ne sert plus des documents mais des applications (je ne parle pas seulement de trucs comme les EJB, mais simplement de sites comme Amazon, etc... Amazon est une application, comme Excel ou Word, pas une pile de documents hypertexte).

Enfin et surtout, Yepou a tout à fait raison en disant que si Internet (et le Web en particulier) s'est développé autant, c'est parce qu'il n'y a pas de point centralisé.

Et si je leur dit qu'ils ne sont obliges de rien, mais que c'est parce qu'ils le veulent bien, je me fais taxer d'inconscient, voire des fois de jeune!!!

Il n'y a pas qu'eux à faire changer, il y a aussi tout ceux avec qui ils communiquent.

En plus, si on te proposait de changer ta voiture (ou ta moto, ton vélo, n'importe) contre un véhicule "qu'est 'achement mieux mais va falloir réapprendre à conduire", tu ralerais aussi.

Tant que Linux ou Windows seront pour toi plus que des outils, tu ne pourra pas comprendre leur problème.