Les bases de la programmation

Ou comprendre ce qu’est un programme, un langage de programmation, l’algorithmique.

Le problème exposé dans ce sujet a été résolu.

Tout bien réfléchi, l'ordre des propos me semble correct (de toute manière, il est désormais fixé). Par contre, je suis d'accord avec Looping sur l'excès d'abstraction de certains passages, et je pense que cela peut se régler assez simplement en n'oubliant pas que le tutoriel s'adresse à des débutants. Mais regardons cela en détail.

Introduction

Et pour ce faire, il vous faut déjà comprendre ce qu’est réellement un ordinateur en fin de compte.

Je chipote, mais je ne suis pas certain que ce soit nécessaire ; tout comme il n'est pas nécessaire de connaître le fonctionnement d'une voiture pour en conduire une.

un ordinateur est composé des trois éléments suivants.

J'ai du mal à voir s'il s'agit ici d'une implication ou d'une équivalence. Ce n'est pas très important, mais toute chose composée de tels éléments est-elle un ordinateur ? Le cas échéant, j'en serais donc un ?

De la mémoire, qui peut prendre des formes extrêmement variées

Peut-être pourriez-vous fournir des exemples simples ?

par exemple, une carte graphique, pour afficher des choses sur un support visuel, une carte son, pour… produire du son, une carte réseau, pour communiquer avec d’autres ordinateurs

Pour avoir vécu la réforme des prépas scientifiques, avec des cours obligatoires d'informatique, je pense que beaucoup de ces termes ne seront pas connus par la plupart des lecteurs. Peut-être prendre des exemples plus simples, comme les claviers, souris et compagnie ?

En effet, bien qu’il fonctionne à l’électricité

Une petite note à ce propos pour la culture serait chouette. En fait, ça permettrait peut-être même d'éclairer le propos en disant que l'électricité n'est qu'un moyen particulier de réaliser un automate (cf. remarque suivante) et que ce qu'on a dans nos bureaux ne sont que des cas particuliers d'ordinateurs.

un processeur n’est rien de plus qu’un automate : il est possible de lui donner des ordres, que l’on appelle des instructions, et une suite d’instructions strictement identiques produira systématiquement le même résultat, sans la moindre originalité.

Là aussi, peut-être qu'un exemple d'automate autre qu'un processeur serait judicieux. Idéalement, un exemple de la vie courante, connu du plus grand nombre.

mais elles se ramènent toutes à quatre types.

J'ai du mal à voir ce qu'apporte cette liste au programmeur débutant.

Et cela fait, vous ne saurez vous servir que de votre processeur, mais pas comment lui faire contrôler ses périphériques.

Il me semble que le "mais" ne convient pas. Un "et même" irait mieux je crois. En effet, le "que" est placé devant l'objet, pas devant l'action, tandis que le "mais", lui, porte sur cette dernière.


En somme, je pense que cette introduction est un peu trop technique. Or il y a fort à parier que les lecteurs en seront à leur première expérience informatique, en dehors de l'utilisation basique qu'on peut faire d'un ordinateur (par exemple, je doute qu'ils soient experts en réseau). Du coup, il me semble intéressant de raccrocher ces notions aux choses simples qu'ils connaissent (écran, clavier, clé USB, Windows, etc.).

Pour ce qui est de l'approche historique, ce n'est à mon avis pas le propos ici : beaucoup ne liront pas ce tutoriel comme une introduction à l'informatique, mais comme une introduction à la création de son jeu vidéo méga over cool.

Merci pour le contenu. Le texte est toujours aussi agréable. ^^

+1 -0

Ce tutoriel est une bonne idée je trouve. Mais n'ayant lu que l'introduction, je trouve qu'il y a déjà un problème là : J'ai l'impression que le tutoriel est très orienté matériel.

