Discussion :

[el muchacho]

Salut,

Comme je ne fais pas de gros projets, je suis accro à emacs.
Mais quand j'aurais 50 fichiers à gérer, je passerai aux IDE.

Mais il est vrai que pour apprendre il ne faut pas le faire avec des IDE, on ne comprend rien.
J'ai fais mon premier programme C avec Kdevelop et il m'a générer plein de fichier qui servait à rien (je ne savais même pas que le compilateur était gcc).
Je n'ai plus utilisé ce logiciel depuis (ni aucun autre pour apprendre ou pour les petits programmes) et je m'en sors comme ça.

Au boulot, on a des milliers de fichiers à gérer, et on est passé de Visual C++ à Emacs + makefiles sans aucun regret.
Tout d'abord, les dsp de VC++, c'est une vraie merde: parce que l'IDE met tous les /I et /D sur une même ligne, impossible de les comparer en conf sous ClearCase. Donc vive les makefile, et vive les outils comme ant ou jam, qui vont chercher les dépendances eux-même en lisant directement les sources, on n'a plus besoin de les spécifier, et qui en plus peuvent lancer des compilations en parallèle sur des machines biprocesseur en tenant compte des dépendances -> temps de compilation moitié moindre et maintenance des makefiles quasi nulle.

Ensuite, il faut savoir que sous l'IDE, la compilation est environ deux fois plus lente que si le compilateur de Visual est lancé à la main (faites l'essai, vous verrez). Donc sur un projet où la compilation passe de 2h à 35 minutes, on se passe fort bien de Visual. :smile:
L'IDE ne nous sert que comme debugger et pour les cycles de correction rapide, où l'on a besoin de compiler qu'une DLL ou un test.

Emacs permet de faire tout ce qu'un IDE fait (et un peu plus), class browser inclus, pour peu qu'on se donne la peine d'apprendre à l'utiliser. Cet investissement au départ est mille fois remboursé par la suite au quotidien. Ainsi, avec quelques scripts, on peut configurer une plateforme, la lancer, lancer les tests, etc. On peut aussi faire des scripts complexes pour modifier l'intégralité du code source plus facilement qu'en Perl, etc.

Pour pratiquer les deux, les IDE sont sympas au quotidien, mais ont l'inconvénient de rendre les gens intellectuellement "paresseux" et passifs. L'avantage de la méthode "roots" est évident et dès qu'un projet dépasse 5 personnes, parce que chacun se met à écrire des scripts pour automatiser les tâches. Ces scripts sont capitalisés et une fois mis en commun, on bâtit rapidement un environnement adapté au projet bcp plus performant qu'avec des clics de souris.
Ceci dit, pour faire des IHM, un IDE comme Delphi, c'est très utile (à cet égard, Visual C++ n'a strictement aucun intérêt).

[Franck.H]

Moi je serais surement pour le plus arcaïque des EDI possible mais tout en gardant un minimum, je suis actuellement sous Dev C++ 4, il gere des projet mais c'est toi meme qui relie tes differents fichiers entre eux, pas comme avec par exemple C++ Builder !!

Donc pour resumer, s'il faut prendre ne serais-ce que un editeur de texte simple et le compilateur et le linker à part, je pencherais plus pour cette pratique car tu en apprend deja plus rien que sur ton compilateur ce qui ne serais pas franchement la cas avec un EDI qui te fait tout sauf des fonction personnalisées !!

Pour moi le tout cuit, c'est trop cuit donc pas bon !! Mieux vaut commencer avec une methode la plus arcaïque possible, ne serais-ce que pour apprendre le mieux possible, rien ne t'empeche plust ard de passer sur un EDI qui te facilite la vie..........du moment que tu maitrise ton langage !!

[iolco51]

Tout dépend du projet et des langages je dirais.

Si le projet est en Java l'expérience des IDE Java est très bonne. Que ce soit Eclipse, JBuilder ou netbeans, le gain de temps est appréciable, les outils puissants, et ils ne génèrent pas de surprises.
Cela n'est pas vrai pour C ou C++, en C je pense que la méthode editeur de texte et compilateur en ligne de commande est la meilleure.
En C++ cela dépend de la taille du projet, et de la qualité des éditeurs. Il sera nécessaire de bien connaître son IDE pour maîtriser son projet.

