Liste de tous les languages à apprendre pour avoir une vision global de tous les paradigmes

Salut,

J’aimerais savoir si vous aviez une idée d’une liste de 5/6 languages de programmation (hors web) qui permettrait d’avoir une bonne vision de la programmation de manière général.

J’ai commencé à apprendre la programmation de manière très théorique (principalement en pseudo code), puis là je commence à programmer en C et à lire Modern Operating Systems de Tanenbaum.

Je compte appronfondir le C et l’algorithmique/structure de donné jusqu’à avoir un niveau "avancé", puis j’ai comme objectif d’apprenre 5/6 languages durant mes études et de les appronfondir suffisamment pour comprendre leurs intérêts, leurs partis pris (point fort/point faible) etc…

Donc si vous avez des idées de language qui me permettrait d’avoir une bonne vision général de la programmation, je vous en serais reconnaissant

Salut,

Je pense que si tu ne précises pas un peu ta pensée, tu auras probablement obtenu la liste d’à peu près tous les langages connus avant la fin de cette page.

Le VHDL, y a que ça de vrai.

Hello,

Je vais te conseiller un peu comme Eusèbe mais avec des langages plus moderne.

Pourquoi apprendre la C quand il y à Rust?

Prolog (what else? je ne connais pas d’équivalent)

Elixir (C’est comme Erlang, sur la VM Erlang, mais en plus, sympa à lire :p)

Ruby (<3) | Python

Kotlin (Desktop) | C#

Kotlin (Mobile) | Swift [Ici pas vraiment question de paradigme différent, mais de techno différente, avec des logiques différentes]

Mais bon, tu auras beaucoup de réponses différentes ici

Le VHDL blabla

Effectivement, j’ai exclu d’office deux chose de ma liste :

• Les langages ésotériques dont le seul intérêt est de ne pas avoir d’intérêt (donc si on pouvait éviter les "lol brainfuck/LOLCODE/whatever y’a que ça de vrai" qu’on trouve dans tous les sujets de ce genre, ce serait bien)
• Les langages de niche ou DSL dont les cas d’application sont tellement hyper-spécifiques que les concepts qu’ils proposent ne sont simplement pas réutilisables ailleurs. Il est communément admis qu’avoir pratiqué un langage fonctionnel peut aider à mieux programmer en Python, mais on ne peut pas en dire autant du VHDL, qui appartient à cette catégorie.

Je vais te conseiller un peu comme Eusèbe mais avec des langages plus moderne.

Pourquoi pas, j’ai dit qu’on pouvait remplacer les langages par d’autres. Mais bon, ici être moderne on s’en fiche un peu, le but est de découvrir des idées de programmation, pas des technologies du futur.

Pourquoi apprendre la C quand il y à Rust?

Parce qu’il a commencé par le C, et que s’il a un bon cours, autant continuer. Par ailleurs, je pense qu’on n’apprécie Rust qu’une fois qu’on a utilisé des langages non sûrs, et qu’il vaut mieux avoir joué un peu avec un langage typé avant.

Elixir (C’est comme Erlang, sur la VM Erlang, mais en plus, sympa à lire :p)

Pourquoi pas.

Ruby (<3) | Python

Ces deux langages sont tellement identiques et parfaitement interchangeables qu’exceptionnellement je pense qu’on peut choisir en ayant en tête son utilisation. Dans ce domaine, Python m’a l’air d’être un choix assez sûr, mais c’est comme on veut.

Kotlin (Desktop) | C#

Aucun intérêt, ils n’apportent rien de nouveau par rapport aux autres langages de la liste.

Kotlin (Mobile) | Swift [Ici pas vraiment question de paradigme différent, mais de techno différente, avec des logiques différentes]

Pareil, si le but est de découvrir la programmation, ça n’a pas un grand intérêt.

J’ajouterai JavaScript car, bien que proche des langages haut niveaux proposés ici, possède un système d’objet assez unique (point positif du langage ou non, à toi de décider) dans les langages populaires (par prototypes) et utilise une event loop dans toutes ses implémentations, qui est disponible dans d’autres langages mais plutôt rarement utilisé ; disons que le langage est bien adapté pour cette utilisation.

