Discussion :

[PF_Dev]

Editeur pour PHP et HTML: Phase5. Simple et efficace.
Editeur pour textes et PHP: NoteTab. Rapide et génial.
Borland Developer Studio 2006: couvre toutes les champs.

[aityahia]

salut,

j'ai voté ,

• Eclipse que j'utilise rarement mais j'aime bien.
• Zend Studio pour le développement PHP offre le support Zend Frameork
• Visual Studio pour le développement dotNet (sans commentaire).
• Aptana studio qui n'est pas dans la liste, je développe avec Ajax et JavaScript en particulier ExtJS.

Salutation.

[dsyann]

Parce que visual studio, il ne permet pas d'éditer le texte ? Vim et emacs, ce n'est pas "notepad avec de la colloration syntaxique" hein, c'est quand même un poil plus que ça !

Disons que certains (même des jeunes, genre, mmh, moi ) n'ont pas encore compris l'intérêt de lancer une usine à gaz à chaque fois qu'ils veulent programmer. Typiquement là : http://www.eclipse.org/screenshots/i...kFix-WinXP.png , on se retrouve avec une surface "utile" (là où il y a le code que j'écris !) de l'ordre de 50% de la surface totale. Quel est l'intérêt ?

A chaque fois que j'ai testé des IDE, j'ai eu l'impression d'être noyé sous un bruit totalement inutile qui m'empêche de simplement me concentrer sur mon code.

argument vrai et irrefutable, quoi qu'on peut les reduire ces vues voir meme les faire disparaitre, certes c'est vrai qu'il faut adorer faire la cour aux menus ou adoré son clavier pour combiner certaines touches de temps en temps, ce qui n'est pas le cas de vi notepad et compagnie ou on a l'ecran à nous;
Au final je dirais question d'habitude, car certains ce sont habitué a tel ou tel environement et qu'en fait c'est plus un argument que je dirais aujourd'hui de preferences et de gout (quoi que je suis tres subjectif).

[rad_hass]

Parce que visual studio, il ne permet pas d'éditer le texte ? Vim et emacs, ce n'est pas "notepad avec de la colloration syntaxique" hein, c'est quand même un poil plus que ça !

Disons que certains (même des jeunes, genre, mmh, moi ) n'ont pas encore compris l'intérêt de lancer une usine à gaz à chaque fois qu'ils veulent programmer. Typiquement là : http://www.eclipse.org/screenshots/i...kFix-WinXP.png , on se retrouve avec une surface "utile" (là où il y a le code que j'écris !) de l'ordre de 50% de la surface totale. Quel est l'intérêt ?

A chaque fois que j'ai testé des IDE, j'ai eu l'impression d'être noyé sous un bruit totalement inutile qui m'empêche de simplement me concentrer sur mon code.

Juste pour dire que dans le screenshot que tu mets, chaque onglet a un petit bouton pour le réduire et tu peux personnaliser l'affichage de ta surface ... (Comme dis au-dessus) ...Ceci étant je serais curieux de savoir, comment tu debug ? Comment tu fais des tests (Tests Unitaires ...) ? Sans parler des toolbox, gestion de serveur et autre gestion de solution ...

[Luc Hermitte]

a- Ceci étant je serais curieux de savoir, comment tu debug ? b- Comment tu fais des tests (Tests Unitaires ...) ? c- Sans parler des toolbox, gestion de serveur et autre gestion de solution ...

Je crois que tu as une idée complètement faussée de ces outils.

a- Cela fait belle lurette qu'emacs intègre le débugage. Pour vim il y a malheureusement quelques restrictions. (Et vi, quelle idée que de s'en servir)

b- ??? Un test unitaire n'est jamais qu'un fichier source qui réalise diverses assertions. Ces assertions, le principe c'est un peu de les exécuter automatiquement, genre avec la compilation nocturne, ce qui veut dire qu'on les intègre à la chaine de compilation (qu'elle soit construite pour make, ant, scons, bjam, ou ...). À partir du moment où ces outils (vim, emacs, ...) savent intègrer l'appel à la chaine de compilation, où est le problème ?

c- Tu peux définir précisément les termes que tu utilises STP ?

[rad_hass]

Je crois que tu as une idée complètement faussée de ces outils.

a- Cela fait belle lurette qu'emacs intègre le débugage. Pour vim il y a malheureusement quelques restrictions. (Et vi, quelle idée que de s'en servir)