Par exemple il est très simple de développer une appli. sous Visual Studio, mais l'environnement génère tellement de choses à lui seul (ne serait-ce que les options de compilation et les librairies liées) qu'il devient impossible de faire un intégration si on ne connait pas bien le langage, le compilateur et l'éditeur.


Dans tous les cas il est important de maîtriser le langage, les méthodes de compilation et d'édition de lien avant de développer sous un IDE.

[blbird]

Je ne conseil pas de faire des applications graphiques ou des applications moyennes ou grosses sans au minimum un IDE.

L'apprentissage d'un langage, c'est comme les divisions à l'école primaire. On a appris à les faire, qui en fait encore à la main après le lycée? L'important est d'avoir appris à le faire au moins une fois.

L'interêt d'un IDE pour moi est celui de l'informatique de base : automatiser ce qui peut être automatiser.

Et, pour moi, l'edition de liens fait partie de la catégorie à automatiser. Jamais eu aucun interêt à le faire à la main dans les langages dans lequel j'ai developpé sur de gros projets.

De même, quand je vois quelqu'un taper 15 lignes de codes (et encore je suis gentil) pour créer une fenêtre windows, ca me sidère. J'aurais envie de le faire reprogrammer en assembleur sa fenêtre Windows.

[shkyo]

Bon avant toute choses, je précise que j'aime travailler "à l'ancienne", pour du C => emacs+gcc et en ce moment je me remets doucement à l'assembleur Intel "pour le fun"...

En résumé, j'aime savoir ce qui se passe derrière chaque ligne de code que je tape... Mais non je ne suis pas parano...

