Journal Point de vue : un IDE est il un outil de programmation indispensable ?

Posté par dave le 11 mai 2013 à 01:31. Licence CC By‑SA.

Étiquettes :

mai

2013

Bonjour,

Je vous fait part de réflexions sur le sujet des IDE. D'abord, je voudrai dire que je sais programmer, et que je connais bien deux langages (C et python pour les nommer), et vaguement quelques autres (php, C++, java,… ), et que j'ai appris aussi bien à l'école que par moi-même.

Mon profil n'a rien de celui d'un ingénieur ultra-qualifié en développement informatique.

Je réfléchissais en utilisant mon ~~IDE~~ Éditeur de texte que ce serait très bien d'avoir un IDE en mode graphique, ou par exemple on puisse avoir une complétion de code pour les clés de dictionnaire ou les indices de tableau.

Et en fait, la question plus générale m'est venue, de savoir si on pouvait considérer que savoir bien utiliser un IDE est une compétence indispensable pour un programmeur, et si oui, qu'apporte-t-il à votre travail quotidien. Qu'en pensez vous ?

# Automatisation indispensable

Posté par Ontologia (site web personnel) le 11 mai 2013 à 02:37. Évalué à 10.

La programmation a énormément changé depuis 20 ans, tout en restant dans ses bases exactement la même chose.

La seule différence est analogiquement similaire avec la disponibilité de l'information il y a 20 ans et aujourd'hui : il était difficile de s'informer avant, alors qu'on croule sous l'information aujourd'hui.

Le développement a suivi un chemin similaire : pléthore de documentation, forum, librairies.
Et surtout gros changement, la machine avec laquelle j'écris ses lignes a la même puissance qu'une machine du top 100 il y a 25 ans.
Donc logiciels plus gros, plus complexes…

Pour gérer cette masse, on a besoin d'automatiser tout ce qui est possible pour automatiser les parties rébarbatives de problèmes qui sont toujours les mêmes et seulement devenus plus critiques à cause de cette masse d'information/complexité à gérer.

Donc oui, les IDEs, mais les outils en générale sont devenus assez indispensable en nous permettant de gagner un temps précieux et de gérer plus facilement cette complexité.

Les anciens vous expliquerait que le copier/coller n'existait pas pendant longtemps…

Donc, tout outil permettant d'automatiser est potentiellement intéressant : compilateur analysant le typage, vérification de cohérence, etc…

Maîtriser ces outils est juste une capacité du développeur de mieux gérer cette complexité.
L'industrie étant ce qu'elle est, difficile de s'en passer, ou alors dans des domaines de niches, car la productivité moyenne requise est basé sur ces IDEs.

Personnellement, je pense que c'est la sémantique des langages (toujours la même depuis 50 ans) qui est trop limité : pas de possibilité (dans les outils couramment utilisés) de gérer le temps, car le programme est un éternel amnésique sur ses donnés (quelle règle appliquer si on a tel changement successif sur les donnés ?).
Sémantique du langage limité à celle définie lors de sa conception. Aucune notion de calculs sur contraintes entre composant.
Pas de sémantique de définition du comportement global du système.
Etc…

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- [^] # Re: Automatisation indispensable
  
  Posté par psychoslave__ (site web personnel) le 11 mai 2013 à 08:40. Évalué à 5.
  
  Donc logiciels plus gros, plus complexes…
  
  Tout dépend de ce que tu veux faire comme logiciel. Il y a des cas où l’on cherche à minimiser les tâches réalisés par un logiciel (_KISS_ qu’ils disaient), que ce soit par souci de réaliser une pièce qui fleur bon l’œuvre artisanale soignée (_for the love of art and the making_ qu’ils disaient), ou pour des raisons beaucoup plus pragmatiques comme « moins de lignes de code et de fioriture, c’est moins de bug potentiel ».
  
  Donc pour répondre à la question du journal, je dirais que tout simplement ça dépend du projet sur lequel tu bosses. Si toute ton équipe utilise la même IDE et que la maintenabilité du code devient dépendante de celle-ci, alors tu y échapperas que difficilement à travers une démarche probablement pas la plus productive possible.
  
  pas de possibilité (dans les outils couramment utilisés) de gérer le temps, car le programme est un éternel amnésique sur ses donnés (quelle règle appliquer si on a tel changement successif sur les donnés ?).
  
  C’est probablement lié au fait que raisonner sur le temps est un exercice d’une complexité nettement supérieur à celle de réflexions causales (déjà elles mêmes pas toujours évidentes). Mais ce n’est peut-être pas le temps en ce sens que tu signifiais. Pour le cas que tu cites, on peut par exemple maintenir sans trop de peine une structure qui sauvegarde l’historique des changements, une fonction qui prends cette structure et te renvois un nombre, une fonction qui applique un traitement en fonction de ce nombre. Bien sûr je consent qu’en pratique c’est plus ou moins aisé à mettre en œuvre.
  
  Sémantique du langage limité à celle définie lors de sa conception.
  
  Je crois qu’il me faudrait plus d’information pour comprendre ce que tu veux dire. Si on en crois la thèse de Church-Turing tous les programmes sont sémantiquement équivalent (et de toute façon en pratique c’est les mêmes circuits électroniques qui font le circuit au final). Mais je pense que je ne comprends tout simplement pas ce que tu as voulu dire ici.
  
  Aucune notion de calculs sur contraintes entre composant.
  
  Des langages par contraintes ça existe, je ne doute pas que tu le saches, puisque d’après mes souvenirs tu es un gourou du fonctionnel/Ocaml d’où j’infère que tu as un profil à savoir ce genre de choses. Par contre ici je pense que ce qui me manque c’est une explication du entre composant. Pense aux ignares comme moi quand tu écris. ;)
  
  Pas de sémantique de définition du comportement global du système.
  
  Idem.
  - [^] # Re: Automatisation indispensable
    
    Posté par Perthmâd (site web personnel) le 11 mai 2013 à 15:50. Évalué à 6.
    
    Si on en crois la thèse de Church-Turing tous les programmes sont sémantiquement équivalent
    
    Faut arrêter avec l'argument de Turing-completeness des langages de programmation pour justifier de leur expressivité. À peu près n'importe quel système est Turing-complet[1], et en général, dès qu'on essaye de créer un langage de programmation, fût-il domain-specific, il se retrouve Turing-complet.
    
    Dans ce cadre, on ne parle pas de la sémantique calculatoire mais plutôt de la facilité d'étendre un système en restant compatible avec ses garanties intrinsèques, comme le typage par exemple.
    
    On pourrait même être encore plus extrémiste et affirmer que le futur des langages de programmation, ce sont justement des langages non Turing-complets qui ont des garanties ultra-fortes sur l'exécution. Dans la veine des langages purement fonctionnels totaux où on ne peut même pas écrire une fonction qui ne termine pas…
    
    [1] http://xkcd.com/505/
    - [^] # Re: Automatisation indispensable
      
      Posté par lasher le 11 mai 2013 à 22:34. Évalué à 4.
      
      Le departement de l'energie US (enfin, sa division calcul/informatique) met pas mal d'efforts sur l'utilisation de DSL pour correctement exploiter les machines massivement paralleles.
      
      Le probleme c'est l'absence de volonte des utilisateurs/programmeurs d'essayer ces langages d'une part, et l'absence de "dialogue" entre les concepteurs des langages et leurs utilisateurs d'autre part.
