Je vais être un peu moins d'accord et un peu plus nuancé, en tant que docteur en informatique (j'ai certes beaucoup moins d'expérience que toi, même si je programme depuis près de 20 ans). Ou du moins des éléments qui sont assez imprécis ou qui peuvent prêter à confusion à mon sens.
Et le constat est sans appel : LA base, c'est l'algorithmique... Le langage derrière n'est qu'une traduction.
Il faut surtout savoir de quoi on parle. Si on parle de programmation pure et dure, l'algorithmique n'a rien avoir là dedans. Si on parle de faire de l'informatique (donc résoudre des problèmes complexes au moyen de l'outil), il faut en effet prendre en compte l'algorithmique qui est une sous discipline des maths. En d'autres termes, tout le monde peut apprendre à programmer, mais pas tout le monde est capable de résoudre tous les problèmes, et c'est là une différence majeure. Pour imager, tout le monde peut prendre une casserole, mettre de l'eau et cuir des pâtes, mais uniquement un cuisinier peut réaliser des pâtes aldente.
Donc non l'algorithmique n'est pas la base de la programmation. Ensuite, l'algorithmique ne s'apprend pas avec les briques de bases que tu énonces qui ne sont qu'un moyen de formaliser facilement un problème. La vérité c'est qu'on apprenait au primaire l'algorithmique bien avant l'arrivée de l'informatique par un truc simple: la résolution des problèmes en maths. Exemple:
"Le train A par de la gare C à 9h20. Elle est distance de la gare B de 20km. Sachant que le train J part de la gare B à 9h26, à quel endroit les deux trains vont-ils se croiser s'ils roulent à vitesse constante ?"
Trouver une méthode pour résoudre ce problème, c'est de l'algorithmique et c'est bien plus efficace en terme d'apprentissage de cette discipline, c'est même la base. Une autre façon de faire de l'algorithmique: jouer avec des légos. C'est d'ailleurs à la base ça qui a motivé l'essor de la programmation par blocs (qui est en quelque sorte un paradigme de programmation de la famille des paradigmes visuels) que vous mentionnez dans vos post précédents.
Les briques que tu décris d'ailleurs ne sont qu'une méthode de pensée lié à la programmation impérative, et quand on passe en programmation fonctionnelle, certaines n'existent plus (pas de boucle, pas de condition par exemple). Ce n'est donc pas du tout lié à l'algorithmique et plus largement c'est quelque chose de restreint à une famille de paradigmes.
Enfin, il y a deux grandes classes de langage, et dans une moindre mesure, une petite troisième, correspondant aux trois paradigmes principaux (procédurale / orientée objet / événementielle)
Alors non il y a beaucoup plus de paradigmes que ca, et les langages ne correspondent pas aux paradigmes, il n'y a pas de "classe de langage" (ou bien on parle au niveau de la théorie des langues et ce n'est pas du tout la même chose). De nombreux langages sont multi paradigmes justement (le C++ est classé par abus de langage dans la catégorie des langages "orientée objet", mais en réalité, c'est un langage qui permet d'expliciter un problème selon différents paradigmes dont le plus courant est l'orienté objet; le Java lui ne permet pas de faire du déclaratif mais il permet de faire de l'orientée objet, de l'évènementielle, de la programmation concurrente etc; Smalltalk ne permet de formaliser qu'un problème pensé en orientée objet). Les grandes familles de paradigmes sont: le type impératif qui regroupe les paradigmes qui explicite un problème sous forme d'instructions (Allez ici, ouvrir le coffre, mettre la pièce, fermer le coffre, etc), le type orientée objet qui décrit le problème sous forme de relation entre objet (pour accélerer la voiture, je dois appuyer sur la pédale qui va entraîner l'ouverture de la chambre à combustion, qui va permettre au gaz de s'échapper et d'entrer les pistons qui vont faire tourner la chaine motice), le type déclaratif qui permet de décrire la solution à un problème sous forme d'une description (typiquement la toile est composée de couleurs bleu, noir blanc en haut à gauche, et rouge vert jaune en bas à droite) et les autres qu'on ne classifie pas parce que trop nombreux. On peut également parler des paradigmes visuels cités précédemment.
Le paradigme n'est rien d'autre qu'une manière de conceptualiser un problème, une manière de pensée. Un langage permet d'expliciter cette forme de pensée ou non. Si on veut prendre un exemple dans la vie de tous les jours, la langue française permet d'expliciter le masculin et le féminin mais pas le neutre, tandis que l'anglais permet d'expliciter le neutre, et rarement le masculin ou le féminin.
Les langages de script sont des langages également. Un langage de script est interprété par un programme, et un langage de programmation permet de produire des exécutables qui seront directement exécutés par le processeur ou par une VM.
Il y a quelques années, quand la rapidité de traitement était privilégiée, on choisissait les langages compilés. De nos jours, avec la puissance des machines, la différence de rapidité n'est plus flagrante.
Quelque soit la puissance de la machine, un langage compilé est toujours nettement plus rapide qu'un langage interprété, et ce sera toujours le cas, rien avoir avec la puissance de la machine. Et la vitesse reste flagrante. La réalité c'est que ca dépend du problème à traiter, de la classe de l'algorithme utilisé pour résoudre le problème et du niveau de maîtrise du langage. Dans la majorité des cas, les programmes "simples" s'exécutent très vite, et on parle de vitesse de l'ordre de la micro ou de la nanoseconde, donc ca te donne l'impression que ce n'est pas flagrant, mais ca le reste. Un algorithme qui prendra 10 microsecondes à s'exécuter sur un langage de script, prendra 10 nanosecondes sur un langage compilé. Le seul truc qui fait qu'on choisisse un langage interprété qu'un langage compilé: la facilité d'utilisation. On ne se pose pas la question des différentes architectures et des différentes spécificités des systèmes lorsqu'on implémente un programme, et on laisse ça à l'interpréteur. C'est tout. Dans un langage compilé, tu es obligé de prendre en compte beaucoup plus de paramètres et l'optimisation passe à la fois par l'optimisation algorithmique et par l'optimisation technique, ce qui rend le tout complètement inaccessible à des non-spécialistes. C'est pour ça que des langages comme Python gagnent en popularité, parce qu'ils ne nécessitent pas de connaitre des éléments pourtant important en informatique, et qui sont moins important du point de vue de la programmation. Une personne qui ne connait pas toutes les subtilités du C++ et de sa traduction en ASM peut produire un exécutable 10 à 15 fois plus lent que le même algorithme codé en Python. Est ce que c'est parce que c'est le langage qui est plus "lent" ou parce que la personne n'est pas assez compétente dans ce langage ? Par ailleurs, il y a beaucoup de domaines où la vitesse de traitement est toujours privilégié: le jeu vidéo, les systèmes embarqués, les banques par exemple. On y verra très peu de langage de script et les langages interprétés restent sur les processus peu critiques (tu verras jamais un pilote automatique programmé en autre chose qu'en C ou en Fortran et pour encore longtemps).
Bref, je suis désolé, mais je fais parti de cette génération qui milite pour faire comprendre que l'informatique et la programmation sont deux domaines différents, parce que j'en ai assez de voir débarquer à l'université des personnes qui confondent les deux, et qui se rendent compte rapidement que l'informatique est quelque chose de beaucoup plus complexe et pour lequel la programmation n'est qu'une partie minuscule immergée de l'iceberg.
Au final, on se retrouve avec des étudiants qui ne sont ni bons en informatique ni bons en programmation et c'est de plus en plus compliqué de leur faire comprendre parce qu'ils arrivent dans nos cours totalement formatés (et pas dans le bon sens du terme).
Et pour ma part, si je pense que l'initiation à la programmation est une bonne chose sur le papier, c'est une fabrique à mauvaises habitudes et à incompréhension. Il est de plus en plus difficile dans le milieu universitaire de trouver des informaticiens qui comprennent réellement ce qu'ils font, tout simplement parce qu'il y a un méli-mélo et un amalgame de tous les concepts qu'ils ont appris dans leur parcours. Je pense qu'il serait plus sain de faire comprendre la différence entre s'initier à la conceptualisation (ce qu'on enseigne au final aux enfants au travers des paradigmes visuels), la programmation (qui consiste à un manipuler un langage technique pour formaliser un problème conceptuel - un programmeur se doit de maîtriser tous les aspects du langage qu'il utilise, et pas nécessairement l'algorithmique derrière), et l'informatique qui consiste à résoudre des problèmes liés au traitement de l'information (au sens large) au moyen d'un outil électronique ou non (et là c'est l'algorithmique qui prime sur la maîtrise des langages). D'ailleurs, c'est pour cela qu'il y a deux branches dans les pays anglophones: le Computer Engineering et le Computer Science. Le Computer Engineering sera justement orienté sur l'aspect technique de l'informatique et la maitrise technique, tandis que le Computer Science est plus orienté sur la conceptualisation et la résolution des problèmes.
Hors sujet, et je n'ai pas encore cherché sur le forum. Je suis toujours épaté par ceux qui parlent des langues étrangères. Y a-t-il un lien avec l'algorithmique. Je veux dire par là, un mécanisme commun genre sujet / verbe / complément, puis une traduction dans la langue ? Sachant que, comme pour les langages informatiques, on fini par penser directement dans le langage (donc la langue).
Tu parles de plusieurs choses distinctes. La programmation (ou du moins les langages) n'est issue que de la théorie des langages qui traite justement de la transformation et du traitement symbolique de l'information. Ce que tu appelles langages n'est rien d'autre qu'un ensemble syntaxique auquel on associe une sémantique. Les langages de programmation font parties des langages dits formels qui sont un sous-ensemble des langages dits naturels (que tu appelles langue). Ca devrait répondre à ton interrogation.
Pour finir sur une note d'optimisme, la réalité c'est vous faites tous de la programmation ou de l'algorithmique sans vous en rendre compte dans la vie de tous les jours. A chaque fois que vous programmez votre micro-onde, vous faites de la programmation. Lorsque vous manipulez votre classeur excel en utilisant les formules, vous faites de la programmation. Lorsque vous programmez votre réveil, vous faites de la programmation. Lorsque vous résolvez un problème de tous les jours, par exemple, vous voulez vous rendre à Paris alors que vous êtes à Brest, vous tracez un itinéraire en prenant en prenant en compte certaines villes selon certains critères, vous faites de l'algorithmique. Lorsque vous cuisinez, vous faites de l'algorithmique. Lorsque vous réparez votre véhicule, vous faites de l'algorithmique. La seule différence c'est que dans le cas "informatique" dans l'imaginaire collectif (ie faire des programmes), on le formalise avec un langage mathématique pour pouvoir donner des instructions à une machine qui ne comprend que ce langage, et ce pour des raisons purement électrique et électronique. Mais il n'y a rien de sorcier. Il est temps de vous libérer de ces images néfastes qu'on entretient pour mystifier la chose.
Après savoir si vous faites réellement de l'informatique ou non, c'est une autre question qui s'éloigne il me semble du sujet original qui était d'apprendre à programmer.