On dit que les IDE, c'est bien car ça automatise, ça évite les phases pénibles, etc...
Mais je pense qu'à long terme, c'est peut-être un piège, déjà plus ça va et plus on va en faire le minimum (ben oui c'est humain...) puisque les IDE automatisent de plus en plus de chose, pourquoi s'embêter, ça fera bien pareil...

Mais bon, si on réfléchi bien, tout programme d'une certaine taille a des risques de bugs qui augmentent en même temps que son nombre de lignes de code, et les IDE, c'est loin d'être des poids plumes dans le genre...

Vous voyez surement où je veux en venir, si les progs d'IDE ont des bugs qui interfèrent avec ton propre code et le code auto-génèré, le débuggage risque de devenir franchement coton...

Et en plus, maintenant ils bossent sur des progs qui vont te dire si ton code est bon ou non, ou s'il a des bugs... ARGH !!!

Bon j'abuse peut-être, mais au final, dans quelques années, le codeur va écrire 4 lignes, cliquer sur 2 boutons et roulez jeunesse... Mais tout en croisant les doigts que rien ne déconne, sinon il y aura des séances de débuggage à se pendre !!!

Pour plaggier un vieux slogan : "sans maîtrise, la puissance n'est rien..."

[feed_our_vision]

En ce qui concerne les IDE,je n'irai pas de trois chemins,je prends un cas simple,Visual C++.
vou utilisez AppWizard pour parametrer votre apllication MFC(les fameuses 6 etapes),il vous etes tres difficile de revenir en arriere ou carrément impossible pour modifier certains caracteres de votre application.


Les fonctions derivees de CView liees aux clics sont integres a l'IDE,donc vous ne pourriez pas modifier leur nom meme si vous pouvez les surdefinir.Alors qu'il est tres important pour chak developpeur de nommer ses fonctions selon sa technique pour les reconniatre et savoir leur utilites rien qu'en lisant leur nom.
La mnemoteknik proposee par les MFC n'est pas la meilleure...

Il y a donc des contraintes que je trouve assez desobligeantes et peu democratiques.

Par contre,en faisant de la programmation root avec editeur simple ,vour auriez le controle absolu de tout votre code;mais vous coderez sans doute dix fois moins vite que moi et la difference de robustesse ne serait pas perceptible,si elle est existante.


Un choix democraik va s'operer dans ce cas,choisissez ce qui semble etre le mieux pour vous.

Ceci dit,que ce soit le puriste fidele a la technik"je code tout moi meme" ou le chevronné qui optimise en se fiant a un IDE,on ne pourrait se demettre d'une connaissance assez costaud en C++.
On ne dira pas alors ke le puriste est meilleur programmeur mais on pourra dire qu'il a moins de predispositions a travailler dans une equipe.

Reconnaissez qu'il est tres difficile de coder root root en equipe

Salut les faiseurs du monde!!!!

[gege2061]

Bonjour,
Je suis désolé mais je suis à l'inverse de tous le monde: je ne développe uniquement avec kwrite et cela pour deux raisons principales:
- j'ai déja eu des problème a la compilation sous kdevelop et j'ai été incapable de corriger l'erreur alors qu'avec un Makefile maison il n'y a aucun problème
- je n'est jamais réussi à faire ce que je voulai avec Galde, je passe un temps fou à cliquez partout et pour finir je ne comprend par grand chose au code générer depuis je suis passer sous kwrite et je fais (presque) ce que je veu!

J'ai eu aussi à utiliser Visual C++ pour programmer en API Win32 et meme si il est plus simple d'utiliser l'IDE, je suis obliger d'éditer certains fichier avec le blocnote pour pouvoir faire ce que je veu!

[sjrd]

Je suis un adepte des IDE.

Et pour cause : il devient impensable de développer des application graphiques uniquement avec les API !

L'inconvénient est l'exe généré est (beaucoup) plus gros avec IDE que sans... Cependant plus le projet est gros plus le rapport facilité/poids est élevé.

Maintenant vous me demanderez :
Et quand tu fais un petit projet (genre 1 feuille avec 2/3 contrôles), tu en fais quoi de ton rapport facilité/poids ?
Ben ce que j'en fais, c'est que je le transforme en un rapport facilité/temps . De fait, une petite appli comme ça tu fais ton interface en 1 minute avec IDE (contre 30 minutes pour le fonctionnement) alors que tu vas te taper 1 heure sans...

[Mac LAK]

Je pense qu'il y a aussi une nette confusion entre le mot "IDE" et "RAD", dans tous vos propos...

Perso, je n'ai jamais utilisé que des IDE (les makefiles me filent des petits boutons), mais si quelqu'un ici croit que Borland Pascal ou Borland C++ aident à la création du code, il faudra qu'il m'explique comment... :-D
Alors que, bien sûr, Delphi et C++ Builder, tout comme Visual C++, génèrent du code automatiquement suivant les besoins du développeur.

Un IDE (Integrated Development Environment pour mémoire) est juste un programme qui regroupe un éditeur de code, un gestionnaire de projet, un compilateur, un linker et (heureusement !) souvent un debugger, le tout bien intégré et accessible sans changer de programme. Dans ce sens, utiliser UltraEdit ou tout autre éditeur de texte capable de piloter des programmes externes est un IDE. Et oui, vu comme ça, un "emacs" bien configuré peut être considéré comme un IDE...

Un système RAD (Rapid Application Development) est souvent un IDE, mais pas forcément ! La nuance est qu'un RAD, effectivement, effectue une partie du travail du développeur "dans son dos", souvent parceque c'est répétitif et/ou critique et que l'on préfère un code généré de cette manière parceque plus fiable dans 99.99% des cas (et surtout, écrit en moins de 2 secondes au lieu de 2 mois). Vu de cette manière, le petit programme qui prends un .H pour générer le .C correspondant sans devoir se retaper les entêtes est un RAD (mais un RAD primaire, d'accord ! :-D). C'est pareil pour les "compléteurs" de code (genre Ctrl+Espace), qui finissent la frappe du nom de fonction à votre place.

J'ai eu aussi à utiliser Visual C++ pour programmer en API Win32 et meme si il est plus simple d'utiliser l'IDE, je suis obliger d'éditer certains fichier avec le blocnote pour pouvoir faire ce que je veu!

