Skip to content

Généralités (suite)#

Tu es toujours là ? Toujours motivée ? Trop bien ! Reprenons !

Un travail à vocation universelle#

Tu as vu dans le chapitre précédent que la programmation est l'art de mêler l'algorithmique à un ou plusieurs langages.

L'algorithmique est une question de méthode (beaucoup) et de logique (un peu). Elle est indépendante des langages de programmation et indépendante des machines qui exécuteront le programme final. En revanche, le langage de programmation, lui, est lié au coté physique et matériel de la machine car il doit être compris et exécuté par cette dernière.

On va donc distinguer deux types de langages :

  • les langages bas niveau (ex: Assembleur, C ...) : ils permettent la manipulation des aspects matériels de la machine sur laquelle le programme est exécuté. Ce sont des langages terre à terre, qui nécessitent un micro-management de chaque chose : mémoire, périphériques, registre processeur, interruptions, réseau, etc. C'est à la fois fastidieux, mais c'est terriblement précis et puissant.
  • les langages de haut niveau (ex: Python, Javascript ...) : ils masquent le coté technique au profit d'une vision plus abstraite qui leur permettra plus facilement de manipuler des fichiers, des composants graphiques, des données, etc. Ces langages font confiance au système pour la gestion de la mémoire et du reste. Ils vont s'occuper essentiellement des aspects métiers.

Haut et bas niveau n'ont pas de connotation péjorative et n'ont évidemment rien à voir avec les compétences techniques nécessaires à les programmer ! Il s'agit simplement d'une question d'efficacité sur un domaine particulier... et la facilité à gérer contraintes qui vont avec. On pourra toujours faire des choses de bas niveau avec un langage de haut niveau, ou des choses de haut niveau avec un langage de bas niveau. C'est juste beaucoup moins pratique.

En général, les langages de bas niveau sont des langages compilés — car dépendants d'une machine spécifique — alors que les langages de haut niveau sont souvent des langages interprétés.

La Reine avait une seule méthode pour résoudre toutes les difficultés, petites ou grosses.
— « Qu'on lui coupe la tête ! » dit-elle sans même lever les yeux.
Lewis Caroll, Alice au pays des merveilles

Problèmes fondamentaux en algorithmique#

Programmer, c'est comme résoudre un casse tête. C'est un peu un défi qui nécessite d'inventer une solution face à un problème ou une situation donnée. Reste à le faire bien. Lorsqu'on programme, à un moment ou un autre, on se posera des questions sur la calculabilité, la complexité ou la correction de l'algorithme que l'on est en train de concevoir.

La calculabilité est la capacité à calculer un résultat ou une solution : Pour une tâche donnée, existe-t-il un algorithme qui la résolve ? Existe-t-il des tâches pour lesquelles il n'existe aucun algorithme ? Comment savoir si l'on est dans l'un ou l'autre des cas ?

La complexité lie le nombre d'opérations exécutées par l'algorithme à la taille ou la quantité des données qu'il manipule. C'est donc une question de performance et d'optimisation : en combien de temps un algorithme va-t-il atteindre le résultat prévu ? De quel espace (mémoire) a-t-il besoin pour faire son travail ?

Lorsqu'on parle de complexité, on utilise la notation O(...) pour parler des différence de complexité d'un algorithme. Voici les principaux cas :

  • O(1) : l'algorithme en temps constant. C'est excellent ! Il prends toujours le même temps quelle que soit la taille ou la quantité de données qu'il manipule.

  • O(N) : l'algorithme en temps linéaire. C'est moyen. Il prends un temps proportionnel à la quantité de données manipulées.

  • O(log N) : l'algorithme est en temps logarithmique. C'est très bien ! Il prends moins de temps qu'un parcours complet des données.

  • O(N*N*..) : l'algorithme est en temps polynomial. C'est pas terrible. Il prends un temps qui est le carré, le cube ou autre polynôme de la quantité de données manipulées.

  • O(exp(N)) : l'algorithme est en temps exponentiel. C'est pire que tout ! Il y a de fortes chances que l'on n'obtienne pas les résultats dans un temps raisonnable (temps alloué au projet, vie humaine, âge de l'univers, etc.) ;-(

Enfin la correction c'est pouvoir prouver qu'un algorithme répondre bien au besoin pour lequel il a été conçu... et c'est loin d'être évident !

« — Voudriez-vous me dire, s'il vous plaît, par où je dois m'en aller d'ici ?
— Cela dépend beaucoup de l'endroit où tu veux aller.
— Peu m'importe l'endroit...
— En ce cas, peu importe la route que tu prendras.
— ... pourvu que j'arrive quelque part », ajouta Alice en guise d'explication.
— « Oh, tu ne manqueras pas d'arriver quelque part, si tu marches assez longtemps. »

À suivre ?#

Ouf. Jusque là j'ai essayé de poser le contexte, un peu de culture générale et du vocabulaire. Normalement on n'abordera plus ces sujets (à moins que ta curiosité ne prenne le dessus... et que je me laisse faire).

Au prochain chapitre on plongera dans les algorigrammes et on commencera à dessiner nos idées.

Programmer peut entraîner de graves troubles de la vie sociale

En cas d'apparition des symptômes suivants : impossibilité de résister aux défis logiques, envie de dialoguer avec son programme, veillée tardive devant son écran, recherche compulsive sur StackOverflow, réflexions nocturne sur un bug, parler d'un bug à ses proches, dire à quelqu'un qu'on arrive et arriver 1h après, essayer d'automatiser la moindre tâche... n'essaye pas de consulter un spécialiste, il est trop tard, tu êtes foutue ! ;-)