b- ??? Un test unitaire n'est jamais qu'un fichier source qui réalise diverses assertions. Ces assertions, le principe c'est un peu de les exécuter automatiquement, genre avec la compilation nocturne, ce qui veut dire qu'on les intègre à la chaine de compilation (qu'elle soit construite pour make, ant, scons, bjam, ou ...). À partir du moment où ces outils (vim, emacs, ...) savent intègrer l'appel à la chaine de compilation, où est le problème ?

c- Tu peux définir précisément les termes que tu utilises STP ?

Un peu démasqué j'avoue que je trouve l'utilisation de ces outils archaïque, je déteste l'utilisation des makefiles, la gestion non automatisé des sources ... Et pleins d'autres choses ... Sans parlé de mon traumatisme de ces outils lors de mon initiation au développement à la fac ... A ma décharge je ne voulais pas crée de débat stérile mais simplement comprendre comment être productif et industrialisée son développement en utilisant ce genre d'outils ... A l'heure où on utilise des usines logicielle avec l'intégration de plus en plus grande d'outils dans l'IDE pour indistrualisé le process de développement ... Par exemple TFS, pour les tests (pas seulement unitaires d'ailleurs), la gestion des sources, reporting ...

Il est vrai que c'est possible en combinant les outils d'avoir quelque choses qui fonctionne, mais y a pas mal de bidouillage, d'habillage manuel à faire ... Sans parler de l'absence de designer ...

[souviron34]

Un peu démasqué j'avoue que je trouve l'utilisation de ces outils archaïque, je déteste l'utilisation des makefiles, la gestion non automatisé des sources ... Et pleins d'autres choses ... Sans parlé de mon traumatisme de ces outils lors de mon initiation au développement à la fac ... A ma décharge je ne voulais pas crée de débat stérile mais simplement comprendre comment être productif et industrialisée son développement en utilisant ce genre d'outils ... A l'heure où on utilise des usines logicielle avec l'intégration de plus en plus grande d'outils dans l'IDE pour indistrualisé le process de développement ... Par exemple TFS, pour les tests (pas seulement unitaires d'ailleurs), la gestion des sources, reporting ...

Il est vrai que c'est possible en combinant les outils d'avoir quelque choses qui fonctionne, mais y a pas mal de bidouillage, d'habillage manuel à faire ... Sans parler de l'absence de designer ...

tu ne voulais pas créer de débat stérile mais tu le fais

Bref, comme tu le dis toi-même : "A l'heure où on utilise des usines logicielle" ...


Car '"archaique", comme tu dis, est très nettement moins lourd, donc plus rapide....

• Ecrire un programme = taper du texte => donc éditeur de texte
• Bien présenter = manipuler du texte avec quelques règles => présentateur
• compiler = transformer ce texte en code machine => compilateur
• debuguer = trouver les erreurs et se pointer dessus => debugger

4 outils.

Les 2 premiers sont la plupart du temps de nos jours ensemble (et pour ce qui nous occupe, Vim et Emacs le font très bien).

Les 2 opérations suivantes sont de toutes façons dépendantes des outils. Outils simples = opérations simples.


Ce que tu traites "d'archaiques" est au contraire l'ensemble suffisant et nécessaire à notre tâche.

Le reste est du superflu.

MAIS comme c'est ça qui plait... C'est ça la "modernité"...

On nourrit donc le troll


et c'est de la "consommation", comme le GPS alors qu'une carte et des yeux suffisent...

[rad_hass]

tu ne voulais pas créer de débat stérile mais tu le fais

Je ne voulais aucunement provoqué une réaction un peu passionnel dans le sens j'ai raison/tord, tous ce que tu dis est vrai je le sais et je ne le nie pas, mais c'est une vision que je ne partage pas ... Je ne cherche ni à dire que c'est bien ou mauvais (ni convaincre ou être convaincu), je voulais savoir comment les personnes font (prendre l'information), pour non seulement pouvoir travailler de manière efficace mais surtout faire travailler des équipes projets ... Sur des technos modernes et les besoins/problématiques d'aujourd'hui ... Je suis d'accord qu'un gars qui maîtrise un outil (peut importe lequel) est plus productif, mais l'apprentissage de ce développement est plus complexe, on a environnement qu'on doit nous même construire pour gagner en productivité et automatisé des tâches disant pour le moins répétitives et de complexité minime ...