Confusion classique sur un RAD... Le RAD te génère du code "général", adapté à 90% des besoins, et surtout séquencé et organisé comme il faut. Le truc classique, c'est d'éviter de se peler à la main la création des composants, leur insertion, la création des boucles de messages, etc...
Mais ce n'est pas un outil miracle !! Pour certains besoins, il faut modifier les fichiers générés automatiquement pour les adapter !
Le truc, c'est que ça prend moins de temps de toutes façons de modifier ces fichiers que de les réécrire "from scratch". Paradoxalement, un RAD demande à bien connaître l'API et l'OS ciblés...

[Katyucha]

+1 avec la personne qui me précède sur la différences IDE / RAD / roots

Personnellement, je préfère largement programmer avec des environnements plus roots

Pourquoi :
- le mulot, ca me gave
- j'aime vi
- on apprend a programmer plus propre.

Voila, je ferai simple, car beaucoup de mes idées ont été données plus haut

[Erwy]

Je pense qu'il y a aussi une nette confusion entre le mot "IDE" et "RAD", dans tous vos propos...

C'est ce qu'il me semblait aussi
Je travaille essentiellement sur du web html/css/javascript/asp et xslt/xml et j'imagine facilement le temps que je perdrais sans debugger(surtout pour xslt le reve depuis que mon boulot m'a filé un IDE avec debugger, je gagne facilement 60% de temps), coloration syntaxique,liens etc.....
Par contre je n'ai jamais utiliser les generations de codes.

[gege2061]

]J'ai eu aussi à utiliser Visual C++ pour programmer en API Win32 et meme si il est plus simple d'utiliser l'IDE, je suis obliger d'éditer certains fichier avec le blocnote pour pouvoir faire ce que je veu!

Confusion classique sur un RAD... Le RAD te génère du code "général", adapté à 90% des besoins, et surtout séquencé et organisé comme il faut. Le truc classique, c'est d'éviter de se peler à la main la création des composants, leur insertion, la création des boucles de messages, etc...

Désoler pour moi un RAD été dans le genre Glade ou Delphi car avec visual c++, il me généré plutot 10 que 90% du code

[Mac LAK]

Désoler pour moi un RAD été dans le genre Glade ou Delphi car avec visual c++, il me généré plutot 10 que 90% du code

Il en génère beaucoup plus que ça, mais tu ne t'en rends pas compte (c'est normal, c'est fait pour ! :-D). Je disais que dans 90% des cas (et pas 90% du code !), le code généré est adapté à tes besoins, et c'est vrai. Mais le code "caché" qui te convient, tu ne le vois pas et tu t'en fous (puisqu'il convient), tout simplement ! ;-)

Tu n'as peut-être pas connu une époque où la création de composants devait se faire manuellement, de la fenêtre principale jusqu'au moindre bouton et élément de menu. Créer une simple fenêtre vide réclamait une dizaine de lignes de code pour le moins, et encore autant pour chaque composant de cette fenêtre... Là, déjà, tu le "dessines" visuellement, t'as même pas idée du nombre de lignes de code que ça vire...

Ceci étant dit, il est vrai que Visual C++ assiste beaucoup moins que Delphi, ou même Visual Basic (pourtant du même éditeur)... Mais VC++ reste un RAD à part entière, couplé à un IDE.

[gege2061]

Tu n'as peut-être pas connu une époque où la création de composants devait se faire manuellement, de la fenêtre principale jusqu'au moindre bouton et élément de menu. Créer une simple fenêtre vide réclamait une dizaine de lignes de code pour le moins, et encore autant pour chaque composant de cette fenêtre...

Non je n'ai pas connu

Là, déjà, tu le "dessines" visuellement, t'as même pas idée du nombre de lignes de code que ça vire...

Oui, il ya la possibilité d'utiliser un éditeur pour les boite de dialogue mais c'est plus simple d'aligné les boutons en éditant le fichier ressource.

[ourk]

Je pense qu'il y a aussi une nette confusion entre le mot "IDE" et "RAD", dans tous vos propos...

C'est ce qu'il me semblait aussi
Je travaille essentiellement sur du web html/css/javascript/asp et xslt/xml et j'imagine facilement le temps que je perdrais sans debugger(surtout pour xslt le reve depuis que mon boulot m'a filé un IDE avec debugger, je gagne facilement 60% de temps), coloration syntaxique,liens etc.....
Par contre je n'ai jamais utiliser les generations de codes.