Après ça reste assez classique et ne changera pas entièrement ta vision des choses.

C’est dommage de rajouter "hors-web".

Mais je plussoie mes voisons du dessus (même le carïbou troll).

Je pense que Rust peut très bien être remplacer/compléter par D ou Go. Également, jeter un œil sur le C++ serrait très instructif. Et pourquoi pas, regarder un peu les langages exotiques. Le SQL qui est un monde à part, pourait bien te servire un jour. Haxe également pourrait être rigolo.

En dernier lieux, tu aurais certainement tord de ne pas regarder le Javascript (ou langage du même type).

Oh et en C, pour avoir un niveau avancé, c’est assez long. Je te souhaites bonne chance. Le plus simple serrait certainement tout d’abord de tater les langages qui te plaisent, en essayant le plus de chose possible, puis de maîtriser ceux que tu aimes vraiment.

Javascript a un typage tellement pourri et une conception tellement désastreuse que je pense qu’il vaut mieux le laisser de côté. L’idée des évènements est effectivement un des points particuliers du langage, mais pour le coup il y a dans tous les autres langages des bibliothèques qui la mettent en oeuvre. Quant au modèle objet, on retrouve les parties rigolotes dans celui d’OCaml, sauf que c’est bien fait.

en C, pour avoir un niveau avancé, c’est assez long

C’est probablement le langage qu’on peut maîtriser le plus vite, au contraire

Bon bas merci beaucoup, j’ai eu tout ce qu’il me fallait. J’estime que la pire erreur que je pourrais faire en tant qu’étudiant serait de "m’endormir" sur un language.

C’est pourquoi, je veux vraiment profiter d’être étudiant pour tout explorer et avoir une bonne vision global de la programmation.

Dernière petite question, si un jour je venais un m’intéresser aux languages ésotériques, lequel aurait un quelconque intérêt intellectuel ?

Javascript a un typage tellement pourri et une conception tellement désastreuse que je pense qu’il vaut mieux le laisser de côté. L’idée des évènements est effectivement un des points particuliers du langage, mais pour le coup il y a dans tous les autres langages des bibliothèques qui la mettent en oeuvre. Quant au modèle objet, on retrouve les parties rigolotes dans celui d’OCaml, sauf que c’est bien fait.

Oula, c’est extrèmement subjectif ton truc là … Ça va partir en castagne assez rapidement. Je ne trouve pas que Javascript soit particulièrement sympas comme langage. Mais je peux tout à fait concevoir que le modèle objet par prototype et sa gestion de la concurence et le fais que ce soit un langage utilisable en client-side pour du Web le rende très instructif.

Je ne peux que m’opposer à ce message. Le C à une syntaxe simple, certes. Mais comprendre les subtilités du langage jusqu’à comprendre parfaitement (maitriser quoi …). C’est une tout autre histoire. C’est valable pour beaucoup de langage, pas seulement le C. De manière générale maîtriser un langage, c’est très long. Mais par son bas niveau le C impose de comprendre des mécanismes qui sont annexes au langage et complexes. Bref, c’est pas de la tarte.

Les langages "ésotériques" et intéret intelectuel ne sont pas vraiment compatible. Vois ça plus comme un jeu. Le Brainfuck à la limite.

L’intérêt de ces langages n’est pas d’apprendre à programmer avec.

Mais comme ils ont une grammaire simpliste, il est assez facile d’écrire des compilateurs ou des machines virtuelles pour ces langages, ce qui est assez intéressant. Ça donne une première idée avant de le faire pour des langages plus complexes (et typés).

Oula, c’est extrèmement subjectif ton truc là …

Bof, pas tellement. On peut aimer Javascript (ça c’est subjectif), ça n’en reste pas moins un langage plein d’incohérences au typage qu’on peut aussi bien considérer comme totalement absent.

Mais je peux tout à fait concevoir que le modèle objet par prototype et sa gestion de la concurence et le fais que ce soit un langage utilisable en client-side pour du Web le rende très instructif.