- [^] # Re: Automatisation indispensable
  
  Posté par barmic le 11 mai 2013 à 10:56. Évalué à 10.
  
  À mon humble avis, tu confond IDE et éditeur de texte. Si les EDI viennent avec des éditeurs de texte intelligents ça n'empêche pas les éditeurs de texte de le faire aussi.
  
  Un IDE c'est l'intégration dans un seul outil d'un ensemble d'outils dont a besoin le développeur, l'éditeur de texte, le système de build, le gestionnaire de version, l'outil de diff, le debugger, etc. Du coup oui pour moi emacs et vim peuvent être considérés comme des IDE s'ils sont configurés pour. À contrario, j'utilise toujours mon gestionnaire de version à la main même quand je code avec un IDE.
  
  Là où les très gros IDE se démarquent c'est qu'ils intègrent plus de choses par exemple avec l'accès aux bases de données (relationnelles, LDAP ou noSQL) ou le contrôle du serveur d'application pour les IDE java, voir carrément le déploiement et l'accès à la page d'accueil du site que tu es entrain de développer (oui la page affichée directement dans l'IDE). C'est par exemple ce que permet de faire eclipse.
  
  Personnellement, je trouve que le fait d'avoir un outil ou N pour faire tout ça ne dérange pas, il faut juste que le tout se coordonne bien.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# On peut toujours creuser un trou à mains nues...

Posté par Croconux le 11 mai 2013 à 09:26. Évalué à 10.
…mais avec une pelle (voire une pelleteuse) ça va plus vite et c'est moins fatiguant.

Certes il est toujours possible de coder avec juste vi mais niveau productivité on perds énormément. Utiliser un IDE est devenu quasi indispensable sur de gros projets. Le confort apporté est incomparable:
- Auto-complétion
- Aide en ligne: Affichage dans une bulle de la signature des méthodes avec description des paramètres… Lien direct vers la doc complète
- Refactoring: Renommer/déplacer du code, laisser l'IDE montrer les impacts, valider et zou c'est fait Vs compiler, "ah merde il y a ça aussi à changer", recompiler, "ah merde j'en ai oublié un autre"…
- Debugging visuel: Voire en même temps le code source et en surbrillance ce qui est en cours d'exécution, passer la souris sur une variable pour voir son contenu, déplier un objet pour voire toutes ses propriétés…
- Génération de fichier: Makefile ou équivalent, voire code source, package de déploiement
- Intégration avec gestionnaire de source: SVN/GIT…
Tout ça fait que c'est franchement dur de s'en passer. Après je ne dirais pas que la maîtrise d'un IDE donné est indispensable. La plupart des gens n'utilisent pas toutes les fonctionnalités. Prendre ses marques est assez rapide et quand on en a utilisé un, passer à un autre n'est pas très difficile (seuls les raccourcis claviers - modifiables le plus souvent - sont galère). Et puis il faut dire que c'est relativement intuitif en général (à part peut être Eclipse qui a sa propre "philosophie").

Tout dépends aussi du(des) langage(s) utilisé(s). C'est sur des langages typés statiquement et compilés qu'un IDE apporte le plus. Sur des langages interprétés ou typés dynamiquement, les possibilités sont moindres. Il n'y a pas de miracle : Plus on donne d'information à un outil, plus il peut t'aider.
- [^] # Re: On peut toujours creuser un trou à mains nues...
  
  Posté par vincent LECOQ (site web personnel) le 11 mai 2013 à 09:42. Évalué à 2.
  
  et il y a aussi la cohérence de style dans les groupes de dev, largeur des tabulations, indentation par défaut de l'éditeur, style de commentaires, génération de la doc …
  
  Au passage, quelqu'un connaît un bon mode à Emacs pour avoir une vraie complétion plus intelligente aur le M-/ ? avec liste de suggestions et tout et tout ?
  - [^] # Re: On peut toujours creuser un trou à mains nues...
    
    Posté par GeneralZod le 11 mai 2013 à 09:51. Évalué à 6.
    
    Au passage, quelqu'un connaît un bon mode à Emacs pour avoir une vraie complétion plus intelligente aur le M-/ ? avec liste de suggestions et tout et tout ?
    
    auto-complete pour les jolies popup
    semantic pour la complétion sémantique en C, C++
    jedi/ac-python.py (plugin auto-complete) pour Python
    RSense pour Ruby
    etc…
  - [^] # Re: On peut toujours creuser un trou à mains nues...
    
    Posté par G.bleu (site web personnel) le 11 mai 2013 à 09:57. Évalué à 1.
```
    Au passage, quelqu'un connaît un bon mode à Emacs pour avoir une vraie complétion plus intelligente aur le M-/ ? avec liste de suggestions et tout et tout ?
```
    Le module clang avec autocomplete est exactement ce que tu cherche
    - liste de suggestions
    - complétion intelligente des fonctions et des structures
    - ça marche pour tous les langage de clang : c, c++ et objectiveC
    - tu peux compiler avec GCC et utiliser clang pour la complétion si ça te chante
    
    Et clang est un super compilo en plus ! J'adore le flag -analyze pour faire de l'analyse statique à partir de ton makefile d'origine (juste CFLAGS à change)
  - [^] # Re: On peut toujours creuser un trou à mains nues...
    
    Posté par barmic le 11 mai 2013 à 10:58. Évalué à 2.
    
    et il y a aussi la cohérence de style dans les groupes de dev, largeur des tabulations, indentation par défaut de l'éditeur, style de commentaires, génération de la doc …
    
    Ça ne demande qu'un peu de configuration pour pouvoir utiliser n'importe quel éditeur pour ça.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: On peut toujours creuser un trou à mains nues...
  
  Posté par flan (site web personnel) le 11 mai 2013 à 10:14. Évalué à 6.
  
  Tout cela est à peu près disponible dans VIM (au moins en Python, je connais moins pour les autres langages), pas forcément besoin d'un IDE complet. Après, ça demande un peu de temps pour se faire sa configuration. Ceci dit, cela fait longtemps que je me dis qu'il faudrait que j'apprenne à utiliser un IDE pour le Python (notamment PyCharm), mais je n'ai jamais le courage de réapprendre tous mes réflexes (surtout qu'il faudra de toute façon que je conserve VIM à côté).
  
  Mais je suis surtout d'accord avec ta dernière phrase. C'est d'ailleurs pour ça que j'aimerais pouvoir typer statiquement le Python (quitte à avoir un type optionnel), pas forcément pour les perfs mais plutôt pour les possibilités que ça apporte au niveau gestion des erreurs, debug et refactoring, …
- [^] # Re: On peut toujours creuser un trou à mains nues...
  
  Posté par Didier (site web personnel) le 11 mai 2013 à 10:57. Évalué à 1.
  Certes il est toujours possible de coder avec juste vi mais niveau productivité on perds énormément. Utiliser un IDE est devenu quasi indispensable sur de gros projets. Le confort apporté est incomparable:
  - Auto-complétion
  Ctrl+p sous vim.
  - Aide en ligne: Affichage dans une bulle de la signature des méthodes avec description des paramètres… Lien direct vers la doc complète
  :Man sous vim. Possibilité de mapper ça sur une séquence de touches exécutées sur un mot. Je code en C, donc ça me suffit comme doc.
  - Refactoring: Renommer/déplacer du code, laisser l'IDE montrer les impacts, valider et zou c'est fait Vs compiler, "ah merde il y a ça aussi à changer", recompiler, "ah merde j'en ai oublié un autre"…
  Le :make -> amené à la ligne fautive -> correction -> :make -> … est très efficace également.
  - Debugging visuel: Voire en même temps le code source et en surbrillance ce qui est en cours d'exécution, > passer la souris sur une variable pour voir son contenu, déplier un objet pour voire toutes ses propriétés…
  Je n'utilise pas de fonction similaire, donc je passe :)
  - Génération de fichier: Makefile ou équivalent, voire code source, package de déploiement
  Makefile: les autotools le font pour moi
  code source: beurk…
  package: rebeurk (le meilleur moyen d'avoir un package complètement pourri !)
  - Intégration avec gestionnaire de source: SVN/GIT…
  L'intégration existe. Et quand je vois les développeurs sous Eclipse qui se perdent dans l'affichage hiérarchique pour retrouver les modifs réalisées, je me dis que les outils en ligne de commande sont bien plus simple et intuitifs !
  
  Tout ça fait que c'est franchement dur de s'en passer. Après je ne dirais pas que la maîtrise d'un IDE donné est indispensable.
  
  Non, pas du tout. On peut s'en passer. À moins que l'on appelle vim + plugins un IDE, dans ce cas je te rejoins :)
  - [^] # Re: On peut toujours creuser un trou à mains nues...
    
    Posté par barmic le 11 mai 2013 à 11:06. Évalué à 5.
    Aide en ligne: Affichage dans une bulle de la signature des méthodes avec description des paramètres… Lien direct vers la doc complète
    
    :Man sous vim. Possibilité de mapper ça sur une séquence de touches exécutées sur un mot. Je code en C, donc ça me suffit comme doc.
    Ça n'a pas vraiment de rapport mais c'est un truc qui manque avec les langages autre que C et perl.
    Intégration avec gestionnaire de source: SVN/GIT… L'intégration existe. Et quand je vois les développeurs sous Eclipse qui se perdent dans l'affichage hiérarchique pour retrouver les modifs réalisées, je me dis que les outils en ligne de commande sont bien plus simple et intuitifs !
    Personnellement, je n'aime pas eclipse et ne l'utilise pas. J'ai toujours préféré utiliser mon gestionnaire de version à la mimine. Mais eclipse est pas mal foutu. Le plugin svn (je sais jamais si c'est subclipse ou l'autre) permet d'avoir une vue où tu vois les différences entre ta copie locale et le serveur (les choses à pousser, celles à récupérer et les conflits). C'est vraiment pas mal.
    
    Tout ça fait que c'est franchement dur de s'en passer. Après je ne dirais pas que la maîtrise d'un IDE donné est indispensable.
    
    Non, pas du tout. On peut s'en passer. À moins que l'on appelle vim + plugins un IDE, dans ce cas je te rejoins :)
    
    Si on considère eclipse comme un IDE, alors je ne vois pas pourquoi vim n'en serait pas un. La majorité des choses que fait eclipse sont issu de plugins.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: On peut toujours creuser un trou à mains nues...
      
      Posté par Didier (site web personnel) le 11 mai 2013 à 12:11. Évalué à 1.
      
      Aide en ligne: Affichage dans une bulle de la signature des méthodes avec description des paramètres… Lien direct vers la doc complète
      :Man sous vim. Possibilité de mapper ça sur une séquence de touches exécutées sur un mot. Je code en C, donc ça me suffit comme doc.
      
      Ça n'a pas vraiment de rapport mais c'est un truc qui manque avec les langages autre que C et perl.
      
      Ça a complètement à voir. Avec un mapping clavier pour appeler :Man sur un mot, j'ai bien l' Affichage dans ~~une bulle~~ dans une fenêtre de mon editeur de la signature des méthodes avec description des paramètres… Lien direct vers la doc complète
      
      Je t'accorde le fait que tous les langages n'ont pas de pages man. Mais rien n'empêche d'en construire à partir de la doc officielle ou bien de modifier la commande :Man pour afficher d'autres formats. Les autres IDE ne sont certainement pas capables d'afficher les infos pour tous les langages nativement, un plugin par langage doit certainement être nécessaire. Je parle de :Man car je fais du C, donc c'est la partie qui me concerne et que je connais bien.
      
      Intégration avec gestionnaire de source: SVN/GIT…
      L'intégration dans vim existe. Et quand je vois les développeurs sous Eclipse qui se perdent dans l'affichage hiérarchique pour retrouver les modifs réalisées, je me dis que les outils en ligne de commande sont bien plus simple et intuitifs !
      Personnellement, je n'aime pas eclipse et ne l'utilise pas. J'ai toujours préféré utiliser mon gestionnaire de version à la mimine. Mais eclipse est pas mal foutu. Le plugin svn (je sais jamais si c'est subclipse ou l'autre) permet d'avoir une vue où tu vois les différences entre ta copie locale et le serveur (les choses à pousser, celles à récupérer et les conflits). C'est vraiment pas mal.
      
      Je n'ai pas été convaincu par l'utilisation qu'en font les dévs là où je bosse. Il leur faut 10 clics et pas mal d'allers et retours dans l'aborescence pour parvenir à leur fin. En ligne de commande, avec un (git|bzr|svn) status on a un résumé concis et facile à lire avec l'appui de qq touches au clavier.
      
      Tout ça fait que c'est franchement dur de s'en passer. Après je ne dirais pas que la maîtrise d'un IDE donné est indispensable.
      Non, pas du tout. On peut s'en passer. À moins que l'on appelle vim + plugins un IDE, dans ce cas je te rejoins :)
      Si on considère eclipse comme un IDE, alors je ne vois pas pourquoi vim n'en serait pas un. La majorité des choses que fait eclipse sont issu de plugins.
      
      Je suis d'accord avec toi. J'ai formulé ma phrase ainsi car vim n'est souvent vu que comme un simple éditeur de texte alors qu'il fait bien plus que ça.
      - [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par Gof (site web personnel) le 11 mai 2013 à 12:33. Évalué à 5.
        
        Avec un mapping clavier pour appeler :Man sur un mot
        
        Ça marche bien quand tu as un langage impératif ou les « mots » ne dépendent pas du contexte. Mais dés que tu as des objects, des namespaces, ou différent manuels en fonction de la bibliothèque utilisée, ça ne marche plus.
        
        image.save("foo.png");
        
        Comment ton simple éditeur fait pour savoir que il faut aller chercher la doc de QImage::save(QString) ?
        
        Un IDE est assez intelligent pour savoir que la fonctione gdk_pixbuf_save est déclarée dans un header gtk et que donc c'est cette doc qu'il faut ouvrir.
      - [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par barmic le 11 mai 2013 à 12:40. Évalué à 2.
        
        Ça a complètement à voir.
        
        C'est ma complainte qui n'avait rien à voir. Je trouve dommage qu'il n'y ai pas plus de langage qui utilisent man.
        
        Je n'ai pas été convaincu par l'utilisation qu'en font les dévs là où je bosse. Il leur faut 10 clics et pas mal d'allers et retours dans l'aborescence pour parvenir à leur fin.
        
        Ils n'ont pas une vue « synchronize » ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par groumly le 11 mai 2013 à 19:41. Évalué à 2.
        
        C'est ma complainte qui n'avait rien à voir. Je trouve dommage qu'il n'y ai pas plus de langage qui utilisent man.
        
        D'un autre cote, autant man sleep, ca va, mais man org.springframework.database.hibernate.HibernateSessionFactory.createSession ca le fait un peu moins a taper.
        
        De meme quand c'est pour ton propre code que tu modifies souvent, tu vas pas t'emboucanner a reinstaller toutes les man pages a chaque git pull.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par ckyl le 11 mai 2013 à 19:59. Évalué à 2.
        
        On peut rajouter entre autre:
        
        Comment tu gères les différentes versions des libs & runtimes en parallèle
        
        Comment tu intègres ton code ou toutes les deps dans les mans
        
        Comment tu exposes les langages objets dans des mans (et comment tu gères les relations entre les objets)
        
        Les mans c'est très bien pour le système ou la lib C mais pour le reste ce n'est pas adapté
        
        Une fois que tu as résolu le problème des mans, on peut réfléchir à comment on accède facilement au code tiers, ce qui est dispo dans tout éditeur.
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par Didier (site web personnel) le 12 mai 2013 à 10:27. Évalué à -2.
        
        C'est ma complainte qui n'avait rien à voir. Je trouve dommage qu'il n'y ai pas plus de langage qui utilisent man.
        
        D'un autre cote, autant man sleep, ca va, mais man org.springframework.database.hibernate.HibernateSessionFactory.createSession ca le fait un peu moins a taper.
        
        D'où le mapping clavier pour avoir l'aide sur le mot en cours. Reste à savoir si cette fonction peut marcher avec des délimiteurs "." comme évoqué par un autre message.
        
        De meme quand c'est pour ton propre code que tu modifies souvent, tu vas pas t'emboucanner a reinstaller toutes les man pages a chaque git pull.
        
        Pour ton propre code en C ou C++, je te conseille http://cscope.sourceforge.net/ . Avec quelques raccourcis clavier bien choisis, tu peux naviguer dans ton code très aisément. Si tu place la doc de chaque fonction dans son entête (au format doxygen par exemple), alors tu obtiens la doc de ton code très aisément.
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par groumly le 12 mai 2013 à 10:35. Évalué à 3.
        
        D'où le mapping clavier pour avoir l'aide sur le mot en cours. Reste à savoir si cette fonction peut marcher avec des délimiteurs "." comme évoqué par un autre message.
        
        Et il est capable de faire la difference entre HibernateSessionFactory.createSession et HTTPServlet.createSession?
        
        Pour ton propre code en C ou C++, je te conseille http://cscope.sourceforge.net/ .
        
        Ou alors je peux utiliser un ide adapte, qui fera la meme chose, sur mon code et celui des autres, sans avoir besoin de changer de fenetre en permanence. Juste une idee, hein.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par Didier (site web personnel) le 12 mai 2013 à 11:13. Évalué à -4.
        
        D'où le mapping clavier pour avoir l'aide sur le mot en cours. Reste à savoir si cette fonction peut marcher avec des délimiteurs "." comme évoqué par un autre message.
        Et il est capable de faire la difference entre HibernateSessionFactory.createSession et HTTPServlet.createSession?
        
        Je ne sais pas. D'où ma remarque:
        
        Reste à savoir si cette fonction peut marcher avec des délimiteurs "." comme évoqué par un autre message
        
        Pour ton propre code en C ou C++, je te conseille http://cscope.sourceforge.net/ .
        Ou alors je peux utiliser un ide adapte, qui fera la meme chose, sur mon code et celui des autres, sans avoir besoin de changer de fenetre en permanence. Juste une idee, hein.
        
        Regarde un peu la page mentionnée avant de dire des bêtises : cscope est parfaitement intégré dans vim. Pas de besoin d'une autre fenêtre : ctrl+g m'amène à la définition d'une fonction, ctrl+c me liste tous les appels à la fonction, ctrl+s me liste toutes les occurrences du symbole…
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par ckyl le 12 mai 2013 à 11:39. Évalué à 5.
        
        Je ne sais pas. D'où ma remarque:
        
        Tu ne comprends visiblement pas le problème qui n'est pas une histoire de . mais qu'il faut avoir compilé le code pour être capable de déterminer le type d'une variable.
        
        Quel est le type de foo.createSession() ? Comment gères tu le polymorphisme entre foo.createSession(varInt) et foo.createSession(varLong) ? Comment gères l'héritage pour aller chercher la doc d'une méthode non surchargée ?
        
        Et oui encore une fois le boulot d'un IDE c'est de manipuler l'AST (et souvent un AST complétement invalide vu qu'en cours de dev).
        
        Ce ne sont que les problèmes les plus triviaux. Après tu as aussi ceux sur l'environement. Comment vas tu automatiquement chercher la bonne doc pour toutes tes deps (il faut parser le pom et aller tapper dans le repo m2 local).
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par Didier (site web personnel) le 12 mai 2013 à 12:56. Évalué à -2.
        
        Tu ne comprends visiblement pas le problème qui n'est pas une histoire de . mais qu'il faut avoir compilé le code pour être capable de déterminer le type d'une variable.
        
        Quel est le type de foo.createSession() ? Comment gères tu le polymorphisme entre foo.createSession(varInt) et foo.createSession(varLong) ? Comment gères l'héritage pour aller chercher la doc d'une méthode non surchargée ?
        
        Ce n'est pas de l'incompréhension. On n'a simplement pas les mêmes objectifs. S'il y a plusieurs occurrences de la fonction (polymorphisme par ex), rien n'empêche d'afficher les différentes possibilités. Cela va moins loin que ce à quoi tu penses et donc tu rejetteras probablement cette simplification en disant qu'elle rend la fonction complètement inutile et que tu serais 300 fois efficace qu'avec la fonction plus complète. Je veux bien te l'accorder, je n'ai pas l'usage de la fonction plus complète donc je n'émettrais pas d'avis sur la question.
        
        Et oui encore une fois le boulot d'un IDE c'est de manipuler l'AST (et souvent un AST complétement invalide vu qu'en cours de dev).
        
        Ce ne sont que les problèmes les plus triviaux. Après tu as aussi ceux sur l'environement. Comment vas tu automatiquement chercher la bonne doc pour toutes tes deps (il faut parser le pom et aller tapper dans le repo m2 local).
        
        Tu penses trop Java quand tu formules ta réponse. L'écosystème Java a une gestion d'un projet et plus particulièrement des dépendances assez particulière (en comparaison d'un projet autotools en C par exemple). Mes dépendances sont installées sur le système, les pages man également. Si j'ai besoin de dépendances particulières, je les ai installées dans ~/myapps/ et j'ai configuré mes outils pour également aller chercher les headers/librairies/man dans ce répertoire. Pas besoin d'aller parser la base RPM/DEB/…
    - [^] # Re: On peut toujours creuser un trou à mains nues...
      
      Posté par anaseto (site web personnel) le 12 mai 2013 à 10:58. Évalué à 1.
      
      Ça n'a pas vraiment de rapport mais c'est un truc qui manque avec les langages autre que C et perl.
      
      Pas que, en ocaml 'man Array' me donne la doc du module Array sous forme de page man (par contre le rendu n'est pas spécialement joli, je trouve, avec de gros espaces je sais pas trop pourquoi).
  - [^] # Re: On peut toujours creuser un trou à mains nues...
    
    Posté par mackwic le 11 mai 2013 à 12:31. Évalué à 10. Dernière modification le 11 mai 2013 à 12:34.
    
    Honnêtement, je peux dire que je suis un bon vimeur. Et je ne peux pas t'accorder le fait que Vim a un dixième des qualités d'un IDE.
    Contres-citation et ajouts:
    
    Auto-complétion
    
    Ctrl+p sous vim.
    
    Non, non, et non. L'autocompletion est un des points noirs de vim. Et ce pour plusieurs raisons:
    1. C'est horriblement lent dès que l'on est pas dans la completion de mots des buffers ou de chemins (^X^F FYI).
    2. On ne peut pas avoir plusieurs plugins qui alimentent le buffer de completion en même temps, il faut créer un faux-plugin wrapper pour cela (neocomplete + neosnippet + neocomplcache, oubliez clang-complete, snipmate, ou autre).
    3. Elle n'est pas intelligente. Clang-complete fait un début de completion intelligente pour un cas précis (méthodes et attributs), mais ça n'a rien à voir avec une completion qui prend en compte le type, la sémantique probable, etc. Ce que sait faire un bon IDE.
    4. Interruption du flot d'écriture. Si la completion est bien faite (hommage à ReSharper et InteliJ Idea), elle ne doit pas interrompre trop le flux d'ecoulement des doigts sur le clavier. Celle de Vim en est douloureuse, mais c'est un héritage à assumer.
    
    Aide en ligne: Affichage dans une bulle de la signature des méthodes avec description des paramètres… Lien direct vers la doc complète
    :Man sous vim. Possibilité de mapper ça sur une séquence de touches exécutées sur un mot. Je code en C, donc ça me suffit comme doc.
    
    :Man not an editor command. J'assume que tu parles de Man.vim. Tu savais qu'il existe ^K pour ça ? (EDIT: c'est pour un afichage en pop-up OK)
    À part ça, dans un gros ou moyen projet, le fait de ne pas pouvoir voir la doc autrement qu'avec ^], c'est souvent gênant. Et encore, il faut avoir généré le tagfile idoine, et qu'il soit dans le tagpath de vim.
    
    Refactoring: Renommer/déplacer du code, laisser l'IDE montrer les impacts, valider et zou c'est fait Vs compiler, "ah merde il y a ça aussi à changer", recompiler, "ah merde j'en ai oublié un autre"…
    Le :make -> amené à la ligne fautive -> correction -> :make -> … est très efficace également.
    
    Non. Il l'est dans ton cas. Les problèmes de :make sont:
    1. Make est lent de base. Si ton projet est un peu gros et en C++, avec des templates, avec CXX=g++, tu as perdu.
    2. Surtout si certains de tes fichiers sont générés par un soft externe (eg: flex, bison, swig, doxygen, script de rapatriement perso)
    3. :make met vim en pause ! Tu ne peux pas travailler pendant que ça compile en background.
    4. :make pour du C# ? Pour du Java ? Pour du Qt ?
    
    Bref, je m'arrête là. J'ai aussi une nette préférence pour Vim lorsque je code en C. Mais en C++ je sors KDevelop avant que les choses ne dégénèrent. ;)
    - [^] # Re: On peut toujours creuser un trou à mains nues...
      
      Posté par LeMagicien Garcimore le 11 mai 2013 à 21:49. Évalué à 2.
      Make est lent de base. Si ton projet est un peu gros et en C++, avec des templates, avec CXX=g++, tu as perdu.
      
      J'ai un peu du mal avec cette affirmation. Avec les .d, tu recompiles exactement ce dont tu as besoin, je vois pas comment tu peux faire plus rapide. Tu proposes quoi ?
      
      J'utilise Ant, Maven et Gradle quotidiennement, je peux t'assurer que make est rapide…
      - [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par mackwic le 11 mai 2013 à 23:04. Évalué à 3.
        
        J'utilise Ant, Maven et Gradle quotidiennement, je peux t'assurer que make est rapide…
        
        J'allais parler des filtres make (%.o:%.c) qui sont lent mais j'avoue que là tu sors encore pire.
        
        En conclusion: laissez le générateur de Makefile faire son boulot, et utilisez ninja quand vous pouvez.
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par LeMagicien Garcimore le 12 mai 2013 à 00:42. Évalué à 4.
        
        J'allais parler des filtres make (%.o:%.c) qui sont lent mais j'avoue que là tu sors encore pire.
        
        Les règles implicites sont lentes ? Honnêtement c'est bien la première fois que je lis ça ! par rapport a la compilation elle même (surtout sur des projets c++ qui abusent des templates/STL/Boost, c'est rien AMHA.
        On peut reprocher beaucoup de chose a make, mais l'accuser de lenteur c'est assez injuste…
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par barmic le 12 mai 2013 à 01:06. Évalué à 3.
        
        utilisez ninja quand vous pouvez.
        
        Il y a quelqu'un d'autre que chrome qui s'en sert ? C'est vraiment maintenu par google ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par G.bleu (site web personnel) le 12 mai 2013 à 11:00. Évalué à 1.
        
        Moi je m'en sers !
        Avec Cmake tu peux configurer pour utiliser make ou ninja au choix en un seul clique (et au aussi préférer clang à gcc de la même façon ^⁾
        
        Au final on gagne un peu en vitesse (mais c'est anecdotique sur autre chose qu'un gros projet avec des makefiles récursifs) et surtout une compilation automatiquement parallélisé et une sortie bufferisé (comme ça les messages d'erreurs ne se mélangent pas en cas de compilation parallèle)
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par barmic le 12 mai 2013 à 14:07. Évalué à 2.
        
        une compilation automatiquement parallélisé
        
        En quoi elle est mieux que make -j ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par G.bleu (site web personnel) le 13 mai 2013 à 20:33. Évalué à -1.
        
        En quoi elle est mieux que make -j ?
        
        make -j ne limite pas le nombre de compilations à lancer en parallèle (il respect juste les dépendances de compilation), donc si tu peux lancer 40 compilation en même temps il va le faire (enfin c'est ce qui est écrit dans la doc en tout cas, j'ai jamais testé)
        
        D'après man make :
        
        If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.
        
        Au final 40 compilations en parallèle sur un PC avec 4 coeurs, ça en fait du temps perdu en changement de tâches !
        
        Ninja est pensé pour déterminer automatiquement le nombre de compilations à lancer en parallèle (je pense qu'il fait peut ou prou la méthode Gentoo : "le nombre de CPU + 1")
        Donc avec 40 compilations en parallèle possible, il n'en lancera que 5 à la fois sur un quadcore.
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par barmic le 13 mai 2013 à 22:15. Évalué à 6.
        
        Passer de make à ninja pour simplement éviter d'avoir à écrire " 4" (la règle du nombre de cpu + 1 n'est plus valable) ça me semble un peu too much.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par G.bleu (site web personnel) le 14 mai 2013 à 09:23. Évalué à 2.
        
        Je résume donc :
        
        ninja est prévu pour n'être pas écrit à la main mais généré automatiquement. Passer de make à ninja revient donc à configurer une option avec cmake (c'est aussi simple que de passer de gcc à clang en fait !). Évidemment, si tes Makefiles sont fait à la main, c'est "too much" de passer à ninja ;-)
        
        ninja gère automatiquement le bon nombre de processus à lancer : make -j4 sur simple coeur fera perdre des performances. En plus, en cas de Makefile récursif l'argument "-j" fournit initialement par l'utilisateur doit être propagé dans les autres appels ce qui n'est pas commode du tout alors que ça "juste fonctionne" avec ninja
        
        ninja gère mieux les dépendances (typiquement les modifications dans les .h que make ne prend pas en compte sans "gcc-M") et recompile en cas de changements dans les flags
        
        ET SURTOUT : ninja bufferise ta sortie, en cas d'erreur tu n'as pas une chiée de messages dans tous les sens relatif à différents fichiers. En cas d'erreur, il imprime tout seul comme un grand la commande de compilation qui a échouée ainsi que le/les messages d'erreurs
        
        [^] # Re: On peut toujours creuser un trou à mains nues...
        
        Posté par barmic le 14 mai 2013 à 11:34. Évalué à 2.
        
        Le premier point me semble important en effet (j'ai pas l'habitude de cmake et pmake apporte déjà quelques avantage sur make notamment au sujet de la parallélisation).
        
        Il semble maintenu en plus : http://martine.github.io/ninja/ (je n'en avais pas entendu parlé depuis l'annonce de sa sortie)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: On peut toujours creuser un trou à mains nues...
      
      Posté par barmic le 12 mai 2013 à 00:43. Évalué à 6.
      
      Pour :make, il ne s'agit pas d'un appel à make mais d'un appel à ton builder, si tu défini un autre builder (via la variable makeprg) tu pourras appeller le builder que tu veux.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: On peut toujours creuser un trou à mains nues...
      
      Posté par Didier (site web personnel) le 12 mai 2013 à 10:45. Évalué à -2.
      Auto-complétion
      Ctrl+p sous vim.
      Non, non, et non. L'autocompletion est un des points noirs de vim. Et ce pour plusieurs raisons:
      1. C'est horriblement lent dès que l'on est pas dans la completion de mots des buffers ou de chemins (^{X^F} FYI).
      2. On ne peut pas avoir plusieurs plugins qui alimentent le buffer de completion en même temps, il faut créer un faux-plugin wrapper pour cela (neocomplete + neosnippet + neocomplcache, oubliez clang-complete, snipmate, ou autre).
      3. Elle n'est pas intelligente. Clang-complete fait un début de completion intelligente pour un cas précis (méthodes et attributs), mais ça n'a rien à voir avec une completion qui prend en compte le type, la sémantique probable, etc. Ce que sait faire un bon IDE.
      4. Interruption du flot d'écriture. Si la completion est bien faite (hommage à ReSharper et InteliJ Idea), elle ne doit pas interrompre trop le flux d'ecoulement des doigts sur le clavier. Celle de Vim en est douloureuse, mais c'est un héritage à assumer.
      
      Oui, la complétion est loin d'être parfaite, je le reconnais volontiers, mais elle me suffit. De mon expérience perso, taper les 3-4 premiers caractères suffit à me trouver une seule occurrence, au pire 2-3.
      
      :Man not an editor command. J'assume que tu parles de Man.vim. Tu savais qu'il existe ^K pour ça ? (EDIT: c'est pour un afichage en pop-up OK)
      À part ça, dans un gros ou moyen projet, le fait de ne pas pouvoir voir la doc autrement qu'avec ^], c'est souvent gênant. Et encore, il faut avoir généré le tagfile idoine, et qu'il soit dans le tagpath de vim.
      
      Pour la doc sur mon propre projet, j'utilise cscope. Cf. ma réponse au message précédent.
      
      Le :make -> amené à la ligne fautive -> correction -> :make -> … est très efficace également.
      Non. Il l'est dans ton cas. Les problèmes de :make sont:
      
      Oui, je parle de mon expérience perso de développeur C. Ce n'est pas forcément transposable au C++, au Java ou <insérer votre langage préféré ici>
      
      Make est lent de base. Si ton projet est un peu gros et en C++, avec des templates, avec CXX=g++, tu as perdu.
      
      make n'est pas responsable, ça dépend ce que tu en fais. J'utilise des Makefile générés par les autotools. Ils gèrent les dépendances et donc ne regénèrent que ce qui est nécessaire. C'est très rapide pour mon usage.
      
      Surtout si certains de tes fichiers sont générés par un soft externe (eg: flex, bison, swig, doxygen, script de rapatriement perso)
      
      Si tu interviens sur le template et que la génération est plutôt lente, oui. Mais ce n'est pas le cas général. Ce qui arrive le plus souvent, c'est le renommage d'une variable ou fonction ou bien un changement de signature. Ma méthode est bcp moins fine que celle d'un IDE plus évolué, elle ne fonctionnerait pas avec un langage plus dynamique que le C comme le Python.
      
      :make met vim en pause ! Tu ne peux pas travailler pendant que ça compile en background.
      
      C'est tellement rapide que j'aurais bien du mal à faire qq chose d'autre pendant ce temps ! J'ai tout juste le temps de jeter un oeil à l'openspace autour ;-)
      
      :make pour du C# ? Pour du Java ? Pour du Qt ?
      
      Comme précisé dans un message plus bas, :make peut appeler n'importe quelle commande et pas seulement make. Le nom est historique je suppose.
      
      Bref, je m'arrête là. J'ai aussi une nette préférence pour Vim lorsque je code en C. Mais en C++ je sors KDevelop avant que les choses ne dégénèrent. ;)
      
      Je ne commenterai pas pour le cas du C++, je n'y touche pas ;-)
    - [^] # Re: On peut toujours creuser un trou à mains nues...
      
      Posté par anaseto (site web personnel) le 12 mai 2013 à 11:13. Évalué à 1.
      Elle n'est pas intelligente. Clang-complete fait un début de completion intelligente pour un cas précis (méthodes et attributs), mais ça n'a rien à voir avec une completion qui prend en compte le type, la sémantique probable, etc. Ce que sait faire un bon IDE.
      
      Côté ocaml j'ai trouvé le plugin merlin qui sert pour vim et emacs, qui est sensé donner de la complétion qui dépend du contexte, je ne l'ai pas encore essayé, mais ça a l'air bien. Sinon, en général je suppose que ça doit dépendre du langage et des plugins parce que théoriquement avec l'omni-completion de vim, on devrait pouvoir faire n'importe quoi.
      
      Interruption du flot d'écriture. Si la completion est bien faite (hommage à ReSharper et InteliJ Idea), elle ne doit pas interrompre trop le flux d'ecoulement des doigts sur le clavier. Celle de Vim en est douloureuse, mais c'est un héritage à assumer.
      
      C'est curieux, moi j'ai au contraire horreur des pop-ups avec des trucs qui apparaissent alors que j'ai rien demandé, ça me déconcentre. Par contre, j'utilise le plugin supertab, parce que je trouve ctrl+p pas très pratique : deux touches à taper pour un truc courant c'est trop.
# Non, mais ...

Posté par GeneralZod le 11 mai 2013 à 09:47. Évalué à 10.
Les IDE proposent beaucoup de fonctionnalités qui peuvent améliorer la productivité des développeurs mais ils:
- inflation des fonctionnalités inutilisées voire inutiles (loi de Pareto 80/20 etc.) qui rend plus difficile la courbe d'apprentissage
- souvent très spécialisé pour une configuration donnée, dès qu'on en sort, on en revient à la gadoue (Eclipse/Netbeans/Intellij sont des blagues pour faire du C++) et le "savoir-faire" acquis n'est pas réutilisable.
- ont souvent des éditeurs assez pauvres comparés à Emacs/Vim
- chacun a un workflow personnel différent, ça explique les guéguerres Emacs/Vim, Eclipse/Intellij etc., c'est illusoire de vouloir fournir un IDE pré-configuré pour tous. On ne fait que planter des bâtons dans les roues des gens.
Le plus important, c'est:
- d'automatiser au maximum les tâches chiantes pour le développeur
- de réutiliser le "savoir-faire" acquis
L'avantage du NoIDE, c'est qu'une fois que tu as maitrisé ton environnement de base, il est adapté à ton workflow personnel (pas ou peu de gâchis), complètement maitrisé (qui maitrise 100% de son IDE ?) et s'adapte rapidement à un changement de contexte.

Je ne dis pas que les IDE c'est inutile, juste que ça n'est pas la panacée, dans certains cas, il y a un réel gain de productivité (Eclipse pour faire du Java, QtCreator pour du Qt etc.). Tout ça pour te dire que non, ça n'est pas une compétence indispensable (je préfère un bon développeur bien outillé qu'un développeur médiocre + super IDE), ça peut figurer sur le CV si ça a un rapport avec le poste.
Personnellement, je n'impose aucun environnement de développement, les seules règles étant:
* coding standard <= à respecter strictement (chacun configure son environnement pour, j'ai fait des confs emacs et vim basiques pour démarrer)
* pas des fichiers liés à un IDE dans le SCM <= ils sont souvent réécrits par ceux-ci et polluent l'historique
* revue de code systématique
* auto-régulation dans le nombre de langages, frameworks par projet et au niveau de l'équipe (formule empirique: chienlit = nb de pers * tps d'apprentissage * exp(nb changements de contexte))
Je suis sensé travailler avec des ingénieurs, je ne devrais pas avoir à décider de leur environnement de travail, à eux de s'organiser pour arriver à un résultat professionnel et de collaborer avec les autres.
- [^] # Re: Non, mais ...
  
  Posté par barmic le 11 mai 2013 à 11:21. Évalué à 7.
  - inflation des fonctionnalités inutilisées voire inutiles (loi de Pareto 80/20 etc.) qui rend plus difficile la courbe d'apprentissage
  Il faut voir, mais je crois qu'on peut virer énormément de choses du plus gros des IDE, eclipse.
  - souvent très spécialisé pour une configuration donnée, dès qu'on en sort, on en revient à la gadoue (Eclipse/Netbeans/Intellij sont des blagues pour faire du C++) et le "savoir-faire" acquis n'est pas réutilisable.
  Je ne sais pas pour faire du C ou du C++ avec eclipse par exemple (même si j'entends parler de personnes qui le font, je pense que c'est assez marginal). Mais là où tu y gagne c'est que ces éditeurs von généralement t'offrir une abstraction du système de build, du gestionnaire de version etc pour au final te permettre d'en changer facilement.
  - ont souvent des éditeurs assez pauvres comparés à Emacs/Vim
  Je ne le crois pas (et je suis fan de vim). Ils ont un éditeur clairement plus intelligent que vim/emacs (alors emacs peut utiliser CDT je crois pour être au niveau d'eclipse pour vim je sais pas), mais n'ont pas les fonctions puissantes du vieux couple.
  
  Mais généralement on ne sait pas tout ce que peut faire l'éditeur des IDE eclipse/netbeans/intellij, parce qu'on s'y intéresse moins et qu'on a tendance à croire qu'on est face à un équivalent de gedit (ce qui est faux !). Eclipse peut intégrer vim comme éditeur de texte.
  - chacun a un workflow personnel différent, ça explique les guéguerres Emacs/Vim, Eclipse/Intellij etc., c'est illusoire de vouloir fournir un IDE pré-configuré pour tous. On ne fait que planter des bâtons dans les roues des gens.
  Là tu parle d'imposer un IDE à un ensemble de personne. Comme tu le dis c'est aussi intelligent de forcer l'utilisation d'emacs que de forcer l'utilisation de netbeans.
  
  L'avantage du NoIDE, c'est qu'une fois que tu as maitrisé ton environnement de base, il est adapté à ton workflow personnel (pas ou peu de gâchis), complètement maitrisé (**qui maitrise 100% de son IDE ?**) et s'adapte rapidement à un changement de contexte.
  
  Qui maitre 100% de son éditeur de texte, de son gestionnaire de version et de son shell ? Ça ne me semble pas un bon argument, on a accès à des outils incroyablement puissants qu'il est très difficile/impossible de maitriser dans leur ensemble et cela que l'environnement de développement soit intégré ou non. D'ailleurs il est possible que ce soit bien plus simple de maitriser 100% d'un IDE que d'un DE (la documentation est moins éclatée et il y a moins de fonctionnalités (en nombre je ne dis pas que l'un est un sous-ensemble de l'autre)).
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Non, mais ...
    
    Posté par mackwic le 11 mai 2013 à 12:38. Évalué à 4.
    
    ont souvent des éditeurs assez pauvres comparés à Emacs/Vim
    
    Je ne le crois pas (et je suis fan de vim). Ils ont un éditeur clairement plus intelligent que vim/emacs (alors emacs peut utiliser CDT je crois pour être au niveau d'eclipse pour vim je sais pas), mais n'ont pas les fonctions puissantes du vieux couple.
    
    Mais généralement on ne sait pas tout ce que peut faire l'éditeur des IDE eclipse/netbeans/intellij, parce qu'on s'y intéresse moins et qu'on a tendance à croire qu'on est face à un équivalent de gedit (ce qui est faux !). Eclipse peut intégrer vim comme éditeur de texte.
    
    Je plussoie. D'autant plus que le plugin vim de Intellij Idea est excellent. Il supporte les buffers de copie, les macros, les commandes vim complexes, pour l'instant je ne l'ai pas pris en défaut.
  - [^] # Re: Non, mais ...
    
    Posté par GeneralZod le 11 mai 2013 à 16:09. Évalué à 5.
    
    Il faut voir, mais je crois qu'on peut virer énormément de choses du plus gros des IDE, eclipse.
    
    C'est fastidieux -AMHA, plus que d'adapter un Vim/Emacs à son besoin-, et t'as des IDE qui sont très monolithiques.
    
    Mais là où tu y gagne c'est que ces éditeurs von généralement t'offrir une abstraction du système de build, du gestionnaire de version etc pour au final te permettre d'en changer facilement.
    
    J'ai un très mauvais souvenir des abstraction de systèmes de constructions, sachant que j'utilise autohell ou CMake qui sont déjà des abstractions de haut-niveau. Quant aux SCM, Emacs et Vim proposent une très bonne intégration, bien supérieure à ce que j'ai vu dans les IDE.
    De fait, on en change assez rarement (sinon, ça indique un problème plus grave au sein du projet et/ou de l'équipe)
    
    Là tu parle d'imposer un IDE à un ensemble de personne. Comme tu le dis c'est aussi intelligent de forcer l'utilisation d'emacs que de forcer l'utilisation de netbeans.
    
    Régulièrement, j'entends des pairs dirent qu'il faut imposer un environnement commun, pour garantir que tout le monde suit les mêmes conventions. En gros, on file un machin pré-configuré et on espère -à juste titre- que les clampins soient trop fainéants pour le reconfigurer.
    Bien évidemment, les mecs ont des accidents claviers et committent du code mal formaté ou des espaces qui trainent (les mecs oublient aussi d'appuyer sur le bon bouton qui reformatte le tout), etc. => c'est un processus lourd et infantilisant qui oublie l'essentiel: livrer un produit qui apporte une valeur ajoutée aux clients et le faire de manière professionnelle.
    
    Qui maitre 100% de son éditeur de texte, de son gestionnaire de version et de son shell ?
    
    Comme pour toute chose, pour maitriser un outil ou une technique, il faut s'entrainer régulièrement.
    
    Ce qui m'agace vraiment c'est les développeurs incapables de coder sans IDE (qu'on soit moins productifs sans ses outils, je peux comprendre). Mais même si la pente initiale est plus douce, un IDE demande également un temps d'apprentissage non négligeable. J'ai déjà vu des gugusses bloqués parce qu'ils ne trouvaient pas la fonction qui allait bien, ou les conflits avec le code généré qu'on édite manuellement (don't do that), les commits monolithiques foireux etc …
    C'est plus un problème de personnes qu'un problème d'outillage, mais bon.
    
    Si vous voulez m'entendre râler vraiment, on peut parler des tests, ou des mecs qui détournent les bonnes pratiques de développement (aka Shitware Crapsmanship)
    - [^] # Re: Non, mais ...
      
      Posté par Antoine le 11 mai 2013 à 17:04. Évalué à 7.
      
      Si vous voulez m'entendre râler vraiment, on peut parler des tests, ou des mecs qui détournent les bonnes pratiques de développement (aka Shitware Crapsmanship)
      
      Vas-y !
    - [^] # Re: Non, mais ...
      
      Posté par Dring le 11 mai 2013 à 23:01. Évalué à 1.
      
      C'est fastidieux -AMHA, plus que d'adapter un Vim/Emacs à son besoin-, et t'as des IDE qui sont très monolithiques.
      
      Bof bof. Dans le cas de Eclipse, il existe des distributions déjà spécialisées, un coup PHP, un coup appli Web java, etc.
      
      Du coup, en général y'a strictement rien à faire, ça juste marche out of the box.
      
      Après, je pense que si tu n'es pas un gros codeur Java, tu ne peux pas avoir le même ressenti que "nous". Java Enterprise Edition est une telle soupe, avec son milliard d'API, d'outils connexes, de code lourdingue à taper/gérer, que sans un IDE tu y passes tes nuits.
      - [^] # Re: Non, mais ...
        
        Posté par wilk le 12 mai 2013 à 09:18. Évalué à 3.
        
        Après, je pense que si tu n'es pas un gros codeur Java, tu ne peux pas avoir le même ressenti que "nous". Java Enterprise Edition est une telle soupe, avec son milliard d'API, d'outils connexes, de code lourdingue à taper/gérer, que sans un IDE tu y passes tes nuits.
        
        C'est clair qu'il y a des langages qui demandent un ide beaucoup plus que d'autres. La seule fois où j'en ai eu besoin c'était pour du java justement.
        De la même manière, ça dépend aussi de ce qu'on code. Si on arrive à rester dans la philosophie unix à découper le problème en plusieurs petites taches on a beaucoup moins besoin d'un ide que si on code une usine à gaz.
        
        [^] # Re: Non, mais ...
        
        Posté par barmic le 12 mai 2013 à 14:12. Évalué à 6.
        
        C'est clair qu'il y a des langages qui demandent un ide beaucoup plus que d'autres. La seule fois où j'en ai eu besoin c'était pour du java justement.
        
        Je me demande si on utilise des IDE en Java parce que Java le nécessite ou si c'est parce que c'est avec lui qu'il y a les IDE les plus évolués. (c'est sincère comme questionnement)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Non, mais ...
        
        Posté par wilk le 12 mai 2013 à 15:44. Évalué à 2.
        
        Je pense que les IDE java sont venu avec le besoin. Personnellement j'ai senti l'intérêt des IDE avec java et j'ai senti que je n'en avais plus besoin avec python. Et je n'en avais pas besoin en C mais ça fait très longtemps, à l'époque la doc tenait dans un seul bouquin et le code était très concis.
        Mais je n'ai toujours fais que des spécifs très concis, et généralement seul, pas d'usines à gaz… Donc je ne témoigne que de mon cas particulier.
        Si j'avais du démarrer la prog avec obligation d'utiliser un IDE, je ne pense pas que j'aurai continué !
        
        [^] # Re: Non, mais ...
        
        Posté par Batchyx le 12 mai 2013 à 16:33. Évalué à 5.
        
        Quiconque ayant déjà renommé une classe Java et changé son ~~namespace~~ package à la main te dira que c'est Java qui nécessite un IDE et non le contraire.
        
        (je parle pas de changer le code des utilisateurs de la classe hein, juste de changer le nom et le package d'une classe).
        
        Pour information, pour ceux qui ne pratiquent pas java, voilà ce que le langage impose de faire si je veux renommer une classe Toto (pas encore utilisée) dans le namespace par défaut en com.bloat.providers.TotoProvider:
        
        Remplacer Toto par TotoProvider dans le fichier (normal).
        
        Rajouter package com.bloat.providers; (normal).
        
        Créer le répertoire com/bloat/providers (mkdir -p est ton ami, avec une GUI tu crève).
        
        Déplacer Toto.java dans com/bloat/providers, et le renommer en TotoProvider.java, en pensant au gestionnaire de version.
        
        Autrement dit, tu va retaper Toto deux fois, com.bloat.providers au moins trois fois et TotoProvider deux fois, et t'a pas intérêt à faire une typo quelque part, sinon ça va être coton à savoir ou.
        
        Enfin bref, c'est super chiant, et tu ne fera jamais ça plus d'une fois dans la journée.
        Java à besoin d'un IDE pour renommer une classe, même si elle n'est pas utilisée.
        
        Après on peut parler des ìmport à grain trop fin, de la javadoc illisible par défaut, ou des bibliothèques bloats qui sont inutilisables sans autocompléteur/générateur de code.
        
        [^] # Re: Non, mais ...
        
        Posté par barmic le 12 mai 2013 à 19:41. Évalué à 4. Dernière modification le 12 mai 2013 à 19:42.
        
        Euh… sur tes 4 points, les deux qui ne sont pas normales me semblent être une bonne pratique. C'est un peu comme si tu disais qu'avec Java t'es obligé (je ne suis même plus sûr de savoir si c'est une obligation ou de si ça pète juste un warning) de déclarer une seules classe par fichier (sans compter les hinners classes), ça me semble être une bonne pratique.
        
        Pour comparer avec le C++, tu dois remplacer Toto par TotoProvider et le package 2 fois chacun (une fois pour l'entête et une fois pour le corps). Puis changer les directives d'include conditionnelle dans le corps (à 2 endroits au moins, personnellement je préfère aussi le mettre en commentaire à la suite de la fin du if). Pareil je parle pour une classe qui n'est pas utilisée.
        
        Et tu te retrouve avec un dossier src qui contient en vrac différents namespace.
        
        Les imports à « grains fin » (tu peut utiliser des wildcard, mais je n'aime pas), permettent de voir ce qui est utilisé ou non dans la classe. Là encore à comparer au C++, il va falloir ajouter des includes qui vont bien, les modifier ou pas va dépendre de comment tu organise tes classes.
        
        de la javadoc illisible par défaut
        
        Tu entends quoi par là ? La javadoc, me paraît tout à fait lisible (et immédiatement à jour par rapport à cppreference ou cplusplus ()j'apprécie beaucoup ces 2 sites là n'est pas la question) qui sont moins à jour et qui, dans le cas de cppreference, se contente de décrire l'API (Java à ce genre de choses). Après je trouve qu'il mange des chose, j'aimerais bien avoir dans la javadoc la complexité de certaines fonctions et indiquer de manière systématique si une méthode est thread-safe ou non.
        
        Excuse-moi de revenir à C++, mais c'est le langage le plus proche que je connaisse. Peut être que Objective-C ou un autre langage fait mieux.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Non, mais ...
        
        Posté par windu.2b le 12 mai 2013 à 19:54. Évalué à 3.
        
        C'est un peu comme si tu disais qu'avec Java t'es obligé (je ne suis même plus sûr de savoir si c'est une obligation ou de si ça pète juste un warning) de déclarer une seules classe par fichier (sans compter les hinners classes), ça me semble être une bonne pratique.
        
        En Java, tu n'as le droit qu'à une seule classe déclarée public par fichier .java, mais tu peux mettre d'autres classes (déclarées protected, private ou sans déclaration).
        
        [^] # Re: Non, mais ...
        
        Posté par Batchyx le 13 mai 2013 à 22:15. Évalué à 5.
        
        Euh… sur tes 4 points, les deux qui ne sont pas normales me semblent être une bonne pratique. C'est un peu comme si tu disais qu'avec Java t'es obligé (je ne suis même plus sûr de savoir si c'est une obligation ou de si ça pète juste un warning) de déclarer une seules classe par fichier (sans compter les hinners classes), ça me semble être une bonne pratique.
        
        C'est sans doute une bonne pratique en Java (on y est un peu obligé), mais en C++ c'est totalement artificiel, vu que la bibliothèque standard ne respecte pas cette convention, et heureusement. Personne ne s'amuserait à créer un fichier pour y mettre uniquement
        
        # include <implementation_detail/binary_operator> namespace std { template <typename T> struct less : std::__implementation_detail::binary_operator<bool, T,T> { bool operator()(const T& a, const T& b) const { return a < b; } }; }
        
        et à faire ça 6 fois pour les opérateurs relationnels sans parler de la centaines de classes/fonctions de la bibliothèque standard qui s'implémentent en moins de dix lignes ou qui ne sont que des alias/typedef.
        
        Non, la bonne pratique en C++ c'est d'activer son cerveau et de distinguer les grosses classes/fonctions à mettre dans un fichier séparé des petites classes/fonctions que l'on peut regrouper intelligemment dans un seul fichier si ça a un sens de les mettre ensemble. Sachant que, bien entendu, les petites classes sont préférables aux grosses (il faut mieux casser des grosses classes pour les remplacer par un typedef d'amas de petites classes templates).
        
        Pareil pour les namespaces; La bibliothèque standard ne met pas tout ses includes dans std/. Et les namespaces de boost ne correspondent pas forcement aux répertoires dans lequel se trouvent les includes.
        
        Enfin bref: "Apply common sense".
        
        Pour comparer avec le C++, tu dois remplacer Toto par TotoProvider et le package 2 fois chacun (une fois pour l'entête et une fois pour le corps). Puis changer les directives d'include conditionnelle dans le corps (à 2 endroits au moins, personnellement je préfère aussi le mettre en commentaire à la suite de la fin du if). Pareil je parle pour une classe qui n'est pas utilisée.
        
        C'est certes plus de boulot, mais toutes ces opérations impliquent uniquement d'utiliser son éditeur de texte. C'est beaucoup plus confortable que de devoir créer un répertoire et y déplacer ses fichiers.
        
        Et tu te retrouve avec un dossier src qui contient en vrac différents namespace.
        
        Mauvaise idée, vaut mieux faire le contraire: les namespaces en C++ ne servent pas à catégoriser les classes ou a limiter leur visibilité comme en Java, mais uniquement à éviter les conflits de noms. Utiliser un ou deux namespaces par projet est suffisant (exemple: la bibliothèque standard, encore une fois…), il n'y a pas de raison d'en avoir plus si tu ne compte pas avoir de conflits de noms (les principaux types de conflits étant ceux liés à la recherche dépendant des paramètres). Et même lorsque tu à besoin d'un namespace, tu peux toujours le planquer en utilisant un typedef ou autre.
        
        Absolument rien ne t'empêche de simplement séparer tes fichiers dans des répertoires différents en gardant le même namespace.
        
        Les imports à « grains fin » (tu peut utiliser des wildcard, mais je n'aime pas)
        
        Le compilo non plus, ça augmente ses temps de compilations, mais pas autant qu'une compilation C++.
        
        permettent de voir ce qui est utilisé ou non dans la classe. Là encore à comparer au C++, il va falloir ajouter des includes qui vont bien, les modifier ou pas va dépendre de comment tu organise tes classes.
        
        Si tu sépare des classes intelligemment, tu n'a pas plus de problème qu'avec des wilcards en Java. Parce que les imports à grain fin, en plus de rentre inintelligible la liste de ce que tu utilise, t'oblige à la maintenir avec un IDE. Une liste d'include est plus courte et mieux catégorisée.
        
        Tu entends quoi par là ? La javadoc, me paraît tout à fait lisible (et immédiatement à jour par rapport à cppreference ou cplusplus ()j'apprécie beaucoup ces 2 sites là n'est pas la question) qui sont moins à jour et qui, dans le cas de cppreference, se contente de décrire l'API (Java à ce genre de choses). Après je trouve qu'il mange des chose, j'aimerais bien avoir dans la javadoc la complexité de certaines fonctions et indiquer de manière systématique si une méthode est thread-safe ou non.
        
        Gahh, des frames, en 2013. Passons, j'ai pris une classe au hasard: AbstractQueue: http://docs.oracle.com/javase/7/docs/api/java/util/AbstractQueue.html
        
        J'ai :
        - de l'information bateau qui m'intéresse pas forcement (savoir de quoi ça hérite, qui l'implémente …) mais qui se trouve au début, donc c'est ce qui s'affichera en premier dans une petite fenêtre
        - La doc (normal)
        - Les constructeurs/méthodes de la classe avec leur description courtes (normal)
        - Un trop bref résumés des méthodes héritées des classes mères, alors que pourtant, elles font partie de l'API.
        - Le détail des méthodes, qui prend une place absolument folle.
        
        La plupart des programmeurs Java que je vois préfèrent naviguer dans les méthodes et leur documentations dans leur IDE (ou son autocompléteur de code) que regarder la javadoc. Il y a peut-être une raison. Bizarrement, les IDE ne planquent pas les méthodes héritées, et n'affichent les hiérarchies de classe que dans la doc.
        
        Excuse-moi de revenir à C++, mais c'est le langage le plus proche que je connaisse. Peut être que Objective-C ou un autre langage fait mieux.
        
        Je fais du C++ avec vim. Et j'ai pas absolument besoin de ses fonctionnalités d'IDE les plus avancées (elles ne font qu'augmenter ma productivité). Des windowsiens utilisent des éditeurs plus pauvres comme notepad++ pour des petits projets C/C++, et ça ne semble pas les gêner pas tant que ça.
        
        Mais en Java, je n'ai jamais vu quelqu'un utiliser un IDE moins lourd que netbeans ou eclipse, même pour des petits projets de 3 classes. C'est juste impossible de programmer sans.
        
        [^] # Re: Non, mais ...
        
        Posté par barmic le 14 mai 2013 à 00:50. Évalué à 2.
        
        Si tu sépare des classes intelligemment, tu n'a pas plus de problème qu'avec des wilcards en Java. Parce que les imports à grain fin, en plus de rentre inintelligible la liste de ce que tu utilise, t'oblige à la maintenir avec un IDE. Une liste d'include est plus courte et mieux catégorisée.
        
        Je vois pas en quoi ça rend les choses illisibles.
        La seule vrai différence (d'un point de vu fonctionnel parce que d'un point de vu technique ça n'a rien avoir). C'est dans la gestion des dépendances : grosso si j'include une classe A qui include une classe B, je n'ai pas besoin d'inclure cette classe B. Les deux approches me semblent avoir des arguments.
        
        de l'information bateau qui m'intéresse pas forcement (savoir de quoi ça hérite, qui l'implémente …) mais qui se trouve au début, donc c'est ce qui s'affichera en premier dans une petite fenêtre
        
        Ça fait parties des choses que je regardent le plus. Contrairement au C++, Java a un système de type simple (simpliste ?) quasi uniquement basé sur l'héritage donc ce genre d'informations est importantes.
        
        Un trop bref résumés des méthodes héritées des classes mères, alors que pourtant, elles font partie de l'API.
        
        Ça ne me paraît pas déconnant qu'elle ne soit pas dupliquée (on est d'accord c'est de la duplication automatique et pas du copier-coller). Je trouve que ça permet de bien distinguer ce qui est spécifique à cette classe et ce qui fait parti d'une classe mère.
        
        Le détail des méthodes, qui prend une place absolument folle.
        
        Ouai. Personnellement j'ai plutôt tendance à dire qu'elle n'en prend pas assez et que certaines informations manque (la méthode est elle thread safe, null-safe et sa complexité par exemple). La place je m'en balance sacrément, l'objectif n'est pas d'avoir le maximum de fonction décrites sur un même écran mais juste celle que tu regarde. C'est pour ça que j'utilise généralement la vue avec frame, avoir de la place pour rien ne m'est pas utile. Pour ce qui est des frames avoir la liste des classes sur le coté est primordial (pour les package ça l'est moins). Tu peut recréer la même chose via des CSS, mais mis à part s'interdire d'utiliser des frame par superstition je ne vois pas le problème.
        
        La plupart des programmeurs Java que je vois préfèrent naviguer dans les méthodes et leur documentations dans leur IDE (ou son autocompléteur de code) que regarder la javadoc. Il y a peut-être une raison. Bizarrement, les IDE ne planquent pas les méthodes héritées, et n'affichent les hiérarchies de classe que dans la doc.
        
        C'est normal les interfaces sont totalement différentes. L'IDE t'indique perpétuellement la classe et les classes mères ou interface de tes objets, c'est son boulot. Donc tu en a bien moins besoin.
        
        Pour ce qui est d'utiliser la doc incluse plutôt que la javadoc, je ne suis pas aussi tranché. Moi je n'y allais jamais, mais après mettre fait reprendre plusieurs fois par des collègues parce que je n'avais pas compris comment s'organiser les classes entre elles, je m'y suis m'y et le fait de naviguer dans l'arborescence des classes est un vrai plus (trouver rapidement les implémentations de telle ou telles classes).
        
        Je fais du C++ avec vim. Et j'ai pas absolument besoin de ses fonctionnalités d'IDE les plus avancées (elles ne font qu'augmenter ma productivité). Des windowsiens utilisent des éditeurs plus pauvres comme notepad++ pour des petits projets C/C++, et ça ne semble pas les gêner pas tant que ça.
        
        Tu ne m'a pas vu dire le contraire.
        
        Mais en Java, je n'ai jamais vu quelqu'un utiliser un IDE moins lourd que netbeans ou eclipse, même pour des petits projets de 3 classes. C**'est juste impossible de programmer sans.**
        
        Ça c'est faux, il m'arrive fréquemment de le faire parfois pendant plusieurs semaines et je réorganise aussi des fois avec mon shell. Je ne dis pas que c'est la panacée juste que ça se fait.
        
        Je pense qu'il y a 3 choses qui entrent en ligne de compte :
        
        certains langages ont plus besoin d'IDE que d'autres
        
        certains langages sont plus simples à outiller que d'autres
        
        il y a des grosses différences culturelles entre les communauté de programmeurs
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Non, mais ...
        
        Posté par ckyl le 14 mai 2013 à 08:29. Évalué à 3.
        
        Soit dit au passage, la Scaladoc a dépassé le maitre. Y'a pleins de petits détails à backporter dans la Javadoc
        
        [^] # Re: Non, mais ...
        
        Posté par barmic le 14 mai 2013 à 11:30. Évalué à 2.
        
        En effet ça a l'aire vraiment bien fait (je parle de la forme et pas du contenu que je ne pourrais pas bien juger sans utiliser le langage).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Non, mais ...
        
        Posté par groumly le 14 mai 2013 à 15:44. Évalué à 1.
        
        C'est juste impossible de programmer sans.
        
        Meh, ca se discute. Apres 18 mois a bouffer de l'objc et ses import a la mord moi le noeud, et clang qui se chie dessus parce qu'une enum est declaree deux fois, et le pch qui vient foutre la chtouille aussi. Apres 18 mois, t'y penses plus trop, t'es resigne.
        
        Je viens de passer 2 jours a ecrire du java, ben putain. Taper un type, sauver et avoir l'import automagiquement apparaitre, ou retrouver un nom de classe juste en tapant qq lettres, ben ca fait plaisir.
        Je fais du proof of concept la, donc du refactoring, j'en ai fait, des typos dans les noms de classes, j'en ai bouffe, et pas qu'un peu, des signatures et des noms de methodes des bois, en veut tu en voila, quand a changer des classes de package (voire de projet), j'en ai fait pas mal aussi.
        Cmd alt r pour renommer, et paf, c'est fait. Le changement de package? Drag n drop. V'la le sentiment de liberation d'avoir du refactoring qui marche (bordel). A l'inverse j'ai des classes/methodes avec des typos qui se balladent dans mon projet iOS depuis des mois parce que je sais qu'elles sont utilisees un peu partout, et j'ai autre chose a foutre de tout peter pour inverser 2 lettres.
        
        Desole, mais non, objective c (ou c++ si ca ca te fait plaisir) ca a rien de plus sympa. Devoir faire le yoyo en permanence a remonter, trouver le bon endroit pour ton import, faire gaffe qu'il y soit pas en double (on sait jamais), nettoyer un ou deux imports inutiles pour enfin redescendre et se rendre compte que t'as perdu ton fil de pensee, ca va 5 minutes.
        
        La grosse difference, c'est qu'un ide va t'apporter tres peu en c/c++ la ou le java se prete tres bien a un refactoring super efficace. Quand t'as goute a ca, t'as aucune envie de retourner a gerer les choses a la mano, et a l'inverse, en c/c++ tu l'acceptes et tu fais avec parce que de toute facons, beeen… Tu peux pas vraiment faire autrement, alors…
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Non, mais ...
        
        Posté par pifou le 13 mai 2013 à 09:28. Évalué à 7.
        
        Ayant commencé à faire de Java sous emacs avant l'apparition d'Eclipse (1999), je peux te dire que lorsqu'un gars de chez XXX (IBM France ?) ayant travaillé sur le JDT a présenté Eclipse en 2002 (DESS=Master 2), ça a été la révolution (voir la révélation). Il faut bien imaginer qu'avec Java, rien que l'histoire des exceptions à catcher/thrower est une galère sans IDE à moins de naviguer dans ta javadoc à chaque écriture de ligne ou à connaître l'API par cœur.
        
        Revers de la médaille : j'ai noté que de plus en plus les nouveaux développeurs (technicien ou ingénieur) sont incapables de travailler sans IDE (souvent Eclipse). Par exemple la génération de package est une grosse boite noire, ils ne savent même pas ce que contient un ear/jar/war qu'ils envoient à un client. Je ne parle même pas des frameworks utilisés sans aucun recul. A la limite ce n'est pas trop gênant tant qu'il sont en phase de développement, par contre quand on passe en qualification/intégration/recette/production ça devient embêtant d'avoir des personnes ne pouvant pas expliquer un problème sans leur IDE (qui n'est pas connecté sur ces serveurs). Certains ne savent même pas utilisé un bon grep/awk (voir tout simplement une ligne de commande) dans les logs pour faire de l'analyse.
        
        Voila, c'était le moment vieux con ! Jeunes développeurs ne prenaient pas le paragraphe d'au-dessus comme une attaque, quand je dis "de plus en plus", c'est que le phénomène existait déjà quand je suis sorti d'étude et il y a bien sûr encore beaucoup de très bons développeurs sortant actuellement des écoles/fac.
        
        [^] # Re: Non, mais ...
        
        Posté par ariasuni le 13 mai 2013 à 10:11. Évalué à 1.
        
        Revers de la médaille : j'ai noté que de plus en plus les nouveaux développeurs (technicien ou ingénieur) sont incapables de travailler sans IDE (souvent Eclipse). Par exemple la génération de package est une grosse boite noire, ils ne savent même pas ce que contient un ear/jar/war qu'ils envoient à un client.
        
        C'est exactement ce que je vois à l'IUT, moi le premier d'ailleurs. Mais je vais peut-être savoir compiler des paquets Java grâce aux commentaires mesquins plus bas.
        
        Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Non, mais ...
  
  Posté par barmic le 11 mai 2013 à 14:52. Évalué à 7.
  
  inflation des fonctionnalités inutilisées voire inutiles (loi de Pareto 80/20 etc.) qui rend plus difficile la courbe d'apprentissage
  
  Tu trouve que vim ou emacs ont une courbe d'apprentissage simple ?
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Non, mais ...
    
    Posté par flagos le 11 mai 2013 à 15:03. Évalué à 4.
    
    Justement, comme tu l'as dit, ce sont des IDE.
    
    CQFD.
  - [^] # Re: Non, mais ...
    
    Posté par GeneralZod le 11 mai 2013 à 15:38. Évalué à 3.
    
    Tu trouve que vim ou emacs ont une courbe d'apprentissage simple ?
    
    Non, mais je n'ai pas à "apprendre" un IDE pour chaque langage, framework etc. Je te concède que la pente initiale est beaucoup plus raide avec Emacs ou Vim.
    - [^] # Re: Non, mais ...
      
      Posté par barmic le 11 mai 2013 à 15:44. Évalué à 6.
      
      Non, mais je n'ai pas à "apprendre" un IDE pour chaque langage, framework etc.
      
      Tu dois trouver et apprendre une série de plugin par langage.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Non, mais ...
    
    Posté par wilk le 11 mai 2013 à 22:16. Évalué à 2.
    
    La courbe d'apprentissage il faut la comparer à la durée et à la plage d'utilisation. Vi c'est un investissement sur le long terme, des dizaines d'années, et utilisable absolument de partout (pour taper ce texte par exemple). Tandis que les IDE les plus sophistiqués ont une durée de vie très courte et une plage d'utilisation extrêmement réduite donc la courbe d'apprentissage sera à répéter sans cesse.
    Le principe d'unix de ne faire qu'une chose mais bien a fait ces preuves.
    - [^] # Re: Non, mais ...
      
      Posté par flan (site web personnel) le 11 mai 2013 à 22:21. Évalué à 7.
      
      Cela fait pourtant quelques années qu'Eclipse est en place. Changer d'IDE tous les 15 ou 20 ans, ça reste raisonnable, je trouve.
      - [^] # Re: Non, mais ...
        
        Posté par wilk le 12 mai 2013 à 09:20. Évalué à -2.
        
        Je ne connais pas eclipse, mais généralement les ide même sans en changer il faut continuellement rester au jus, je me trompe ?
    - [^] # Re: Non, mais ...
      
      Posté par barmic le 12 mai 2013 à 00:52. Évalué à 6. Dernière modification le 12 mai 2013 à 00:54.
      
      La courbe d'apprentissage il faut la comparer à la durée et à la plage d'utilisation.
      
      Non.
      
      Il a dit que la courbe d'apprentissage des IDE était difficile, celles d'emacs ou de vim sont horribles. Rien est intuitif dans ces éditeurs. Laissent n'importe qui ouvrir l'un de ses 2 éditeurs, leur faire écrire "hello world!" puis enregistrer et fermer le fichier. C'est impossible sans explication (particulièrement dans vim).
      
      Oui ces éditeurs sont géniaux et je les apprécie (notamment vim), mais là on parle de complexité d'une courbe d'apprentissage et on est pas loin du pire qui existe dans le domaine des éditeurs de texte.
      
      Que cet apprentissage soit bénéfique ou pas est un autre débat. Ça dépend des utilisateurs.
      
      Le principe d'unix de ne faire qu'une chose mais bien a fait ces preuves.
      
      Tu rigole ? emacs ne fait qu'une chose ? Si oui la chose en question ce n'est pas éditeur de texte, mais plutôt interpréteur évolué pour emacs-lisp ou quelque chose dans ce genre.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Non, mais ...
        
        Posté par wilk le 12 mai 2013 à 09:39. Évalué à 3.
        
        Il a dit que la courbe d'apprentissage des IDE était difficile, celles d'emacs ou de vim sont horribles. Rien est intuitif dans ces éditeurs.
        
        Je pense que tu dis ça parce que tu les utilise comme des IDE, dans ce cas effectivement la courbe d'apprentissage est sans fin. C'est un peu comme si on veut utiliser firefox avec une centaine de plugin tout de suite.
        J'ai eu la chance d'apprendre Vi (pas vim) à l'époque où les possibilités étaient très réduites mais néanmoins énormes par rapport aux éditeurs à la ligne. La courbe d'apprentissage était vraiment courte, et les commandes très intuitives. w=word i=insert a=append… J'avais un seul livre "la prog sous linux" de rifflet, la doc pour utiliser vi tien sur 6 pages.
        Maintenant c'est vrai que c'est parfois tentant de reproduire un ide avec, mais on s'écarte de la philosophie d'unix tu as raison et on retombe exactement dans les mêmes travers qu'avec les ide. (tu remarqueras que je ne parle que de vi, pas d'emacs !)
        Je suis également d'accord avec toi comme j'ai dis dans un autre commentaire, ça dépend de l'utilisateur, parfois du langage…
        
        Je voulais juste témoigner sur le fait qu'il est possible d'utiliser un simple éditeur de texte ultra efficace pendant des décennies sans se prendre la tête avec des ide.
        
        [^] # Re: Non, mais ...
        
        Posté par barmic le 12 mai 2013 à 15:13. Évalué à 2.
        
        Je pense que tu dis ça parce que tu les utilise comme des IDE, dans ce cas effectivement la courbe d'apprentissage est sans fin. C'est un peu comme si on veut utiliser firefox avec une centaine de plugin tout de suite.
        
        Tu te fourvoie. J'utilise vim depuis bien plus longtemps que des IDE, je n'utilise aucun plugins avec.
        
        J'ai eu la chance d'apprendre Vi (pas vim) à l'époque où les possibilités étaient très réduites mais néanmoins énormes par rapport aux éditeurs à la ligne. La courbe d'apprentissage était vraiment courte, et les commandes très intuitives. w=word i=insert a=append… J'avais un seul livre "la prog sous linux" de rifflet, la doc pour utiliser vi tien sur 6 pages.
        
        Il a une courbe d'apprentissage intéressante, mais c'est la même chose avec les gros IDE. Tu commence à apprendre le fonctionnement du logiciel et quand tu en comprend les principes, tu peut facilement réutiliser ces acquis pour de l'ensemble des fonctions du logiciel. Ça l'est moins avec les gros IDE qu'avec vim et ça l'est moins avec emacs qu'avec vim.
        
        J'aime beaucoup vim et je m'en sert quotidiennement depuis 6 ou 7 ans. Ça ne m'empêche pas d'être critique :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Non, mais ...
        
        Posté par wilk le 12 mai 2013 à 15:54. Évalué à 1.
        
        Il a une courbe d'apprentissage intéressante, mais c'est la même chose avec les gros IDE. Tu commence à apprendre le fonctionnement du logiciel et quand tu en comprend les principes, tu peut facilement réutiliser ces acquis pour de l'ensemble des fonctions du logiciel.
        
        Je comprends bien, je suis souvent tenté, il ne faut pas croire, je sais bien que dans certaines circonstances ça me serait utile. Mais ce qui m'embêterait le plus c'est d'avoir à passer du temps à chercher quel IDE et ensuite le changer. Rien que sur ce journal on a vu plusieurs noms défiler. Les IDE d'aujourd'hui n'ont vraiment rien à voir avec ceux d'il y a 10 ou 20 ans, peut-être qu'eclipse sera l'exception. Pareil pour n'importe quelle interface graphique, WM etc. d'ailleurs.
        Tandis qu'avec vim je ne me pose plus de question (à part pour mouler ici !), c'est un gain de temps appréciable.
        
        [^] # Re: Non, mais ...
        
        Posté par barmic le 12 mai 2013 à 16:03. Évalué à 2.
        
        Personnellement, je ne vois pas trop le problème. Changer d'outils, c'est un peu comme changer de langage. Tu as des trucs à réapprendre et des trucs que tu réutilise tranquillement. Au final c'est celui dont tu as le plus besoin ou qui te sert le plus que tu maitrise le mieux.
        
        Le problème avec la crainte de changer d'outil, c'est de toujours réutiliser le même (parce qu'on connait). J'ai construit des ear avec make, mais ça n'était pas une bonne idée, c'est lancé gcc via des script shell plutôt que make mais là non plus c'est pas une bonne idée.
        
        Comme on dit :
        
        Quand on est un marteau, tous les problèmes ressemblent à des clous.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Non, mais ...
        
        Posté par wilk le 12 mai 2013 à 16:30. Évalué à 1.
        
        Je suis vraiment marteau alors parce que que j'écrive du français, de l'anglais, un dessin ou un schéma sur une feuille, j'utilise toujours un crayon depuis ma plus tendre enfance ;-)
        
        [^] # Re: Non, mais ...
        
        Posté par barmic le 12 mai 2013 à 19:45. Évalué à 2.
        
        j'utilise toujours un crayon
        
        Tu as passé des examens ? Tu as déjà écris une lettre ? On t'a jamais remis un paquet où il fallait que tu signe un reçu ? Tu as écris ton commentaire au crayon ? puisque c'est dans l'air du temps, tu n'a jamais manifesté avec des banderoles sur la quelle tu avait écris quelques choses ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Non, mais ...
    
    Posté par Moonz le 12 mai 2013 à 13:53. Évalué à 3.
    Ce n’est absodument pas comparable.
    
    Tu apprends eclipse, tu apprends le système de build eclipse, l’éditeur eclipse, le SCM eclipse, le debuggueur eclipse.
    
    vim, tu apprends gdb (ou tout autre debuggueur), make (ou tout autre système de build), git (ou tout autre SCM), l’éditeur de texte vim.
    
    Déjà, il faut savoir ce qu’on compare : la full-stack ? éditeur-vim vs éditeur-eclipse ? éditeur-vim vs ide-eclipse ? Et quelle que soit la comparaison, est-elle pertinente ?
    
    De plus, cette séparation des outils permet tout de même une bien meilleure compréhension globable du workflow, indispensable pour travailler en équipe AMHA. Quand un de mes projets C++ (sans IDE) ne builde pas sur la machine d’un de mes collègues, je sais immédiatement où se situe le problème. Par contre un projet eclipse, com.truc.bidule.machin.chose.PackageAuNomImbitable not found, ça peut venir :
    - D’une mauvaise configuration du projet de ma part
    - D’une mauvaise configuration de l’IDE
    - D’une mauvaise configuration/installation de Java
    La différence entre IDE et non-IDE à ce niveau est simple : l’IDE mélange allègrement (que ce soit dans l’arborescence du système de fichiers ou dans l’interface graphique de configuration) « configuration de l’environnement de dev personnel » (préférences de l’IDE, configuration globale Java), « configuration personnelle du projet » (typiquement : configuration du SCM, mais pas que…), et « configuration du projet » (paramètres build debug/release, classpath…) et qu’il est extrèmement simple, en équipe, de se foirer à ce niveau (commiter un paramètre personnel vers tout le monde, ou au contraire avoir une configuration du projet qui ne marche que chez soi…)
    - [^] # Re: Non, mais ...
      
      Posté par barmic le 12 mai 2013 à 15:38. Évalué à 4.
      
      Ce n’est absodument pas comparable.
      
      C'est le monsieur du dessus qui parlait de courbe d'apprentissage. Rien que d'un point de vu éditeur de texte, la courbe est bien plus compliquée pour vim.
      
      Pour ton souci de build en Java avec eclipse, ça fait quand même quelques années maintenant que maven est sorti. Utiliser autre chose (certain me diront que gradle et buildr font aussi bien), c'est aller au devant des même danger qu'avec make.
      
      La reproductibilité du build est un des objectifs principal de maven. Il est intégrer aux IDE.
      
      Faut arrêter de croire qu'utiliser les gros IDE c'est utiliser uniquement des outils internes à ceux-ci. Tu utilise svn/git/hg et pas le gestionnaire de version interne de l'IDE (ils en ont un) fait pareil avec le build.
      
      L'intégration c'est d'avoir toutes les fonctionnalités disponibles au travers d'un même outil, celui-ci peu utiliser une implémentation interne ou un outil extérieur.
      
      Ça ne fait que révéler des manques qui viennent d'ailleurs. L'installation de Java d'une part je vois pas comment on peut la rater, d'autre part c'est pas quelque chose qui apparaît tous les 4 matins. Les deux autres montrent surtout comme je le dis ailleurs qu'on s'appuie sur le builder interne de l'IDE sans trop en mettre en gestion de conf, c'est mal.
      
      Pour ce qui est du mélange des configuration dans eclipse, tu as une perspective pour configurer le projet et une pour l'éditeur.
      
      Bref tout ça pour dire que c'est plus une méconnaissance des outils qu'un problème de l'outil (moi aussi je connais mieux vim/emacs/zsh que mon IDE.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Non, mais ...
  
  Posté par Moonz le 12 mai 2013 à 13:28. Évalué à 4. Dernière modification le 12 mai 2013 à 13:28.
  chacun a un workflow personnel différent, ça explique les guéguerres Emacs/Vim, Eclipse/Intellij etc., c'est illusoire de vouloir fournir un IDE pré-configuré pour tous. On ne fait que planter des bâtons dans les roues des gens.
  
  C’est le gros point noir des IDE pour moi.
  
  Soit tu imposes un IDE à tous les membres de ton équipe et tu auras 90% d’insatisfaits.
  
  Soit tu laisses le choix à l’IDE et tu vas devoir gérer :
  - celui qui a commité le répertoire build/ (ou autre fichier généré n’ayant pas vocation à être commité) par erreur
  - celui qui au contraire a commité une modification qui nécessite un changement dans la configuration du projet, et qui du coup casse le build sur la machine de tests et les autres IDE
  - les IDE qui mettent des chemins absolus dans les fichiers ant/make…
  - [^] # Re: Non, mais ...
    
    Posté par claudex le 12 mai 2013 à 14:08. Évalué à 6.
    
    celui qui a commité le répertoire build/ (ou autre fichier généré n’ayant pas vocation à être commité) par erreur
    
    En quoi ça n'arrive pas quand on n'utilise pas d'IDE ? Je l'ai déjà vu dans des git add fait à la main. En général, un .gitignore (ou équivalent) évite la plupart des problèmes, que ce soit avec un IDE ou sans.
    
    celui qui au contraire a commité une modification qui nécessite un changement dans la configuration du projet, et qui du coup casse le build sur la machine de tests et les autres IDE
    
    Je le vois plus quand il faut faire les commit à la main, un IDE montre les fichiers changé avec une case à cocher ce qui rend les fichiers non commité plus visible (c'est la même chose avec un git status mais il faut penser à le faire).
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Non, mais ...
    
    Posté par barmic le 12 mai 2013 à 15:20. Évalué à 2.
    celui qui a commité le répertoire build/ (ou autre fichier généré n’ayant pas vocation à être commité) par erreur
    Les gestionnaires de versions sont capable d'ignorer certains fichiers ou dossier si on leur dis. Tu aura le même problème avec ton éditeur qui crée des fichiers *~.
    celui qui au contraire a commité une modification qui nécessite un changement dans la configuration du projet, et qui du coup casse le build sur la machine de tests et les autres IDE
    J'ai jamais vu ça sauf dans un cas idiot quand on appuie son build sur l'IDE, mais qu'on ne commit pas ces fichiers. Je m'entends si à la place d'utilise make, tu utilise un truc interne à ton IDE, donc tout le monde utilise cet ide parce que c'est avec lui qu'on build, mais bon on commit pas les fichiers projets parce qu'il paraît que c'est crade. À ce moment là tu n'a pas dans ton gestionnaire de version les informations suffisante pour construire ton projet.
    
    Dans les autres cas, les gens sont plus ou moins obligé de configurer leur IDE pour s'appuyer sur l'outil de build qui est commité et il n'y a pas de problème.
    
    Note : C'est aussi un sacré argument pour mettre en place une intégration continue.
    les IDE qui mettent des chemins absolus dans les fichiers ant/make…
    Ça existe encore ça ? Maven est cool là dessus il est fait pour que ce soit compliqué.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Ça dépend du language et évolution de l'écosystème

Posté par RB le 11 mai 2013 à 11:18. Évalué à 6.

On va dire que les plus utile c'est une très bonne complétion (+refactoring de temps en temps). Cette complétion marche surtout bien avec les langages compilables (java, c++, …) mais donne peu ou aucun résultat avec les langages interprétés comme ruby ou la structure des objects/classes peut évoluer au cours de l'éxécution.

Ensuite, pour moi ce qui est le plus utile, ce sont l'ensemble des méthodologies/outils qui ont totalement changés. Déjà les frameworks (forme d'injection de dépendances) et les méthodologies qu'ils encourages comme les tests unitaires et/ou les tests d'intégration.

Git, puis les repository comme github ont dynamisé les échanges et les évolutions des projets (en y réfléchissant, je trouve que le DVCS sont ce qui à le plus changer ma façon de travailler).

La virtualisation a également favorisé de nouvelles pratiques de dev et de tests.

A mon point de vue, les changements dans les éditeurs/IDE sont finalement peu important par rapport à l'évolution de l'écosystème.
# Lecture et Navigation

Posté par Gof (site web personnel) le 11 mai 2013 à 12:08. Évalué à 10.

Un des gros avantage d'un bon IDE qui « comprends » le language dans lequel on écrit est que ça facilite la lecture et la navigation du code.

Personnellement, il m'arrive de travailler sur des grosses base de code écrit par d'autres. Je passe beaucoup de temps à lire et comprendre le code avant de le modifier. Pour cela, un IDE aide beaucoup grâce aux tooltips qui contiennent des information sur les types ou la documentation. Le fait de pouvoir facilement passer d'un fichier à l'autre et d'une fonction à l'autre est aussi très important ;
Ainsi que pouvoir, en un seul shortcut, aller voir l'implémentation d'une fonction pour être sur de ce qu'elle fait, puis revenir là ou on était.
Trouver tous les endroit où une fonction est utilisée pour savoir si on peux ou pas changer son comportement.

Les IDE propose aussi plus que de la simple coloration syntaxique, mais de la coloration sémantique, qui permet de facilement repérer les erreurs ou de visualiser les types ou scopes.

Cette navigation est pour moi indispensable, qui fait que lire le code sans est vraiment pénible.
(C'est pour ça que j'ai même écrit un site qui permet de naviguer dans le code en ligne comme dans un IDE: http://code.woboq.org )
- [^] # Re: Lecture et Navigation
  
  Posté par navaati le 11 mai 2013 à 12:53. Évalué à 6.
  
  Mais ton site est génial ! Merci !
# Design pour un IDE sous GNOME

Posté par remjg le 11 mai 2013 à 14:22. Évalué à 0.

J'aime beaucoup le design d'IDE proposé pour l'environnement GNOME :
https://live.gnome.org/Design/Apps/IDE

La simplicité du design pourra peut-être me réconcilier avec les IDE. J'ai toujours utilisé un éditeur de texte pour mes développements "amateurs" car je trouve les IDE difficiles à appréhender au début.

C'est peut-être la raison pour laquelle je ne suis pas capable de contribuer au code de mes logiciels libres préférés ! Face à la masse d'informations (librairies) et la multitude de problèmes secondaires au début (makefile, git, etc…), il faudrait accepter de se faire aider ;-)
- [^] # Re: Design pour un IDE sous GNOME
  
  Posté par Marotte ⛧ le 11 mai 2013 à 14:28. Évalué à 3.
  
  Un IDE spécial pour les applications Gnome ? Pourquoi ne pas intégrer le spécifique Gnome à Anjuta ?
  - [^] # Re: Design pour un IDE sous GNOME
    
    Posté par remjg le 11 mai 2013 à 15:12. Évalué à -1.
    
    Je ne sais pas si le travail de migration vers GNOME 3 peut être fait facilement en prenant Anjuta comme base.
    
    Le cas Rhythmbox/Music est intéressant à ce propos puisqu'il fut question un temps de prendre comme base Rhythmbox. Au final la solution retenue fut de repartir de zéro pour Music tandis que Rhythmbox a évolué doucement vers GNOME 3.
  - [^] # Re: Design pour un IDE sous GNOME
    
    Posté par rewind (Mastodon) le 11 mai 2013 à 16:27. Évalué à 7.
    
    C'est un peu un syndrome chez GNOME de refaire les applis tous les quatre matins depuis zéro. Si on refaisait l'historique, je me demande combien on trouverait de lecteur de musique, de navigateur, etc.
# IDE python

Posté par Sekigo le 11 mai 2013 à 17:09. Évalué à 5.

Alors, je programme en Python. De temps à autres en Cython et enfin, très rarement en C.
Je code aussi énormément en XSLT, mais je n'en parlerais pas ici parce que je ne me suis pas penché sur la question d'un IDE pour les fichiers xml, xslt, xschema, etc…

Avant, j'utilisais Geany, quand je vivais dans le péché et la luxure sous Gnome. C'est vraiment très bien comme "petit" éditeur de code.
Puis, j'ai migré vers KDE, loué soit son nom à travers les âges et que sa lumière nous éclaire, et j'ai commencé à utiliser Kate. C'est vraiment bien aussi, mais moins puissant que Geany je trouve (mais ça va certainement s'arranger, j'ai vu le mois dernier le blog de Kate et il y a ENFIN la possibilité de créer SIMPLEMENT des scripts Python \o/. Mais le temps que ça arrive dans Debian, j'aurais déjà coder mon propre IDE…)

Je me suis mis à la recherche intensive d'un IDE qui correspondrait à mes attentes (principalement, la coloration syntaxique, la documentation visible LE PLUS RAPIDEMENT possible et un tas d'autres petits machins). J'ai testé KDevelop (que j'ai fermé au bout de 30 secondes), et j'ai galéré quelques heures sur Eric (qui est vraiment horrible à configurer, la faute à une documentation merdique).

Puis, au fin fond d'une question stackoverflow, je suis tombé sur Spyder. Je l'ai testé, et je l'ai finalement adopté comme IDE depuis un bon moment maintenant (plus d'un an ? deux ans ? J'ai oublié)
Ce qui améliore ma productivité :
- le fait d'avoir un widget avec la documentation en reStructuredText (et allelluia, Spyder accepte la documentation typée numpydoc. Même si j'avoue avoir légèrement forké le style numpydoc pour un usage personnel car la génération avec sphinx ne produit pas un résultat satisfaisant à mes yeux. On s'égare mais c'est essentiel pour moi d'avoir une documentation lisible DANS le code et APRÈS la génération d'une doc html.
- La coloration syntaxique. Bon, 99,9% des éditeurs de code ont ça, qui est généralement de bon niveau. Mais j'aime bien celle proposer par Spyder.
- Mettre des points d'arrêts en un click pour utiliser le debugger Python pdb. Ma période "print print print" est terminé.
- La console interactive python ou ipython. Accessible d'un click ou raccourci clavier.
- L'intégration de pylint, pour respecter à peu près les standards d'écriture Python, et profiler le code, pour repérer les bouchons. La sortie du profiler est très lisible et visuel, c'est cool.
- La complétion du code presque efficace (j'en parle un peu plus bas)
- Le pc ne fait pas fondre la table sous la charge processeur (non, non, je ne vise personne…).

Y a des trucs qui peuvent être utile à d'autres:
- L'inspecteur d'objet. Quand on lance le code, on peut aller trifouiller dans la mémoire via un widget et observer/remplacer visuellement les valeurs des objets Python. Perso, bien que je comprenne l'utilité, je ne l'utilise pas du tout, préférant la console.
- L'intégration git. Vu que je ne fais que des "pull, commit, push", je vais plus vite en ligne de commande que clicker.
- Y a un tas de features sur les graphiques mathématiques, les formules et plein de bordel scientifique. Moi, je suis un gueux, je n'y connais rien et je n'en ai pas du tout l'utilité pour le moment. Mais je comprend parfaitement ce coté killer-feature de Spyder.
- etc…

Et Spyder est vivant, ce n'est pas un code qui dort dans google code.

Le seul truc qui me déçoit, c'est la complétion de code DANS l'éditeur de code. Sur les libs standard, pas de problème. Sur mon propre code non plus. Mais dès que je tape dans lxml par exemple (une bibliothèque indispensable pour mon boulot), ou SFML, la complétion ne me propose plus rien du tout. L'effet de bord non négligeable est que le widget de documentation ne se remplit pas automatiquement.
Mais par contre, dans la console de l'IDE, pas de problème. J'ai bien toutes les complétions possible, avec la doc qui s'affiche en temps réel.

En tout cas, j'ai presque trouver mon bonheur avec Spyder !
- [^] # Re: IDE python
  
  Posté par flan (site web personnel) le 11 mai 2013 à 18:27. Évalué à 2.
  
  Je teste actuellement (depuis ce matin, c'est dire si je maîtrise le sujet) PyCharm (version Python d'IntelliJ / PHPStorm).
  
  Python 3 permet d'annoter le code en marquant les types d'entrée et de retour des fonctions ou méthodes, et j'ai découvert avec joie que pris en compte par PyCharm. Autrement dit, ça permet une complétion du code bien plus efficace. Spyder fait-il de même ?
  - [^] # Re: IDE python
    
    Posté par ariasuni le 11 mai 2013 à 19:29. Évalué à 1.
    
    Python 3 permet d'annoter le code en marquant les types d'entrée et de retour des fonctions ou méthodes
    
    Comment on fais?
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: IDE python
      
      Posté par flan (site web personnel) le 11 mai 2013 à 19:57. Évalué à 2.
      Exemple de base :
      
      from package.subpackage.module import maclasse def toto(arg1: maclasse, arg2: int) -> str: return ''
      - [^] # Re: IDE python
        
        Posté par kadalka le 11 mai 2013 à 20:44. Évalué à -9.
        
        Dommage qu'il ne soit pas gratuit…
        (il gère django !)
        
        Merci à Sekigo qui a mentionné Spyder:
        Spyder (software) - Wikipedia, the free encyclopedia
      - [^] # Re: IDE python
        
        Posté par Zylabon le 12 mai 2013 à 14:41. Évalué à 10. Dernière modification le 12 mai 2013 à 14:41.
        
        Python… tant d'efforts pour supprimer les types, suivis d'encore plus d'efforts pour les remettre…
        
        Please do not feed the trolls
        
        [^] # Re: IDE python
        
        Posté par Antoine le 12 mai 2013 à 15:35. Évalué à 2.
        
        Tant d'erreurs en une phrase:
        
        tant d'efforts pour supprimer les types,
        
        Python est loin de supprimer les types, tout objet est typé, y compris les types eux-mêmes.
        
        suivis d'encore plus d'efforts pour les remettre…
        
        Pas du tout, les annotations sont purement génériques et accessoires, tu peux mettre "toto" si ça te chante. L'interpréteur n'en tient pas compte, d'où l'utilisation possible comme documentation ou comme indice à destination d'un outil tiers (comme l'IDE suscité).
        
        [^] # Re: IDE python
        
        Posté par barmic le 12 mai 2013 à 15:42. Évalué à 7.
        
        Pas du tout, les annotations sont purement génériques et accessoires, tu peux mettre "toto" si ça te chante. L'interpréteur n'en tient pas compte, d'où l'utilisation possible comme documentation ou comme indice à destination d'un outil tiers (comme l'IDE suscité).
        
        C'est quand même un sacré retour en arrière pour le duck typing. On se rend compte que finalement avoir l'information de type ça a un vrai intérêt. Allez introduction d'un typage statique dans la prochaine version 3.3.1 ? :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE python
        
        Posté par ckyl le 12 mai 2013 à 16:41. Évalué à 5.
        
        Déconnes pas les mecs de Jetbrains se sont fait chier pour collecter les types à runtime pour pouvoir proposer une completion correcte. Tu vas les faire se pendre…
        
        http://blog.jetbrains.com/pycharm/2013/02/dynamic-runtime-type-inference-in-pycharm-2-7/
        
        Cela dit rigolo c'est tendance de vouloir faire un faux typage statique dans les langages dynamique (python, js) après s'être rendu compte qu'on devait de toute facon spécifier les types dans la documentation… C'est cool tu spécifies tout mais ca ne sert à rien !
        
        [^] # Re: IDE python
        
        Posté par Antoine le 12 mai 2013 à 16:55. Évalué à 2.
        
        C'est quand même un sacré retour en arrière pour le duck typing.
        
        Pas du tout. Les annotations n'imposent rien du tout (ni un type ni autre chose), elles ne font qu'associer une information aux différents paramètres d'une fonction. Cela permet de formaliser des descriptions qui auparavant pouvaient être faites de manière informelle, par exemple dans une docstring.
        
        Si tu veux en savoir plus, je te conseille d'aller lire la PEP associée : http://www.python.org/dev/peps/pep-3107/
        
        Si tu voulais un formalisme concurrent au duck typing, tu ferais mieux d'aller voir les ABC : http://docs.python.org/dev/library/abc.html#module-abc
        
        [^] # Re: IDE python
        
        Posté par barmic le 12 mai 2013 à 19:48. Évalué à 5. Dernière modification le 12 mai 2013 à 19:49.
        
        Les annotations n'imposent rien du tout […]
        
        J'ai bien compris, mais il n'en reste pas moins que c'est un aveux que ces informations sont importantes. Que ce soit pour l'interpréteur ou pour le développeur.
        
        Merci pour les liens, j'avais oublié abc et je vais un peu regarder la PEP.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE python
        
        Posté par flan (site web personnel) le 12 mai 2013 à 19:45. Évalué à 1.
        
        Bien sûr que le duck-typing a un certain nombre d'inconvénients (dont l'absence d'info dans l'IDE fait partie), mais également un certain nombre d'avantages également. Malheureusement, on ne peut pas tous les avantages en même temps, donc il faut faire un choix, et heureusement que tout le monde n'a pas fait le même :)
        
        Au moins, l'approche proposée par Python 3 permet de supprimer à la demande certains des inconvénients. Dans 99% des cas, typer statiquement n'est pas gênant, mais parfois c'est vraiment pas pratique de devoir typer fortement (ou alors on type en « object », ce qui revient à ne pas typer), ou alors on peut construire sa classe peu à peu, remplacer dynamiquement certaines méthodes, etc. J'aime bien la possibilité de mixer les méthodes de programmation, ça permet parfois de bien se faciliter la tâche.
        
        [^] # Re: IDE python
        
        Posté par barmic le 12 mai 2013 à 19:55. Évalué à 7.
        
        Au moins, l'approche proposée par Python 3 permet de supprimer à la demande certains des inconvénients. Dans 99% des cas, typer statiquement n'est pas gênant, mais parfois c'est vraiment pas pratique de devoir typer fortement (ou alors on type en « object », ce qui revient à ne pas typer), ou alors on peut construire sa classe peu à peu, remplacer dynamiquement certaines méthodes, etc. J'aime bien la possibilité de mixer les méthodes de programmation, ça permet parfois de bien se faciliter la tâche.
        
        Comme je le dis plus haut, je dois être un marteau. Personnellement écrire :
        
        a=12 # bla bla a='coucou'
        
        Me choque et me font penser qu'il y a un problème dans l'écriture de l'algo.
        
        Le typage dynamique sert essentiellement pour ne pas avoir à gérer de la généricité et pour ne pas trop se prendre la tête au sujet sur les héritage, mais il permet des choses qui me sembles très crades (amha les gains ne valent pas les pertes). À la rigueur si c'était en opt-in (un typage statique sauf en cas de besoin particulier), ça me conviendrait mieux.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE python
        
        Posté par grim7reaper le 12 mai 2013 à 20:54. Évalué à 1.
        
        Ça te choque car tu vois les variables en Python comme des variables en C.
        Or, ça ne fonctionne pas pareil.
        Après, on est d’accord, nommer une variable a c’est choquant car c’est très mauvais nommage.
        
        Sinon l’argument de « ça permet de faire des choses crades », bof.
        Le C est typé statiquement, pourtant je te fais des choses crades à la pelle si l’envie me prend.
        
        [^] # Re: IDE python
        
        Posté par barmic le 12 mai 2013 à 21:15. Évalué à 3.
        
        Ton lien n'a aucun rapport. Le fait que les variables soit des références ne change rien quant au type de typage. Mon problème dans l'exemple que j'ai donné c'est que tu donne le même nom à 2 choses qui sont différentes et cela au sein du même algorithme.
        
        Si tu veux faire un peu plus sale tu va jusqu'à mettre la seconde instruction dans une condition. En sortie de celle-ci, ta variable peut avoir 2 types différents et plus rigolo comme tu ne déclare pas tes variables cet identifiant peut avoir 2 sémantiques totalement différentes et ton interpréteur attendra le dernier moment pour te le dire.
        
        L'inférence de type c'est tout de même un peu plus propre à mon humble avis.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE python
        
        Posté par grim7reaper le 12 mai 2013 à 21:41. Évalué à 2.
        
        Si, il y a bien un rapport.
        
        Dans ton exemple oui, c’est bidon et crade car ça change sans aucune raison ni logique.
        Il y a des cas où c’est justifié, et du coup c’est bien pratique :
        Genre tu veux lire 2 entiers dans un fichier, et bien je ne trouve pas ça choquant de faire :
        
        with open('INI2.dataset', encoding='utf-8') as dataset: a, b = dataset.readline().rstrip().split(' ') a, b = int(a), int(b)
        
        Et pourtant, a et b sont des chaînes de caractères puis deviennent des entiers.
        Est-ce que le monde va s’effondrer pour autant ? Est-ce que le code est illisible et devient très sale ?
        Il me semble que non.
        (Oui, je sais que je pourrais passer par une liste en intention ici, mais c’est histoire de faire un exemple)
        
        Après, c’est sûr qu’une inférence de type efficace (à la Haskell par exemple), ça offre beaucoup plus de garantie et de sécurité.
        
        [^] # Re: IDE python
        
        Posté par flan (site web personnel) le 12 mai 2013 à 22:08. Évalué à 3.
        
        oui, ton exemple est un exemple de mauvais code Python. Mais comme déjà dit, on peut faire des trucs sales dans tous les langages, y compris en C.
        
        Mais voilà deux autres exemples de code
        
        current_line = file_descriptor.readline() current_line = int(current_line) # on sait que le fichier contient que des entiers
        
        => bouh, c'est sale, on change le type de current_line (de str à int).
        
        int i; for(i = 0; i < 10; i++) { blablabla } [...] i = mon_appel_de_fonction(); i += 42; return i;
        
        => ouf, c'est bon, i reste un entier. Pourtant, je trouve que c'est bien pire que l'exemple précédent, vu que la sémantique de i a complètement changé entre les deux utilisations.
        
        Alors, oui, l'inférence de type est plus propre, mais par définition c'est plus contraignant et ne permet pas la souplesse offerte par Python (genre la construction dynamique des types, la récupération des arguments dans un dictionnaire, etc.).
        
        [^] # Re: IDE python
        
        Posté par barmic le 12 mai 2013 à 22:33. Évalué à 1.
        
        Mais comme déjà dit, on peut faire des trucs sales dans tous les langages, y compris en C.
        
        Je trouve bizarre cet argument. C'est comme si quand certains disent que python est lent (affirmation péremptoire et généralement fausse), vous répondiez :
        
        oui mais le <placer ici le langage que l'on veut> peut être lent (toc !)
        
        Vous donnez des contres exemples à vos exemples… Je n'ai pas grand chose à y dire. Des fois c'est moins sale que d'autres, mais ils apportent assez peu de choses dans vos exemple.
        
        Je suis sûr qu'on peut trouver de bons exemples (d'ailleurs ça m'intéresse) qui seront probablement plus lié à la manière de faire de la POO en python (par exemple pour gérer les tuples ou les générateurs), mais avant que vous ne continuez sans cesse à chercher des exemples je vais me répéter :
        
        amha les gains ne valent pas les pertes (Note du citateur : je reconnais volontiers qu'il y a des gains)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE python
        
        Posté par Antoine le 12 mai 2013 à 22:38. Évalué à 5.
        
        Le bon exemple typique, c'est l'utilisation de None comme valeur de retour signifiant "n'existe pas" ou "non spécifié". None a son propre type (ce n'est ni un entier, ni une chaîne, etc.), pourtant il ne me semble pas sale du tout de l'utiliser ainsi.
        
        [^] # Re: IDE python
        
        Posté par barmic le 12 mai 2013 à 22:50. Évalué à 2.
        
        En effet c'est un bon exemple.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: IDE python
        
        Posté par groumly le 12 mai 2013 à 22:44. Évalué à 2.
        
        Mais voilà deux autres exemples de code
        current_line = file_descriptor.readline() current_line = int(current_line) # on sait que le fichier contient que des entiers
        => bouh, c'est sale, on change le type de current_line (de str à int).
        
        Et quel est l'interet de ce code par rapport a:
        current_line = file_descriptor.readline() current_int = int(current_line) # on sait que le fichier contient que des entiers
        
        Le deuxieme me parait vachement clair, et correct. Je sais pas ce que retournes int() mais j'imagines que si string n'est pas un nombre, tu perds la valeur de string, ce qui t'empeche de logger correctement l'erreur en plus (oui, parce que les "on sait" sur un fichier, ca fini toujours par te peter a la gueule un jour).
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: IDE python
        
        Posté par lasher le 13 mai 2013 à 01:16. Évalué à 3.
        
        Bon on va sans doute m'expliquer que je fais du code moche, mais qu'y a-t-il de mal à faire ce qui suit?
        
        # on sait que le fichier contient que des entiers current_line = int ( file_descriptor.readline() )
        
        Certes si jamais le fichier ne contient pas que des entiers, ça va casser, et donc au moment de debugger, il faudra séparer la ligne en deux. Mais bon de toute manière le bug existera même avec les deux lignes initiales.
# question à l'entretien

Posté par Yukito (site web personnel) le 11 mai 2013 à 18:03. Évalué à 3.

En tout cas, un candidat qui me dirait en entretien qu'il n'utilise jamais d'ide parce que vim c'est mieux que tout, je ne l'embauche surtout pas. Trop compétent pour le poste…
# Les IDE, c’est chiant

Posté par ariasuni le 11 mai 2013 à 19:29. Évalué à 6.

Prenons un exemple tout bête: quand je commence à écrire une fonction dont le type de retour n’est pas void, il me souligne en rouge que je n’ai pas mis de return, ce qui est affreusement chiant. À chaque fois que je m’arrête pour réfléchir, il me souligne un truc en rouge, ce qui à le don de me déconcentrer (et surtout de me fatiguer), même si je m’habitue au bout d’un moment.

Ensuite, avec un IDE on comprend pas forcément ce qu’on fait. À l’IUT on utilise NetBeans (dont l’indentation est à chier d’ailleurs) ou Eclipse (dont l’UI est un monstre), dedans on crée des «packages» mais je ne sais pas comment compiler ce code en dehors de l’IDE (à chaque fois que j’ai essayé, ça ne fonctionnait pas).

Finalement ne pas utilisé un IDE je pense à un côté positif dans le sens ou il faut faire plus attention à ce qu’on écris, et je pense donc que c’est bien pour l’apprentissage. Ça oblige aussi à compiler de temps pour voir si ça fonctionne et à faire des fonctions pour tester ce qu’on vient de faire plutôt que de ne compter que sur l’IDE pour nous signaler les erreurs.

Bref, je ne condamne pas les IDE (les erreurs en temps réel d’Eclipse, c’est très pratique) mais je préfère les environnements plus légers, qui sont plus «transparents», plus configurables et qui permettent de coder dans tous les langages. J’ai l’impression de ne pas avoir le contrôle quand j’utilise un IDE, je préfère compiler à la main et utiliser des outils pas trop sophistiqués qui marchent partout. J’aime bien aussi QtCreator dont l’UI est plutôt pas mal, dommage qu’on ne puisse pas faire de tout avec.

Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Les IDE, c’est chiant
  
  Posté par mackwic le 11 mai 2013 à 19:51. Évalué à 5.
  
  Prenons un exemple tout bête: quand je commence à écrire une fonction dont le type de retour n’est pas void, il me souligne en rouge que je n’ai pas mis de return, ce qui est affreusement chiant. À chaque fois que je m’arrête pour réfléchir, il me souligne un truc en rouge, ce qui à le don de me déconcentrer (et surtout de me fatiguer), même si je m’habitue au bout d’un moment.
  
  C'est un comportement d'Éclipse, ça. Pas de Visual Studio, KDevelop ou Intellij Idea (au moins). Ne généralise pas ce défaut à tous les IDEs. ;)
  
  Ensuite, avec un IDE on comprend pas forcément ce qu’on fait. À l’IUT on utilise NetBeans (dont l’indentation est à chier d’ailleurs) ou Eclipse (dont l’UI est un monstre), dedans on crée des «packages» mais je ne sais pas comment compiler ce code en dehors de l’IDE (à chaque fois que j’ai essayé, ça ne fonctionnait pas).
  
  Si tu ne comprends pas, c'est à toi d'aller voir comment ça marche ! http://ant.apache.org/manual/tutorial-writing-tasks.html
  
  Finalement ne pas utilisé un IDE je pense à un côté positif dans le sens ou il faut faire plus attention à ce qu’on écris, et je pense donc que c’est bien pour l’apprentissage.
  
  Je suis d'accord.
  - [^] # Re: Les IDE, c’est chiant
    
    Posté par groumly le 11 mai 2013 à 19:57. Évalué à 0.
    
    C'est un comportement d'Éclipse, ça. Pas de Visual Studio, KDevelop ou Intellij Idea (au moins). Ne généralise pas ce défaut à tous les IDEs. ;)
    
    Va faire un tour dans les parametres du compilo java et decoche la case qui va bien si ca te gene tant que ca.
    
    Si tu ne comprends pas, c'est à toi d'aller voir comment ça marche ! http://ant.apache.org/manual/tutorial-writing-tasks.html
    
    Ant? Yen a encore pour utiliser ce monstre?
    
    Pour l'apprentissage, j'en envie de dire que c'est le contraire, l'ide masque tout la build chain, le packaging et un paquet de trucs du style.
    J'aurais plutot envie que les eleves comprennent pourquoi eclipse peut "souligner un truc en rouge" la ou le mvn install va compiler sans problemes. Par contre, une fois que tu comprends comment marche tout ca, c'est une grosse perte de temps de s'emboucanner avec ca.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    - [^] # Re: Les IDE, c’est chiant
      
      Posté par mackwic le 11 mai 2013 à 20:08. Évalué à 2. Dernière modification le 11 mai 2013 à 20:09.
      
      Ant? Yen a encore pour utiliser ce monstre?
      
      Pour comprendre la façon dont on build du java, écrire un fichier ant fait bien avancer les choses je trouve. On peut jouer avec les classpath, les jar, les taches annexes.
      
      On est d'accord sur le reste, ceci dit.
    - [^] # Re: Les IDE, c’est chiant
      
      Posté par ariasuni le 11 mai 2013 à 21:30. Évalué à -2.
      
      @mackwic:
      
      C'est un comportement d'Éclipse, ça. Pas de Visual Studio, KDevelop ou Intellij Idea (au moins). Ne généralise pas ce défaut à tous les IDEs. ;)
      
      Je ne généralise pas, je pointais juste un problème particulier qui touche plusieurs IDE.
      
      Si tu ne comprends pas, c'est à toi d'aller voir comment ça marche ! http://ant.apache.org/manual/tutorial-writing-tasks.html
      
      En fait je parlais pas de Ant (que je connaissais pas — que c’est moche le XML, mais bon quand je regarde les makefile générés par CMake je me dis que de toute façon c’est imbuvable) mais par exemple, avoir vu le détails d’un makefile très très basique c’est très utile pour comprendre comment fonctionne make (et la plupart des autres chaines de compilation je suppose). Après rien à foutre de l’écrire à la main, tant qu’on a compris comment ça fonctionnait.
      
      Pour l'apprentissage, j'en envie de dire que c'est le contraire, l'ide masque tout la build chain, le packaging et un paquet de trucs du style.
      
      Certes, mais si je suis incapable de recompiler le projet actuel sans l’IDE, c’est quand même problématique (bon tu me diras je fais du Java donc je suis pas à ça prêt :p).
      
      @groumly:
      
      Va faire un tour dans les parametres du compilo java et decoche la case qui va bien si ca te gene tant que ca.
      
      Dans les paramètres du compilo… Logique. Évidemment. Les erreurs affichés dans l’interface utilisateur dans les options du compilo… J’ai un peu cherché mais c’est l’horreur les options d’Eclipse et franchement à part désactiver complètement les warnings et les erreurs de compilateur je ne vois pas ce que je peux faire de plus.
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Les IDE, c’est chiant
        
        Posté par groumly le 11 mai 2013 à 22:47. Évalué à 3.
        
        que je connaissais pas — que c’est moche le XML, mais bon quand je regarde les makefile générés par CMake je me dis que de toute façon c’est imbuvable
        
        C'est peut etre moche, mais maven a clairement montre que le declaratif pur pour un systeme de build, ca marche vachement mieux et ca permet a tout le monde de builder le projet comme il faut avec une ligne, tout en evitant au mainteneur de passer des heures a s'assurer que tout va marcher correctement que tu sois sous linux/window/macos ou dans un context CI.
        
        Certes, mais si je suis incapable de recompiler le projet actuel sans l’IDE, c’est quand même problématique (bon tu me diras je fais du Java donc je suis pas à ça prêt :p).
        
        Si t'es incapable de builder un projet d'ecole java en ligne de commande, comment dire?
        javac -classpath libs/*.jar -sourcepath src/ -d class/
        Ca fait bien 5 ou 6 ans que j'ai pas lance javac a la main et j'ai retrouve cette ligne de memoire a 80%…
        Dans la vraie vie, t'aurais un pom.xml que ton IDE mangerais avec plaisir et tu ferais mvn install
        
        Logique. Évidemment. Les erreurs affichés dans l’interface utilisateur dans les options du compilo…
        
        Oui, les flags de compilation se configurent generalement dans la partie "option de compilation". Ca me parait tres logique personnellement. Si je voulais changer la couleur du soulignage, par contre, j'irais voir sous Appearance.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par ariasuni le 11 mai 2013 à 23:41. Évalué à 0.
        
        C'est peut etre moche, mais maven a clairement montre que le declaratif pur pour un systeme de build, ca marche vachement mieux et ca permet a tout le monde de builder le projet comme il faut avec une ligne, tout en evitant au mainteneur de passer des heures a s'assurer que tout va marcher correctement que tu sois sous linux/window/macos ou dans un context CI.
        
        CMake ça fonctionne pas sous tous les système d’exploitation? (vraie question)
        
        Si t'es incapable de builder un projet d'ecole java en ligne de commande, comment dire?
        javac -classpath libs/*.jar -sourcepath src/ -d class/
        Ca fait bien 5 ou 6 ans que j'ai pas lance javac a la main et j'ai retrouve cette ligne de memoire a 80%…
        Dans la vraie vie, t'aurais un pom.xml que ton IDE mangerais avec plaisir et tu ferais mvn install
        
        Je suis en première année de DUT Informatique, et quand on compilait du Java à la main c’était javac programme.jar et ça s’arrêtait là (et je trouve ça dommage, mais on a un peu approfondi avec le C quand même, mais je ne vois pas à quoi sert l’option -d — il y a plusieurs .class à la fin? Ça peut tourner sans être assemblé dans un JAR?).
        
        Et sinon j’ai toujours pas compris comment on gérait les packages
        
        Oui, les flags de compilation se configurent generalement dans la partie "option de compilation". Ca me parait tres logique personnellement. Si je voulais changer la couleur du soulignage, par contre, j'irais voir sous Appearance.
        
        On s’est mal compris. Je veux juste qu’il ne m’affiche plus certaines erreurs dans le code, pas que le compilo ne me signale plus aucune erreur.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par groumly le 12 mai 2013 à 00:04. Évalué à 3.
        
        Je suis en première année de DUT Informatique, et quand on compilait du Java à la main c’était javac programme.jar et ça s’arrêtait là (et je trouve ça dommage, mais on a un peu approfondi avec le C quand même, mais je ne vois pas à quoi sert l’option -d — il y a plusieurs .class à la fin? Ça peut tourner sans être assemblé dans un JAR?).
        Et sinon j’ai toujours pas compris comment on gérait les packages
        
        J'allais ecrire un paquet plus haut, a propos de ton "manque de controle dans un ide". En gros, j'allais dire que si tu sens que tu perds le controle dans un ide, c'est que tu ne comprends pas la chaine de build. Si tu comprends la chaine de build, tu comprends ce que fait l'ide, et t'as pas la sensation de perdre le controle, parce que l'ide fait generalement quelque chose d'adapte (il a ete ecrit par des gens qui savent ce qu'ils font). Tu peux ne pas etre d'accord, mais il va falloir argumenter serieusement, et vu le niveau de questions, je doute que tu en soit vaguement capable (et ya pas de mal, tout le monde commence un jour).
        A la vue de tes questions, effectivement tu as des lacunes monstrueuses dans la chaine de compil java.
        Pour faire simple: oui, chaque class est compile dans un .class (meme les classes anonymes). La jvm mange ces .class, qu'ils se trouvent dans un zip ou directement sur le fs.
        Les "packages" ne sont ni plus ni moins qu'une archive zippee.
        cd class; zip ../projet.jar * et t'as un jar (ou un war, ou un ear).
        
        On s’est mal compris. Je veux juste qu’il ne m’affiche plus certaines erreurs dans le code, pas que le compilo ne me signale plus aucune erreur.
        
        Si le compilo te dit que c'est une erreur, il a probablement une bonne raison de te le dire, tu crois pas?
        De meme pour les warnings, si on te dit de faire gaffe, c'est probablement qu'il faut que tu fasses gaffe, non? @SuppressWarning est la pour les tres rares cas ou le warning est un faux positif.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par groumly le 12 mai 2013 à 00:05. Évalué à 1.
        
        CMake ça fonctionne pas sous tous les système d’exploitation? (vraie question)
        
        Ca va tres probablement pas tourner sous windows du premier coup, et t'as de grande chances d'avoir diverses incompatibilites subtiles entre linux et macosx.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par barmic le 12 mai 2013 à 01:14. Évalué à 3.
        
        CMake ça fonctionne pas sous tous les système d’exploitation? (vraie question)
        
        Sa syntaxe est meilleure ?
        
        Un pom.xml est très facile à valider et à parser, que demander de mieux. De plus tu n'y touche jamais ou très peu donc pourquoi s'interdire le XML ?
        
        Note qu'avec maven 3 en principe maven peut utiliser entre autre du json, mais en vrai c'est jamais utilisé et personne ne le supporte.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par groumly le 12 mai 2013 à 02:03. Évalué à 1.
        
        Le probleme du json, c'est que ca ne conserve pas l'ordre des champs, l'ordre etant dependant du hash, qui est implementation specific.
        En pratique, ca te donne de vilain diffs des qu'un outil manipule le pom de facon automatique (que ca soit un mvn release ou un editeur haut niveau qui t'ajoute/exclue des dependances).
        
        Ya beaucoup de choses a redire sur le xml, mais pour de la config dans ce style, les schema et la rigidite de la specs sont plutot des atouts je trouve.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par barmic le 12 mai 2013 à 15:22. Évalué à 2.
        
        Le probleme du json, c'est que ca ne conserve pas l'ordre des champs, l'ordre etant dependant du hash, qui est implementation specific.
        
        Je ne savais pas.
        
        Ya beaucoup de choses a redire sur le xml, mais pour de la config dans ce style, les schema et la rigidite de la specs sont plutot des atouts je trouve.
        
        Je ne m'en pleins pas personnellement.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par Antoine le 12 mai 2013 à 15:36. Évalué à 4.
        
        Le probleme du json, c'est que ca ne conserve pas l'ordre des champs, l'ordre etant dependant du hash, qui est implementation specific.
        
        Sauf si le sérialiseur est assez sympa pour balancer les champs dans l'ordre lexicographique.
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par barmic le 12 mai 2013 à 15:45. Évalué à 4.
        
        Le probleme du json, c'est que ca ne conserve pas l'ordre des champs, l'ordre etant dependant du hash, qui est implementation specific.
        
        Sauf si le sérialiseur est assez sympa pour balancer les champs dans l'ordre lexicographique.
        
        ?!
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par Antoine le 12 mai 2013 à 17:41. Évalué à 0.
        
        Eh bien, quoi ? Jette un oeil à l'option "sort_keys":
        http://docs.python.org/dev/library/json#json.JSONEncoder
        
        (l'objection d'origine étant « en pratique, ca te donne de vilain diffs des qu'un outil manipule le pom de facon automatique » : pas de vilain diff si la sortie est déterministe, par exemple en triant les clés)
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par barmic le 12 mai 2013 à 19:59. Évalué à 3.
        
        Tu nous parle d'une implémentation, alors qu'il parle de n'importe la quelle. Le fait de savoir que la bibliothèque standard de python le fait de manière déterministe, c'est bien mais ça ne change pas le problème que tu n'a aucune garantie que toutes les implémentations sont déterministe d'une part et le sont de la même façon que python.
        
        Un pom.xml n'a pas vocation à être manipulé par un seul outil (les IDE n'utilisent pas la commande mvn) et tu peut très bien vouloir faire un outils perso qui les manipulent.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Les IDE, c’est chiant
  
  Posté par barmic le 12 mai 2013 à 01:02. Évalué à 2.
  
  Ensuite, avec un IDE on comprend pas forcément ce qu’on fait. À l’IUT on utilise NetBeans (dont l’indentation est à chier d’ailleurs) ou Eclipse (dont l’UI est un monstre), dedans on crée des «packages» mais je ne sais pas comment compiler ce code en dehors de l’IDE (à chaque fois que j’ai essayé, ça ne fonctionnait pas).
  
  C'est triste. Surtout que l'on peut utiliser netbeans pour lui faire utiliser maven et ça lisse énormément les choses.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Les IDE, c’est chiant
  
  Posté par ckyl le 12 mai 2013 à 10:12. Évalué à 7.
  
  Ensuite, avec un IDE on comprend pas forcément ce qu’on fait.
  
  Franchement le problème c'est toi et uniquement toi, pas l'IDE. Tes questions montrent que tu ne maitrises même pas les concepts que l'on doit apprendre vers le deuxième cours de Java. Et tu oses expliquer ce qui est bien ou non…
  
  Bref avant de juger les outils, ou de dire " bon tu me diras je fais du Java donc je suis pas à ça prêt " tu ferais mieux d'ouvrir quelques livres sur le langage et sur l'IDE pour ne pas passer pour un charlot. Tout ce dont tu as parlé est trivial et tes lacunes ne te permettent même pas de comprendre à quoi peut bien servir un IDE.
  - [^] # Re: Les IDE, c’est chiant
    
    Posté par ariasuni le 12 mai 2013 à 16:27. Évalué à -1.
    Franchement le problème c'est toi et uniquement toi, pas l'IDE.
    
    Bon déjà je comprend tout à fait comment ça se passe en C (des .c que l'on compile en .o et que l'on assemble en fichier binaire), j'imagine qu'en Java c'est pas bien différent, sauf qu'il y a pas binaire, et que les .o sont les .class que l'on assemble des fois en .jar (mais je ne savais pas qu'on était pas obligé).
    
    Tes questions montrent que tu ne maitrises même pas les concepts que l'on doit apprendre vers le deuxième cours de Java.
    
    C'pas moi qui fait les cours.
    
    Et tu oses expliquer ce qui est bien ou non…
    
    Bref avant de juger les outils
    
    Faut arrêter les procès d'intention, je donne juste un avis très personnel.
    
    J'aime bien comprendre précisément ce que je fais, et le fait que je ne sache pas trop comment compiler un paquet Java «à la main» (faut compiler chaque paquet séparément?) déjà ça me soule, et en plus je trouve rien sur le net.
    
    ou de dire " bon tu me diras je fais du Java donc je suis pas à ça prêt "
    
    Si on ne peux plus troller sur DLFP… Mais ouais le Java ça me gave, parce que même si ça donne des performances correctes ça bouffe toute la RAM de mon ordinateur. Et parce que System.out.println c'est long, et que la classe Scanner est super chiante à utiliser en plus de poser des problèmes de mémoire tampon. Et parce
```
public class Main() {
    public static void main(String args) {
        // blabla
    }
}
```
    c'est super chiant pour commencer un programme. Parce que si je met public static void main(), il me dit qu'il ne trouve pas la classe main.
    
    tu ferais mieux d'ouvrir quelques livres sur le langage et sur l'IDE pour ne pas passer pour un charlot.
    
    Là n'est pas vraiment le sujet. Ce que je voulais dire, c'est que l'on m'a appris à utiliser une fonctionnalités dans un IDE et que je ne sais pas le faire à la main. C'est peut-être un exemple pas très bon mais ça montre que l'apprentissage des choses par l'IDE est pas forcément une bonne chose. En outre l'exemple d'Eclipse sus-cité montre que dans certains cas les IDE c'est relou.
    
    Pour en revenir au sujet, même Kate est relou des fois avec l'auto-complétion basique mais que l'on peut désactiver. Le soulignage intempestif des IDE, les pop-up, les interfaces monstreuses… Il y a un IDE pour un ou deux langage (QtCreator, Eclipse, Netbeans, Code::blocks, KDevelopp, est) ou alors il est basique (Geany).
    
    Reste vim et Emacs, pas eu le courage de m'y mettre jusqu'à présent mais je connais les commandes de base.
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Les IDE, c’est chiant
      
      Posté par barmic le 12 mai 2013 à 20:23. Évalué à 5.
      
      J'aime bien comprendre précisément ce que je fais, et le fait que je ne sache pas trop comment compiler un paquet Java «à la main» (faut compiler chaque paquet séparément?) déjà ça me soule, et en plus je trouve rien sur le net.
      
      Il faut vouloir chercher et arrêter d'avoir des présupposés à la noix sans connaître vraiment pour pouvoir trouver. Première page de ddg avec les mots clef "usage javac" me donne ça par exemple : http://stackoverflow.com/questions/8027670/compiling-four-java-files-within-one-package-using-javac
      
      Un truc qui serait intéressant que tu fasse (mais de bonne foie donc pas la peine de répondre c'est pour toi que tu le fait), c'est de réfléchir au temps que tu as mis pour apprendre à le faire en C et le temps que tu as mis pour apprendre à le faire en Java avant de te dire que « Java c'est de la merde ».
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Les IDE, c’est chiant
        
        Posté par ariasuni le 13 mai 2013 à 07:05. Évalué à -1.
        
        Il faut vouloir chercher et arrêter d'avoir des présupposés à la noix sans connaître vraiment pour pouvoir trouver. Première page de ddg avec les mots clef "usage javac" me donne ça par exemple : http://stackoverflow.com/questions/8027670/compiling-four-java-files-within-one-
        
        Merci ça répond à ma question mais je conaissais pas ddg (c'est l'équivalent de ld pour Java c'est ça?) Mais visiblement ouais visiblement je connais pas tout sur la compilation Java, ce langage ne me plait spécialement mais je profite quand même de l'occasion pour apprendre un truc.
        
        Un truc qui serait intéressant que tu fasse (mais de bonne foie donc pas la peine de répondre c'est pour toi que tu le fait), c'est de réfléchir au temps que tu as mis pour apprendre à le faire en C et le temps que tu as mis pour apprendre à le faire en Java avant de te dire que « Java c'est de la merde ».
        
        Bah le truc c'est que je fais du C++ personnellement et du Java à l'IUT, chacun ses priorités.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par tape le 13 mai 2013 à 07:40. Évalué à 1. Dernière modification le 13 mai 2013 à 07:41.
        
        ddg, DuckDuckGo, un moteur de recherche dont une des particularités est de mettre l'emphase sur la confidentialité des données de l'utilisateur. Il y a eu quelques dépêches sur LinuxFr. Une alternative à l'habituel Google.
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par ariasuni le 13 mai 2013 à 08:49. Évalué à 2.
        
        C'est le moteur de recherche que j'utilise. J'ai mal lu…
        
        Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Les IDE, c’est chiant
      
      Posté par groumly le 12 mai 2013 à 22:37. Évalué à 1.
      
      Tu confirmes juste que le probleme, c'est toi, la.
      
      Bon déjà je comprend tout à fait comment ça se passe en C (des .c que l'on compile en .o et que l'on assemble en fichier binaire), j'imagine qu'en Java c'est pas bien différent, sauf qu'il y a pas binaire, et que les .o sont les .class que l'on assemble des fois en .jar (mais je ne savais pas qu'on était pas obligé).
      
      Ya des differences fondamentales entre le c et le java, qui sont dues essentiellement au fait que java est compile vers un bytecode et tourne dans une jvm qui est tres haut niveau par rapport a l'environnement d'execution du c. Ca simplifie beaucoup de choses.
      Le simple fait que tu "imagines" quelque chose qui est largement documente sur le web et dans la literature en dit long sur ton gout de comprendre.
      
      c'est super chiant pour commencer un programme. Parce que si je met public static void main(), il me dit qu'il ne trouve pas la classe main.
      
      Pov chou. Il faut que tu tapes 10 characteres de plus. Non, 12, t'as oublie le []. Une fois dans la vie de ton programme. Trop dur! Ca justifie de dire que le java c'est pas bien, effectivement.
      
      bouffe toute la ram
      
      Regardes les parametres de la jvm. Une heap par defaut a 64mb (si je ne m'abuse), ca me parait pas "bouffer toute la ram", ou alors tu codes sur un iphone. Et vu que tu ne sais meme pas compiler, je doute que tu aies trouve -Xms/-Xmx. Mon petit doigt me dit que tu te contentes de repeter des choses que tu as lues ailleurs - choses qui peuvent etre vraies dans un certain contexte, mais probablement pas dans le tien.
      
      println
      
      Println, personne ne l'utilise en java. C'est pas comme si les loggers etaient rare dans ce langage.
      Utilises logger.debug("whatever"), c'est aussi simple a taper que printf et c'est beaucoup plus flexible (niveau de log et appenders, entre autre).
      Si vraiment tu veux rester ignorant, utilises les static import et continues a utiliser println.
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Les IDE, c’est chiant
        
        Posté par barmic le 12 mai 2013 à 22:49. Évalué à 4.
        
        Utilises logger.debug("whatever"), c'est aussi simple a taper que printf et c'est beaucoup plus flexible (niveau de log et appenders, entre autre).
        
        Selon le logger que tu utilise, tu peut aussi avoir de gros gains en performance (en évitant la concaténation de chaine quand ce n'est pas nécessaire). Je pense à slf4j en particulier.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Les IDE, c’est chiant
        
        Posté par ariasuni le 13 mai 2013 à 07:20. Évalué à 2.
        
        Ya des differences fondamentales entre le c et le java, qui sont dues essentiellement au fait que java est compile vers un bytecode et tourne dans une jvm qui est tres haut niveau par rapport a l'environnement d'execution du c. Ca simplifie beaucoup de choses.
        Le simple fait que tu "imagines" quelque chose qui est largement documente sur le web et dans la literature en dit long sur ton gout de comprendre.
        
        L'état de fait: le Java m'intéresse pas spécialement, et à l'IUT on m'a par pris certaines choses. Tu noteras que j'ai quand même profité de l'occasion pour apprendre quelque chose.
        
        Pov chou. Il faut que tu tapes 10 characteres de plus. Non, 12, t'as oublie le []. Une fois dans la vie de ton programme. Trop dur! Ca justifie de dire que le java c'est pas bien, effectivement.
        
        Les TMS sont la maladie professionnelle la plus courante dans les pays développés. Sans compter le fait que trop d'info tue l'info. Donc ouais ça aurait pu être mieux.
        
        Regardes les parametres de la jvm. Une heap par defaut a 64mb (si je ne m'abuse), ca me parait pas "bouffer toute la ram", ou alors tu codes sur un iphone. Et vu que tu ne sais meme pas compiler, je doute que tu aies trouve -Xms/-Xmx. Mon petit doigt me dit que tu te contentes de repeter des choses que tu as lues ailleurs - choses qui peuvent etre vraies dans un certain contexte, mais probablement pas dans le tien.
        
        Le -Xmx 515M n'empêche pas Java de me prende plus d'1,2Gio de mémoire vive. Est-ce que les paramètres pour la taille de la pile permettrait de régler ça?
        
        Println, personne ne l'utilise en java. C'est pas comme si les loggers etaient rare dans ce langage.
        Utilises logger.debug("whatever"), c'est aussi simple a taper que printf et c'est beaucoup plus flexible (niveau de log et appenders, entre autre).
        Si vraiment tu veux rester ignorant, utilises les static import et continues a utiliser println.
        
        Je me fais engueuler parce que j'utilise la fonction standard de la bibliothèque standard pour écrire un truc à l'écran… Mais merci du conseil.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par groumly le 13 mai 2013 à 08:06. Évalué à 1.
        
        Je me fais engueuler parce que j'utilise la fonction standard de la bibliothèque standard pour écrire un truc à l'écran… Mais merci du conseil.
        
        Non, tu te fais engueuler parce que t'as un avis peremptoire sur des choses dont tu ne connais strictement rien, sans avoir fait le moindre effort pour te renseigner, tout en pretendant que tu aimes comprendre ce que tu fais.
        
        Sur ce je vais arreter la, le coup de demander si ddg etait le linker java m'a bien fait rigoler, mais ya un moment ou il faut savoir s'arreter.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par ariasuni le 13 mai 2013 à 09:49. Évalué à 6.
        
        Sur ce je vais arreter la, le coup de demander si ddg etait le linker java m'a bien fait rigoler, mais ya un moment ou il faut savoir s'arreter.
        
        J'avais pas lu le lien que tu m'avais filé (je l'avais juste mis en marque-pages). Mais ouais j'étais sur mobile, j'ai mal lu ce que tu as écrit…
        
        Bon moi je vais arrêter ton ton insultant ça va bien deux minutes. Ce n'est pas parce que l'on est pas d'accord et que raconte des conneries que ça excuse ton attitude de cours de récré, se moquer de moi parce que j'ai pas capté que ddg ça voulait dire duckduckgo (parce que j'appelle ça par le nom complet).
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par barmic le 13 mai 2013 à 09:03. Évalué à 2. Dernière modification le 13 mai 2013 à 09:04.
        
        à l'IUT on m'a par pris certaines choses
        
        Bienvenue dans le monde des études supérieurs (je ne doute pas qu'au moins l'un de tes professeurs est ouvert aux question, si tu as besoin de savoir ce genre de choses).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par barmic le 13 mai 2013 à 09:05. Évalué à 3.
        
        Les TMS sont la maladie professionnelle la plus courante dans les pays développés. Sans compter le fait que trop d'info tue l'info. Donc ouais ça aurait pu être mieux.
        
        Troll moins, tes doigts te remercierons plus tard.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Les IDE, c’est chiant
      
      Posté par ckyl le 12 mai 2013 à 23:38. Évalué à 2.
      
      j'imagine qu'en Java c'est pas bien différent
      
      J'imagine qu'il suffit de lire la doc
      
      C'pas moi qui fait les cours.
      
      Tu peux aussi te sortir les doigts. Si tu bloques la dessus avec des arguments comme ca, tu peux te réorienter tant qu'il est encore temps.
      
      J'aime bien comprendre précisément ce que je fais,
      
      Ca se combine pas très bien avec le fait que tu restes comme un gros bênet ne faisant même pas un man javac mais qui préfère ecrire 4 messages pour bien étaler son avis.
      
      et en plus je trouve rien sur le net.
      
      Dans ce cas consulte un livre fait de bois mort.
      
      Si on ne peux plus troller sur DLFP…
      
      C'est un poil gavant à la longue les boulets qui trollent dans le vide.
      
      Mais ouais le Java ça me gave […]
      
      Bien tes arguments montre que tu as fait un hello world
      
      mais ça montre que l'apprentissage des choses par l'IDE est pas forcément une bonne chose
      
      Non ca montre que tu restes dans ta crasse. L'IDE n'y est pour rien. Si il n'était pas la, tu ferais quoi ? Tu resterais assis à attendre ? La démarche pour javac et jar n'est pas plus compliquée, et même beaucoup plus simple que gcc & co. L'IDE te facilite la vie, ne pas apprendre ce que tu dois apprendre, c'est toi qui le décide. Tout comme mal l'utiliser.
      - [^] # Re: Les IDE, c’est chiant
        
        Posté par ariasuni le 13 mai 2013 à 08:47. Évalué à 0.
        
        J'imagine qu'il suffit de lire la doc
        
        Tu peux aussi te sortir les doigts. Si tu bloques la dessus avec des arguments comme ca, tu peux te réorienter tant qu'il est encore temps.
        
        Ca se combine pas très bien avec le fait que tu restes comme un gros bênet ne faisant même pas un man javac mais qui préfère ecrire 4 messages pour bien étaler son avis.
        
        J'ai fais javac -help. J'ai fais une rapide recherche sur le net, j'ai pas trouvé, j'ai compilé avec Eclipse (faut bien bosser…) et plus tard je suis pas revenu ça.
        
        En TP de Java je code en Java, en dehors je fais du C++ (j'ai récemment appris à utiliser CMake de façon basique, je compte approfondir), j'essaie le Python, le D et le Rust, je m'occupe de mon serveur auto-hébergé et de mon blog, je lis Linuxfr.org, le Framablog, le planet KDE, et bien d'autres sites. Je fais des rapports de bugs aussi, je participe au wiki/forum/ml du Bépo, projet pour lequel je fais un peu de C++. Et crois-moi, savoir que std::swap, std::move et std::vector::reserve existent m'aide bien plus que de connaitre tous les détails de la compilation Java (que je ne refuse d'apprendre mais dont je n'ai pas eu le temps/l'envie de creuser car j'ai d'autres priorités).
        
        Dans ce cas consulte un livre fait de bois mort.
        
        Si faut un bouquin pour savoir compiler en Java, la forêt est dans la merde.
        
        C'est un poil gavant à la longue les boulets qui trollent dans le vide.
        
        Désolé. Je pensais faire un peu d'humour inoffensif.
        
        Non ca montre que tu restes dans ta crasse. L'IDE n'y est pour rien. Si il n'était pas la, tu ferais quoi ? Tu resterais assis à attendre ?
        
        Bah peut-être que l'on m'aurait appris comment faire… Mais imagine les autres étudiants de l'IUT, la très grosse majorité sera moins renseignée que moi et n'en auras rien à faire (alors que ça m'intéresse si quelqu'un me dis comment faire comme ici).
        
        La démarche pour javac et jar n'est pas plus compliquée, et même beaucoup plus simple que gcc & co. L'IDE te facilite la vie, ne pas apprendre ce que tu dois apprendre, c'est toi qui le décide. Tout comme mal l'utiliser.
        
        Si ça ne tenais qu'à moi je n'aurais pas appris le Java, ça m'occupe déjà pas mal d'apprendre d'autres langages.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par barmic le 13 mai 2013 à 09:14. Évalué à 5.
        
        Dans ce cas consulte un livre fait de bois mort.
        
        Si faut un bouquin pour savoir compiler en Java, la forêt est dans la merde.
        
        Le papier se recycle et se fabrique à partir des reste de bois non-utilisé dans l'industrie du bois et c'est une ressources qui se renouvelles. Tu peut aussi passer voir la bibliothèque universitaire (ouai c'est pas ouaib 2.0). Il est à mon avis plus écolo de lire des bouquins que des sites web.
        
        D'autres part Java ne déroge pas à la règle. Pour presque tous les langages, il y a des bouquins qui expliquent tout à partir des bases. C'est aussi le cas pour le C ou le C++.
        
        Si ça ne tenais qu'à moi je n'aurais pas appris le Java, ça m'occupe déjà pas mal d'apprendre d'autres langages.
        
        C'est toi qui choisi de faire des choses à coté, ne te pleins pas et met les priorités là où tu veux (tes projets perso ou tes cours). Mais viens pas nous expliquer que Java c'est mal parce que tu écoute la moitié de tes cours et que tu fais tes TP par dessus la jambe, trop occupé par tes projets perso.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les IDE, c’est chiant
        
        Posté par ariasuni le 13 mai 2013 à 09:59. Évalué à 1.
        
        Mais viens pas nous expliquer que Java c'est mal parce que tu écoute la moitié de tes cours et que tu fais tes TP par dessus la jambe, trop occupé par tes projets perso.
        
        Je suis très bien les cours et je fais correctement les TP merci, mais j'ai pas envie plus que ça s'approfondir. Le problème que j'essaie de pointer est l'enseignement du Java qui nous apprend à faire certaines choses avec un IDE mais pas autrement.
        
        D'ailleurs même avec l'explication sur StackOverFlow c'est clair du tout, faudrait que je teste chez moi.
        
        Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Les IDE, c’est chiant
      
      Posté par lasher le 13 mai 2013 à 01:06. Évalué à 3.
      Bon, j'ai fait un IUT. Pendant mes 2 ans a l'IUT, j'ai (je melange les deux annees):
      
      Fait de l'algorithmique en C (en utilisant Visual Studio);
      
      fait de la programmation événementielle en Visual Basic (avec VS aussi);
      
      fait du C++ (la partie OO, pas de STL ou de templates);
      
      fait du Java (en utilisant VisualAge a l’époque; d'autres faisaient du C++ plus avance a la place);
      
      fait du XML et du XSL/T (d'autres faisaient du COBOL a la place);
      
      fait de l'ASP (avec VS; d'autres faisaient du C++…);
      
      fait du SQL (sur de l'Access et de l'Oracle).
      
      En plus de cela, j'ai vu (je mélange encore les deux années):
      
      De l'architecture des ordinateurs (de l'électronique numérique aux multi-processeurs, en passant par la façon dont les registres et la mémoire fonctionnent);
      
      comment les principales fonctions d'un OS fonctionnent;
      
      comment faire un makefile portable pour windows et linux;
      
      les protocoles réseau (OSI, ethernet, TCP/IP, un tout petit peu de X25/frame relay);
      
      comment faire de la prog système;
      
      les bases de l'administration sous Linux et Windows;
      
      comment concevoir des systèmes d'info avec le génie logiciel (aaaah, Merise et UML …);
      
      comment modéliser des bases de données.
      
      A cela s'ajoutent l'Anglais, les cours de communication et expression, les maths, la gestion et organisation, etc.
      
      Bref. Les cours de système et environnement de programmation sont ceux qui m'ont appris comment la chaine de compilation se faisait en C. Je ne sais plus si j'ai vu comment on chaîne en Java en ligne de commande a l'époque, mais je suis certain qu'on m'a explique comment le système de packages fonctionnait.
      
      Tout ça pour dire quoi ? En IUT, les profs on deux ans pour transformer des étudiants qui pour plus de la moitie (je dirais facilement les 2/3, voire les 3/4) ne savent pas réellement ce que signifie "faire de l'informatique" au moment ou ils arrivent en techniciens qualifiés. Ils n'ont pas toujours le temps de tout faire. Dans mon cas, le prof de Java était bien trop occupe a essayer de nous inculquer les principes de POO que nous n'avions qu'effleure en 1ere année en C++ (les trucs genre aller un peu plus loin dans la prog générique, l'overloading et le polymorphisme, la réutilisation de composants, etc.).
      
      Comme tu le dis quelque part, compiler en Java ou en C c'est grosso modo la même chose. Tu as déjà appris la chaîne de compil en C. Pourquoi se faire chier a passer du temps a te faire passer par un shell alors que y'a tellement d'autres trucs a t'expliquer ?
# Serieux?

Posté par groumly le 11 mai 2013 à 19:52. Évalué à 3.

Yen a encore pour se poser cette question en 2013?
Ou c'est juste une tentative de troll?

Que ca soit Eclipse/VisualStudio/IntelliJ/Xcode/autre ou emacs/vi avec 12000 plugins finis a la pisse, ya serieusement quelqu'un qui code encore uniquement avec un simple editeur de texte de nos jours?

Un IDE est un outil, savoir utiliser les outils de programmation me parait etre une competence indispensable d'un ingenieur.

C'est quoi le prochain journal? Un debuggeur est il reellement utile? Les outils graphiques servent ils reellement a quelque chose?

Linuxfr, le portail francais du logiciel libre et du neo nazisme.
- [^] # Re: Serieux?
  
  Posté par Antoine le 11 mai 2013 à 20:30. Évalué à 4.
  
  Que ca soit Eclipse/VisualStudio/IntelliJ/Xcode/autre ou emacs/vi avec 12000 plugins finis a la pisse, ya serieusement quelqu'un qui code encore uniquement avec un simple editeur de texte de nos jours?
  
  Je ne sais pas trop ce que veut dire coder sérieusement (je suis probablement un guignol), mais je code quotidiennement avec Kate. Après, on peut prétendre que Kate est un début d'IDE, mais je m'en sers comme "pur" éditeur de texte.
  - [^] # Re: Serieux?
    
    Posté par kadalka le 11 mai 2013 à 20:35. Évalué à -9.
    
    ya serieusement quelqu'un qui code encore uniquement avec un simple editeur de texte de nos jours?
    
    Je ne pense pas que quelqu'un code uniquement avec Kate.
    Mais je reconnais que dans la majorité écrasante des cas je n'utilise pas la complétion…
    Donc à la limite je pourrais vous donner raison…
    
    Mais c'est difficile de faire sans IDE de nos jours, notamment pour les gros projets critiques.
- [^] # Re: Serieux?
  
  Posté par fearan le 11 mai 2013 à 20:50. Évalué à 2.
  
  Je crois qu'il ne considère pas emacs/vim comme des IDE; sinon je ne vois pas. Qui code avec ed ou nano/pico.
  
  Et puis dans emacs on peut programmer avec la puissance de l'effet papillon ;)
  
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  - [^] # Re: Serieux?
    
    Posté par ariasuni le 11 mai 2013 à 21:33. Évalué à 2.
    
    Faudrait quand même pas oublier le lien hypertexte vers la nimage.
    
    Écrit en Bépo selon l’orthographe de 1990
# Geany est un bon début

Posté par kadalka le 11 mai 2013 à 20:08. Évalué à -7.

J'utilise Geany, c'est ce que je recommande lorsqu'on débute.
D'ailleurs vous pouvez facilement le compiler avec très peu de dépendances…

Mais de mon point de vue personnel, ce n'est pas satisfaisant…
NetBeans me paraît être bien foutu ou codeblocks…
Eclipse est un peu usine à gaz donc il faut du matériel puissant.
Je préfère d'ailleurs des versions spécialisées d'Eclipse si je dois m'en servir.

Mais il m'arrive de taper du code avec Kwrite [Bash, perl, python, C, etc.].
(oui un crime de lèse majesté)

Au quotidien, l'intérêt est de pouvoir faire de l'autocompletion rapidement.
Vous pouvez aussi voir les fonctions/objets que vous avez créés, et les plus aboutis gèrent l'UML (graphes).
# IDE

Posté par Physche le 11 mai 2013 à 20:59. Évalué à 6.

Personnellement, j'utilise un IDE qui s'appelle « Unix ». Il y a tout le nécessaire dont j'ai besoin pour programmer efficacement : compilateurs, éditeurs de texte, manuels, outils de recherche et de refactorisation du code…
- [^] # Re: IDE
  
  Posté par navaati le 11 mai 2013 à 21:39. Évalué à 5.
  
  C'est quoi tes outils de refactorisation de code ?
  - [^] # Re: IDE
    
    Posté par lendemain le 11 mai 2013 à 23:12. Évalué à 5.
    
    sed
    
    Ok je sors.
  - [^] # Re: IDE
    
    Posté par Dring le 11 mai 2013 à 23:21. Évalué à 1.
    
    grep et awk j'imagine…
    - [^] # Re: IDE
      
      Posté par ariasuni le 11 mai 2013 à 23:43. Évalué à 2.
      
      ~~grep~~ ~~ack~~ ag et awk j'imagine…
      
      Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: IDE
    
    Posté par fearan le 12 mai 2013 à 10:31. Évalué à 2.
    
    pas dur! Emacs + cedet (ou cscope), puis macro (next-tag -> replace)
    
    Compiler, regarder les erreurs de compil en priant le grand créateur que les foirrages provoquent effectivement des erreurs de compil ;)
    
    Sinon y a kdevelop4.
    
    Personnellement, étant beaucoup plus efficace avec emacs + pléthore de script bash (pour le C++ du moins), pour quand ça dépasse le truc donné en plaisanterie, genre sortir une classe interne non statique java dans un fichier séparé, mais j'ai pas trouvé de solution qui marche à tous les coups (genre utilisation de membre de la classe encapsulante…
    
    Il ne faut pas décorner les boeufs avant d'avoir semé le vent
    - [^] # Re: IDE
      
      Posté par groumly le 12 mai 2013 à 10:39. Évalué à 1. Dernière modification le 12 mai 2013 à 10:39.
      
      pas dur! Emacs + cedet (ou cscope), puis macro (next-tag -> replace)
      Compiler, regarder les erreurs de compil en priant le grand créateur que les foirrages provoquent effectivement des erreurs de compil ;)
      
      Et le jour ou tu dois renommer getId, t'y passes 2 jours, avec 250 errrurs de compilation, effectivement, "pas dur".
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# On peut toujours planter un clou avec un marteau...

Posté par calandoa le 12 mai 2013 à 23:02. Évalué à 7.

…mais avec un marteau électrique ça va plus vite et c'est moins fatiguant.

Et dans mon cas, j'utilise Kdevelop 3 sur Linux uniquement comme éditeurs de texte multi fichiers (ainsi que UltraEdit sur Windows, et un peu Scite aussi pour les projets de qqs fichiers). J'ai dégagé la plupart des plugins qui me bouffent des ressources pour rien et que je n'utilise jamais, et j'ai modifié qq parties à ma sauce. Et je n'utilise quasiment jamais de debugger. Et je me marre bien quand il y a des types qui prétendent que seule leur façon de développer est la bonne. Je ne connais pas les projets sur lesquels ils bossent, donc je ne me permettrai pas de juger leur méthodes, et de toutes façons je m'en cogne le bambou, mais apparemment leur fenêtre d'appréciation est aussi large que l'un de mes poils de cul.

Quand même, je reconnais que mes outils ont pleins de défaut, mais j'ai passé un temps incalculable à en chercher des mieux sans succès, et depuis je passe un temps incalculable à les customiser (et ça me gave).
# Il faut commencer par définir ce qu'est un IDE...

Posté par freem le 13 mai 2013 à 14:23. Évalué à 5.
Pour certains, vim n'en est pas uns, pour d'autres si. C'est le premier truc qui viens à l'esprit.

Si on prend l'acronyme et qu'on le déplie, ça donne Integrated Development Environment, ce qui signifie que tout dois déjà être intégré. Donc, si on prend vim, de base, non, ce n'est pas un IDE.
Sauf que ce n'est pas si simple, puisque les IDE actuels se basent très souvent sur des mécanismes de plug-in, poussant la technique au maximum. Donc, si on les prends "de base" aussi, sans leurs plug-in, ils ne sont pas non plus des IDE…
Bon, évidemment, vim viens sans une palanquée de ces ajouts, contrairement aux logiciels qui se réclament IDE. Pour moi, c'est ça le point à retenir pour distinguer un IDE d'un autre logiciel: le fait que tout soit intégré par l'installateur officiel (donc, pour moi, vim n'est pas un IDE).

Pour revenir à la question posée par le titre de l'article: non, un IDE n'est pas indispensable.
Si on mets ensemble nos outils, qu'on les configure pour qu'ils interagissent aisément, on obtiens un environnement tout à fait utilisable, et aussi efficace, voire plus, qu'un IDE ou l'intégration est faite par d'autres.
Pour autant, ce n'est pas un IDE puisque tout n'es pas intégré à l'origine.

Ceux qui n'utilisent pas (quand on a le choix j'entends) d'IDE pour coder ne se passent pas pour autant de manipuler plusieurs fichiers en même temps, ni de débogueur, et encore moins de système de build ou de contrôle de version!
On passe plus de temps au début à prendre en main chacun de nos outils séparément, là où un utilisateur d'EDI va pouvoir coder en moins de 5 minutes, donc de ce point de vue, c'est moins efficace.
Par contre, ce que j'ai constaté c'est un coût largement réduit au niveau des ressources à l'utilisation, et les logiciels séparés que l'on utilise ont tendance à être plus mûrs et moins exposés au bugs, ce qui fait qu'a l'utilisation on finit par être plus efficace avec nos solutions maison qu'avec un outil dédié à toutes ces tâches.

Je viens du monde windows, voire DOS: les 1ers EDI que j'ai utilisés ont été QBasic et TurboC, puis j'ai testé devcpp ou un truc du genre, qui était graphique mais bien plus pénible que turboC pour gérer un projet.
En BTS j'ai utilisé Visual Studio et KDevelop, puis j'ai découvert Code::Blocks et QtCreator, et récemment j'ai été contraint (y'a pas d'autres mots) à utiliser eclipse en reprenant des études. Celui-ci m'a tellement gonflé (lourd, lent, instable sur la machine que j'avais, pourtant pas une bas de gamme niveau proc et 4 bon Go de ram…) que j'ai cherché une alternative, trouvée avec l'outil netbeans.
Parallèlement, j'ai commencé à utiliser vim pour l'administration de ma Debian, et au fur et à mesure je me suis retrouvé à ne plus utiliser que vim.

Pourtant, vim à de sacrés soucis par rapport à un véritable IDE:
- auto-complétion de merde (il faut dire ce qui est) qui ralentit quand on programme (mais qui au moins ne se lance pas intempestivement, contrairement aux IDE que j'ai essayés)
- interaction avec les autres logiciels optionnelle (je pense surtout au copier/coller qui est une plaie, surtout avec les options de smart-indent activées)
- complexité du bouzin (3 tonnes de raccourcis clavier pas si simples que ça a changer, quoiqu'en diront les experts, par exemple)
- des ralentissements/blocages quand je code (le logiciel se bloque pendant une demi seconde on sais pas trop pourquoi. Problème qui n'apparaît pas sur la même machine avec un IDE plus lourd.)
- fonctionnalités qui semblent absentes par rapport aux outils basés sur Scintilla (je pense précisément à l'édition multiple, mais je rappelle que j'ai employé le mot "semblent". En plus cette édition multiple de scintilla est quand même limitée: le moindre retour chariot par exemple et il n'y a plus rien…)
- remplacement de chaînes de caractères extrêmement pénible (devoir échapper les caractères spéciaux parce que c'est regex par défaut, c'est lourd)
bref, toujours pas la panacée, mais vu qu'il s'agit avant tout d'un éditeur de texte, il offre des fonctionnalités et une simplicité d'usage (paradoxalement) que je n'ai jamais pu atteindre avec les EDI, surtout au niveau de la vitesse de déplacement dans le code source.

Combiné à CMake pour la gestion de projet, qui, contrairement aux IDE que j'ai testés, permets d'utiliser les masques de fichiers et évite donc d'avoir à modifier le projet dès qu'on crée un fichier, on arrive vraiment à une simplicité et un confort que je n'ai jamais atteins avec un outil intégré.

Pour en revenir à vim, un certain nombre des défauts cités dans les commentaires précédents, et que je confirme (auto-complétion) ne sont pas si gênants que ça, ou plutôt ne le sont plus pour moi, parce qu'en m'apercevant de ce défaut, ma façon de programmer s'est adaptée plus ou moins naturellement, par exemple mes classes sont devenues beaucoup moins entremêlées (vu que c'est moins simple de compléter un nom d'un autre fichier, évitons de créer des dépendances si on peut s'en passer), les noms des méthodes plus explicites, des méthodes mieux documentées…
Bref, j'ai retrouvé une grande part de mon confort en améliorant ma façon de faire les choses (je ne dis pas que c'est valable pour tout le monde hein, mais je codais vraiment comme un porc avant) et je fais les choses de façon plus atomiques. Enfin, ça, c'est peut-être dû aussi à git :)
J'ai compensé le manque de débogueur intégré (de toute façon, les débogueurs en IHM sous linux sont à des années lumières de ceux dispo sous windows niveau confort d'utilisation. En tout cas, je n'ai jamais vu quoique ce soit qui approche ollydbg… ) par le fait de toujours vérifier les valeurs de retour des fonctions que j'appelle si elles héritent de la méthode C, et dans mon propre code, je lance une exception si les pré-conditions ne sont pas respectée, avec un message d'erreur unique qui décrit la violation en question, de sorte que si un problème arrive, je sais de quoi il s'agit… sauf en cas de sigsegv.
Pour les outils de refactoring, je suis resté au bête chercher/remplacer, mais vu que je m'arrange pour ne pas emmêler mes dépendances (sur les bons conseils de cccc) il n'y a pas besoin de fouiller dans 3000 fichiers.

Après, pour l'auto-complétion… sincèrement, je n'ai pas encore vu le moindre outil qui soit capable de gérer l'auto-complétion du C++ correctement, alors je préfère ne pas trop m'y fier. Une bonne vieille documentation de référence sur une fenêtre est tout aussi bien. Et pour l'aspect de panneaux si cher aux IDE, bah j'utilise un tiling window manager, donc je l'ai de toute façon.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.