Le tutoriel se nomme "Les bases de la programmation". Je ne suis pas certain que le fait de savoir de quoi est composé un ordinateur (processeur, mémoire, périphérique), pour pouvoir dire qu'en fait c'est le processeur qui reçoit les instructions, soit utile au débutant qui débarque sur le tutoriel. C'est le travail d'un tutoriel sur le fonctionnement interne de l'ordinateur de dire ce genre de chose. On veut donner les bases de la programmation et la programmation c'est du logiciel/software. On s'attend donc à ce qu'on nous parle de software et pas de hardware (et encore plus dans l'introduction).

Le tutoriel (si vraiment il est destiné à un débutant) gagnerait à prendre l'ordinateur comme une boite noire, et se concentrer sur le logiciel.

@firm1 : Autant je suis d'accord pour que l'aspect matériel soit présenté de manière plus simple et moins technique en vue d'être compréhensible par les débutants, autant je ne pense pas qu'il faille non plus considérer l'ordinateur comme une boite noire : le matériel impacte bien plus qu'on ne le pense la construction des langages, et donc notre façon de comprendre la programmation.

Ce qui serait intéressant selon moi, c'est de décrire l'ordinateur comme un automate, doté d'une mémoire, d'une unité de traitement/transformation de données et de capacités d'échanges avec l'extérieur. De là, on peut expliquer que programmer revient à mettre des choses en mémoire qui seront utilisées pour effectuer du traitement et des interactions avec le monde. Ensuite, faire la distinction instructions/données, et continuer sur le cours tel que déjà fait.


Je suis ravi de voir que ma note à propos d'ARM a été pris en compte, et maintenant je trouve que le rythme de la phrase est un peu cassé :p (je chipote vraiment pour rien) et je proposerais comme alternative "les processeurs de famille ARM conçus par… ARM"


Edit : correction d'erreur syntaxique en Markdown. Faut vraiment que je maitrise mieux ce truc

Mais n'ayant lu que l'introduction, je trouve qu'il y a déjà un problème là : J'ai l'impression que le tutoriel est très orienté matériel.

En fait, tu as lu la seule partie où il est question de matériel. ^^

Je ne suis pas certain que le fait de savoir de quoi est composé un ordinateur (processeur, mémoire, périphérique), pour pouvoir dire qu'en fait c'est le processeur qui reçoit les instructions, soit utile au débutant qui débarque sur le tutoriel.

Je pense au contraire que ça l'est. Ce n'est pas nécessaire, mais bien intéressant ; au même titre qu'il est intéressant de savoir ce qu'il se passe sous le capot quand on appuie sur l'accélérateur ou qu'on change de vitesse.

Ca nous explique ce qu'il se passe, sans rentrer dans les détails trop techniques inutiles au débutant, et permet de ce fait de démystifier la programmation. En prépa scientifique par exemple, les élèves savent, en principe, que print permet d'afficher du texte à l'écran, que cliquer sur tel bouton permet d'envoyer un message à untel sur tel réseau social, etc. mais beaucoup ignorent complètement ce qu'il y a derrière, et donc tout cela leur apparaît "magique". C'est dommage, non ?

Le tutoriel (si vraiment il est destiné à un débutant) gagnerait à prendre l'ordinateur comme une boite noire, et se concentrer sur le logiciel.

Je ne comprends pas le rapport entre le lectorat débutant et l'absence de propos sur le hardware. Du moment où c'est bien expliqué et ne devient pas inutilement technique, où est le problème ?

+3 -0

@firm1 : […] le matériel impacte bien plus qu'on ne le pense la construction des langages, et donc notre façon de comprendre la programmation.

luxera

C'est peut-être intéressant de le savoir, mais je ne pense pas que ce soit nécessaire et pour un débutant. Je dirais même que ça freine la lecture. Je ne vois pas forcément l’intérêt d'expliquer ce qu'est un processeur dans l'introduction d'un cours de programmation. Dire qu'un processeur n'est rien de plus qu'un automate n'arrangera pas les choses, car tu suppose que la notion d'automate est une notion bien connue de tes lecteurs, ce qui n'est pas forcément le cas.

En fait, tu as lu la seule partie où il est question de matériel. ^^ […]

Vayel

Je suis allé lire la suite du coup, et je trouve justement dommage que l'introduction soit si orientée matériel. La suite du cours est compréhensible sans avoir besoin de savoir que derrière c'est le processeur qui reçoit les instructions fait les calculs, je ne comprend pas pourquoi on s'impose donc ces concepts (processeurs, automates, cartes graphiques, carte son, carte réseau, …) ici.

C'est sans doute très intéressant de savoir ce qu'il y a derrière, mais ce ne sont plus les bases à mon sens.

C'est sans doute très intéressant de savoir ce qu'il y a derrière, mais ce ne sont plus les bases à mon sens.

Si on enlève le vocabulaire que seul une personne familière avec l'informatique peut connaître et qui n'est pas très utile ici (carte son, carte réseau, mais pas automate, qu'il me semble important de découvrir), l'introduction n'aborde que des choses simples à propos du hardware. Le contenu revient en gros à dire qu'il y a un moteur dans une voiture.

A la limite, il serait peut-être judicieux de changer cette phrase

Et pour ce faire, il vous faut déjà comprendre ce qu’est réellement un ordinateur en fin de compte.

en un truc du genre

Et pour ce faire, il est intéressant de comprendre ce qu’est réellement un ordinateur en fin de compte.

+0 -0

Je ne vais pas répondre à chacun, mais plutôt essayer d'apporter une réponse globale aux différents points soulevés concernant cette introduction.

Les craintes concernant le vocabulaire.
Les termes comme « carte graphique » ou « carte réseau » sont explicités immédiatement après leur utilisation. Ainsi, si quelqu'un ne sait pas ce qu'est une carte graphique, il saura en lisant simplement la phrase où le mot est utilisé qu'il s'agit d'« un circuit électronique dédié à une tâche précise, et qui sert au processeur à communiquer avec le monde extérieur, […] pour afficher des choses sur un support visuel ». Ce qui est amplement suffisant pour mon propos.

Quand les termes ne sont pas explicités, c'est qu'ils doivent être compris dans leur sens trivial, et non technique. Ainsi, « automate » ne doit pas être compris au sens d'« automate fini » ou autre concept de l'informatique théorique, mais bien de « bidule qui fait des trucs tout seul quand on appuie sur le bouton ».

L'utilité de parler matériel.
L'idée derrière cette introduction, c'est de faire admettre cette vérité fortement contre-intuitive, qu'un ordinateur n'est pas une machine super intelligente, mais un bestiau très très con. D'où, notamment, la liste des instructions disponibles : si je me contente de dire que le processeur ne sait faire que des choses basiques, il y aura nécessairement des sceptiques ; en montrant à quel point il est limité, j'élimine le doute.

Mais évidemment, pour amener ce point, je suis obligé de sortir l'ordinateur de sa boite noire, et de montrer qu'étant donné de quoi il est composé, son « intelligence » est strictement limitée à celle de son processeur. Pour reprendre la métaphore automobile, cela revient à expliquer que la vitesse d'une voiture est largement dépendante de son moteur (et de sa boite de vitesses), et qu'on ne pourra jamais rouler plus vite que ce que le moteur permet.

L'aboutissement de ces explications étant que, pour faire quelque chose d'intelligent avec une machine aussi crétine, c'est super dur. Et qu'on a donc développé des outils pour y parvenir plus simplement, la programmation, roll credits. En mode « je parle à Kevin, 14 ans, qui veut faire le nouveau MMORPG révolutionnaire », ça veut dire « Ben si, faudra bien que t'apprennes un langage bizarre pour faire ton super jeu de la mort, parce que si t'essayes de t'en passer, t'es pas sorti de l'auberge ».

L'utilité de ne point trop en faire.
Ceci étant dit, cette introduction n'a pas vocation à être un cours sur l'aspect matériel de l'ordinateur : je n'y aborde que ce dont j'ai besoin pour permettre à mon explication d'être claire. Pour tout le reste, je laisse le soin au cours de Mewtow de faire le travail mieux que moi : parler des différentes sortes de mémoire, expliquer comment l'électricité fait fonctionner le bousin, développer ce qu'est un automate, détailler ce qu'est une carte son, etc.

De même, cette introduction étant déjà controversée, il ne m'apparaît pas judicieux d'y ajouter encore une histoire des ordinateurs non programmables (on parle bien d'un tuto de programmation), ou pis encore une réflexion sur ce qu'est l'informatique (on ne parle bien ici que de la programmation des ordinateurs).

J'ai malgré tout pris en compte quelques remarques (notamment certaines reformulations), mais rien qui justifie une nouvelle mise en bêta. :)

+2 -0

L'idée derrière cette introduction, c'est de faire admettre cette vérité fortement contre-intuitive, qu'un ordinateur n'est pas une machine super intelligente, mais un bestiau très très con. D'où, notamment, la liste des instructions disponibles : si je me contente de dire que le processeur ne sait faire que des choses basiques, il y aura nécessairement des sceptiques ; en montrant à quel point il est limité, j'élimine le doute.

Personnellement je vois pas le lien avec le matériel. Tu pourrais très bien expliciter cette idée en mentionnant (d'une manière ou d'une autre) une machine de Turing.

Justement, ce qui compte c'est pas le matériel mais ce qu'il permet. À cet égard, je vois pas l'intérêt de décrire chaque composant si c'est pour conclure que ça fait pas grand chose d'extraordinaire. Tu pourrais le dire directement : un ordinateur ne fait rien d'exceptionnel si ce n'est compter rapidement avec des nombres de taille finie.

Les termes comme « carte graphique » ou « carte réseau » sont explicités immédiatement après leur utilisation. Ainsi, si quelqu'un ne sait pas ce qu'est une carte graphique, il saura en lisant simplement la phrase où le mot est utilisé qu'il s'agit d'« un circuit électronique dédié à une tâche précise, et qui sert au processeur à communiquer avec le monde extérieur, […] pour afficher des choses sur un support visuel ». Ce qui est amplement suffisant pour mon propos.

Le souci, c'est que ça ajoute des éléments inconnus du lecteur au texte. Certes, ce n'est pas compliqué, mais il me semble préférable, pour un contenu destiné majoritairement à des débutants, de rester sur du familier.

Quand les termes ne sont pas explicités, c'est qu'ils doivent être compris dans leur sens trivial, et non technique. Ainsi, « automate » ne doit pas être compris au sens d'« automate fini » ou autre concept de l'informatique théorique, mais bien de « bidule qui fait des trucs tout seul quand on appuie sur le bouton ».

Le problème, c'est que je ne suis pas sûr que ce sens soit trivial pour tout le monde. ^^

L'idée derrière cette introduction, c'est de faire admettre cette vérité fortement contre-intuitive, qu'un ordinateur n'est pas une machine super intelligente, mais un bestiau très très con. D'où, notamment, la liste des instructions disponibles : si je me contente de dire que le processeur ne sait faire que des choses basiques, il y aura nécessairement des sceptiques ; en montrant à quel point il est limité, j'élimine le doute.

Ce qu'il y a, c'est qu'on ignore que cette liste a pour seul objectif de montrer la stupidité d'un processeur. Ce fut notamment mon cas, puisque j'ai fait une remarque à ce propos. Peut-être pourrais-tu te montrer un peu plus explicite sur ton raisonnement ?

Il faudra que je repasse sur cette introduction, puisque des passages m'ont échappé, comme :

Copier le contenu d’un emplacement en mémoire vers un autre emplacement en mémoire.

Je ne suis même pas certain que le débutant sache ce qu'est un disque dur (une clé USB probablement, parce qu'on s'en sert, mais un disque dur reste souvent dans la boîte). Du coup, je ne pense pas qu'il connaisse la notion d'emplacement. :)

+0 -0

Salut,
Je viens de m'apercevoir d'un truc : tu ne parles pas du tout d'HTML. Ce n'est pas un langage de programmation, certes, mais le débutant ne le sait pas ! Surtout que tu parles de développement Web, avec Javascript par exemple, et de langages cotés client/serveur (du coup un lecteur pourra se dire "attends, moi on m'a parlé d'un truc qui s'appelle HTML"). Et du coup je m'aperçois aussi que tu parles de ces notions sans les définir (appli web, site dynamique, coté client/serveur…).

Bonjour,

Je viens de relire le tutoriel (sauf la description finale des langages de programmation).

Je pense qu'il constitue une bonne introduction pour les débutants (mais je ne suis plus débutant depuis un moment maintenant donc mon avis est un biaisé). Un autre tuto générique sur les structures de données et de contrôles serait interessant mais ce sera certainement le sujet du tuto sur les paradigmes de programmation.

Quelques commentaires au fils de la lecture :

Vocabulaire

il est possible de lui donner des ordres, que l’on appelle des instructions, et une suite d’instructions strictement identiques produira systématiquement le même résultat, sans la moindre originalité.

Je ne mettrai pas le "produira systématiquement le même résultat" mais plutôt "aura exactement le même fonctionnement / les même conséquences". Le résultat est dépendant des données de départ et la définition de résultat est fortement influencée par les mathématiques.

Schéma

Sur la partie entre le code source et l'exécution, il serai peut être bien d'avoir un schéma avec les différentes étapes :

  • code source
  • compilateur ou interpréteur
  • binaire ou bytecode
  • actions

Je pense à quelque chose comme ce schéma mais en plus simple :

Les outils

Entre "Un compilateur ou interpréteur" et "Un débogueur", j'aurai ajouté une section "Outil divers" pour présenter les outils de type make, ant, maven qui servent à outiller la chaîne de compilation et à faciliter le processus de développement.

Frameworks

Dans la section "Les structures logicielles", je ferai quand même la distinction entre les bibliothèques spécialisées dans une fonction (apache commons en java, glib en c, etc.) et les frameworks complets qui structurent complètement l'application cible (django en python, jee en java, qt en c++). Le paragraphe me semble très orienté framework complet j'ai l'impression qu'il laisse à penser que lors ce qu'on utilise n'importe quoi ne faisant pas partie de la bibliothèque standard on vend son âme à un framework.

Langage de présentation

Je rejoins Looping sur le html mais de manière plus générale, le tutoriel est fortement axé sur la présentation des langages de programmation avec l'exécution pour cible (quel que soit le paradigme). Je pense qu'il manque au moins une définition des langages de description de données, peut être juste pour dire qu'ils ne sont pas décrits dans le document.

Par exemple, une note après "les limites du classement" : Il existe également une catégorie de langage qui servent à décrire des données afin de les présenter. On trouve des cycles de compilation et d'interprétation similaires à ce qui a été décrit plus haut mais le but n'est pas de produire une suite d'instructions exécutable par la machine mais un document. Ce document peut être imprimable, affichable à l'écran ou même être compréhencible uniquement par une machine. On trouve parmis ces langage le html, le markdown, le latex, etc.

Encore bravo à tous pour cet exellent tuto.

Bon courage pour la suite

Bonjour

Comme beaucoup de mes prédécesseurs, j'ai du mal avec la première partie. Après lecture de ton explication, je comprend où tu veux en venir, mais ça ne ressort pas dans le texte. Je n'ai pas nécessairement de proposition pour y remédier cependant.

Quelques petites remarques et interrogations, fort probablement dues à mon statut d'éternel débutant :)

Il existe au total des milliers de langages différents. Certains sont proches du fonctionnement réel de la machine, d’autres très éloignés : on appelle les premiers des langages de bas niveau et les autres des langages de haut niveau.

Qu'est ce qu'un fonctionnement réel proche ou éloigné de la machine ? L'expliquer plus en détails permettrais peut-être d'éclairer la première partie.

Je suis également d'accord avec mes VDD en ce qui concerne le html. Ca pourrait s'introduire dans ce paragraphe par exemple.

Pour programmer des applications Web, vous devrez apprendre deux langages (notez qu’il commence à être possible d’utiliser le même langage des deux côtés). Pour le côté client, JavaScript est à peu près inévitable, sauf à utiliser un langage qui génère du JavaScript, comme CoffeScript ou Elm. Pour le côté serveur, PHP tient le haut du pavé, mais Python et Ruby se défendent bien. Il est également possible de réaliser des applets Java, ou des applications Flash avec ActionScript, mais ces pratiques sont de plus en plus décriées.

Il n'est nulle part fait mention des langages de type shell.

Je me serais également attendu à trouver des petites explications sur les variables, les boucles, les tests qui me semble des notions communes à presque tous les type de langage, excepté ceux de présentation.

En tout cas, ça sera un tuto super utile je pense :)

Vous savez quoi ? Les topics en bêta, c'est génial pour faire de la validation, alors je vais en profiter.

En gros, le tuto est presque prêt à être publié au moins dans une première version. Les problèmes suivants doivent être corrigés pour que soit possible :

  1. Les explications que tu as donné quant à la première partie me conviennent, mais doivent transparaître dans le texte. Personnellement, en l'état, elle m'a plus embrouillé qu'autre chose, et son but n'est absolument pas évident sans explication.
  2. C'est triste, mais on ne peut pas mettre de lien vers un tuto en bêta dans un tuto publié. Déjà parce que les lecteurs non inscrits ne peuvent pas les voir. Ensuite, parce que ces contenus ne sont pas considérés comme publiables par leurs auteurs, avec tout ce que ça implique – à commencer par le fait qu'ils ne seront peut-être jamais finis.
  3. Un détail irritant : les connaissances en Java exposées sont complètement périmées et te font dire des erreurs :
    • L'exemple de code ne ressemble à rien.
    • La gourmandise en ressources est équivalente ou moindre que la plupart des autres langages présentés.
    • Java est très présent côté serveur, et en plus on a sans doute le meilleur tuto francophone sur le sujet.
    • Plus personne ne fait d'applet Java (et de toutes façons presque aucun navigateur moderne ne les accepte)

Au-delà de ça, il me reste une question : pourquoi les exemples de codes source sont des captures d'écran et non des codes sources ?

C'est triste, mais on ne peut pas mettre de lien vers un tuto en bêta dans un tuto publié.

On peut signaler que la bêta existe ou même ça c'est hors limite ? Le cours de Mewtow sur le fonctionnement des ordinateurs, il faut le sabrer aussi, malgré la certitude qu'il sera terminé, et le fait qu'il avait déjà été publié une première fois ? :)

L'exemple de code ne ressemble à rien.

J'ai pas de code Java sous la main, alors j'ai pris un code tiré du Javaquarium.

pourquoi les exemples de codes source sont des captures d'écran et non des codes sources

Parce qu'on nous a demandé des images pour aérer le texte, et que dans cette section-là, on peut difficilement mettre autre chose que des captures d'écran de code source.

+0 -0

Tu peux signaler qu'un tuto est en préparation, oui. Le but est vraiment d'éviter que des liens d'un contenu public ne renvoient vers un forum privé et par nature fortement instable.

Pour le code Java (et pour les autres langages), n'hésite pas à piocher dans les programmes libres, comme Joda Time ou Apache Tomcat (licences Apache).

Et OK pour les screenshots de différents codes / éditeurs pour illustrer.

Créer des programmes

Tous et chacun de vos jeux vidéos

Il me semble qu'il n'y a pas de s à "vidéo".

c’est lui qui décide quel programme tourne à quel moment sur le processeur

J'ai peur que le débutant ne comprenne pas cela, vu que les explications sur les programmes dans ce qui précède se résument à "Programmer un ordinateur, cela consiste donc à placer en mémoire les données adéquates pour que votre processeur et ses périphériques, contrôlés par lui, se comportent comme vous le voulez.", dans l'introduction.

le disque dur ne sait pas ce qu’est un fichier, il ne connaît que les secteurs, des blocs de mémoire d’une taille déterminée. Un programme va se contenter de demander à lire tel fichier, et c’est le système d’exploitation qui convertira cela en instructions destinées au modèle précis de disque dur présent dans la machine. De cette manière, ce programme pourra fonctionner sur une autre machine, et avec un autre modèle de disque dur, pour peu que le même système d’exploitation y soit installé : pas besoin de le réécrire.

Au début, tu dis que le disque ignore ce qu'est un fichier, puis qu'on demande à l'OS d'en lire un. Du coup, on s'attend un peu à ce que tu dises que l'OS "transforme les secteurs en fichiers", et pas uniquement qu'il permet de gérer différents types de disques. Autrement dit, il serait peut-être judicieux d'expliciter "et c’est le système d’exploitation qui convertira cela en instructions destinées au modèle précis de disque dur présent dans la machine".

Vu que je m'exprime peu clairement, j'illustre mes propos avec un exemple de formulation :

et c’est le système d’exploitation qui convertira cela en instructions destinées au modèle précis de disque dur présent dans la machine : à partir d'un nom de fichier, il demande au disque le contenu de certains secteurs afin de reconstituer ledit fichier

On affiche généralement les fichiers sous une forme arborescente, au moyen d’un gestionnaire de fichiers (ici, Nemo), qui est lui-même un programme.

Je le note ici, parce que j'y ai pensé à ce moment-là, mais tu donnes beaucoup d'exemples de programmes offrant une interface graphique. Il est évident que derrière une telle interface il y a quelque chose, mais ne penses-tu pas que le débutant pourrait penser qu'un programme est nécessairement "une fenêtre" ?

En effet, quand on fait faire à un programme ce pour quoi il est conçu, on dit qu’on l’exécute.

Cette phrase veut-elle bien dire qu'un fichier exécutable est un programme (ainsi que la réciproque) ?

Une bibliothèque logicielle est une collection de petits outils destinés à une tâche bien précise qui sont partagés, car ils peuvent être utiles à de nombreux programmes.

Quelle est la différence entre une bibliothèque logicielle (un .so) et une bibliothèque Python, par exemple ?

cela consiste à générer un ou des fichiers exécutables pour un système d’exploitation donné (ou des données exécutables sans système d’exploitation, si vous êtes un Rambo de l’informatique), éventuellement par plusieurs systèmes d’exploitation

Tu as un coup un "pour", un coup un "par", ça fait un peu bizarre. ^^


Tu me connais, j'aime bien les trucs visuels. Du coup, je me demandais s'il pourrait être judicieux de faire un schéma qu'on compléterait au fur et à mesure, histoire d'avoir une vue d'ensemble sur les diverses notions (bibliothèque, programme, logiciel, code source, langage, etc.).

+0 -0

Au commencement était le code source

AJOUTE MEM2 et MEM1 et stocke le résultat dans MEM2

Je ne comprends pas à quoi sert cette ligne.

Voici un exemple de code source, ici dans le langage Rust et sous l’éditeur Sublime Text.

Peut-être serait-il préférable de ne pas parler de Sublime Text avant d'introduire la notion d'éditeur ? Un exemple de code source sous forme de code source (entre les balises correspondantes) serait peut-être plus adapté, non ?

Le bon côté, en revanche, c’est qu’un même code source pourra être compilé ou interprété de manière à fonctionner sur plusieurs processeurs différents : là où chaque processeur doit être contrôlé au moyen de ses instructions spécifiques qui ne marcheront pas ailleurs, un programme écrit dans un langage de programmation autre que l’assembleur sera réutilisable sur d’autres types de machine, pour peu que le compilateur/interpréteur soit disponible sur cette plate-forme.

Il semblerait que cela soit une conséquence de "On appelle cela la syntaxe d’un langage, et si on ne la respecte pas à la lettre, le compilateur/interpréteur refusera de fonctionner.", mais je ne comprends pas pourquoi.

et la programmation concurrente

C'est la programmation asynchrone ?

En effet, il serait très pénible de réinventer la roue chaque fois que l’on veut créer un nouveau programme.

Mais il y a les bibliothèques logicielles pour ça, non ?

+0 -0
Ce sujet est verrouillé.