Discuter:Programme informatique

Un article de Wikipédia, l'encyclopédie libre.

Si on définit le programme informatique comme un fichier exécutable, un logiciel est plutôt un ensemble de programmes. Non ? Didier 22:38 jan 19, 2003 (CET)

Euh... Non. Pourquoi un logiciel comporterait-il plusieurs fichiers exécutables? J'ai plutôt l'intuition qu'un logiciel est un programme ayant atteint une taille critique. Et cette définition est encore criticable. Tout dépend du logiciel. Il me semble que Word (est-ce un mauvais exemple?) ne comporte qu'un seul exécutable, tout emacs (c'est mieux non? Emacs est bien un logiciel, pour toi?). Parmentier 21:45 jan 29, 2003 (CET)

Pour moi, tout programme est déjà un logiciel, même si on utilisera plutôt le mot "logiciel" pour quelque chose de plus complexe (sous peine de paraître un peu ridicule); en tout cas la ligne de démarcation n'est pas claire (et n'est pas liée au nombre d'exécutables). Pour ce qui est de Word, je crains que ce soit un mauvais exemple, je parie qu'il y a un gazillion de DLLs (librairies exécutables partagées) là-dedans, et peut-être l'un ou l'autre programme annexe. Ceci dit, on peut toujours définir un logiciel comme un ensemble de programmes et fichiers annexes, qui dans le cas d'un programme isolé se réduit à ce seul programme. FvdP 22:21 jan 29, 2003 (CET)

En micro, c'est vrai que c'est particulier, et qu'on va rencontrer énormément de logiciel avec un seul programme (word, emacs, vi, etc, etc...). Si on prends des exemples sur "gros systèmes" (mainframe), c'est plus net, un logiciel de paie par exemple, sera composé de N programmes. Maintenant, je développe pour la micro, et de temps en temps on a plusieurs .exe pour une activité (bien souvent, un principal et quelques autres pour des fonctions bien particulières). Pour moi, le logiciel, c'est l'ensemble du paquet, les exe sont les programmes. Didier 22:44 jan 29, 2003 (CET)

Oui, mais nous sommes d'accord qu'un programme exécutable seul (dans un cas extrême, car sinon il peut aussi être accompagné d'autres fichiers non exécutables) peut constituer un logiciel? Pour moi un logiciel serait plutôt une entité cohérente (qui traite un "sujet" particulier; zut! je ne trouve pas les termes appropriés) qu'on peut installer et utiliser sur un ordinateur... Hmmm... c'est pas complètement satisfaisant, mais c'est mieux que d'expliciter de quoi est constitué un logiciel (si ça se trouve, ça va encore changer...). Parmentier 19:09 jan 31, 2003 (CET)

On est d'accord :-) Il faudrait trouver le mot pour "entité cohérente". (Logiciel de compta, de paie, de traitement de texte, de gestion de courrier, etc... ça peut-être assez varié) Didier 19:16 jan 31, 2003 (CET)

Dans le grand dictionnaire terminologique, un logiciel est un ou plusieurs programme Pfv2 3 octobre 2005 à 18:00 (CEST)

---

Déplacé depuis programmes

A intégrer dans cet article

Liste d'instructions dans un langage donnée. Cetet liste est traité par un equipement informatique pour realiser des actions.

langage informatique communs : C, C++, assembleur

Les programes peuvent être compilé ou interpreté. voir compilateur, programme informatique.

" ; par exemple la théorie de l'information étudie le comportement de programmes idéaux exécutant des programmes d'ordinateurs générés de manière aléatoire."

Je ne connais pas d'exemple de cela. Il y a des choses comme la complexité de Kolmogorov, mais il s'agit de l'étude de la taille de programmes écrivant des séquences aléatoires. David.Monniaux 23 oct 2004 à 23:53 (CEST)

Il y a bien des objets comme le nombre Oméga de Chaitin, qui est quelque chose comme la probabilité d'arrêt d'un programme aléatoire. Mais ça reste hors-sujet. MM (pas Utilisateur:MM) 9 mai 2005 à 09:45 (CEST)

[modifier] Un programme fait-il ce qu'il doit faire ?

Suite a l'interessant "revert" d'Utilisateur:Aurelienc je lance ce débat : Doit-on dire :

• Un programme informatique indique à un ordinateur ce qu'il devrait faire. ou bien
• Un programme informatique indique à un ordinateur ce qu'il doit faire.

Je suis personnellement en faveur de la seconde solution, car un programme donne l'ordre à un ordinateur de faire, il ne lui laisse pas le choix. Dans la première phrase, on peut penser que l'ordinateur, muni de raison peut ou non décider de ce qu'il doit faire.

On va me rétorquer : Oui, mais il y a les bugs, certes, mais le bug est dans le programme, le programme indique des anneries à l'ordinateur, mais ce dernier doit toujours exécuter ces anneries.

On va me rétorquer : Oui, mais il y a les évenements exterieurs comme les coupures de courant. Certes, mais quand je ne dis pas à un enfant tu devrais faire tes devoirs sous prétexte qu'il peut arriver un accident domestique à mon enfant, je lui dis bien tu dois faire tes devoirs.

C'est pour toutes ces raisons, que je demande à ce que le revert soit reverté. Epommate 22 jun 2005 à 18:01 (CEST)

C'est bien la question des bugs. 99,999% des programmes ne sont pas écrits en langage machine mais dans des langages de plus ou moins haut niveau, dont la plus intéressante propriété est de faciliter la lecture et la maintenance par des humains. Un bug dénote un décalage entre une intention programmée et l'exécution divergente de l'intention. Il est clair qu'un programme, plus précisément son expression intentionnelle, le code source dans tel ou tel langage de programmation, indique ce que devrait faire l'ordinateur, si le programmeur ne s'est pas gourré (et si le compilateur ne commet pas d'erreur, etc.). En général, l'exécution d'un programme incorrect donne des résultats inintéressants (allant de la production silencieuse de faux résultats au crash pur et simple) ; je ne vois pas l'intérêt d'insister sur le fait qu'un programme indique à un ordinateur ce qu'il doit faire dès lors qu'en pratique, pour toutes sortes de raison, il y a un décalage persistant entre ce doit et la réalité. Aurélien

Il me semble que la distinction "doit faire"/"devrait faire" est fondamentale dans le cas de certains langages non-impératifs. Je n'ai malheureusement aucune compétence en la matière, et aucun autre exemple à fournir que celui de l'évaluation paresseuse.

... ou de la programmation logique ou par contraintes peut-être. Mais c'est plutôt une distinction entre devrait et pourrait, dans le sens où certains langages ouvrent la porte à la notion d'exécution paresseuse (on n'exécute qu'en cas de besoin) ou spéculative (on essaye d'évaluer qqchose dans l'espoir d'arriver à un résultat consistant). Aurélien 12 mars 2006 à 22:18 (CET)