[Jean-Marc.Bourguet]

Un peu démasqué j'avoue que je trouve
l'utilisation de ces outils archaïque,

Bizarre, ces outils me semblent toujours d'un usage courant, leur
utilisation n'est pas encore un archaïsme (quand je m'amuse à utiliser le
emacs originel batit sur TECO avec un emulateur de PDP-10, la oui, c'est de
l'archaisme; assumé).

je déteste l'utilisation des makefiles,

C'est ton droit. Mais c'est difficile, il me semble, de nier qu'ils ont
une utilite qui n'est remplie par aucun des autres outils qui ont ete
specifiquement construits pour les remplacer. L'un d'entre eux (ou une
combinaison) finira peut-etre les rendre reellement obsoletes. Recemment
encore, j'ai vu quelqu'un faire le tour de ce qui se propose comme
remplacement et decider de rester a Imake + make...

la gestion non automatisé des sources ...

Qu'entends-tu par la? (Je vois des choses, ou c'est gere par emacs depuis
longtemps -- genre avant que les EDI le gere --, ou je ne vois pas du tout l'interet d'avoir ca dans un EDI)

Et pleins d'autres choses

Comme? Configurer Firefox pour editer les messages de ce forum avec un EDI
et faire en sorte que quand on se trouve entre des balises de code une
combinaison de touche permet de tester si ca compile? Je le fais avec
emacs. Je faisais une variante (je prenais le texte selectionne plutot que
de me fier a des balises absentes) deja sur Usenet avec emacs il y a 10
ans.

A ma décharge je ne voulais pas crée de débat stérile

C'est pas toi. C'est le sujet meme de cette discussion non?

mais simplement comprendre comment être productif et industrialisée
son développement en utilisant ce genre d'outils

En comprenant ces outils?

A l'heure où on utilise des usines logicielle avec l'intégration de
plus en plus grande d'outils dans l'IDE pour indistrualisé le process de
développement

C'est le vieux debats entre des "point tool" qui font chacun une chose et
tres bien et les "suites" qui font tout, bien integre, mais chaque chose
moins bien que les "point tools" specialises. On peut preferer etre moins
integre: il faut que l'integration apporte quelque chose pour que la
qualite inferieure des outils individuels soit compensee.

La seule chose citee jusqu'a present qui me semble pouvoir avoir une valeur
ajoutee a etre integre aussi fort, c'est la completion. Mais VC++ etant le
seul EDI qui semble avoir quelque chose de meilleur qu'emacs pour le C++ en
la matiere soufrant du defaut redhibitoire de n'etre pas disponible sur les
plateformes cibles de mes projets, je n'ai jamais pu tester en pratique
pour voir si ca suffisait comme avantage pour m'inciter a y passer.

Par exemple TFS, pour les tests (pas seulement unitaires
d'ailleurs),

Qu'est-ce que ca fait? (Les tests chez moi c'est lance de la meme maniere
par le build automatique toute les nuits que par le developpeur avant son
check in; et le build automatique n'a rien a faire avec un EDI. Avoir un
bouton qui lance un script, emacs le fait tres bien, merci.).

la gestion des sources,

Qu'entends-tu par la? (Je vois des choses, ou c'est gere par emacs depuis
longtemps, ou je ne vois pas du tout le rapport avec un EDI)

reporting ...

Qu'entends-tu par la? (Je vois des choses, mais je ne vois pas du tout le
rapport avec un EDI).

Il est vrai que c'est possible en combinant les outils d'avoir
quelque choses qui fonctionne, mais y a pas mal de bidouillage, d'habillage
manuel à faire...

Tu as un projet existant, pour passer a un EDI, il faut aussi adapter le
projet a l'EDI -- ce qui est un defaut majeur des EDI a mon avis. J'en ai
essaye pas mal a une epoque, pas un ne m'a sembler apporter quelque chose
qui vaille cet effort. Pas un ne m'a sembler apporter quelque chose qui vaille
l'effort d'essayer d'adapter l'EDI a la structure existante. Pire, pas un ne m'a
sembler apporter quelque chose qui vaille l'effort de changer mes habitudes
pour mes nouveaux projets persos. Pire, j'ai l'impression que pour ce que je fais,
je resterai plus productif avec ma configuration d'emacs.