La force du RAD ne réside pas tant dans la génération de code que dans la génération de "données". Le RAD et la souris sont surtout des outils de dessin et pour dessiner des états ou des écrans je n'ai franchement pas envie de me passer de la souris et de la palette d'alignement.
Maintenant ce qui est vrai pour l'informatique de gestion n'est sûrement pas vrai pour les autres domaines de l'info.

[Mac LAK]

Maintenant ce qui est vrai pour l'informatique de gestion n'est sûrement pas vrai pour les autres domaines de l'info.

Perdu... J'utilise un RAD pour microcontrôleurs embarqués (Tu vois où c'est, l'info de gestion ? Ben c'est à l'autre bout ! ;-)). Le module "Processor Expert" de CodeWarrior, pour le citer.

Ben t'as pas idée du temps que ça fait gagner par rapport à l'initialisation d'un contrôleur en s'épluchant la datasheet, calculatriceS à la main.

Un RAD est applicable partout où il y a des actions bêtes, méchantes, répétitives ou calculatoires à faire. Et quand ce n'est plus un "ou" des quatres mais un "et", ça devient carrément impératif !

[ourk]

Perdu... J'utilise un RAD pour microcontrôleurs embarqués (Tu vois où c'est, l'info de gestion ? Ben c'est à l'autre bout ! ;-)). Le module "Processor Expert" de CodeWarrior, pour le citer.

Ben t'as pas idée du temps que ça fait gagner par rapport à l'initialisation d'un contrôleur en s'épluchant la datasheet, calculatriceS à la main.

Je te crois sur parole parce que, comme tu l'as dit, c'est un peu à mille lieues de ce que je fait.

J'imagine aussi que quelque soit le domaine les progrès qui ont été fait dans les IDE au niveau des fonctions des debuggers sont un gain de temps indéniable. La facilité avec la quelle on peut placer des points d'arrêts ou surveiller la valeurs des variables n'a rien à voir avec ce qu'on a pu connaître il y a quelques années de celà.

[Mac LAK]

J'imagine aussi que quelque soit le domaine les progrès qui ont été fait dans les IDE au niveau des fonctions des debuggers sont un gain de temps indéniable. La facilité avec la quelle on peut placer des points d'arrêts ou surveiller la valeurs des variables n'a rien à voir avec ce qu'on a pu connaître il y a quelques années de celà.

Non seulement au niveau debugger, mais surtout au niveau de la génération automatique de code : que ce soit 400 lignes d'Assembleur pour initialiser un microcontrôleur ou une quadruple requête SQL avec moult jointures et index, en passant par la création de contrôles graphiques d'une fiche, tous sont du code généré automatiquement à partir d'un module plus ou moins graphique (en général, c'est "plus" quand même !). Et ce sont des heures, voire des jours de développement qui se résolvent en quelques minutes, et avec un taux d'erreur proche du ridicule...

C'est beau, le progrès, quand pour une fois ça nous simplifie la vie, à nous, développeurs...

[rolkA]

Désoler pour moi un RAD été dans le genre Glade ou Delphi car avec visual c++, il me généré plutot 10 que 90% du code

Je suis tout à fait d'accord et je ne vois pas ce que viendrait faire VisualC++ dans les vrais outils RAD comme Delphi ou Windev.

Pour la question initiale je suis adepte des IDE mais je crois qu'avoir fait plusieurs makefiles à la main dans sa vie n'est pas du luxe (pour rester sur l'exemple du C/C++).

[Mac LAK]

Je suis tout à fait d'accord et je ne vois pas ce que viendrait faire VisualC++ dans les vrais outils RAD comme Delphi ou Windev.

Confonds pas "RAD" au sens strict du niveau d'assistance du RAD en question... C'est sûr que Delphi ou WinDev génèrent bien plus de code que Visual C++, mais quoi qu'il en soit, ce dernier est bien un RAD malgré tout : cf. les Wizards "New MFC Application", "Insert new class", "Insert new form", etc...