Définition et Difficultés

1  Définitions :

Pour définir la programmation, on peut se mettre dans le contexte historique :

Un ordinateur suivant la définition acceptée de Von Neumann, est une machine dont le programme est enregistré dans sa mémoire.
Dans sa mémoire, le programme est dans une forme dite "exécutable", c'est à dire une forme binaire interprétable directement par les circuits logiques de la machine.

Par programme d'ordinateur on entendait en 1940, 1950, 1960, la série d'instructions qui définissent la série d'opérations élémentaires que la machine doit effectuer pour exécuter une ou plusieurs tâches données. On utilisait alors des instructions définies en langage binaire, puis en langages de base transformés ensuite par un programme "interpréteur".
A chaque instruction élémentaire correspond la commande d'un circuit logique (électro-mécanique ou électronique).

Cette définition est restée valable depuis les machines à cartes perforées et les premiers calculateurs jusqu'à l'apparition, au début des années 1960, des "systèmes opératoires".

Les systèmes opératoires sont des séries de programmes chargés de gérer et coordonner les fonctionnalité de base de la machine. Ils sont réalisés pour une fois pour toute pour une série de machine. Actuellement , par exemple, UNIX, LINUX, WINDOWS sont des systèmes opératoires. Les systèmes opératoires sont, en quelque sorte, l'interface entre les logiciels d'application et le matériel.

La programmation prend maintenant un sens plus vaste : il s'agit de l'ensemble des instructions à définir pour résoudre un problème donné, sans s'occuper des spécificités propres à une machine donnée, mais en tenant compte du ou des systèmes opératoires prévus et des langages disponibles.
On programma ainsi via des "langages" élaborés tels anciennement FORTRAN, COBOL, BASIC, RPG et maintenant C et C++, HTML, JAVA, ...(la liste est longue, tant des anciens langages que des modernes).
Pour ce qui concerne les ordinateurs qui furent vendus par Bull, GE, Honeywell, CII, consulter les tableaux des langages de programmation présentés dans ce site.

Un programme est une unité logique d'exécution. Une application, un logiciel, un progiciel sont constitués d'une multitude de programmes, appelés en mémoire au fur et à mesure des besoins.

Toutes ces notions sont explicitées dans de multiples ouvrages, plus ou moins approfondis.
Le lecteur belge intéressé par ces questions trouvera entre autre en librairie un excellent ouvrage destiné aux étudiants en première année universitaire en Informatique :
 « Les fondements de l'informatique - Du bit à l'Internet », par H.Bersini, M-P. Spinette et R. Spinette.  La dernière édition de cet ouvrage paraîtra fin 2008 chez Vuibert (France)

2   Difficultés :

Si , sur Internet, la littérature abonde concernant les langages de programmation, l 'accent a été moins mis sur les difficultés qui furent et sont encore rencontrées par les rédacteurs de programmes, les programmeurs. J'en reprend une liste, non exhaustive :

Il n'est pas facile de bien saisir toute la portée et les nuances définies par l'analyse fonctionnelle et détaillée du problème. L'analyse est un travail spécifique qui ressort généralement de la responsabilité de l'analyste ou du chef de projet. Une analyse incomplète ou mal transmise ne peut conduire qu'à un programme inadapté aux besoins des utilisateurs. Divers outils existent pour éviter de tomber dans ce piège.

Programmer de manière efficace suppose de concevoir une bonne structure générale de ce programme. Chaque fonction particulière : affichage de résultat, fonction de calcul, fonction de recherche, etc fait l'objet de sous-programmes ou tâches appelées par le programme principal. On dira alors du programme qu'il est "structuré". Une bonne structuration est essentielle pour assurer une bonne fiabilité du programme.

S'il est devenu relativement simple d'écrire un programme, il est difficile de concevoir des "jeux d'essais" qui reproduisent les conditions d'emploi du programme.
Ainsi la phase de test est-elle critique et nécessite la collaboration active de futurs utilisateurs. Le programmeur imagine mal la manière dont un non informaticien va réagir face à ce que lui a prévu.

Un programme quel qu'il soit doit respecter des normes de réalisation, en vue d'en faciliter les corrections et les adaptations futures.
Un programme vite fait mais mal conçu finira par coûter très cher en maintenance.

Les applications qui tournent actuellement sur les grands serveurs informatiques impliquent des millions d'utilisateurs. Le moindre défaut dans un programme entraîne des coûts énormes. Cela se vit encore régulièrement quand un opérateur (télécoms, télévision, banque, ..;) procède à l'introduction d'une nouvelle version de son logiciel.

Le dialogue entre analyste et programmeur doit aboutir à un dossier d'utilisation (aide, mode d'emploi) précis et clair. S'il peut exister des lacunes dans les explications d'un programme de correction de photos ou même d'un tableur, il ne peut exister aucune ambiguïté dans les explications concernant un programme comptable ou de gestion des approvisionnements, par exemple. Bien entendu, ces explications qui se retrouvaient à l'époque dans un dossier papier sont maintenant rendues disponibles via le poste de travail de l'utilisateur.

Plus des programmes sont destinés à un grand nombre d'utilisateurs, plus il faudra les rendre faciles à utiliser, faciles à comprendre et clairement documentés.
Ils doivent se présenter dans  la langue des utilisateurs. En Belgique, au Québec on ne pourra présenter une application que si elle est au moins bilingue.

Le travail produit par un programmeur ou une équipe de programmation est souvent sous-traité à une firme extérieure à l'entreprise propriétaire du produit.
Cela entraîne une difficulté supplémentaire : la validation de programmes fournis.

Il est souvent demandé au programmeur de corriger ou modifier des programmes dont il n'est pas l'auteur. Cela demande une grande souplesse d'esprit.

Si les langages de programmation sont relativement standards, les environnement dans lesquels les programmes sont censés tourner ne le sont pas : Unix, Linux, Windows, Systèmes propriétaires. Le programmeur devra en tenir compte quand il fait appel à des routines ou des interfaces avec les systèmes opératoires.

Pour certains programmes, tels les éditeurs, les anti-virus, par exemple, il faut une bonne connaissance des interfaces avec les systèmes opératoires dans lesquels ils sont censés fonctionner. Pénétrer la connaissance de ces interfaces n'est généralement pas chose aisée. Rappelons que la condamnation de Microsoft par la Commission Européenne concernait précisément la non publication par ce dernier des interfaces opératoires de son système Windows.

Comme dans bien des domaines, parmi les pièges qui attendent le programmeur, un des pires est la ou les modifications des spécifications en cours de travail.
Dans le pire des cas, une modification peut entraîner un bouleversement complet de la structure du programme.
En tout état de cause, le programmeur doit tenir son propre journal des modifications, car retracer celles-ci après quelque temps devient vite impossible. Il ne doit jamais compter sur l'analyste ou le chef de projet pour le faire à sa place, car eux ne mesurent pas toujours le poids des modifications demandées.