Sans parler de l'absence de designer ...

Typiquement mieux traite par un point tool a mon avis :-)

[rad_hass]

Bizarre, ces outils me semblent toujours d'un usage courant, leur
utilisation n'est pas encore un archaïsme (quand je m'amuse à utiliser le
emacs originel batit sur TECO avec un emulateur de PDP-10, la oui, c'est de
l'archaisme; assumé).

[...]

Typiquement mieux traite par un point tool a mon avis :-)

Merci pour cette réponse assez complète avec cette petite pointe d'ironie

Etant développeur .NET sur windows, je n'ai jamais vu un environnement projet en entreprise basé sur Emacs , d'où mes interrogations (ça me semblait je l'avoue improbable, mais ce n'est qu'un préjugé j'ai jamais analysé la chose), de plus je n'ai jamais approfondi l'utilisation de ces outils, mes questions étaient par curiosité, non pas pour crée un débat, donc merci de m'avoir éclairci sur certains points.

[Jean-Marc.Bourguet]

Tu as un projet existant, pour passer a un EDI, il faut aussi adapter le
projet a l'EDI -- ce qui est un defaut majeur des EDI a mon avis.

Je n'ai pas ete clair ici. Ce qui me semble un defaut est que la plupart des EDI que j'ai rencontre semblent favoriser grandement l'adaptation de la structure des projets a l'EDI plutot qu'eux s'adapter au projet existant.

[souviron34]

Je n'ai pas ete clair ici. Ce qui me semble un defaut est que la plupart des EDI que j'ai rencontre semblent favoriser grandement l'adaptation de la structure des projets a l'EDI plutot qu'eux s'adapter au projet existant.

Absolument d'accord...

Et en plus en général ils créent tout un tas de types de fichiers, d'abroescences, etc, totalement artificiels par rapport au source et à son architecture...

[Garulfo]

[..]
Etant développeur .NET sur windows, je n'ai jamais vu un environnement projet en entreprise basé sur Emacs , d'où mes interrogations (ça me semblait je l'avoue improbable, mais ce n'est qu'un préjugé j'ai jamais analysé la chose), de plus je n'ai jamais approfondi l'utilisation de ces outils, mes questions étaient par curiosité, non pas pour crée un débat, donc merci de m'avoir éclairci sur certains points.

