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

  1. #21
    Expert éminent sénior
    Citation Envoyé par Luckyluke34 Voir le message
    Moi j'aurais mis "plateformes/runtimes plus supportés" et pas "langages plus supportés". Dire qu'un langage n'est plus supporté n'a pas grand sens.

    ../..

    Tous ces mots ont un sens, ce n'est pas pour qu'on les utilise à tort et à travers.
    Tout à fait...

    Et je pense que, si j'étais méchant () je dirais "bien fait !!" par rapport au constat du PO..

    Car dans le fond, on nous fait miroiter depuis presque 20 ans que c'est super, les biblios, les frameworks, etc etc... Les "nouveaux devs" ne jurent que par ça, tout comme leurs chefs...

    Tant pis pour eux si ils "oublient" que les versions changent rapidement, et qu'ils se basent sur ces "features"...


    En fait, comme tu le dis, du point de vue des langages les choses évoluent beaucoup plus lentement, sans parler de certains acceptant les délais mis en place lors des "anciens" langages (5 ans pour avertir d'une obsolescence prévue- 10 ans pour la mettre en place) comme Fortran, C, etc etc..


    La règle de base que j'ai toujours eue est : ne JAMAIS utiliser les "features" spéciales , sauf pour les "flags/drapeaux" de compil' ... Ne JAMAIS dépendre d'une bibliothèque externe sauf par un module facilement auto-débranchable et auto-détectable... Les langages ont normalement toutes les fonctionalités dont on a besoin pour faire tout ce qu'on veut en programmation....

    Et si on ne sait pas s'en servir, on n'est pas un "programmeur", donc - à mon avis - on n'a rien à faire dans une équipe de fabrication d'un logiciel...



    Citation Envoyé par clementmarcotte Voir le message
    Les programmeurs d'origine pensaient que leurs créations seraient tout simplement remplacées quelques années plus tard... Les remplacements ne se sont jamais produits. Les fonds disponibles allaient à la création de nouvelles applications et non au remplacement des applications existantes. On dirait que les leçons du passé sont trop vite oubliées
    C'est surtout que c'est plutôt l'inverse : on faisait des programmes pour qu'ils durent.... Les langages utilisés - comme celui que tu cites - est toujours là 40 ans plus tard... Comme mes programmes en Fortran ou C...

    En ce qui concerne le "bug de l'an 2000", c'est surtout qu'on n'y avait pas pensé... et qu'on n'avait pas les moyens techniques :

    • d'une part 20 ans c'est long et personne en 1980 ne pensait que dans le monde entier tout serait connecté.... et que donc une "faille" pourrait créer un chaos à l'échelle planétaire.... (ce qui d'ailleurs n'a pas été le cas et a été une mine d'or pour toutes les SSII....)
    • Mais d'autre part, la mémoire était "ridicule" par rapport à aujourd'hui .. J'ai fait des programmes de traitement d'images en 1986 avec 64K de mémoire "programme" et 64K de "data"... 3 lignes d'une image 512x512 8-bits, OU uniquement le "switch" des fonctionalités (un switch contenant juste "addition, soustraction, multiplication, zoom, déplacement, et sauvegarde, avec l'appel des fonctions" était tout ce que pouvait prendre la mémoire) .. Donc on fait ce qu'on peut avec les moyens qu'on a ...


      Exemple d'un programme en 1984-86 sur PDP 11/23 :

      Code FORTRAN :Sélectionner tout -Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      program toto()
      integer*8 icode
       
      READ (5, *) icode
       
      switch (icode) {
       case lire : 
           call readim()
           break
       case ecrire : 
           call writeim()
           break
       case add: 
           call add()
           break
       case sub : 
           call sub()
           break
       case mul : 
           call mul()
           break
       case zoom : 
           call zoom()
           break
       case shift : 
           call shift()
           break
      }
      END

      (ou à peu près, je fais de mémoire... )





    Citation Envoyé par clementmarcotte Voir le message
    Et actuellement, n'importe quel gestionnaire moindrement au courant de l'histoire du système Phénix doit avoir une peu bleue de tout remplacement radical d'un programme qui fonctionne même s'il est antédiluvien et mal foutu, par un nouveau programme. Cela n'aidera en rien au remplacement des antiquités.
    Avec raison...

    Quand quelque chose marche, pourquoi le remplacer ???

    On proteste contre l'obsolescence programmée, mais les programmes non-obsolètes, pourquoi les changer si ce n'est parce que on ne trouve plus de programmeurs capables de comprendre/modifier ces programmes...

    J'ai vu des échecs monumentaux, et j'ai participé à ce que je soupçonne être des échecs monumentaux (les retards de la SNCF qui augmentent dans les dernières années par exemple...)... lors de ré-écritures... D'une part parce que la connaissance accumulée est loin d'être entièrement documentée, et il faudrait aller la rechercher profondément dans le code, en comprenant absolument tout et en reconstruisant tous les arbres et le flux, mais aussi parce que fondamentalement tout nouveau code génère son lot de bugs... par définition....



    (un bon lien que j'ai déjà donné à ce sujet est ici : Rewrites Considered Harmful?, et, bien qu'écrit en 2004, il ne vieillit pas )



    PS: j'ai voté "quand ça arrive en fin de vie"
    "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. #22
    Expert éminent sénior
    Ce message n'a pas pu être affiché car il comporte des erreurs.
    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.

  3. #23
    Candidat au Club
    NON PERTINENT
    21 réponses: ce sondge n'est pas pertinent. 21 réponses ne peuvent refléter la réalité

  4. #24
    Expert éminent sénior
    Citation Envoyé par souviron34 Voir le message
    Ne JAMAIS dépendre d'une bibliothèque externe sauf par un module facilement auto-débranchable et auto-détectable... Les langages ont normalement toutes les fonctionalités dont on a besoin pour faire tout ce qu'on veut en programmation....
    ehhh monsieurs Souviron34 et El_slapper je crois qu'il faudrait régler vos montres, on n'est plus il y a 20 ou 30 ans à faire des programmes en langage C avec la philosophie de Kerningan et Richie !
    Stricto sensu vous avez raison mais maintenant un projet informatique du fait de l'assemblage de technologies existantes ce que l'on appelle pompeusement "intégration logicielle" c'est du développement avec 50-70 % de dépendances et modules externes.
    Et que faire du code maintenant dans un projet d'entreprise ça se réduit plus à faire du paramétrage qu'à faire du code encore faudrait-il faire la nuance entre ces deux notions certes.
    D'ailleurs c'est pour ça que des géants comme IBM, Salesforces,Google commercialisent des systèmes d'API web sur le Cloud.
    Sans compter des trucs comme la Blockchain..
    Maintenant on est arrivé l'interconnectivité web via des API modulaires.
    Ce qui fait qu'une entreprise qui veut développer un projet informatique via une SSII ou non ,en fait va développer une partie très limitée du projet,tout le reste c'est des modules externes donc forcément payant
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  5. #25
    Expert éminent sénior
    Citation Envoyé par Mat.M Voir le message
    ehhh monsieurs Souviron34 et El_slapper je crois qu'il faudrait régler vos montres, on n'est plus il y a 20 ou 30 ans à faire des programmes en langage C avec la philosophie de Kerningan et Richie !
    Stricto sensu vous avez raison mais maintenant un projet informatique du fait de l'assemblage de technologies existantes ce que l'on appelle pompeusement "intégration logicielle" c'est du développement avec 50-70 % de dépendances et modules externes.
    ../..
    Ce qui fait qu'une entreprise qui veut développer un projet informatique via une SSII ou non ,en fait va développer une partie très limitée du projet,tout le reste c'est des modules externes donc forcément payant
    As-tu lu le post original ???????
    "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

  6. #26
    Expert éminent sénior
    Citation Envoyé par souviron34 Voir le message
    As-tu lu le post original ???????
    oui je l'ai lu ,errare humanum est perseverare diabolicum
    Citation Envoyé par souviron34 Voir le message

    Quand quelque chose marche, pourquoi le remplacer ???
    je l'ai écris un milliard de fois sur ce forum ; l'économie de marché donc le marché des hautes technologies et des gros éditeurs de logiciel forcent les choses à se renouveler donc effectivement par le biais de l'obsolescence.

    Ce qui leur permet de gagner de l'argent et de faire des montagnes de dollar$ .

    Bref le projet informatique que la moindre entreprise a mis avec tant de peine à finaliser, une fois bien finalisé et fonctionnel, les gros éditeurs ( suivez mon regard ) vont vous dire que le projet est technologiquement obsolète et qu'il faut passer à une nouvelle voie technologique ( comme le Cloud ) alors que l'entreprise n'en a absolument pas besoin..

    bref l'entreprise ou bien vous et moi vont devoir mettre la main à la poche pour de nouveaux investissements technologiques coûteux alors que oui ça tourne très bien et qu'il ne faut rien changer effectivement.

    De toute façon les gros éditeurs ils s'en fichent royalement si le projet informatique échoue, ils sont là pour vendre leurs produits.
    J'ai travaillé dans un paquet d'entreprises sur des projets logiciels notamment pour un éditeur de logiciel d'immobilier il faut acheter Ms-Office en même temps que le logiciel pour sortir des rapports
    Citation Envoyé par souviron34 Voir le message

    D'une part parce que la connaissance accumulée est loin d'être entièrement documentée
    d'un autre côté produire des tonnes de documentation est-ce bien utile ? La on est dans l'absolutisme bureaucratique qui consiste à décrire tout ce que l'on fait au lieu de produire des chose de manière concrète
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  7. #27
    Expert confirmé
    Citation Envoyé par el_slapper Voir le message
    La doc c'est de la merde. Seul le code fait foi.
    Citation Envoyé par Mat.M Voir le message
    d'un autre côté produire des tonnes de documentation est-ce bien utile ? La on est dans l'absolutisme bureaucratique qui consiste à décrire tout ce que l'on fait au lieu de produire des chose de manière concrète
    Attention, sans une documentation à jour, seuls les développeurs peuvent vraiment savoir comment fonctionne le logiciel.
    Or, quand des clients remontent des problèmes au centre d'assistance, moins le personnel du centre d'assistance connaît le fonctionnement du logiciel, plus il a tendance à relayer directement les problèmes aux développeurs, même les problèmes qui ne viennent pas de bogues du logiciel.
    Les développeurs perdent alors du temps à faire du travail du centre d'assistance "au lieu de produire des choses de manière concrète".

  8. #28
    Expert éminent sénior
    Citation Envoyé par Pyramidev Voir le message
    Attention, sans une documentation à jour, seuls les développeurs peuvent vraiment savoir comment fonctionne le logiciel.
    je n'ai jamais affirmé le contraire ; cependant il faut savoir mettre le curseur comme il faut, faut pas en faire des tonnes comme il ne faut pas en faire de manière insuffisante.
    Or faire trop de documentation c'est coûteux à mon sens ; cela va à l'encontre de l'intérêt de l'informatisation qui a pour but de simplifier les choses.
    Citation Envoyé par Pyramidev Voir le message
    Or, quand des clients remontent des problèmes au centre d'assistance, moins le personnel du centre d'assistance connaît le fonctionnement du logiciel, plus il a tendance à relayer directement les problèmes aux développeurs, même les problèmes qui ne viennent pas de bogues du logiciel.
    Les développeurs perdent alors du temps à faire du travail du centre d'assistance "au lieu de produire des choses de manière concrète".
    ça c'est toute la problèmatique d'un projet logiciel...souvent les fonctionnalités du logiciel sont insuffisantes ou mal définies, par manque de ressources humaines et financières.
    Cela rejoint quelque part ce qu'écrivent Souviron34 et El_slapper..
    Et puis avec le turn-over des équipes techniques notamment de développeurs ça n'arrange vraiment pas les choses.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  9. #29
    Expert éminent sénior
    Citation Envoyé par Mat.M Voir le message
    je n'ai jamais affirmé le contraire ; cependant il faut savoir mettre le curseur comme il faut, faut pas en faire des tonnes comme il ne faut pas en faire de manière insuffisante.
    Or faire trop de documentation c'est coûteux à mon sens ; cela va à l'encontre de l'intérêt de l'informatisation qui a pour but de simplifier les choses.
    Le truc aussi, c'est qu'indépendamment de la problématique technique(origine de ce fil) ou du manque de ressources(que tu évoques après), un logiciel, ça change assez vite au niveau des fonctionnalités. Donc maintenir une doc à jour, c'est extrêmement couteux, et généralement faux...sauf si la doc est juste un point d'entrée. Plus elle est précise, et plus vite elle est fausse. Trouver le juste milieu est souvent un casse-tête.

    Citation Envoyé par Mat.M Voir le message
    ça c'est toute la problèmatique d'un projet logiciel...souvent les fonctionnalités du logiciel sont insuffisantes ou mal définies, par manque de ressources humaines et financières.
    Cela rejoint quelque part ce qu'écrivent Souviron34 et El_slapper..
    Et puis avec le turn-over des équipes techniques notamment de développeurs ça n'arrange vraiment pas les choses.
    Et aussi par une vision projet : on a le projet d'ajouter des trucs, one ajoute des trucs, ça marche, on est contents..... Mais ça manque d'une vision globale de l'application. C'est la nouvelle marotte de Martin Fowler et de son ami Sriram Narayan. Narayan insiste en particulier sue le "you build it, you run it".

    Et Narayan insiste aussi sur un point rigolo : l'avantage du mode projet est que le "succès" pour les managers est facile à mesurer. Sur un produit en travail continu, il est plus délicat(même si pas impossible) de mettre en œuvre des KPI pertinents. D'ou la tendance des managers à se ruer sur le mode projet pour faire briller leur carrière.
    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.