Encore une fois, on ne parle pas d’utilisation ici (que ce soit client-side pour du Web, mobile ou embarqué dans des fusées), mais de concepts de programmation. Dans cette optique, la gestion de la concurrence en Javascript n’a pas d’intérêt particulier, et l’évènementiel se retrouve aussi bien dans d’autres langages avec nue foultitude de bibliothèques (mais d’une façon par ailleurs souvent plus claire, parce qu’explicite).

Je ne peux que m’opposer à ce message. Le C à une syntaxe simple, certes. Mais comprendre les subtilités du langage jusqu’à comprendre parfaitement (maitriser quoi …). C’est une tout autre histoire.

C’est le cas pour absolument tous les langages. Le C n’est pas facile ni rapide à maîtriser, mais ça reste un des langages qu’on peut maîtriser le plus rapidement, même si ça n’est pas de la tarte. C’était particulièrement vrai avant qu’ils ne tentent d’introduire un modèle mémoire (qui est par ailleurs cassé de partout, mais c’est une autre histoire), mais je pense que ça reste le cas (avec peut-être un an ou deux supplémentaires d’utilisation à plein temps du langage – on reste en dessous de 10 ans en commençant à zéro).

Ah et au fait :

Je pense que Rust peut très bien être remplacer/compléter par D ou Go

Certainement pas. Les deux sont à des années lumière des concepts et de la sûreté que propose le typage de Rust.

Tu as un avis très tailler dis moi. Si ce qui te gène en JS ce sont les absurdités "{} + []" et "[] + {}" ou ce genre de chose, tu loupes une grande partie. Partie qui est très intéressante en plus.

Mais peu importe, le JS étant déjà un peu HS je n’ai pas envie d’en rajouter.

Au sujet du C. Le Bash en 1 an c’est bon tu maîtrises. Le python et le Go pour citer des langages que je connais bien, me semblent plus simple car rajoutant une bonne couche d’abstraction par rapport au système, ce qui est une bonne chose.

Mais bon, ce que je voulais faire comprendre à l’OP c’est que maîtriser un langage, c’est long donc je vais pas non plus m’étendre plus sur le sujet.

Pour le Rust, je ne connais pas bien mais ce n’est pas par leur typage que je compare ces langages. Même si j’avoue que je ne comprend pas trop ce que Rust apporte basiquement de plus à ce niveau là. Les variables immuable et le passage de message apparement. Du coup, j’irrais me renseigner.

Maitriser un language ça veut de toute manière pas dire grand chose. On parle de quoi ? D’être efficace d’un point de vue professionnel ? De comprendre ses paradigmes et son utilité ? D’être plus calé dans ce language que son propre créateur ?

J’ai déjà indiqué mes objectifs, je veux avoir une vision global de la programmation et je veux pousser suffisamment chaque language pour comprendre ses caractéristiques propres, le "pourquoi il existe". Il n’y a donc pas de débat à avoir sur la difficulté à maitriser tel ou tel language.

Quant au C j’ai déjà dis que j’apprenais actuellement le fonctionnement (dans le détail), des différents types d’OS. Notamment avec Modern Operating Systems de Tanenbaum. Donc j’apprend le C en parallèle, ce qui est au fond parfaitement logique, j’ai encore jamais vu un noyau d’OS être codé en Python, ni en Rust, ni en Javascript hein !

En tout cas merci à tous, j’ai appris pas mal de chose et j’ai une petite liste de language, bonne soirée

C’est très bien. Vu que tu avais déjà compris ça alors ma remarque sur le C n’avait aucun intérêt.

Juste, au passage, en français, c’est un langage. Le language, c’est en anglais.

Ça n’apporte rien au débat et ça ne répond pas à la question, mais ça me titillait.

Loupé : https://www.tockos.org/documentation/getting-started . Et putain, si, ce serait logique de ne plus utiliser C pour développer dans des couches basses, mais plutôt quelque chose comme Rust. Mais il y a encore du travail pour avoir une gestion fine des horreurs nécessaires au développement low-level, pour perdre la sûreté plus sélectivement (voir du côté par exemple des attributs de désactivation de C++ core guideline library).