C'est probablement pour ça que tu ne comprends pas ce que sont Emacs et VIM. Si tu les utilisais un peu tu verrais que ce sont des outils extrêmement puissant. Faire mieux que Emacs me parait assez impossible. Avoir tout l'appareillage d'un Vim en ajoutant sa légèreté, me semble aussi difficile à moins de refaire Vim finalement. Quand je vois le temps qu'il me faut pour lancer Netbeans ou Eclipse (je n'ai qu'un petit Power Book G4 qui a trois ans, soit l'age de la retraite pour un portable), j'ai le temps d'ouvrir le fichier avec VI, faire les modifications, lancer le make et recommencer deux trois fois au besoin .

[fr1man]

Quoique vous puissiez en dire, je n'ai pas encore vu de projets Java/J2EE sous emacs ou autre.
Il y a certes un effet de mode, comme dans tous les domaines, mais il faut aussi reconnaître que des EDI comme Netbeans ou Eclipse permettent de gagner du temps sur pas mal de choses.
Et là, je parle de projets où l'on voit tout type de développeur, des débutants, des expérimentés.
Encore une fois, je parle du monde Java puisque c'est celui que je connais.

[Garulfo]

Quoique vous puissiez en dire, je n'ai pas encore vu de projets Java/J2EE sous emacs ou autre.[...]

Personnellement j'en ai vu.
Mais même si ce n'était pas le cas, en quoi le fait que tu n'en ais pas vu fait que Emacs ne soit pas un bon IDE La même remarque se posait si j'essayais de dire que c'est un IDE de qualité parce que j'ai vu qqun l'utiliser. Ça ne fait pas avancer le schmilblik tout ça.

[fr1man]

Tu déformes ce que je dis.
Je n'ai pas affirmé qu'Emacs était un mauvais IDE.
J'ai simplement dit, que je pensais que des IDE comme Netbeans ou Eclipse étaient plus adaptés au développement Java en général. C'est à dire sur petits ou gros projets.

Et le fait que je n'en ai pas vu, veut quand même dire que ce n'est pas très répandu(même si je n'ai pas la prétention de connaitre tous les projets en France) et que si ça ne l'est pas, c'est peut-être aussi qu'il y a une raison.

[souviron34]

Et le fait que je n'en ai pas vu, veut quand même dire que ce n'est pas très répandu(même si je n'ai pas la prétention de connaitre tous les projets en France) et que si ça ne l'est pas, c'est peut-être aussi qu'il y a une raison.

oui, il y a une raison..

La mode et le marketing commercial...




Et le bourrage de crâne + la "philosophie" M$...

[kaymak]

oui, il y a une raison..

La mode et le marketing commercial...




Et le bourrage de crâne + la "philosophie" M$...

Pas d'accord.
Tu sembles traiter la philosophie ms comme la dernière des m***

En attendant, ils ont le mérite de proposer des produits qui sont bien intégrés dans leur environnement.

Linux à depuis toujours, à mon goût, un gros problème d'intégration.
Il y à énormément de difficultés à trouver des ensembles logiciels cohérents tout intégré.
Avec les défis techniques que connaissent les développeurs linux, c'est le grand problème à améliorer selon moi sur linux....
Sa force et sa faiblesse.

Et les multiples distributions, si elles ont le méritent de démontrer la grande flexibilité de cet OS, sont aussi une perte de temps incroyable et un frein absolument terrible à la création d'un ensemble cohérent.
Comme simple exemple il n'y à qu'à voir les n types de packages existant entre les .deb, les .rpm, les .ebuild sur gentoo ect ect Et bien sur les n manager de package qui vont avec...

Franchement tout cela n'est pas très DRY.

Et tout cela ne me semble pas être une question de mode ou de marketing.... Simplement de volonté.

Mai sur linux, si les différents logiciels le composant sont très indépendant, les volontés sous jacente le sont aussi...

PS: bon sa dérive... désolé

[fr1man]

La mode et le marketing commercial...

Et le bourrage de crâne + la "philosophie" M$...

Et tu n'as jamais pensé que ça pouvait simplement être du aux qualités de Netbeans, Eclipse ou autre ?

On ne va comparer avec Microsoft et son Windows qui est embarqué sur pratiquement chaque PC vendu.

Que je sache, on ne force personne à utiliser Eclipse ou autre.

Je vais arrêter là car de toute façon, le débat est interminable, chacun a ses habitudes et est persuadé que l'outil qu'il utilise est mieux que celui du voisin.

[souviron34]

Et tu n'as jamais pensé que ça pouvait simplement être du aux qualités de Netbeans, Eclipse ou autre ?

J'ai dit que je trouvait NetBeans bien, et bien mieux que Eclipse...

Je répondais juste à ta question sur l'omni-présence...


Car, avant la grande déferlante d'il y a moins de 10 ans des gens du monde PC vers le monde unix via Linux (qui a effectivement atteint le coeur de Linux, en y transportant une partie de la philosophie M$, en l'occurence des versions non compatibles entre elles), les grands et mini-systèmes et leurs informaticiens se trouvaient très à l'aise avec un éditeur simple et un compilo et un bon débuggeur...

Donc si, il y a bien une influence gigantesque du "style" M$... Et comme l'informatique s'est "démocratisée", et que pour beaucoup de gestionaires ou chefs d'équipe c'était comme si on parlait le chinois, il y a eu (et il y a toujours, si l'on suit par exemple les modes de méthodologie de développement, mais les IDE et les langages sont dans le même cas), la très grande majorité des décisions sont prises sous l'influence de "l'intox" commerciale et marketing, et non pas sur la vraie valeur des outils... par rapport au travail...


PS : Il suffirait de faire un sous-sondage sur les 3 produits arrivant en tête en demandant sous quel OS ils tournent.. Déjà il y a 1 des 3 qui est M$. A eux 3, cela représentent ici, aujourdhui, 73 % de ce qui est utilisé..