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 :

Conception et réalisation de programmes hautes performances et/ou sûrs


Sujet :

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

  1. #141
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    ... n'est pas en Haskell, alors ? Ou mes compilos ? Ou mes outils de dév ?

    il faut quand même se rappeler que tous les outils touchant un peu de près à la "théorie des langages" sont reconnus par enormement de monde comme les "killer app" des langages fonctionnels... donc il y a sûrement moyen de faire quelque chose d'efficace (même si les vieux projets -- ie des projets ayant au moins 15 ans -- qui constituent l'essentiel du marché
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      0  0

  2. #142
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    @Mac LAK & alex_pi :

    Arrêtez, c'est stérile, prend de la bande passante, et devient fortement ennuyeux..

    Discutez-en par MP si vous voulez, mais là ça commence à devenir un troll velu, qui occupe maintenant les 3/4 de cette discussion, pour un argument sur un mini-point.....

    Et votre logorhée à tous les 2 est épuisante....



    .
    Citation Envoyé par alex_pi Voir le message
    le Nist (National Institute of Standards and Technology) dit qu'en fait, les bugs coûteraient 60 milliards de dollars à l'économie américaine chaque année (http://www.nist.gov/public_affairs/releases/n02-10.htm) Et c'était en 2002. Avec l'impact croissant des produits informatique, c'est sans doute bien plus maintenant.
    Voilà ce que les langages de haut niveau font beaucoup mieux que le C...


    tu voulais sans doute dire le contraire

    Car si je ne m'abuse, les produits informatiques depuis 2002 sont de plus en plus avec des langages de haut niveau à la mode... Si ils ont de plus en plus de bugs, c'est donc que ça n'améliore rien (ce que je me tue à dire depuis de nombreux threads)




    Citation Envoyé par jabbounet Voir le message
    Certains humains savent le faire a la main, mais c'est long, avec un risque d'erreur plus grand


    Ce qui arrive super souvent


    C'est plus rare de lui demander un truc correct,sinon y'aurai jamais de maintenance, et de correction de bug a chaque version d'un logiciel.

    mais bon je suis pessimiste par nature, et je suis parfois surpris quand un logiciel tombe en marche.

    "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
      0  0

  3. #143
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    tu voulais sans doute dire le contraire

    Car si je ne m'abuse, les produits informatiques depuis 2002 sont de plus en plus avec des langages de haut niveau à la mode... Si ils ont de plus en plus de bugs, c'est donc que ça n'améliore rien (ce que je me tue à dire depuis de nombreux threads)
    Quels sont les statistiques qui montrent qu'ils ont plus de bugs aujourd'hui ? En fait mon expérience de l'informatique personnelle serait plutôt qu'il y a aujourd'hui moins de bugs problématiques dans la plupart des logiciels que j'essaie qu'il y a une dizaine d'années...
    Par ailleurs, je ne penses pas que toi et AlexPi parliez des mêmes langages, parce que si tu crois que beaucoup des logiciels qui plantent sur ton bureau sont écris en OCaml, Haskell et tutti quanti, tu as un PC bien différent du mien.

    --
    Jedaï
      0  0

  4. #144
    alex_pi
    Invité(e)
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    C'est ça qui m'éclate, avec toi : tu crois qu'on se permet des "aliasing tordus" dans du code sûr, ou même dans du code dédié à la performance ???
    T'es le mec qui nous explique qu'une boucle foreach, c'est mal, parce qu'un autre thread peut être en train de modifier la structure, mais à part ça, t'alias pas...

    Citation Envoyé par Mac LAK Voir le message
    Quand au bug dans le pipeline : t'as réussi à comprendre que l'on n'utilise JAMAIS de composants qui n'ont pas une durée d'existence minimale, donc débarrassés de leurs pannes de jeunesse ?
    Ouais alors en fait, le "software pipeling", dont j'ai parlé plus d'une fois, ça n'a pas grand chose à voir avec un "pipeline", genre un tuyaux dans lequel on fait passer du pétrole hein... Donc rien à voir avec des "composants fiables"...
    Le software pipeling, c'est une optimisation des boucles qui consiste à les dérouler et à réaranger les instructions, en sachant que
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    z = z * t;
    y = y + 2;
    x = y +3;
    c'est plus efficace que
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    y = y + 2;
    x = y +3;
    z = z * t;
    Et vu que ça produit des modification très importante du code, il est particulièrement facile de se planter de d'oublier un corner-case moisi. Bref, historiquement, c'est là que sont les bugs dans les compilos (pas dans les foreach...) !

    Citation Envoyé par Mac LAK Voir le message
    Chez les gens que TU fréquentes, peut-être. Chez ceux que JE fréquente, le parallélisme et les notions sous-jacentes ne font plus "peur" depuis bien longtemps, en gros depuis que l'on a appris à éviter la plupart des pièges à cons classiques de la programmation parallèle.
    INTEL et Microsoft, disent que le parallélisme, c'est suffisamment complexe pour fonder un labo commun pour trouver des solutions (http://www.intel.com/pressroom/kits/upcrc/index.htm) et qui se fendent d'un communiqué de presse (http://www.intel.com/pressroom/kits/...ckgrounder.pdf ) où il expliquent entre autre que "Parallel programs have been harder to write than sequential ones" et que "Some of these models and languages may provide a better solution to the parallel programming problem than the above “standards”, all of which are modifications to conventional, non-parallel languages like C."



    Citation Envoyé par Mac LAK Voir le message
    Et tu me montres ton driver en Haskell ? Juste pour rire ?
    T'es pas monomaniaque, c'est ça qui est bien

    Allez, rien que pour toi :
    http://programatica.cs.pdx.edu/House/

    Citation Envoyé par Mac LAK Voir le message
    Ah ben zut, alors... Pourquoi est-ce que mon OS n'est pas en Haskell, alors ? Ou mes compilos ? Ou mes outils de dév ? Ou mes jeux favoris ?
    Pour l'OS, cf plus haut. Pour mes compilos, ils sont tous en caml, coq ou haskell. D'ailleurs esterel-industries ont fait valider OCaml par les autorités de certification aéronotique pour pouvoir écrire leur outils en OCaml. A croire qu'ils en avait ras le bol d'écrire des compilo en C

    Citation Envoyé par Mac LAK Voir le message
    J'sais pas, moi, je dois être crédule : on me propose un produit fabuleux, qui n'est pourtant pas vastement implanté tout partout, n'y aurait-il pas quelques anguilles sous roche ?
    Pourquoi autant de choses sont faites en C, en fortran, en COBOL ? Pour un certain nombre, parce que ce sont des bons choix, voir les seuls choix possible. Mais pour une immense majorité, parce qu'on a toujours fait comme ça. Les raisons qui l'imposaient ont disparus (oui, le Lisp des années 50 étaient 300 fois plus lent que le même algo en Fortran, mais les différences de perfs n'ont plus rien à voir, et les contraintes non plus), mais puisque le réflexe a été pris, ça continue.
    Et pour un décideur, c'est beaucoup moins dangereux. Si un chef décide d'utiliser un truc un peu différents pour un projet, et que le projet se casse la gueule pour des raisons complètement autre, il se fera décarrer la tête. Par contre, s'il a pris une solution "que tout le monde a toujours utilisé", et que le projet s'effondre à cause de ce choix, il pourra toujours dire "on a toujours fait comme ça", et donc ça se passera mieux.

    Citation Envoyé par Mac LAK Voir le message
    Là, je te parle du VOLUME de l'XML de façon générale... On ne va pas embarquer un fichier XML de 20
    [...]
    La même chose en XML ? Cela prendrait cinq à dix fois plus de place... Rien qu'en temps de chargement, on fait exploser le temps d'initialisation du système !!
    Mais pourquoi tu me parles de l'utilisation de l'XML dans ta vie trépidante ? Je te donne juste un exemple d'un truc en haut niveau qui va plus vite qu'un truc en bas niveau. On s'en fout de savoir si le truc que ça fait est adapté à ta petite problématique.

    Ah et pour l'embarqué, je te conseille une petite lecture : http://www.cea.fr/content/download/3...CEA_260906.pdf
    Les mecs du CEA (des guignols sans contact avec le monde réel je pense) y explique que le problème c'est que
    Néanmoins, les systèmes embarqués sont développés de manière artisanale au cas par cas. Ils restent donc difficiles et longs à développer, faute de méthodes de conception formalisées et ‘industrielles’. Résultats : les systèmes commercialisés aujourd’hui sont bridés en fonctionnalités et parfois en performances, malgré des temps et des coûts de développement élevés.
    et qu'il pense pouvoir, par l'apport d'outils adaptés (et plus haut niveau...):
    Ces outils et démarches méthodologiques garantissent pour les applications
    industrielles, une augmentation de la qualité et des performances des logiciels, tout en permettant une réduction des coûts et délais de développement de 50%.
    Mais bon, ça reste le CEA, ces choses là, ils y comprennent pas grand chose
      0  0

  5. #145
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Juin 2009
    Messages : 1 909
    Points : 3 284
    Points
    3 284
    Par défaut
    Fin tu me fais quand même bien marrer à toujours expliquer qu'il faut à tout pris "comprendre ce que fais la machine, être au plus près de la réalité, blahblah". C'est quand la dernière fois que tu as vérifié les équation quantique qui régissent les transistors ? Ou même plus simple, quand est ce que tu les as comprise...
    Ah et pour l'embarqué, je te conseille une petite lecture : http://www.cea.fr/content/download/3...CEA_260906.pdf
    Les mecs du CEA (des guignols sans contact avec le monde réel je pense) y explique que le problème c'est que
    la ils parlent du secteur automobile ou l'embarqué a un quinzaine d'années tout au plus, ils sont allé voire ce qu'il se faisait dans le férroviaire ou l'aéronautique, qui en font depuis bien plus longtemps?
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com
      0  0

  6. #146
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par jabbounet Voir le message
    la ils parlent du secteur automobile ou l'embarqué a un quinzaine d'années tout au plus, ils sont allé voire ce qu'il se faisait dans le férroviaire ou l'aéronautique, qui en font depuis bien plus longtemps?
    euh oui... y a des projets du CEA qui s'intéressent même à du code créé dans les années 70 et fonctionnant encore en production aujourd'hui
    après c'est probablement une autre équipe
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      0  0

  7. #147
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Evidemment, l'une des raisons pour lesquelles je soutiens le maintien de ce sujet c'est parce que j'ai l'impression que les arguments de MacLak ont vraiment été battus en brèche dans les derniers échanges (autrement dit on a avancé que ce soit dans un sens ou dans l'autre), mais comme je suis relativement partisan d'origine, je peux avoir laisser mes opinions colorer mon jugement.

    --
    Jedaï
      0  0

  8. #148
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    il faut quand même se rappeler que tous les outils touchant un peu de près à la "théorie des langages" sont reconnus par enormement de monde comme les "killer app" des langages fonctionnels... donc il y a sûrement moyen de faire quelque chose d'efficace (même si les vieux projets -- ie des projets ayant au moins 15 ans -- qui constituent l'essentiel du marché
    Sauf que... Ils ne se répandent pas. Quand une technologie ne "perce" pas, il y a toujours une raison derrière.


    Citation Envoyé par alex_pi Voir le message
    T'es le mec qui nous explique qu'une boucle foreach, c'est mal, parce qu'un autre thread peut être en train de modifier la structure, mais à part ça, t'alias pas...
    Pas d'aliasing si les domaines sont disjoints. C'est d'une évidence crasse.

    Citation Envoyé par alex_pi Voir le message
    Pour être honnête, je suis face à un dilemme ! D'un coté j'ai MacLAK <snip>
    De l'autre coté, j'ai INTEL et Microsoft <snip>
    Qui croire ???
    Si tu avais pris la peine de lire en profondeur, tu saurais qu'ils se concentrent :
    • Pour Intel, sur les problèmes d'accès concurrent au bus mémoire mémoire ou aux co-processeurs, tous "uniques" sur la puce multi-cœurs (entre autres). Bref, sur les problèmes hardware du parallélisme.
      Chose difficile, on ne peut pas prévoir l'activité des cœurs à l'avance pour tous les cas possibles.
    • Pour Microsoft, sur la généricité du parallélisme, c'est à dire sur la création de structures totalement génériques garantissant une utilisation correcte quels que soient les cas d'utilisation. Bref, sur des API dédiées au parallélisme.
      Chose difficile, on ne peut pas prévoir l'activité des processus/threads à l'avance pour tous les cas possibles.
    • Pour le Lak, sur de la programmation parallèle parfaitement spécifique et définie dans un cadre parfaitement connu à l'avance, le tout en s'appuyant sur une connaissance poussée des mécanismes sous-jacents.
      Chose facile, vu que l'on maîtrise tout de A à Z... A condition d'être un minimum doué pour ça, quand même, bien entendu.


    Citation Envoyé par alex_pi Voir le message
    Donc, d'un coté, tu nous dit "l'embarqué c'est la vie, y en a dans les voitures", et après, tu nous dit qu'en fait, l'embarqué dans les voiture, c'est pas de l'embarqué, c'est un pc. C'est chaud à suivre là :-\
    Et en plus, c'est faux
    L'ordinateur de bord avec son bel écran tactile est bien plus proche d'un TabletPC que d'un microcontrôleur comme celui qui gère l'ABS. Démontes-donc en un, si tu ne me crois pas, regarde donc les composants soudés dessus...

    Citation Envoyé par alex_pi Voir le message
    De même qu'on ne voit pas de C dans les avions. Tout va bien
    T'as très mal regardé... Et on trouve aussi de l'Ada.
    Et puis ce n'est pas comme si les équipements de test réel des avions/trains lui-même étaient tous écrits en C, hein...

    Faut pas confondre les validations des simulations et les validations du système opérationnel, ce sont deux types radicalement différents de bancs de test... Du haut niveau pour concevoir la théorie, OK, c'est plus rapide. La réalisation "réelle", ça reste du domaine du bas niveau.



    @Jedaï : Le problème qu'il se passe aussi, c'est que je suis malheureusement soumis à un devoir de réserve. J'essaie au maximum, par des analogies et des exemples (trop ?) précis, d'expliquer certains faits que je ne peux pas divulguer précisément dans leur ensemble.

    Ce ne sont nullement des secrets d'État ou des projets CD/SD, bien sûr, et ceux qui savent lire entre les lignes et extrapoler un minimum comprendront.

    Mais, et je le répète encore une fois, il est impossible pour un développeur "lambda", surtout sans expérience, de se rendre compte de l'importance énorme de l'embarqué et de l'informatique industrielle si l'on n'a pas un pied dedans. C'est un milieu fascinant, très exigeant et dans lequel le chômage est plus que réduit : il n'y a qu'à voir le mal que l'on a à embaucher des gens compétents... Sur 50 AT présentés, on n'en retiendra qu'une dizaine, et seuls un ou deux dans le lot seront finalement embauchés... Après souvent un an d'évaluation en "situation réelle".

    Libre à chacun après de faire ce qu'il veut, cela n'est pas mon problème. Je me contente d'expliquer un monde que 90% des visiteurs du forum ne soupçonnent même pas d'exister...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO
      0  0

  9. #149
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    Sauf que... Ils ne se répandent pas. Quand une technologie ne "perce" pas, il y a toujours une raison derrière.

    je l'ai donnée... il faut être aggrégé en maths minimum pour commencer à espérer s'en servir efficacement, ce qui limite beaucoup les utilisateurs potentiels

    Citation Envoyé par Jedai Voir le message
    Evidemment, l'une des raisons pour lesquelles je soutiens le maintien de ce sujet c'est parce que j'ai l'impression que les arguments de MacLak ont vraiment été battus en brèche dans les derniers échanges (autrement dit on a avancé que ce soit dans un sens ou dans l'autre), mais comme je suis relativement partisan d'origine, je peux avoir laisser mes opinions colorer mon jugement.

    perso, je ne suis pas de cet avis... selon moi, on a :
    • d'un côté MacLak, qui dit que certains domaines ont besoin d'un tout bas niveau, et qui expliquent les utilisations, etc ; mais qui reconnait que ce n'est pas toujours le cas, et qu'il ne faut pas utiliser un langage hors de son contexte "optimal"
    • de l'autré alex_pi, qui affirme que le tout bas niveau est TOUJOURS une absurdite, et qu'on fera toujours mieux en ne laissant qu'un coeur bas niveau et des modules très haut niveau, voire en tout très haut niveau mais avec passage automatisé par un langage bas niveau pour éviter les overheads de certains runtime trop haut niveau (des DSL haut niveau en gros )
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      0  0

  10. #150
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    je l'ai donnée... il faut être aggrégé en maths minimum pour commencer à espérer s'en servir efficacement, ce qui limite beaucoup les utilisateurs potentiels
    Donc, pas diffusables par rapport à beaucoup de langages impératifs, et même certains fonctionnels un peu moins "matheux" que les autres...

    Je sais que l'expression est vexante, mais cela reste alors des "jouets de laboratoire" : c'est intéressant, potentiellement révolutionnaire et tout et tout, mais c'est exactement la même chose pour moi que les annonces de téléportation d'un bit sur un mètre, ou d'un transistor réalisé avec quelques atomes, ou encore d'une porte logique totalement optique. C'est alléchant pour l'avenir, cela donne une idée ce qu'il sera peut-être possible d'avoir d'ici 5, 10, 20 ou 100 ans, mais cela reste quelque chose d'inapplicable dans la vie "réelle" d'aujourd'hui.

    Dans ce cas précis, je pense que cela donne d'excellentes pistes de recherche, en attendant que la technologie soit suffisamment évoluée pour permettre de faire tourner ce genre de trucs sur la machine du quidam moyen et non pas uniquement sur des "monstres", quand ce ne sont pas carrément des supercalculateurs.
    En attendant, le monde réel est là, et il faut bien continuer de le faire vivre avant de songer à le faire évoluer...

    Citation Envoyé par gorgonite Voir le message
    perso, je ne suis pas de cet avis... selon moi, on a :
    • d'un côté MacLak, qui dit que certains domaines ont besoin d'un tout bas niveau, et qui expliquent les utilisations, etc ; mais qui reconnait que ce n'est pas toujours le cas, et qu'il ne faut pas utiliser un langage hors de son contexte "optimal"
    • de l'autré alex_pi, qui affirme que le tout bas niveau est TOUJOURS une absurdite, et qu'on fera toujours mieux en ne laissant qu'un coeur bas niveau et des modules très haut niveau, voire en tout très haut niveau mais avec passage automatisé par un langage bas niveau pour éviter les overheads de certains runtime trop haut niveau (des DSL haut niveau en gros )
    Merci d'avoir résumé...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO
      0  0

  11. #151
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    perso, je ne suis pas de cet avis... selon moi, on a :
    • d'un côté MacLak, qui dit que certains domaines ont besoin d'un tout bas niveau, et qui expliquent les utilisations, etc ; mais qui reconnait que ce n'est pas toujours le cas, et qu'il ne faut pas utiliser un langage hors de son contexte "optimal"
    • de l'autré alex_pi, qui affirme que le tout bas niveau est TOUJOURS une absurdite, et qu'on fera toujours mieux en ne laissant qu'un coeur bas niveau et des modules très haut niveau, voire en tout très haut niveau mais avec passage automatisé par un langage bas niveau pour éviter les overheads de certains runtime trop haut niveau (des DSL haut niveau en gros )
    Ce n'est pas comme ça que je l'ai lu : AlexPi ne dit pas que le tout bas niveau est toujours une absurdité (cite-moi où il dit ça), il dit que contrairement à ce que MacLak prétend, embarqué n'implique pas forcément tout bas niveau, et qu'au contraire il y a pas mal d'équipes expérimentés travaillant dans le domaine qui utilisent des approches haut niveau sur coeur de bas niveau ou génération de bas niveau par DSL de haut niveau (qui profitent en grande part des capacités d'abstraction d'un langage de haut niveau même s'il génère du bas niveau au final) et ceci avec des résultats excellents. MacLak crie ensuite au fou qui ne veut absolument pas de bas niveau (et on les code en quoi nos runtimes tu crois ?)...

    Par ailleurs on avait débuté sur le foreach(), où j'avais dit que le foreach() était toujours préférable si l'on voulait parcourir un conteneur entier, s'il n'y avait pas de problème d'accès concurrent et que sinon il fallait utiliser le type de boucle approprié (un for() par exemple). MacLak s'est empressé de répondre avec un cas extrêmement spécifique où un for est préférable pour parcourir une partie déterminée du conteneur (celle qui existe en début de boucle) lorsqu'il y a un accès concurrent au conteneur. A partir de là j'ai suivi le débat de loin, j'avais un peu perdu courage je dois dire... Il est difficile de convaincre quelqu'un qui peut tranquillement faire preuve d'une telle mauvaise foi.

    --
    Jedaï

    PS : Sur l'approche de génération de bas niveau par du haut niveau, MacLak explique que ce n'est pas du haut niveau puisqu'il y a du bas niveau dans l'affaire... Il semble complètement négliger le fait que ce bas niveau n'est pas écrit par le programmeur et qu'à ce compte il n'existe pas de différence de niveau entre le C et l'assembleur puisque tout finalement est réduit à du langage machine (dont on peut examiner la transcription assembleur). AlexPi a tenté plusieurs fois de faire passer le message mais MacLak continue d'expliquer que c'est le C ou l'ADA tourne sur son microprocesseur au final, pas le langage de haut niveau qui l'a généré, il me semblait à moi et à AlexPi que ce qui tournait au final c'était le langage machine et uniquement le langage machine.
      0  0

  12. #152
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    Je sais que l'expression est vexante, mais cela reste alors des "jouets de laboratoire" : c'est intéressant, potentiellement révolutionnaire et tout et tout, mais c'est exactement la même chose pour moi que les annonces de téléportation d'un bit sur un mètre, ou d'un transistor réalisé avec quelques atomes, ou encore d'une porte logique totalement optique. C'est alléchant pour l'avenir, cela donne une idée ce qu'il sera peut-être possible d'avoir d'ici 5, 10, 20 ou 100 ans, mais cela reste quelque chose d'inapplicable dans la vie "réelle" d'aujourd'hui.

    Dans ce cas précis, je pense que cela donne d'excellentes pistes de recherche, en attendant que la technologie soit suffisamment évoluée pour permettre de faire tourner ce genre de trucs sur la machine du quidam moyen et non pas uniquement sur des "monstres", quand ce ne sont pas carrément des supercalculateurs.
    En attendant, le monde réel est là, et il faut bien continuer de le faire vivre avant de songer à le faire évoluer...
    Wouah, je ne dois pas être le quidam moyen, je faisais tourner "ce genre de truc" sur ma machine il y a 10 ans, j'avais donc un supercalculateur sans le savoir !! Je croyais pourtant que c'était un fixe tout pourrave acheté à l'économie pour encourager un petit jeune.
    Je ne savais pas que les "jouets de laboratoire" déterminait les équipes de vol de grandes compagnies aérienne, encodait des biens financiers complexe et leur évolution dans des banques d'envergures internationales, dirigeait l'hydraulique des véhicules d'une transnationale comme Eaton (et c'est du vrai embarqué, heureusement que l'hydraulique n'est pas dirigé depuis l'ordinateur de navigation, je n'aurais pas confiance !)...

    Franchement, je ne doute pas que tu sois parfaitement calé dans ton domaine, mais peut-être devrais-tu te renseigner un minimum sur une technologie extérieure à ce domaine avant de faire une vingtaine de messages interminables la dénigrant.

    --
    Jedaï
      0  0

  13. #153
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Ce qui m'embête un peu dans cette discussion, c'est que j'ai l'impression de lire que les langages de haut niveau ne seraient utilisables que dans des situations où on n'a absolument rien à cirer des performances.

    Je ne conteste pas qu'il soit nécessaire d'utiliser du bas niveau lorsqu'il est question de tirer la quintessence de la puissance d'un processeur, toutefois je supposerai que ça ne doit se faire que lorsque l'offre du haut niveau est entièrement insuffisante et que l'écart ne peut pas être absorbé différemment.

    Et je pense que c'est sur cette limite que alex et mac lak ne s'entendent pas. Alex me semble partisan de laisser plus de responsabilités à la machine et de favoriser l'utilisation du haut niveau, avec ce que ça implique : temps de développement et risques de bugs réduits. Ceci au prix d'un overhead plus ou moins lourd et significatif. Mac Lak est semble prôner la solution de prendre plus de responsabilité côté développeur, en acceptant les risques mais avec la garantie d'un niveau de contrôle aussi fin que possible.

    C'est sans doute spécifique et différent pour chaque domaine mais ces deux visions des choses doivent un moment donné se croiser, et j'ai l'impression que c'est sur les coordonnées exactes de ce croisement qu'il y a désaccord.
      0  0

  14. #154
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par _skip Voir le message
    Ce qui m'embête un peu dans cette discussion, c'est que j'ai l'impression de lire que les langages de haut niveau ne seraient utilisables que dans des situations où on n'a absolument rien à cirer des performances.
    Je ne suis donc pas fou ou paranoïaque ?! D'autres ont lu la même conversation que moi ?

    Citation Envoyé par _skip Voir le message
    Et je pense que c'est sur cette limite que alex et mac lak ne s'entendent pas. Alex me semble partisan de laisser plus de responsabilités à la machine et de favoriser l'utilisation du haut niveau, avec ce que ça implique : temps de développement et risques de bugs réduits. Ceci au prix d'un overhead plus ou moins lourd et significatif.
    C'est aussi ce que j'ai compris. Il faut noter que d'ailleurs l'overhead peut être pratiquement non-existant pour les applications qui s'y prêtent et au prix d'un certain effort initial : c'est l'approche du DSL générant du code de bas niveau. Si ton application a une structure adapté à Atom (le DSL générant les programmes temps réel pour l'embarqué qui dirige l'hydraulique des véhicules d'Eaton) il n'y aura pratiquement aucun overhead par rapport à une implémentation directe en C. Evidemment ce n'est pas toujours applicable (ou même le coût initial peut être prohibitif), ce que ne semble pas entendre MacLak quand il prétend que nous voulons mettre du haut niveau partout.

    Citation Envoyé par _skip Voir le message
    C'est sans doute spécifique et différent pour chaque domaine mais ces deux visions des choses doivent un moment donné se croiser, et j'ai l'impression que c'est sur les coordonnées exactes de ce croisement qu'il y a désaccord.
    Tout à fait, c'est un vieux débat, mais MacLak semble pousser cette limite très loin, plus loin qu'elle ne l'a été historiquement alors même que nous sommes en train de progresser dans les performances du haut niveau... Les seuls exemples d'applications pour lesquelles il a admis que le haut-niveau pouvait être approprié c'est les one-shots et les GUIs (GUI pure s'entend, le gros du boulot devant être assuré par du bas-niveau par en-dessous).

    --
    Jedaï
      0  0

  15. #155
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par Jedai Voir le message
    AlexPi ne dit pas que le tout bas niveau est toujours une absurdité (cite-moi où il dit ça)
    Trouves-moi un seul message, alors, ou il ne critique pas totalement le bas niveau...

    Citation Envoyé par Jedai Voir le message
    A partir de là j'ai suivi le débat de loin, j'avais un peu perdu courage je dois dire... Il est difficile de convaincre quelqu'un qui peut tranquillement faire preuve d'une telle mauvaise foi.
    Dans ce message, tu disais, je cite : "je fais ici abstraction des problèmes des conteneurs mutable en présence de threads, le problème est le même pour for ou foreach".
    Et non, justement, les problèmes ne sont pas les mêmes du tout... Un for peut être conçu pour fonctionner dans un tel cas, un foreach, jamais, pas sans verrouiller l'intégralité du tableau du moins (ce qui est fortement pénalisant...).

    Tu as également dit, je cite aussi, "L'avantage du foreach() c'est qu'il fait exactement ce qu'on lui demande (parcourir intégralement un conteneur/itérateur) de façon immédiatement lisible.".
    Or, justement, c'est ce problème de "complétude" qui lui interdit déjà tout contexte multitâche, ce que je trouve personnellement rédhibitoire vu le sens que prends actuellement l'informatique, à savoir un parallélisme de plus en plus omniprésent.

    Citation Envoyé par Jedai Voir le message
    PS : Sur l'approche de génération de bas niveau par du haut niveau, MacLak explique que ce n'est pas du haut niveau puisqu'il y a du bas niveau dans l'affaire...
    Un générateur de code est une chose, très pratique d'ailleurs. J'en utilise moi-même, comme je l'ai précisé d'ailleurs.

    Mais il faut quand même distinguer fortement l'outil de génération de ce que l'on génère : "pisser" du code bas niveau et croire qu'il sera efficace, voire optimal, c'est très très légèrement prétentieux... Générer du code bas niveau, ce n'est pas simplement traduire des concepts haut niveau en concepts bas niveau, cela ne fonctionne pas aussi simplement que ça.
    Prends l'exemple de l'optimisation C->ASM : on ne peut pas effectuer cette opération sans maîtriser parfaitement les deux côtés, et ce n'est possible que parce que le C n'est pas loin de l'ASM.

    L'automatisation, cela peut être pratique. Mais elle ne tient que très rarement compte des cas particuliers, et peut encore moins trouver des optimisations qui ne peuvent être trouvées que par une réflexion humaine... Et c'est là que les spécialistes du bas niveau interviennent : comment veux-tu "traduire" un langage vers un autre sans avoir des spécialistes des deux côtés pour juger de la validité de la traduction ???

    Enfin, toujours sur la génération : si le passage par le C ou l'Ada est "inutile", ou "juste une étape", pourquoi ne pas aller directement jusqu'à l'ASM ? Ah, peut-être parce que des compilateurs Ada sont certifiés, et que les compilateurs C sont prouvés par temps de bon fonctionnement... Et qu'ils constituent donc une base référentielle connue, validée et déclarée sûre ?

    Citation Envoyé par Jedai Voir le message
    Wouah, je ne dois pas être le quidam moyen, je faisais tourner "ce genre de truc" sur ma machine il y a 10 ans, j'avais donc un supercalculateur sans le savoir !!
    Remets les choses dans leur contexte : tu ne fais pas non plus tourner l'équivalent des "gros" projets haut niveau chez toi. Tout comme je pense que tu es loin du niveau de complexité qu'atteignent ces projets dans tes réalisations personnelles.

    Citation Envoyé par Jedai Voir le message
    Franchement, je ne doute pas que tu sois parfaitement calé dans ton domaine, mais peut-être devrais-tu te renseigner un minimum sur une technologie extérieure à ce domaine avant de faire une vingtaine de messages interminables la dénigrant.
    Ben figures-toi que oui, dans mon domaine, je suis parfaitement calé...

    Citation Envoyé par _skip Voir le message
    Ce qui m'embête un peu dans cette discussion, c'est que j'ai l'impression de lire que les langages de haut niveau ne seraient utilisables que dans des situations où on n'a absolument rien à cirer des performances.
    Où l'on n'a rien à cirer des performances machine... Vitesse d'exécution et footprint notamment, ainsi que le coût du matériel.
    Par contre, la performance "vitesse de développement" y est plutôt prépondérante, tout comme la capacité d'abstraction ou de manipulation d'éléments complexes.

    Chacun son boulot... Je l'ai déjà dit, mais je le répète : le haut niveau ne peut rien faire sans un bas niveau efficace, et la demande croissante de puissance du haut niveau alimente le développement bas niveau. Les deux sont indissociables, c'est juste qu'ils sont presque totalement disjoints et qu'ils s'entraînent l'un-l'autre.

    Citation Envoyé par _skip Voir le message
    Mac Lak est semble prôner la solution de prendre plus de responsabilité côté développeur, en acceptant les risques mais avec la garantie d'un niveau de contrôle aussi fin que possible.
    Parce que c'est ce que mes clients exigent... Contrôle total, pérennité totale, aucun élément ne doit être "inconnu" sur la chaîne critique, et l'on doit tirer le maximum de possibilités des machines pour baisser le coût du matériel.

    Citation Envoyé par Jedai Voir le message
    Evidemment ce n'est pas toujours applicable (ou même le coût initial peut être prohibitif), ce que ne semble pas entendre MacLak quand il prétend que nous voulons mettre du haut niveau partout.
    Non, c'est plutôt le raccourci un peu violent qui voudrait faire croire qu'un générateur de code serait du "haut niveau dans des capteurs", par exemple, ou autres raccourcis de ce genre...
    Je le redis : c'est aussi idiot que de dire que le kernel Linux est programmé en Makefile... L'outil n'est pas le langage.

    Citation Envoyé par Jedai Voir le message
    Les seuls exemples d'applications pour lesquelles il a admis que le haut-niveau pouvait être approprié c'est les one-shots et les GUIs (GUI pure s'entend, le gros du boulot devant être assuré par du bas-niveau par en-dessous).
    C'est pas comme si j'avais cité la génération de code et la conception globale dans la même phrase, hein, et en 3ème page...

    Au fait : les systèmes hydrauliques sont considérés comme monstrueusement lents, en "temps machine", tu sais ?
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO
      0  0

  16. #156
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Jedai Voir le message
    Les seuls exemples d'applications pour lesquelles il a admis que le haut-niveau pouvait être approprié c'est les one-shots et les GUIs (GUI pure s'entend, le gros du boulot devant être assuré par du bas-niveau par en-dessous).
    Sur ce point, il a raison

    Faire un logiciel graphique d'affichage de 20000 symboles qui se raffraîchissent en 1/10 seconde en simili temps réel est impossible à faire avec du haut niveau...
    "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
      0  0

  17. #157
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Juin 2009
    Messages : 1 909
    Points : 3 284
    Points
    3 284
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    histoire de calmer un peu les esprits... pourquoi chaque visiteur se sentant concerné ou intéressé par cette discussion n'essayerait pas d'en faire un résumé en 1 post, en reprenant uniquement les exemples, les grandes idées (et en évitant les trolls et attaques personnelles )

    ainsi, peut-être qu'il serait possible de repartir ensuite sur des bases plus saines (voire de remplacer tout ce qui a été fait précédemment par quelque chose de plus constructif)
    enfin une proposition interessante, esperons que ça calemra un peu les ardeurs....
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com
      0  0

  18. #158
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    Je me lance:

    Le sujet du post est hautement trollesque. Pas besoin d'être un expert pour comprendre que c'est typiquement le genre de sujet qui tournera en rond sans fin, à l'image d'un sujet comme Java vs. C++ pour les jeux (^^): l'un dira blanc et le posteur suivant lui trouvera systématiquement un contre exemple pour un cas précis pour 'prouver' que le blanc n'est pas si blanc et même que dans son exemple précis, le blanc devrait au contraire être noir.

    On arrive assez rapidement (pas plus de 4 posts dans ce sujet) à une sorte de mini-guerre des tranchées ou chacun va déballer son lot de connaissances pointues sur des sujets tout aussi pointus pour essayer d' "avoir raison" le temps d'un post ou deux.

    Ma vérité (toute personnelle) est que:

    - dans un projet informatique, le choix d'un langage de programmation en tant qu'outil offrant une palette de technologies plus ou moins spécifiques n'est qu'un paramètre totalement secondaire dans l'immense majorité des cas.

    Evidemment il y a certains projets ou la technologie employée est un aspect important du projet (je ne vais pas m'amuser à pondre un driver vidéo ou une pile réseau en QBasic), mais soyons clairs: ce type de projet c'est 1% des projets en informatique ou des boites en informatique. Parmis ce qui reste, au moins 80% sont des projets d'informatique de gestion où les perfs sont bien moins importantes que la maintenance et l'évolutivité sur le long terme par exemple.

    De fait, dans le cas où le langage de programmation n'est pas restreint par des contraintes technologiques (cf ci-dessus) ou l'existant, le meilleur langage est ... celui que les développeurs qui vont faire ce projet connaissent bien.

    - les performances sont un faux problème (à nouveau: sauf dans certains cas particuliers qui ne représentent pas la majorité des projets amha). Dans la plupart des cas, renouveler un matériel pour faire tourner un bouzin pas ultra-hyper-optimisé (quelque milliers d'euros) coûte au final moins cher que payer x homme.jours supplémentaires à cause de la perte de productivité lié au choix d'un langage -certes plus adapté sur le papier- mais que les devs. connaissent pas/peu/moins.

    - enfin, le langage ou les concepts inhérents au langage (rigueur du code, typage) ne se substituent jamais au développeur. Quel que soit le langage, on trouvera toujours des bons développeurs et des mauvais. C'est comme un marteau : quel que soit le marteau et ses qualités, il n'empêchera jamais son utilisateur de se taper sur les doigts.
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.
      0  0

  19. #159
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    1 258
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 1 258
    Points : 1 539
    Points
    1 539
    Par défaut
    J'ai suivi cette conversation depuis le début, sans trop rien dire... Faut dire que quand j'ai commencé à la lire, il devait déjà y avoir une demi-douzaine de pages... Dont... une demi-douzaine de pages de trolls.

    nouknouk a plutôt bien résumé le truc, je pense.
    En définitive, il n'y a pas grand chose de nouveau et d'intéressant techniquement parlant, à retenir de cette conversation.

    C'est con, mais ce que je retiens surtout, c'est que certaines personnes feraient certainement mieux d'aller profiter du beau temps...
      0  0

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Troll? Sans doute, mais j'ai beaucoup appris, spécialement sur le bas niveau(même si je ne suis pas Mac des masses sur ses raisonnements).

    Sinon, ce que j'en retire, bah, toujours la même chose : suivant les besoins du client, on utilisera telle ou telle méthode. J'ai connu un client qui nous a demandé d'améliorer nôtre qualité logicielle(ça concernait exclusivement les bugs). Eh bien nous sommes passés d'une facturation de 9 heures par évolution unitaire à 20 heures..... Le client a fait la tronche, mais il a décidé qu'un bug ça coutait plus cher que ça. On a divisé leur nombre par 3 ou 4.

    Mais le client est roi. Si demain il demande des milliards de trucs pour le surlendemain("slapper, on a un problème, y'a un programme qu'on a oublié de faire, on l'avait chiffré à 10 jours et il faut que ça tourne après-demain" - authentique), evidemment, y'a des choses qui ne seront pas vérifiées. Le client est roi.
    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.
      0  0

Discussions similaires

  1. Réponses: 1
    Dernier message: 26/10/2012, 11h19
  2. réalise un programme avec Delphi tres compliqué
    Par ouldfella dans le forum Delphi
    Réponses: 11
    Dernier message: 05/09/2006, 00h49
  3. Réponses: 15
    Dernier message: 18/05/2006, 14h43
  4. conception et réalisation d'une application client/serveur
    Par masvivi dans le forum Développement
    Réponses: 1
    Dernier message: 24/08/2005, 13h32
  5. Qui a inventé le concept de "langage de programmation?
    Par Biane dans le forum Langages de programmation
    Réponses: 10
    Dernier message: 11/02/2004, 11h11

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