Pour le C et sa difficulté de maîtrise, je suis (bizarrement) plutôt d’accord avec @Eusèbe, mais avec des limites. Ce n’est pas tant l’utilisation de C qui est complexe que les programmes qui en résultent et surtout les tâches qu’on réalise avec. Bref : c’est pas le langage qui est dur, c’est ce qu’on exprime avec. Cela dit, reconnaître un UB au premier coup d’oeil, vu la longueur de la liste, ça demande des années de pratiques.

Concernant le modèle mémoire, il n’y a, au fond, qu’un point qui est vraiment cassé et le fait que les compilos ne soient pas du tout compliant à ce modèle. Mais c’est plutôt pas si mal. Les papiers de Vafeiadis permettent de bien se mettre dans la manière de raisonner avec.

Finalement pour Go (on va faire C en plus facile à utiliser et en mieux) et D (pareil pour C++), non, clairement. Déjà pour le mieux : ils sont type-safe mes fesses. Et pour le "plus facile", ça passe à côté de la raison pour laquelle ces langages sont durs à utiliser dans les domaines où l’on les utilise : des tâches sont complexes dans les méandres du bas niveau. A l’inverse Rust n’a pas cherché à éluder cette complexité et a fourni par son typage les moyens de le faire plus proprement, même si c’est toujours dur. Et c’est un bien meilleur choix.

Allez, hors-troll :

Le VHDL , y a que ça de vrai.

Eusèbe, ce n’est pas parce que tu as un avis sur les langages que c’est forcément LA réponse. Chacun sa sensibilité et sa façon de voir les choses. L’OP veut connaitre / avoir un aperçu large de l’informatique, sans préciser de domaines d’applications (et donc je part du principe qu’il veut enrichir sa culture), je vois pas pourquoi on dégagerait certains aspects parce qu’il ne rentre pas dans les cases de ton quotidien. Moi dans mon informatique il y a une part d’électronique, et donc j’ai appris à faire du VHDL. Oui, ca ne sert pas souvent (voire jamais), mais ça n’empêche que c’est une façon bien particulière de voir le déroulement d’une suite d’opération. De la même façon, personne n’a parlé de l’assembleur, même pour le troll #Déception.

Aussi, personne non plus n’a parlé des trucs plus orienté "sciences" type R, Matlab… qui n’en reste pas moins de la programmation.

On aurait aussi pu parler des langages comme le VBA pour faire des macros Excel. Ca parait con, mais pour certains c’est le quotidien de la programmation.

Bref, l’informatique est une science très vaste, ne prenez pas vos cas pour des généralités.

Matlab

À mort ! Pardon, réflexe. Plutôt que d’utiliser un langage de piètre qualité ne pouvant être interprété que par un programme propriétaire, je recommande chaudement numpy+scipy, qui font le boulot dans la plupart des cas sans tracas.

Et effectivement, penser un code en se limitant aux opérations matricielles est une gymnastique intellectuelle différente d’un code impératif.

De la même manière pour la programmation orientée objet, la programmation d’interface graphique (ou orienté évènements), le multiprocesseur (OpenMP et MPI)…

Deux langages que j’ai envie de regarder par pure curiosité intellectuelle (comme je l’ai fait pour Ocaml à une époque), c’est Eiffel (programmation par contrat) et Ada.

Je m’insère dans la castagne.

En dehors du côté niche (très large) du VHDL, il apporte aussi un aspect de la programmation qui est rarement mis en avant: il introduit à la programmation synchrone. Il n’y a pas de séquencement des instructions, elles se produisent toutes en même lors du tick de l’horloge. Les langages synchrones comme Lustre ou Esterel sont très utilisés dans l’embarqué. Et VHDL permet de se frotter à la notion facilement.

Sur l’argument de niche d’Eusebe, entre Coq et VHDL, je considère clairement Coq plus une niche que VHDL. Dans beaucoup de cursus, les élèves vont faire un peu de VHDL et/ou en entendre parler. Alors que Coq, lolilol.

Edit: ca peut être l’occasion d’un tuto pour mettre les choses au clair. qui est partant ?