Discussion:COBOL

Une définition du Jargon Français.
Aller à : Navigation, rechercher

Programmation structurée

Bonjour,

Il semble qu'il y ait une confusion dans le sens que l'on peut prêter à la phrase suivante (telle que je la comprends ):

Des normes ont défini COBOL 74 et surtout COBOL 85, qui lui autorisent la programmation structurée (avec des boucles et des alternatives) (d'après Jean Wojtalik).

En effet la programmation structurée qui s'est imposée dans les années 70 a permis de normaliser les développements mais cela ne sous-entend pas que les langages de programmation n'était pas dotés d'ordres permettant de structurer les programmes. En COBOL l'ordre PERFORM ....... et ses options VARYING.. UNTIL... existaient bien avant cette époque.

Cordialement,

Christian.

Le gros de tout cela date AFAIK d'ALGOL
(Christian: vous pouvez signer et estampiller vos interventions dans les discussions en y plaçant ~~~~)
Natmaka 10 janvier 2007 à 17:47 (CET)

Je viens de modifier la page avec ce que je considère comme étant intéressant. Maintenant, je crois que Christian connaît bien COBOL, alors allez-y Christian, modifiez-la, quitte à tout changer de A à Z. Note supplémentaire : ne pas oublier de structurer la définition de telle sorte qu'elle présente le terme en quelques lignes pour commencer, puis faire un bloc "encyclopédique" en entrant dans les détails. Roland 10 janvier 2007 à 18:30 (CET)

Je m'en occupe. christian 10 janvier 2007 à 22:07 (CET)

Modèle révision

Je viens de créer un nouveau modèle, un peu meilleur que {{reviser}}. C'est le modèle {{révision}}, avec l'accent, qui peut prendre un paramètre pour indiquer qui travaille sur une page (mais sans verrouillage de la page hein ?). S'utilise comme ça, par exemple : " {{révision|~~~~}} " (sans guillemets évidemment). Le paramètre est libre. Roland 12 janvier 2007 à 10:12 (CET)


Help me

Bonsoir,

Peu habitué à ce genre de travail, j'ai besoin d'avis critiques sur ce que j'ai commis sur ce site, notamment la tirade sur COBOL qui est conséquente (trop ?)

Je ne vous en tiendai (peut-être) pas rigueur !

Merci,

christian 27 janvier 2007 à 01:18 (CET)

En ce qui me concerne, je n'ai pas de reproches à faire, au contraire, je trouve vos contributions très intéressantes, surtout qu'elles touchent des domaines que je connais peu ! (d'ailleurs, du coup, je ne peux pas trop me prononcer sur le contenu !). En ce qui concerne l'article COBOL, il est devenu un peu atypique pour le Jargonf, qui a l'habitude d'être beaucoup plus superficiel, ce qui était inévitable puisqu'il était édité principalement par une personne seule sur son temps libre... Mais tout l'intérêt de cette nouvelle version en forme de wiki est justement de pouvoir travailler en groupe, et donc d'aller un peu plus dans les détails, ceci évidemment en fonction du temps, des compétences et des connaissances de chacun. L'avenir dira si ce type d'article doit se généraliser, ou s'il devrait plutôt être déplacé dans l'espace de nommage "Document" par exemple. Roland 27 janvier 2007 à 03:11 (CET)

Bonjour,


Merci de m'avoir donné votre avis,

Je pense, pour ma part qu'un texte conséquent comme celui sur le COBOL, serait davantage à sa place dans un espace facilement accessible pour les visiteurs qui veulent en savoir plus. Il peut y avoir un effet dissuasif qui risque de démobilser certains visiteurs qui seraient en droit de se demander s'il n'est pas (quand même) nécessaire de tout lire pour s'informer sur le sujet.

christian 27 janvier 2007 à 15:11 (CET)

Ben oui, c'est pourquoi je parlais de l'espace de nommage "Document", en pratique destiné à recevoir toutes les "annexes" que l'on veut adjoindre au dictionnaire. Voir la page du dictionnaire des smileys, déjà vue plus de 2000 fois sur cette nouvelle version du Jargonf... Avec mise en exergue sur : [1], lien présent sur toutes les pages (une page qu'on pourra scinder si elle s'allonge un peu trop). Roland 27 janvier 2007 à 19:14 (CET)

Bonjour,

Pour moi, ça me va bien, je pourrais insérer de exemples synthétiques pour chaque instruction.

christian 30 janvier 2007 à 18:49 (CET)

Programmation structurée

Bonjour,

La programmation structurée (en COBOL) a effectivement été introduite en 1985 sous l'appellation COBOL-II. Puisque l'introduction de la programmation structurée était une révolution pour COBOL. La programmation structurée nécessite, hormis l'assignation, trois autres types d'énoncés. Un énoncé de sélection, un énoncé de répétition et... un énoncé composé. Oui bien des gens croient à tort que l'énoncé (alternatif?) "select when" représente une évolution relative à la programmation structurée. Malheureusement rien n'est plus faux. L'énoncé de sélection "Select When" représente uniquement une structure de "sélections en cascade". Dans presque tous les langages de programmation structurée l'énoncé composé se décline en "Début...Fin" (Do-End). Pour permettre la programmation structurée en COBOL (COBOL-II) il fallait donc uniquement introduire l'énoncé composé. Comme COBOL ne fait jamais les choses comme les autres ils ont introduits une "fin" à chacun de leur énoncé. Question programmation structurée l'exigence est tout de même remplie. Malheureusement je n'ai jamais vue de programmation structurée en COBOL. Il faut être très prudent car des titres de manuel comme "programmation COBOL structurée" ou "Structured programming in COBOL" ne traite habituellement pas de "programmation structurée". Le problème vient du fait que le langage COBOL a été très utilisé avant l'introduction de la programmation structurée. Le langage COBOL devait permettre aux comptables d'écrire eux-mêmes leurs programmes. Les règles lexicales et syntaxiques ont donc été calquées sur l'anglais. Alors plutôt qu'un langage symbolique, un langage de verbiage avec ses phrases, ses paragraphes et ses chapitres (SECTION). Désolé pour ceux qui croyaient que "SECTION" avait une connotation informatique. Malheureusement (ou heureusement) les comptables ont déclarés rapidement forfait. Finalement COBOL était un échec total, tel que l'on peut le lire sur Wikipédia. Mais attention les comptables tiennent les cordons de la bourse alors Ils étaient très facile de trouver les budgets pour des programmeurs COBOL. Le plus mauvais langage est devenu rapidement le plus populaire.

Voilà qui ajoute un élément au débat, merci !
Je tente ci-après de reformuler afin de clarifier pour le profane, et pose des questions entre double parenthèses, pouvez-vous corriger et répondre ?
La programmation structurée (en COBOL), introduite en 1985 sous l'appellation COBOL-85 ou COBOL-II, était une révolution pour ce langage car nécessite, hormis l'assignation, trois autres types de formes : sélection et répétition, ainsi que leur composition que nous appellerons composé ((Pouvez-vous fournir un exemple de sélection (est-ce if?) et de répétition (est-ce une boucle?) ? Leur "composition" est-elle bien ce que l'on appelle ailleurs un bloc, gouverné par au moins une structure de contrôle ?)). Seule cette dernière n'existait pas en COBOL, avant COBOL-II. Beaucoup croient à tort que select when constitue une évolution relative à la programmation structurée, mais il représente en fait une structure de sélections en cascade ((donc bien une alternative ?)). Dans presque tous les langages permettant la programmation structurée un bloc composé débute par une forme (do/while/until...) et est clos par une autre (done/end...). Pour permettre la programmation structurée en COBOL il fallait donc ((je ne comprends pas ce "donc" : les blocs existaient-ils déjà en COBOL (avant COBOL-II) ? Quel rapport avec les SECTIONs ?)) uniquement introduire l'énoncé composé ((écrire "permettre d'exprimer l'alternative gouvernant un bloc" serait-il équivalent? Cela me semble plus clair)). Comme les auteurs de COBOL ne font jamais les choses comme les autres ils ont décidé que chaque bloc aurait une "fin" explicite ((en quoi est-ce différence de ce que l'on trouve par ailleurs ? Dans tout langage un bloc est délimité, ne serait-ce que par de l'indentation)). Il devient ainsi possible de pratiquer la programmation structurée, mais elle demeure rare en COBOL au point que certains manuels a priori pertinents car par exemple intitulés « Programmation structurée en COBOL-II » n'en traitent en fait pas ((en quoi n'en traitent-ils pas ?)). Le problème vient du fait que ce langage a été très utilisé avant l'introduction de la programmation structurée et devait permettre aux comptables d'écrire eux-mêmes leurs programmes. Ses règles lexicales et syntaxiques ont pour cela été calquées sur celles de l'anglais, ses utilisateurs s'y habituèrent et cela leur rend difficile d'adopter la programmation structurée ((est-ce bien ce que vous pensez ? Pourquoi ? Blocs et alternatives sont exprimables dans une langue)). Malheureusement (ou heureusement) les comptables ont rapidement déclaré forfait , mais ils préférèrent longtemps payer des programmeurs COBOL de sorte que ce langage jugé mauvais par de nombreux informaticiens est devenu le plus employé. Natmaka 28 novembre 2007 à 15:23 (CET)

Bonsoir,

Je découvre, avec beaucoup de retard, cette discussion. J'avoue être assez déconcerté, je relis le texte sans parvenir à illustrer mentalement le fond du problème qui est posé. Qui est l'auteur de la première partie du texte ? Peut-il illustrer ses propos avec quelques exemples ? Peut-il également, comme je ne manque pas de le demander dans ce genre de situation, sans avoir à ce jour obtenu la moindre réponse, (me) faire une analyse des mérites comparés de deux (ou plusieurs langages) dont le cobol, utilisés dans une optique (un contexte) professionnelle et en tenant compte de ce qui a présidé à leur orientation au moment de leur conception(scientifique, gestion, industriel, ........). En informatique comme dans tout autre domaine il faut bien se garder de faire dire aux choses ce pour lequel elles ne sont pas faites. En ce qui me concerne, j'ai débuté en 1974 la programmation (en COBOL) je n'ai jamais vu ni entendu parler de comptables se risquer à la programmation. Je crois qu'ils ont (ou avaient) autre chose à faire. Moi qui pensais avoir commencé à programmer en structuré à cette époque, je commence à douter. Tout se passe comme si l'on jouait sur le sens du mot "structuré". Le "structuré" suppose-t-il du "in-line" comme vous semblez le suggérer ? Si oui pour quelles raisons, comparativement à l'"out-line" ? Les instructions COBOL suivantes seraient-elles de nature à répondre, en partie du moins, aux remarques et interrogations ?

OUT_LINE PERFORM :

 PERFORM    DEB-paragraphe          THRU         FIN-paragraphe
            WITH TEST BEFORE (ou after)
            VARYING variable-indice FROM valeur-ou-variable-d'initialisation BY valeur-ou-variable-incrément
                                    UNTIL condition-d'arrêt-de-l'itération (variable-indice)

(éventuellement)

            AFTER variable-2        FROM valeur-ou-variable-d'initialisation BY valeur-ou-variable-incrément
                                    UNTIL condition-d'arrêt-de-l'itération-variable-2-ou-autre-condition 
 END-PERFORM.

DEB-paragraphe.

instructions-1. 
instructions-2. 
instructions-.. 
...............

FIN-paragraphe.

 EXIT.

AUTRE-paragraphe ou fin du PGM; Ca, ça date des années 70.


IN_LINE PERFORM :

PERFORM    
            instructions-1   
            instructions-2   
            instructions-.   
            .............
            WITH TEST BEFORE (ou after)
            VARYING variable-indice FROM valeur-ou-variable-d'initialisation BY valeur-ou-variable-incrément
                                    UNTIL condition-d'arrêt-de-l'itération (variable-indice)
END-PERFORM.

Ca, c'est plus récent années 80.


C IN-LINE FOR (Mais alors, qu'en est-il des procédures et des fonctions si on se limite pour comparaison à ce seul langage ?)

 FOR  (unsigned int variable-indice = valeur-ou-variable-d'initialisation;
                                                 condition-d'arrêt-de-l'itération (variable-indice);
                                                                             valeur-ou-variable-incrément)
     {
      instructions-1   
      instructions-2   
      instructions-.   
      .............
     }

Où se trouve la différence fondamentale entre ces instructions ? Wikipédia n'est pas nécessairement une référence en la matière. Je crois d'ailleurs leur avoir dit ce que je pense à ce sujet. Je vérifierai, si c'est bien eux je n'ai jamais eu de réponse de leur part.

Mais surtout ce qui fini malgré tout par me distraire, après m'avoir je le reconnais, passablement irrité dans un passé récent, c'est cette attitude vindicative, hargneuse, manifestée contre toute évidence à propos d'un simple outil professionnel qui; la plupart du temps sinon systématiquement, est inconnu ou au mieux méconnu de ceux qui tentent de le descendre; (les comptables .... tout de même ! je ne l'avais pas encore entendu celle-là, pourquoi pas les commerciaux.......le service restauration de l'entreprise, .........). Pensez-vous que les financiers/décideurs/employeurs de l'époque (années 70) étaient les rois des cons en informatique ou dans leur domaine au point de déplacer les compétences et demander à leurs comptables d'écrire et tester des programmes (même écrits en COBOL.......), qui occupaient les informaticiens de l'époque huit à neuf heures par jour. Mais à notre époque, compte tenu de l'état d'esprit "new-tech" qui règne actuellement dans les hautes sphères informatiques lesquelles, après s'être auto-proclamées, pensent tout re-découvrir alors qu'elles ne font que du (mauvais) tuning, sommes-nous perçus, les vieux, comme étant toujours, et/ou ayant été, des informaticiens ? J'en doute !

"Le plus mauvais langage est devenu rapidement le plus populaire" TOUS DES BOURRICOTS A C'T'EPOQUE. Et moi qui l'ai "enseigné" durant plus de cinq ans en qualité de formateur à des BAC+5, j'ai encore fait du propre, tiens!

Allez, cordialement quand même.

Christian HILBE.

P.S Je suis allé faire un tour sur Wikipedia, je n'ai rien trouvé qui ressemble à un constat d'échec relatif à COBOL. Précision : Ce n'est pas à Wikipedia à qui j'avais donné mon sentiment sur ce langage.

Bonsoir,
Note: je ne suis pas l'auteur des critiques virulentes.
Qui est l'auteur de la première partie du texte ?: s'agit-il du texte de l'article ? Pour le savoir il faut explorer l'historique donc accéder à l'article puis cliquer sur l'onglet 'historique'. On peut alors, par exemple, cliquer sur le nombre 500 présenté sur la première ligne afin d'obtenir liste d'autant des plus récentes révisions (versions). Cela mène ici. Il suffit ensuite de cliquer sur une date afin de lire la version correspondante. On peut comparer des versions. La toute première révision, placée en fin de liste, est datée 2006-11-15T13:00:00, date d'injection dans le présent wiki d'un corpus pré-existant.
Si tu penses aux éléments de la présente discussion il te suffit de sélectionner, dans l'historique, la plus récente révision dont tu es l'auteur (en admettant que tu as lu tout ce qui précéda) puis de cliquer (ligne 3) sur "(diff)" afin d'accéder aux différences qu'induisit la révision suivante, puis sur "Différence suivante →" (ligne 3, à droite) pour 'parcourir' ainsi les différences successives
Peut-il également ... il faut bien se garder de faire dire aux choses ce pour lequel elles ne sont pas faites: je partage ce point de vue et ne crois pas plus à l'outil très utilisé qui serait le pire qu'à celui qui serait le meilleur quel que soit le besoin.
je n'ai jamais vu ni entendu parler de comptables se risquer à la programmation: sans être aussi aguerri j'ai souvent constaté que la formation de nombreux informaticiens pros maintenant retraités ou proches de l'être ne correspondait pas à leur poste puisqu'il n'existait, lorsqu'ils étudiaient, peu (voire pas) de filière informatique : j'ai ainsi croisé force généralistes et scientifiques universitaires... ainsi que des comptables
Tout se passe comme si l'on jouait sur le sens du mot "structuré".: le sens des termes constitue, comme souvent, le gros du débat. J'ai tenté de préciser programmation structurée, qu'en pensez-vous? Dans votre exemple d'out-line (merci d'avoir ainsi proposé de la matière!) il me semble que si aucune des instructions orchestrées par "with test...", donc rien de ce qui se trouve entre "DEB-paragraphe" et "FIN-paragraphe") n'est accessible directement (sans passer par "with test..."), si tout cela forme un bloc, on peut parler de programmation structurée.
Wikipédia n'est pas nécessairement une référence: Certes. Je ne sais ce qui vous laisse croire que ce projet le serait ici, mais ce n'est pas le cas en ce qui me concerne.
attitude vindicative, hargneuse:Elle est souvent le propre des groupes qu'aucune tranquille certitude ne cimente, donc qui ont besoin d'un ennemi commun consolidant une (factice) union sacrée.
étaient les rois des cons en informatique:afin d'imposer au plus vite un progrès ses tenants se gaussent de la bêtise de leurs prédécesseurs
les hautes sphères informatiques lesquelles, après s'être auto-proclamées, pensent tout re-découvrir alors qu'elles ne font que du (mauvais) tuning:ah, ici et comme pour le cas des comptables devenus informaticiens... je ne vous suivrai pas, car affirmer que les 10 ou 20 dernières années d'informatique ne procèdent que du tuning procède de la logique «tous des bourricots...»
De toutes façons tes avis étayés, sous forme d'ajouts comme de corrections, sont ici les bienvenus
Cordialement, Natmaka 21 décembre 2007 à 03:18 (CET)


Bonsoir,

En effet, j'avais bien compris, de par ta réponse, que tu n'étais pas l'auteur de la première partie du texte.

Merci pour tes précisions à propos de l'historique, je n'y avais pas pensé.

En ce qui concerne "les comptables" l'auteur écrit : "Le langage COBOL devait permettre aux comptables d'écrire eux-mêmes leurs programmes" c'est sur la base de cette formulation que j'ai répondu. Il est vrai qu'à cette époque beaucoup de reconversions se sont efectuées, on manquait cruellement d'informaticiens et l'informatique "était bien payée".

Pour ce qui est de l'évolution de ces dix dernières années, je dirai la même chose des années qui précèdent cette période. Combien de fois (15 ou 20 fois) au cours de ces decennies j'ai vécu sur site des grands bouleversements, ou présentés comme tels, qui allaient fondamentalement révolutionner les études et le développement, les AGL entre autres (UFO, MANTIS) avec leur langage qui génère(ait) du moins pour MANTIS ..... du COBOL. J'en étais arrivé, la lassitude aidant à répondre : Moi, j'attends qu'on me sorte de mon CICS/COBOL/DLI,..... et je citais, non pas pour péter un score, mais bien plutot par ironie la gamme d'outils de développement qui allaient être balayés et que nous utilisions et étions censés maîtriser sur ce site.

Plus recemment je me suis décidé à (tenter d') apprendre le C(++) je ne donnerai pas mon avis sur ce langage, je ne le maîtrise pas (encore) assez, mais là non plus je n'ai rien trouvé de révolutionnaire.

Ce que je veux dire peut s'ennoncer de manière un peu lapidaire de la façon suivante : La méthodologie mise en oeuvre dans les années 70 (pour illustrer : papier/crayon cartes perforées) afin de réaliser un programme (ou un projet) n'était pas différente de celle mise en oeuvre aujourd'hui (écran/clavier/souris). Seule la partie "hardware" a vraiment bougé. Si je m'étends un peu sur le sujet c'est qu'il me semble par le biais, être une illustration de la discussion qui nous occupe. Par exemple (modeste, qu'il convient d'extrapoler à l'ensemble des 2 langages) les 3 instructions ci-dessus en COBOL et en C ne démontrent pas une révolution dans l'"art de programmer". C'est ce que les personnes qui veulent que l'informatique soit un métier hautement intellectuel et pas seulement cérébral, ont du mal à admettre. On dispose d'une caisse à outils et faut faire avec !

L'une des rares "révolutions" que j'ai vécu est précisément le passage (1974) de la pratique de la programmation dite à l'époque "linéaire" à celle de la programmation "structurée". Une petite anecdote pour illustrer mon propos :

Je me souviens qu'une modification assez conséquente d'un pgm de plusieurs milliers de lignes (mal) monté en linéaire, nous avait obligé à faire l'organigramme de sa logique de fonctionnement. Nous étions trois à travailler sur cette modif et pour étaler, une fois terminé l'organigramme (réalisé au dos de plusieurs feuilles de listing jointes avec du scotch) il nous a fallu réunir quatre bureaux de maniére à avoir une vue d'ensemble, et encore ça pendait de chaque côté.


En ce qui concerne ta définition du "sructuré", elle me convient, tu insistes sur l'aspect modulaire et la nécessité d'ignorer l'ordre GO TO ou assimilé afin d'éviter toute interaction entre blocs.

Je me permets seulement une petite remarque à propos de l'association "structuré/itération" (structure de contrôle DO, WHILE, FOR boucle). Je pense aux cas où dans un pgm une ou plusieurs séquences d'instructions, constituant chacune un bloc fonctionnel, ne soit pas soumise à une itération (et dont l'ordre d'appel peut d'ailleurs s'inscrire dans une itération plus générique). C'est ce qui se passe dans les pgm (transactions) CICS montés en pseudo-conversationnel ou les boucles sont, sauf cas de nécessité majeure, à éviter pour des questions d'optimisation. Les séquences d'instructions sont appelées chacune par une instruction simple sans itération du type PERFORM DEB-paragraphe THRU FIN-paragraphe. Resterait bien la possibilité avec les instructions DO, WHILE, FOR, de "monter une boucle bidon" dans laquelle "on ne passerait" qu'une seule fois, mais ce n'est pas très élégant comme méthode de pogrammation. Peut-être pourrais-tu évoquer, afin de lever toute possibilité de confusion sur ce point précis, les procédures/fonctions/modules/sous-programmes,... ou autres dénominations qui, si tu es d'accord avec cette dernière affirmation; participent aussi à l'élaboration d'un programme structuré.

Cordialement,

90.37.153.49 22 décembre 2007 à 00:34 (CET)


Bonsoir,
En ce qui concerne "les comptables":pourquoi ne pas modifier cela? Je te propose "Le langage COBOL devait faciliter le développement de programmes relatifs à la gestion."
Combien de fois ... fondamentalement révolutionner: les sites de production sont "captifs" de leur existant, la réforme brutale est réservée aux chercheurs et aux amateurs
C(++): si tu veux du neuf mieux vaut essayer Scheme ou Python
La méthodologie: on s'éloigne déjà un peu des langages...
réaliser un programme/projet: hmmmm... à présent nombre d'équipes de développement sont homogènes (pas d'analyste/programmeur/... : ils sont tous 'développeurs'), la hiérarchie y est peu marquée, le développement est test-driven et le tout mené de façon agile avec un souci d'interopérabilité donc de normes ouvertes... même sur le plan de la gestion de projet l'erreur du mythical man-month me semble en voie de raréfaction. Non, vraiment, si tu as l'impression que rien n'a bougé depuis 15 ans nous ne vivons pas dans le même monde :-)
écran/clavier/souris: certes. Là encore la réforme est difficile (existant, habitudes...)
les 3 instructions ci-dessus en COBOL et en C ne démontrent pas une révolution dans l'"art de programmer": c'est exact et n'a rien d'étonnant car ces langages relèvent de la même famille. Toutefois C++ marque un relatif progrès en rendant par exemple la STL possible, laquelle fournit des itérateurs grâce auxquels on gagne (entre autres) en généricité (un même algo s'applique à divers types de données, sans perte sur d'autres plans (par ex côté typage), voir par ex ce tuto). C'est utile car, en définitive, cela améliore concision et clarté du code source. Par ailleurs dans une famille de langages différente les développeurs procèderont autrement. LISP, par ex, offre un équivalent de for ('loop') mais certains préfèrent iterate, qui n'est pas standard mais préserve l'emploi d'expressions symboliques, par ex en Common Lisp :
(iterate (for element in list-of-lists) (finding element maximizing (length element))))
semble assez difficile à "mapper" directement en COBOL ou C++... Rappel: LISP est plus vieux que COBOL, donc ce n'est pas une question d'âge du langage mais bien d'adoption des idées : avec le temps les bonnes ré-affleurent (OK, c'est un peu optimiste. Mettons "ré-affleureront". Encore trop? "réaffleurent parfois") et les bidules contemporains de plus en plus utilisés par l'industrie (Perl, Python et Ruby en tête, mais également PHP) en intègrent beaucoup plus de concepts issus des labos durant les années 70 à 90 que les langages plus anciens n'ayant pas évolué. D'intéressants langages plus contemporains offrent des choses tout aussi prometteuses, je parie que les langages des années 2030 en comprendront certaines, ce qui sera impossible sans rédhibitoires contorsions au gros des langages d'aujourd'hui qui ne sont pas conçus pour cela.
C'est ce que les personnes qui veulent que l'informatique soit un métier hautement intellectuel: deux sortes au moins existent. Celles qui souhaitent rendre inutilement compliqué afin de vendre des journées d'ingénieur prestataire... et celles qui tentent de faire avancer le schmilblick comme il a toujours progressé : en réfléchissant afin d'améliorer les outils. Ne les condamnons pas toutes.
Je me souviens qu'une modification assez conséquente d'un pgm de plusieurs milliers de lignes (mal) monté en linéaire ... réunir quatre bureaux de maniére à avoir une vue d'ensemble: moins on structure, moins on abstrait, plus le nombre de bureaux augmente. J'ai l'impression que voici longtemps les informaticiens s'en moquaient (le fait de programmer en langage d'assemblage des ordinateurs disposant de quelques Ko de mémoire n'y était pas étranger: tous les membres de l'équipe avaient tout le code, asm comme langage machine, en tête), puis qu'ils en prirent conscience, et à présent tout (méthodes, outils, formations...) en tient compte. C'est un progrès (quantitatif vers qualitatif, ce qui est rare).
définition du "structuré" ... Je pense aux cas où dans un pgm une ou plusieurs séquences d'instructions, constituant chacune un bloc fonctionnel, ne soit pas soumise à une itération: ah, oui, bien vu, la déf est imparfaite. La notion centrale à la programmation structurée est à mon sens celle de bloc. Je tente d'améliorer la définition, dis-moi ce que tu en penses. Natmaka 22 décembre 2007 à 02:40 (CET)


Bonsoir,

OK pour moi en ce qui concerne ta définition du structuré. Je te signale au passage 1 faute de frappe :.....amas d'instruction ....==> ...amas d'instructionS ..... Je n'ai pas eu la possibilité de préparer une réponse à ta dernière intervention (problèmes de santé, l'âge ...), je m'en excuse, BONNES FETES A TOUS ,

Cordialement,

Christian.


Bonjour, et bonne année,

Désolé pour le retard mis à te répondre, les fêtes ............


En ce qui concerne "les comptables":pourquoi ne pas modifier cela? Je te propose "Le langage COBOL devait faciliter le développement de programmes relatifs à la gestion."

D’accord, ça y est, on les a quand même casés, les comptables !


réaliser un programme/projet: hmmmm... à présent nombre d'équipes de développement sont homogènes………………. Non, vraiment, si tu as l'impression que rien n'a bougé depuis 15 ans nous ne vivons pas dans le même monde .

Précisément, je tente de le découvrir ce (nouveau) monde, C’était en tout cas, animé de cette intention que je commençais, à mon rythme il y a quelques temps, une petite étude orientée « nouvelles technologies »

Ceci dit j’admets être décentré du monde informatique …….? (alors là comment l’appeler ; nouvelles-technologies, micro, …, puisque de manière générale il semble qu’il y ait malheureusement dans l’esprit 2 informatique(s) l’une ainsi dénommée, l’autre appelée mainframe, et peut-être même une troisième, qui est frappée d’antériorité et semble davantage être suggérée que clairement définie.).

Je ne pensais pas aux changements structurels, organisationnels (en l’occurrence ceux touchant les équipes de développement) survenus ces 15 ou 20 dernières années en informatique, mais essentiellement aux changements (bouleversements ?) survenus aux niveaux technique et fonctionnel. Plus précisément aux changements intéressant ce qui est mis en œuvre, à ces niveaux (technique et fonctionnel) lors de la réalisation d’une application (et c’est d’ailleurs la raison pour laquelle j’ai écrit : "La méthodologie mise en œuvre dans les années 70 …………… " à propos de réalisation de programmes/projet, car je pense qu’il existe une méthodologie dans la mise en œuvre des étapes de réalisation finales (découpage organique, écriture des programmes, tests).

Mais ce qui nous intéresse ici ce sont effectivement les langages de programmation qui sans conditionner intégralement cette démarche sont à considérer dans toute étude, afin de choisir l’un d’eux le plus tôt possible. Ce choix ne doit pas être conditionné par des considérations impétueuses ou passionnées.


Rappel: LISP est plus vieux que COBOL, donc ce n'est pas une question d'âge du langage mais bien

Si tout le monde pouvait avoir cette ouverture d’esprit ! …………


Toutefois C++ marque un relatif progrès en rendant par exemple la STL possible, laquelle fournit des itérateurs .........

De manière générale ce qui me gêne dans cette optique « librairies » c’est la profusion de « routines, templates, fonctions  » qui sont autant d’ajouts fonctionnels au langage qui finalement n’évolue pas ou très peu de manière intrinsèque. L’impression première, et je ne suis pas le seul à l’avoir eue, ressentie en prenant contact avec le « C(++) » s’est imposée à moi par le raccourci suivant : « y’en a partout !». Je pense que c’est l’héritage logique de l’optique POO. Ce n’est pas franchement une critique, c’est seulement déroutant.

Par contre il est à "craindre" que les facilités, il est vrai très pratiques, que peuvent amener au développeur ces fonctions aient tendance à lui faire perdre de vue, dans une certaine mesure, la logique qui préside à l’enchaînement des étapes fonctionnelles (steps) qui constituent une application. Par exemple la possibilité de trier (sort) un tableau (ou intercaler ou rajouter des occurrences en début, fin), dans un pgm peut induire un effet pervers identique dans l’esprit à celui évoqué plus bas concernant les programmeurs « linéaires » des années 70 c’est-à-dire « utiliser et s’endormir » sur l’existant. Pour continuer l'exemple Les questions à se poser, dans ce scénario, portent sur l’origine des données renseignant les occurrences du tableau et surtout se demander les raisons pour lesquelles elles n’arrivent pas déjà triées et/ou en totalité au pgm dont le tri n’est pas la fonction principale. Au découpage organique d’une application, un tri est une étape fonctionnelle à part entière. Ce raisonnement ne vaut probablement qu’en informatique de gestion (dans l’ignorance j’ajoute ; « mainframe » après gestion). Mais c’est vrai qu’elles existent ces fonctions et peuvent avoir une utilité dans des cas bien précis.


J'ai l'impression que voici longtemps les informaticiens s'en moquaient (le fait de programmer en langage d'assemblage des ordinateurs disposant de quelques Ko de mémoire n'y était pas étranger

Il y avait deux attitudes ceux qui faisaient du linéaire (peu importe le langage) et ceux qui faisaient « leur structuré » c’est vrai que les premiers étaient plus nombreux. Une petite anecdote à ce sujet (encore une) : Lorsque j’ai pris mon premier emploi en 74 une informaticienne en place m’a dit et ça a été repris en cœur par les autres informaticiens « Le PERFORM ici ne marche pas !» Sans l’instruction PERFORM en COBOL pas de structuré. En fait il fonctionnait très bien. Par contre l’ "homme système" (terme de l’époque pour désigner l’administrateur du système- ingénieur système) préconisait farouchement le structuré et il ne développait ses routines qu’en assembleur.


Cordialement,

christian 6 janvier 2008 à 03:29 (CET)




Meilleurs voeux!
micromainframe:le clivage n'a rien de technique car plus le temps passe, plus les bonnes solutions découvertes et appliquées dans le monde du mainframe voici fort longtemps s'imposent dans la micro: virtualisation, périphériques intelligents, importance cruciale du réseau et du serveur (sur le Web!)...
et peut-être même une troisième, qui est frappée d’antériorité: l'informatique théorique? Ce que l'on peut pratiquer sans ordinateur et qui s'oppose à l'empirisme ambiant?
changements intéressant ce qui est mis en œuvre, à ces niveaux (technique et fonctionnel) lors de la réalisation d’une application ((...)) étapes de réalisation:la notion de développeur, sorte de cumul entre un analyste et un programmeur (au mini) est née, vraisemblablement parce que les premiers utilisateurs de micros, même informaticiens pros, étaient seuls devant la machine et peut-être parce que nombre d'entre eux furent tout d'abord des amateurs isolés. La mode classique de conduite des projets repose sur une erreur.
la profusion de « routines, templates, fonctions  »: je perçois au moins trois façons d'appréhender cela. Celle de l'amateur qui, de tous temps, est en quête de nouveauté et d'apparente richesse fonctionnelle (il explore et n'exploite que peu). Celle du pro qui y perçoit une boîte à outils plus riche donc moins de bugs et de temps de développement, moyennant un temps d'apprentissage qui « élève la barrière » le protégeant de la concurrence de l'amateur. Le théoricien, enfin, souhaite que cette richesse soit conçue et réalisée sans menace l'homogénéité du langage, en un tout harmonieux (comparer Common Lisp à Java...)
sont autant d’ajouts fonctionnels au langage qui finalement n’évolue pas ou très peu de manière intrinsèque: c'est le point de vue d'un théoricien, à mon sens (mais c'est disputé) servant bien un objectif pratique (par ex: choisir un langage sans passion, afin de résoudre un problème).
« C(++) » s’est imposée à moi par le raccourci suivant : « y’en a partout !». Je pense que c’est l’héritage logique de l’optique POO: je crois plutôt que c'est à cause du fait qu'il ajoute une couche OO à un langage non OO, ce qui explique les exceptions (pas elles, mais tout ce qui ne fonctionne pas comme le reste)
les facilités ((...)) faire perdre de vue ((...)) la logique:je crois que le foisonnement d'outils tout comme le peu de souci d'analyser sont deux effets de l'évolution technique choisie par le marché et découlent principalement du faible coût du matériel (ce n'était pas le cas dans le monde mainframe, surtout voici 20+ ans), de la disponibilité de quantités d'informaticiens formés (c'était moins vrai voici 20+ ans) et de l'existence de prestataires (qui ont intérêt à facturer donc à suer sur des bidules compliqués...).
la possibilité de trier ((...)) « utiliser et s’endormir » sur l’existant:c'est exact et valable pour toute technique vivante, voire pour certaines sciences (la calculatrice menace la capacité à poser des opérations arith) où les outils masquent à mesure les difficultés
Les questions à se poser: certes... à tout le moins en théorie. Lorsqu'un algo très efficace (qsort) et très bien implémenté (dans une bibliothèque standard) s'en charge sur une machine contemporaine (valant 6 sous et au CPU très rapide)... certains décident qu'il n'est pas rentable de s'en inquiéter, qu'il vaut mieux systématiquement appeler qsort en cas de doute. Là encore, comme dans le "match" mainframe-micro, ceux qui pratiquent ainsi rencontrent tôt ou tard des problèmes que seuls les autres peuvent résoudre
Le PERFORM ici ne marche pas !: :-) Oui! Ce genre d'approche joue dans les 2 sens!
Cordialement, Natmaka 6 janvier 2008 à 09:34 (CET)


Bonjour,

Merci pour tes voeux.

le clivage n'a rien de technique car plus le temps passe, plus les bonnes solutions découvertes et appliquées dans le monde du mainframe voici fort longtemps s'imposent dans la micro: ….

D’accord , et quand bien même les techniques seraient fondamentalement différentes, c’est davantage de savoir-faire (et de faire savoir), d’aptitude au raisonnement (informatique) dont il est question et non de la sempiternelle "guéguerre" ou "confusion" des langages et des outils en général.

et peut-être même une troisième, qui est frappée d’antériorité : l'informatique théorique? Ce que l'on peut pratiquer sans ordinateur et qui s'oppose à l'empirisme ambiant ?

Par antériorité je pensais à préexistence, à la caricature qui bien souvent est faite de l’informatique du passé. Mais si tu peux m’en dire davantage sur cette "Informatique théorique" ça m’intéresse.

Le mode classique de conduite des projets repose sur une erreur

J’en profite pour te remercier à propos de l’intéressante documentation que tu joins à tes textes. "L’informatique administrative" c’est comme cela que je l’appelle. A la lecture de cet article me reviennent mes démêlés avec la hiérarchie. Il est en effet certain que dans un contexte fait de lourdeurs administratives et de "reports ou fuites" de responsabilités, tel celui décrit par l’auteur, il est difficile d’envisager la réussite d’un projet informatique un tant soit peu conséquent.

Toutes les fois où, sur un site j’ai reconnu ou cru reconnaître, cette (dés)organisation je me suis arrangé à terme pour trouver autre chose. C’est ce qui m’a permis d’évoluer dans des structures à dimensions plus humaines où le contact avec l’utilisateur était bien souvent quotidien. Ce qui a pour effet de changer les données du problème à tel point que sur certains sites l’absence de documents se faisait cruellement sentir. Je te fais grâce des détails d’une nouvelle anecdote, mais il se trouve que j’ai dû interrompre brutalement un contrat en qualité de prestataire indépendant faute de "documentation" au sens large du terme et personne sur le site n’était en mesure de me donner ni les noms des pgm ni même "l'endroit" "où" ils pouvaient bien se trouver.

Un projet mené sur un site où le le chef de projet peut dialoguer avec l’utilisateur, visiter les usines et les services concernés, donc observer ce qui se fait et comment ça se fait "à la main" afin de réaliser une analyse et une CRITIQUE de l’existant n’est probablement pas (je n’ai pas vécu les deux expériences) soumis aux mêmes vicissitudes qu’un projet mené de manière "dogmatique" dans une grande administration.


L’auteur fait glisser lélaboration des programmes de la phase de fabrication (travail simple, facile à quantifier) à celle de conception. C’est peut-être ce qui a été tenté, dans les années 70 avec plus ou moins de succès (suivant l’humeur des décideurs informatique), sous la qualification d’Analyste-programmeur, dénomination qui semble d’ailleurs rejoindre la qualification de développeur prise dans son sens plus récent telle que tu la définis. Pour ma part j’ai toujours soutenu que la programmation (vue sous cet aspect) était et est encore, un métier à part entière.


ceux qui pratiquent ainsi rencontrent tôt ou tard des problèmes que seuls les autres peuvent résoudre Oui, c’est vrai et ça a toujours été comme ça.


Cordialement,

90.41.95.210 8 janvier 2008 à 02:23 (CET)