IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Qui pratique la programmation spontanée ?


Sujet :

Débats sur le développement - Le Best Of

  1. #381
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 900
    Points
    17 900
    Billets dans le blog
    2
    Par défaut
    ben....

    voilà....
    Images attachées Images attachées  
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  2. #382
    Membre éclairé
    Avatar de edfed
    Profil pro
    être humain
    Inscrit en
    décembre 2007
    Messages
    476
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : être humain

    Informations forums :
    Inscription : décembre 2007
    Messages : 476
    Points : 687
    Points
    687
    Billets dans le blog
    1
    Par défaut
    c'est pas faux

    sinon, pourquoi ne pas batir un monument enorme digne des egyptiens ou des mayas, à la gloire de l'electronique, de l'informatique et des sciences, tout en pierre, avec de belles gravures sur pierre pour stocker les données les plus importantes, telles que la structure d'un transistor, le schemas de principe d'un µP, des codes sources en asm, les memes en C, et voire, des données binaires, tout ça gravé dans la roche...
    ça donnerais du boulot à pas mal de gens, ça serait vachement beau comme monument, et en plus, ça fait longtemps qu'on en fait plus, ce qui est dommage.


    et si possible, une machine de "je sais plus qui", le processeur mecanique, en pierre egalement..

    la pierre, ça dure longtemps. tres longtemps.

  3. #383
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par edfed Voir le message
    [...]sinon, pourquoi ne pas batir un monument enorme digne des egyptiens ou des mayas, à la gloire de l'electronique, de l'informatique et des sciences, tout en pierre, [...]
    Il n'y aurait pas assez de pierre pour ton projet

  4. #384
    Membre éclairé
    Avatar de edfed
    Profil pro
    être humain
    Inscrit en
    décembre 2007
    Messages
    476
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : être humain

    Informations forums :
    Inscription : décembre 2007
    Messages : 476
    Points : 687
    Points
    687
    Billets dans le blog
    1
    Par défaut
    bien sur que si.
    il suffit d'ecrire le minimum vital.
    perso, je m'en fiche totalement de l'implementation du java, ou des differentes versions d'un meme programme.

    le minimum vital, c'est ce qu'il faut pour pouvoir refaire l'informatique de zero sans avoir à refaire toutes les erreurs du passé.

    le schema d'un µP ne devrai pas etre plus grand qu'une dalle de 5 metres * 5 metres si on utilise des symboles deja definis sur d'autres dales.

    si on fait le schema à base de transistors, on risque d'avoir de gros problemes.

    pour ce qui est des implementations C et asm, là aussi, on a pas besoin de tout detailler, le minimum vital, c'est ce qui sert de base à la comprehension, les details sont inutiles.
    http://www.famille-rigotmasle.info/I...e%20marbre.JPG
    les tailleurs de pierres s'y connaissent bien pour mettre le maximum de données sur un simple bout de caillou. (petit clin d'oeil à Yansé, futur tailleur de pierre professionnel)
    http://www.ankhonline.com/egypt_pierre_palerme.jpg
    là, on voit bien la compression des données...un truc comme ça sur des disaines de metres de mur peu facilement contenir une librairie complete en brainfuck

    pour ce qui est de la programmation spontanée, je pense que c'est un abus de language.
    meme si on code avec de la doc devant les yeux, c'est surtout avec la memoire du cerveau et l'imagination qu'on travaille.
    donc, meme un programmeur qui code devant des papiers pleins de details techniques pratique la programmation spontanée, car quand il code, il se focalise surtout sur les lignes de code devant lui.

  5. #385
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par edfed Voir le message
    bien sur que si.
    il suffit d'ecrire le minimum vital.
    perso, je m'en fiche totalement de l'implementation du java, ou des differentes versions d'un meme programme.

    le minimum vital, c'est ce qu'il faut pour pouvoir refaire l'informatique de zero sans avoir à refaire toutes les erreurs du passé.

    le schema d'un µP ne devrai pas etre plus grand qu'une dalle de 5 metres * 5 metres si on utilise des symboles deja definis sur d'autres dales.

    si on fait le schema à base de transistors, on risque d'avoir de gros problemes.

    pour ce qui est des implementations C et asm, là aussi, on a pas besoin de tout detailler, le minimum vital, c'est ce qui sert de base à la comprehension, les details sont inutiles.[...]
    Je crois que tu ne te rends pas compte de la problématique
    Bien sûr qu'il y aurait assez de pierre... je parlais du travail colossal et impossible que cela représentes.

    Déjà dans la décision de ce qu'on garde. Tu te fous peut être du Java, mais tu proposes de mettre le C... Pourtant le C n'a rien de particulier. Choisir Fortran serait plus logique; Lisp pour un autre paradigme; Smalltalk puis Prolog ? Mais oublions le problème de décider ce qui mérite ou ce qui ne mérite pas d'être gardé (et je suppose que le C et l'asm sauterait bien vite si on ne regarde que le nécessaire). Te rends tu compte de la longueur pour décrire les specs du C ? Puis il faut parler des résultats théoriques ? Combien de livres, combien d'articles de recherche sont importants ? Ne crois pas que seul le résultat compte. S'il y a bien une chose qu'on apprend en recherche c'est que le chemin est quasiment plus important que le résultat.

    Bien sûr on pourrait réduire au minimum : les maths. Mais même là, le travail est titanesque. Il y a eu plus de résultats scientifiques en 50 ans (1950 à 2000) qu'il n'y en a eu dans le reste de l'histoire de l'humanité. Je doute que tu ne connaisses les résultats de recherche de l'informatique. Me trompes je ? Que choisir ?

    Finalement, Brainfuck nécessite bien plus d'espace que n'importe quel autre langage. Très mauvais choix.

    Mais c'est vrai que ce serait mieux si on espère garder quelque chose plus de 1000 ans.

  6. #386
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par edfed Voir le message
    [...]meme si on code avec de la doc devant les yeux, c'est surtout avec la memoire du cerveau et l'imagination qu'on travaille.[...]
    Humm je ne t'engagerais pas si tu codes avec ton imagination.
    Pour le reste je trouve que tes phrases ne veulent pas dire grand chose « coder avec la mémoire » « meme un programmeur qui code devant des papiers pleins de details techniques pratique la programmation spontanée, car quand il code, il se focalise surtout sur les lignes de code devant lui. »
    Qu'est ce que se focaliser sur « les lignes devant soi » ? en quoi « est-ce spontané » ? ou selon tes propres termes « imaginatifs » ?

  7. #387
    Membre régulier
    Inscrit en
    décembre 2007
    Messages
    46
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 46
    Points : 85
    Points
    85
    Par défaut
    Citation Envoyé par Garulfo Voir le message
    Finalement, Brainfuck nécessite bien plus d'espace que n'importe quel autre langage. Très mauvais choix.
    non, le brainfuck est un excellent choix. Tu imagines toute la génération post-apocalypse d'informaticiens qui pèteront les plombs à essayer de décoder les specs (non documentés, évidement) codés en brainfuck? on dirait presque un gag de Dilbert

  8. #388
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 754
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 754
    Points : 31 705
    Points
    31 705
    Par défaut
    ...tout ça pour dire que la doc, c'est bien gentil, mais que le CODE, lui a tendance à rester(je refonds actuellement un code non commenté qui a 25 ans d'âge, c'est l'horreur).

    Donc la doc, oui, parceque c'est reglementaire, mais l'objectif doit quand même être de faire en sorte que le code se suffise à lui-même, non(je parle dans une perpective de reverse engineering)?
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #389
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    [...]
    Donc la doc, oui, parceque c'est reglementaire, mais l'objectif doit quand même être de faire en sorte que le code se suffise à lui-même, non(je parle dans une perpective de reverse engineering)?
    Non plus ! L'utilisateur final ne va pas aller lire dans le code pour savoir comment ça fonctionne. La documentation utilisateur doit être commencée dès le départ durant l'analyse des besoins, par but de validation des besoins.

    Autre chose, faire un document avant + de la documentation interne permet d'éviter de documenter uniquement ce que tu as écris (paraphrasage). Il faut aussi documenter le suivi des besoins (origine, importance, composantes qui s'en occupe, comment est-ce testé). Ainsi toute modification subséquente peut se voir valider en tenant compte de l'ensemble des besoins.

    Le code ne peut se suffire à lui-même car il ne dit que ce que tu fais. Et tu as besoin de savoir ce que tu voulais faire. S'il n'existait pas de maintenance (je rappelle que c'est plus de 70% du coût d'un logiciel – voir les recherches de Boehm) alors on ne se préoccuperait pas de la documentation (hors celle de l'utilisateur). Mieux, beaucoup des raisons existentielles de choix de conception n'aurait plus lieu d'exister puisqu'une grande partie d'entre eux sont orientés pour simplifier la maintenance (grosso modo: plus d'indirection, moins de complexité, meilleure maintenance – moins d'indirection, plus de complexité, maintenance plus ardue, meilleure performance)

  10. #390
    Membre régulier
    Inscrit en
    décembre 2007
    Messages
    46
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 46
    Points : 85
    Points
    85
    Par défaut
    Citation Envoyé par Garulfo Voir le message
    (grosso modo: plus d'indirection, moins de complexité, meilleure maintenance – moins d'indirection, plus de complexité, maintenance plus ardue, meilleure performance)
    certains ne retiennent que ce dernier point(en gras).

  11. #391
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 754
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 754
    Points : 31 705
    Points
    31 705
    Par défaut
    Citation Envoyé par Garulfo Voir le message
    Non plus ! L'utilisateur final ne va pas aller lire dans le code pour savoir comment ça fonctionne. La documentation utilisateur doit être commencée dès le départ durant l'analyse des besoins, par but de validation des besoins.

    (.../...)
    Je n'ai pas dit que c'était inutile. J'ai dit qu'il fallait prévoir le moment ou ça allait être perdu.

    Après, oui, quand j'appelle le module de gestion de date pour calculer le nombre de jour ouvrés entre la date système et la fin de l'année, je suis heureux d'avoir une doc utilisateur qui me dise qu'il me faut utiliser la fonction 44B avec çi et ça en paramètres. Je suppose que c'est ça que tu appelles la doc utilisateur, et bien sur il faut se la farcir.

    ce que je dis, c'est que dans une grosse organisation, sur des élements qui durent longtemps, la doc est parfois introuvable. D'ou l'utilité de rendre le code un maximum lisible - et pouvant se passer de doc, même si la doc existe quand même.

    Dans le cas que je cite, ça veut dire mettre en commentaire une liste complète des types d'appel au module généralisé. C'est rapide, pas cher, et ça permet de s'en sortir en cas de panne de doc(j'en ai vécu plus d'une).


    ...par contre, en te relisant, je me suis aperçu que je ne savais pas ce que "indirection" signifiait...
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  12. #392
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Je n'ai pas dit que c'était inutile. J'ai dit qu'il fallait prévoir le moment ou ça allait être perdu.

    Après, oui, quand j'appelle le module de gestion de date pour calculer le nombre de jour ouvrés entre la date système et la fin de l'année, je suis heureux d'avoir une doc utilisateur qui me dise qu'il me faut utiliser la fonction 44B avec çi et ça en paramètres. Je suppose que c'est ça que tu appelles la doc utilisateur, et bien sur il faut se la farcir.
    Ça c'est la doc technique. La doc utilisateur c'est pour l'utilisateur finale. Elle fait partie normalement des livrables et doit être préparée dès l'analyse des besoins.

    Citation Envoyé par el_slapper Voir le message
    ce que je dis, c'est que dans une grosse organisation, sur des élements qui durent longtemps, la doc est parfois introuvable. D'ou l'utilité de rendre le code un maximum lisible - et pouvant se passer de doc, même si la doc existe quand même.[...]
    Dis comme ça je suis d'accord.

    Citation Envoyé par el_slapper Voir le message
    ...par contre, en te relisant, je me suis aperçu que je ne savais pas ce que "indirection" signifiait...
    Si tu fais presque que de l'assembleur, c'est clair que tu n'utilises pas beaucoup d'indirection. Grosso modo, une indirection c'est le rajout d'un appel de fonction ou une méthode au lieu d'appeler directement le calcul. Ainsi les getter/setter sont une forme d'indirection. Mais sinon dans un calcul c'est de reléguer une partie des calculs dans une sous-fonction.

  13. #393
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 754
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 754
    Points : 31 705
    Points
    31 705
    Par défaut
    Citation Envoyé par Garulfo Voir le message
    Ça c'est la doc technique. La doc utilisateur c'est pour l'utilisateur finale. Elle fait partie normalement des livrables et doit être préparée dès l'analyse des besoins.
    mmmh, d'accord. Sauf que pour le coup, si effectivement ça fait partie du travail de l'équipe, je ne suis pas sur que ça soit de la responsabilité du programmeur. J'ai toujours vu faire ça par la maîtrise d'ouvrage.

    Citation Envoyé par Garulfo Voir le message
    Si tu fais presque que de l'assembleur, c'est clair que tu n'utilises pas beaucoup d'indirection. Grosso modo, une indirection c'est le rajout d'un appel de fonction ou une méthode au lieu d'appeler directement le calcul. Ainsi les getter/setter sont une forme d'indirection. Mais sinon dans un calcul c'est de reléguer une partie des calculs dans une sous-fonction.
    Non, moi, c'est Cobol et Visual Basic(ou je me suis mis à l'objet récemment, et, comme tu le dis, c'est mégapratique, mais ça bouffe du CPU).

    Dans l'absolu, isoler des fonctions(si j'ai ben compris ta définition de l'indirection), c'est un plus pour la maintenance(là, je me bouffe 6000 lignes de COBOL avec que des Go To, et juste une ou deux fonctions isolées par des perform, à refondre. l'angoisse; quand je parlais d'assembleur, c'est juste au niveau des méthodes de programmation - c'est infâme). Un GROS plus.

    Sauf que au début de ma carrière, j'avais tendance à en faire trop dans cette direction. Le mieux est l'ennemi du bien. Quand tu as 50 encapsulages pour une fonction simple, le programme(ou la fonction, ou la procédure, ou l'objet) appelant est très maintenable; par contre, la fonction décrite devient illisible.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  14. #394
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    [...]
    Dans l'absolu, isoler des fonctions(si j'ai ben compris ta définition de l'indirection), c'est un plus pour la maintenance(là, je me bouffe 6000 lignes de COBOL avec que des Go To, et juste une ou deux fonctions isolées par des perform, à refondre. l'angoisse; quand je parlais d'assembleur, c'est juste au niveau des méthodes de programmation - c'est infâme). Un GROS plus.

    Sauf que au début de ma carrière, j'avais tendance à en faire trop dans cette direction. Le mieux est l'ennemi du bien. Quand tu as 50 encapsulages pour une fonction simple, le programme(ou la fonction, ou la procédure, ou l'objet) appelant est très maintenable; par contre, la fonction décrite devient illisible.
    Effectivement trop d'indirections ça pourrait être néfaste. Mais crois moi: on corrige facilement l'habitude de mettre trop d'indirection. Que ce soit en la changeant ou à l'aide de la technologie (l'instruction inline travaille pour nous dans certains cas ). Par contre, il est encore trop classique de voir des développeurs qui ne font pas assez d'indirections, ce qui entraîne des coût important par la suite. Certes on peut aussi refactoriser (le terme est très parlant quand on comprend ce qu'est une factorisation en math) mais c'est plus difficile que de supprimer des indirections.

  15. #395
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 900
    Points
    17 900
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Garulfo Voir le message
    Effectivement trop d'indirections ça pourrait être néfaste. Mais crois moi: on corrige facilement l'habitude de mettre trop d'indirection. Que ce soit en la changeant ou à l'aide de la technologie (l'instruction inline travaille pour nous dans certains cas ). Par contre, il est encore trop classique de voir des développeurs qui ne font pas assez d'indirections, ce qui entraîne des coût important par la suite. Certes on peut aussi refactoriser (le terme est très parlant quand on comprend ce qu'est une factorisation en math) mais c'est plus difficile que de supprimer des indirections.
    trop de tout tue tout....

    Je suis en ce moment sur un projet tres gros (et d'une duree de vie > 30 ans).

    La premiere version etait en Fortran, puis a ete traduite en C au debut des annees 90, puis est en train (par "inexperience" ou "tendance aux penchants marketing" de la part des grands manitous, et parce que les jeunes n'ont appris que le C++) d'etre traduite en C++.

    La traduction vers C s'est faite dans ll'esprit Objet, mais visiblement avec des gens qui ont ete beaucoup trop dans le decoupage...

    Resultat : c'est aussi illisible et diffcile que si tout etait dans un seul module....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  16. #396
    Membre régulier
    Inscrit en
    décembre 2007
    Messages
    46
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 46
    Points : 85
    Points
    85
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    trop de tout tue tout....

    Je suis en ce moment sur un projet tres gros (et d'une duree de vie > 30 ans).

    La premiere version etait en Fortran, puis a ete traduite en C au debut des annees 90, puis est en train (par "inexperience" ou "tendance aux penchants marketing" de la part des grands manitous, et parce que les jeunes n'ont appris que le C++) d'etre traduite en C++.

    La traduction vers C s'est faite dans ll'esprit Objet, mais visiblement avec des gens qui ont ete beaucoup trop dans le decoupage...

    Resultat : c'est aussi illisible et diffcile que si tout etait dans un seul module....
    C'était une faute. on ne code pas avec un esprit objet dans un language procedural. Ils auraient du attendre C++ ou un langage purement objet pour ça.

  17. #397
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 900
    Points
    17 900
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par gokud-o-matic Voir le message
    C'était une faute. on ne code pas avec un esprit objet dans un language procedural. Ils auraient du attendre C++ ou un langage purement objet pour ça.
    non du tout..

    c'étaiit très bien (je ne reviendrais pas ici sur le débat qu'on peut très bien faire de l'OO dans des langages non Objets)..

    Ils auraient fait la même chose en C++ ou n'importe quoi : ils ont simplement trop poussé la logique de cacher et de classes etc etc..
    (exemple : 6 modules pour envoyer des messages, chacun correspondant à une "classe" (objet général non typé, objet particulier 1, etc..) . Résultat : 6 messages différents (presque) pour faire une seule action...et 6 modules à traverser pour avoir enfin la réception )

    Et ça peut arriver à n'importe quel type de développement. C'est ce que je disais, ainsi que Garulfo...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  18. #398
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    trop de tout tue tout.... [..]
    Je suis complètement d'accord et je n'ai pas dit le contraire.

    J'ai dit que la plupart du temps, il est plus aisé pour quelqu'un qui met trop d'indirections de corriger son habitude, que pour quelqu'un qui n'en met pas assez de le faire.

    Mais il faut savoir doser.

  19. #399
    Membre régulier
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    82
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : décembre 2007
    Messages : 82
    Points : 89
    Points
    89
    Par défaut
    Sujet passionnant, mais il est déjà demain !
    En tout cas "doloop" je veux bien travailler avec vous.

  20. #400
    Membre chevronné Avatar de LooserBoy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2005
    Messages
    1 085
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2005
    Messages : 1 085
    Points : 1 976
    Points
    1 976
    Par défaut
    A la base, je ne suis pas un programmeur spontanné. Malheureusement, j'ai été obligé de m'adapter à cette technique de programmation par la force des choses.
    Peu (voir très peu) de temps pour développer, aucune perspective d'évolution de l'appli à court ou moyen terme, une multitude de développements totalement "custom" sans possibilité de capitaliser sur les developpements futurs rendent cette technique de programmation envisageable au même titre qu'un forgeron ne va pas documenter chaque outil qu'il va fabriquer même si chacun est unique.

    A titre d'exemple, qui est en mesure de développer un mini WMS (système de gestion d'entrepot) avec gestion des entrées/sorties, alertes reapprovisionnement, preparation de commande et reporting des activités sur le mois/l'année en seulement 1.5 mois calendaire entre la commande et la livraison du développement (non obstant 4-5 developpements en parallèles) sans utiliser de technique de ce genre? C'est impossible.
    Je ne dis pas que c'est une bonne solution, je dis seulement que c'est une solution qui a fait ses preuves.

    Je crois qu'on l'apelle aussi "l'Extrem Programming"...

    A la longue, on s'y habitue et même on peut "se spécialiser" dans cette facon de programmer. A tel point, qu'en regardant n'importe quelles sources (de quelqu'un d'autre ou de moi), en très peu de temps, je trace sans grosses difficultés les problèmes qui peuvent se poser. Les seules fois où j'ai pesté sur les sources de quelqu'un, il s'agisait de sources d'un jeune développeur (exp < 2ans). Je travaille désormais assez souvent avec des developpeurs qui ont sensiblement le même niveau d'expérience que moi et cela se passe très bien.
    Vu sur un paquet de cigarettes: "Fumer peut entrainer une mort lente et douloureuse"
    - Vivre aussi... Ce n'est pas forcément moins douloureux et c'est même beaucoup plus lent...

Discussions similaires

  1. Logiciel qui permet de programmer en Fortran ?
    Par lesvacances dans le forum Fortran
    Réponses: 2
    Dernier message: 05/11/2007, 21h53
  2. Tutorial bonne pratique du programmation avec JAVA
    Par menzlitsh dans le forum Langage
    Réponses: 10
    Dernier message: 02/07/2007, 11h56
  3. Script Shell qui lance un programme sur un ordi distant avec SSH
    Par bilibou dans le forum Shell et commandes GNU
    Réponses: 5
    Dernier message: 02/06/2007, 11h18
  4. Erreur qui bloque mon programme
    Par bugland dans le forum Langage
    Réponses: 6
    Dernier message: 21/12/2006, 22h32
  5. Réponses: 19
    Dernier message: 26/12/2005, 01h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo