À mon avis, ce que les gens considèrent couramment comme un "langage de programmation" sont en réalité trois choses distinctes:
- Type de langue et syntaxe
- Langue IDE
- Bibliothèques disponibles pour une langue
Par exemple, lorsque quelqu'un parle de C # dans une discussion, vous pensez peut-être qu'il parle de syntaxe de langage (1), mais il est certain à 95% que la discussion impliquera .Net framework (3). Si vous ne concevez pas une nouvelle langue, il est difficile et généralement inutile d’isoler (1) et d’ignorer (2) et (3). En effet, l'IDE et la bibliothèque standard sont des "facteurs de confort", des choses qui affectent directement l'expérience d'utilisation d'un outil donné.
Ces dernières années, j'ai moi aussi participé à Google Code Jam. La première fois que j’ai opté pour C ++ parce qu’il supporte bien la lecture de l’entrée. Par exemple, la lecture de trois entiers à partir d’une entrée standard en C ++ ressemble à ceci:
int n, h, w;
cin >> n >> h >> w;
En C #, la même chose ressemblerait à ceci:
int n, h, w;
string[] tokens = Console.ReadLine().Split(' ');
n = int.Parse(tokens[0]);
h = int.Parse(tokens[1]);
w = int.Parse(tokens[2]);
C'est beaucoup plus de frais généraux mentaux pour une fonctionnalité simple. Les choses deviennent encore plus compliquées en C # avec une entrée multiligne. Peut-être que je n'ai tout simplement pas trouvé une meilleure solution à l'époque. En tout cas, je n’ai pas réussi à passer le premier tour parce que j’avais un bug que je ne pouvais pas corriger avant la fin du tour. Ironiquement, la méthode de lecture des entrées a obscurci le bogue. Le problème était simple, l'entrée contenait un nombre trop grand pour un entier de 32 bits. En C # int.Parse(string)lève une exception, mais en C ++, le flux d'entrée du fichier définit un certain indicateur d'erreur et échoue sans que le développeur non averti ne soit pas au courant d'un problème.
Les deux exemples montrent comment la bibliothèque a été utilisée plutôt que la syntaxe du langage. La première montre la verbosité et l’autre la fiabilité. De nombreuses bibliothèques sont portées dans plusieurs langues et certaines langues peuvent utiliser des bibliothèques qui ne sont pas spécialement conçues pour elles (voir la réponse de @ vartec sur Python avec les bibliothèques C).
Pour conclure, connaître le bon algorithme peut aider. Dans les compétitions de codage, c'est crucial, en particulier lorsque des ressources telles que le temps d'exécution et la mémoire sont volontairement limitées. Dans le développement d'applications, c'est bienvenu mais généralement pas crucial. La maintenabilité y est plus importante. Pour ce faire, il est possible d’appliquer des modèles de conception corrects, d’avoir une bonne architecture, un code lisible et une documentation pertinente. Toutes ces méthodes dépendent fortement des bibliothèques internes et tierces. Je trouve donc plus important de savoir quel type de roues sont déjà inventées et comment elles s’adaptent, puis comment fabriquer les miennes.
