Informatique

J'ai essayé de réécrire sur papier ce que j'avais compris de tout ce que j'avais lu :

Un algorithme c’est des variables avec des données à l’intérieur et elles peuvent prendre une direction ou une autre selon la structure de contrôle.

Les variables sont stockées dans la mémoire de l’ordinateur et on peut leur attribuer des types de données et les valeurs de ces types de données peuvent changer pendant l'exécution du programme notamment selon la structure de contrôle (à l'instar des constantes qui restent "fixe").

Une structure de contrôle étant par exemple une boucle, une alternative ou un appel de fonctions.

La structure de contrôle à un impact sur la donnée qui constitue la variable.

Exemple de plusieurs types de données = Intégral, Floating, Point, Character, Character String etc. (pleins selon les langages mais il en reste pas moins qu’il y a une base commune à tous)

Par rapport au langage de programmation, il y a le langage interprété et le langage compilé.

Le langage interprété étant converti en binaire au fur et à mesure de l'exécution.
Le langage compilé étant directement converti avant l'exécution (d’où la compilation).

(J’ai compris qu’il y pouvait avoir les deux paradigmes dans un langage parfois selon ce qu’on met dans le code comme le Ruby par exemple).

Concernant les langages back-end, j’ai compris qu’il pouvait avoir les OOP (instructions exécutées dans un ordre particulier) ou Fonctionnelle (langage déclaratif, donc exécutées dans n'importe quel ordre) + les langages peuvent être statically typed (rigide) ou dynamically typed (souple mais plus "difficile").

Dîtes moi s'il y a des erreurs (je suis quasiment certain qu’il y en a), je ne suis pas parti dans les détails / subtilités encore, mais j’aimerais avoir une vision à peu près globale des bases pour être plus clair dans ma tête

Il y a des choses que je ne sais pas où placer encore, comme les tableaux, les classes, les objets, les fonctions.

T'as une compréhension beaucoup trop scolaire des choses. Soit tu comprends soit tu comprends pas, les définitions ne servent qu'à guider l'intuition mais sont pas suffisantes.

Le 28 novembre 2021 à 22:25:52 :
T'as une compréhension beaucoup trop scolaire des choses. Soit tu comprends soit tu comprends pas, les définitions ne servent qu'à guider l'intuition mais sont pas suffisantes.

Oui c'est ce qu'on m'a dis, qu'en pratique c'est plus complexe que ça, je viens de commencer à m'y intéresser donc c'est un peu normal je pense, qu'est ce que tu me conseille ?

Les langages interprete ne sont pas forcement converti en binaire. Ils sont execute a travers un interpreteur qui est un programme annexe (et qui lui meme peut etre ecrit dans un langage compile ou interprete). Apres il y a des interpreteur qui font une conversion en langage binaire a la volee.

Pour le reste, prends un langage de programmation, n'importe lequel, et apprends a programmer un peu. qu'est ce qui est une variable, qu'est ce qu'est une structure de donnee viendra tout seul.

Au delà de ça y a des choses que t'as manifestement pas comprises du tout dans ce que tu dis.

Le langage interprété étant converti en binaire au fur et à mesure de l'exécution.
Le langage compilé étant directement converti avant l'exécution (d’où la compilation).

Avant de réfléchir aux histoires de langages faut que tu comprennes comment marche un programme sur ton ordinateur.

Grossomodo un programme c'est une suite d'instruction qui vont être passées à ton processeur (ou plus généralement à une machine de Turing universelle) qui va se charger de les exécuter. Une instruction ça peut être quelque chose du genre : copie un octet de l'adresse a vers l'adresse b, ajoute les entiers aux adresses a et b et mets le résultat à l'adresse b, si l'entier à l'adresse a est nul alors déplace le pointeur d'instruction vers l'adresse b.

En pratique les programmes sont généralement stockés dans des fichiers accompagnés de metadonnées, on parle de fichier exécutable. Sous linux on a les fichiers ELF, sous windows on a les .exe Grossomodo il faut se dire que ces fichiers contiennent les instructions à passer au processeur en plus de quelques metadonnées.

Quand tu compiles un programme écrit en C, ce que tu fais c'est transcrire le code du programme écrit en C en un fichier exécutable. C'est comme s'il y avait plusieurs langages pour écrire un programme mais comme le processeur ne comprend qu'un certain langage il faut faire la traduction en amont pour qu'il puisse l'exécuter.

Quand tu interprètes un programme c'est différent, au lieu de traduire le programme en amont tu vas en quelque sorte le traduire à la volée par le biais d'un interpréteur. Grossomodo tu vas exécuter l'interpréteur en lui passant le code source du programme et il va se charger de traduire les instructions les unes à la suite des autres pour le processeur.

Il faut bien comprendre que tu peux toujours "compiler" un langage interprété en créant un exécutable contenant l'interpréteur et le code source du programme. En pratique on ne parle pas vraiment de compilation parce qu'on a pas les avantages d'une vraie compilation, à savoir une véritable traduction en amont du programme qui permet d'accélérer l'exécution notamment.

Concernant les langages back-end, j’ai compris qu’il pouvait avoir les OOP (instructions exécutées dans un ordre particulier) ou Fonctionnelle (langage déclaratif, donc exécutées dans n'importe quel ordre) + les langages peuvent être statically typed (rigide) ou dynamically typed (souple mais plus "difficile").

Ça c'est du grand n'importe quoi, t'as absolument rien compris à tout ce que tu cites dans cette phrase.

Le 28 novembre 2021 à 22:30:38 :

Le 28 novembre 2021 à 22:25:52 :
T'as une compréhension beaucoup trop scolaire des choses. Soit tu comprends soit tu comprends pas, les définitions ne servent qu'à guider l'intuition mais sont pas suffisantes.

Oui c'est ce qu'on m'a dis, qu'en pratique c'est plus complexe que ça, je viens de commencer à m'y intéresser donc c'est un peu normal je pense, qu'est ce que tu me conseille ?

C'est pas une question de complexité, c'est juste que tu peux pas comprendre en apprenant des définitions. Les définitions ça sert juste à aiguiller ta compréhension. Imagine apprendre à un perroquet la définition de ce qu'est un parapluie, il pourra te répéter 100 fois la définition ça voudra pas dire qu'il aura compris quoi que ce soit pour autant.

Pour vraiment savoir si tu comprends un mot / un concept il faut que tu emploies ce mot dans des situations appropriées. Exemple : cet algorithme ne termine pas. Ça c'est une utilisation valide du mot algorithme. Exemple : ce langage est lent. Ça c'est une mauvaise utilisation du mot langage, un langage n'est ni rapide ni lent en tant que tel, ce qui est rapide ou lent c'est le programme résultant, mais ça dépend fortement des compilateurs et interpréteurs disponibles. Petite subtilité, en pratique c'est quand même assez utile de parler de la lenteur d'un langage, mais il faut bien comprendre ce qu'on entend par là, on entend en fait la lenteur des programmes utilisant les meilleurs compilateurs / interpréteurs disponibles.

Par exemple, python est assez lent parce que peu importe quel interpréteur de python tu utilises, certains programmes écrits en python seront plus lents que les programmes issus des mêmes algorithmes dans d'autres langages.

Le 28 novembre 2021 à 22:46:40 :
Au delà de ça y a des choses que t'as manifestement pas comprises du tout dans ce que tu dis.

Le langage interprété étant converti en binaire au fur et à mesure de l'exécution.
Le langage compilé étant directement converti avant l'exécution (d’où la compilation).

Avant de réfléchir aux histoires de langages faut que tu comprennes comment marche un programme sur ton ordinateur.

Grossomodo un programme c'est une suite d'instruction qui vont être passées à ton processeur (ou plus généralement à une machine de Turing universelle) qui va se charger de les exécuter. Une instruction ça peut être quelque chose du genre : copie un octet de l'adresse a vers l'adresse b, ajoute les entiers aux adresses a et b et mets le résultat à l'adresse b, si l'entier à l'adresse a est nul alors déplace le pointeur d'instruction vers l'adresse b.

En pratique les programmes sont généralement stockés dans des fichiers accompagnés de metadonnées, on parle de fichier exécutable. Sous linux on a les fichiers ELF, sous windows on a les .exe Grossomodo il faut se dire que ces fichiers contiennent les instructions à passer au processeur en plus de quelques metadonnées.

Quand tu compiles un programme écrit en C, ce que tu fais c'est transcrire le code du programme écrit en C en un fichier exécutable. C'est comme s'il y avait plusieurs langages pour écrire un programme mais comme le processeur ne comprend qu'un certain langage il faut faire la traduction en amont pour qu'il puisse l'exécuter.

Quand tu interprètes un programme c'est différent, au lieu de traduire le programme en amont tu vas en quelque sorte le traduire à la volée par le biais d'un interpréteur. Grossomodo tu vas exécuter l'interpréteur en lui passant le code source du programme et il va se charger de traduire les instructions les unes à la suite des autres pour le processeur.

Il faut bien comprendre que tu peux toujours "compiler" un langage interprété en créant un exécutable contenant l'interpréteur et le code source du programme. En pratique on ne parle pas vraiment de compilation parce qu'on a pas les avantages d'une vraie compilation, à savoir une véritable traduction en amont du programme qui permet d'accélérer l'exécution notamment.

Concernant les langages back-end, j’ai compris qu’il pouvait avoir les OOP (instructions exécutées dans un ordre particulier) ou Fonctionnelle (langage déclaratif, donc exécutées dans n'importe quel ordre) + les langages peuvent être statically typed (rigide) ou dynamically typed (souple mais plus "difficile").

Ça c'est du grand n'importe quoi, t'as absolument rien compris à tout ce que tu cites dans cette phrase.

Le 28 novembre 2021 à 22:30:38 :

Le 28 novembre 2021 à 22:25:52 :
T'as une compréhension beaucoup trop scolaire des choses. Soit tu comprends soit tu comprends pas, les définitions ne servent qu'à guider l'intuition mais sont pas suffisantes.

Oui c'est ce qu'on m'a dis, qu'en pratique c'est plus complexe que ça, je viens de commencer à m'y intéresser donc c'est un peu normal je pense, qu'est ce que tu me conseille ?

C'est pas une question de complexité, c'est juste que tu peux pas comprendre en apprenant des définitions. Les définitions ça sert juste à aiguiller ta compréhension. Imagine apprendre à un perroquet la définition de ce qu'est un parapluie, il pourra te répéter 100 fois la définition ça voudra pas dire qu'il aura compris quoi que ce soit pour autant.

Pour vraiment savoir si tu comprends un mot / un concept il faut que tu emploies ce mot dans des situations appropriées. Exemple : cet algorithme ne termine pas. Ça c'est une utilisation valide du mot algorithme. Exemple : ce langage est lent. Ça c'est une mauvaise utilisation du mot langage, un langage n'est ni rapide ni lent en tant que tel, ce qui est rapide ou lent c'est le programme résultant, mais ça dépend fortement des compilateurs et interpréteurs disponibles. Petite subtilité, en pratique c'est quand même assez utile de parler de la lenteur d'un langage, mais il faut bien comprendre ce qu'on entend par là, on entend en fait la lenteur des programmes utilisant les meilleurs compilateurs / interpréteurs disponibles.

Par exemple, python est assez lent parce que peu importe quel interpréteur de python tu utilises, certains programmes écrits en python seront plus lents que les programmes issus des mêmes algorithmes dans d'autres langages.

Je garde tout ça en tête, ça m'aide a y voir un peu plus clair

P.-S. même chose, prends pas tout ce que j'ai écrit au pied de la lettre, ni quoi que ce soit d'ailleurs. Toutes les notions dont il est question sont assez floues, il y a beaucoup d'abus de langage dans tous les sens pour éviter certaines lourdeurs, y a pas mal de choses plus ou moins fausses selon comment on les perçoit.

Ce qui compte vraiment c'est l'emploi de ces termes plus que leur explication formelle. Y a beaucoup de choses qui dépendent du contexte, tu peux avoir du mal à voir la différence entre macro, procédure, fonction, programme, algorithme en lisant simplement les définitions mais en pratique tu comprendras rapidement à quel contexte on associe tous ces mots et qu'est-ce qu'on désigne exactement.

Je vais reformuler tes phrases de manière plus simple à comprendre, on s'y perd à utiliser une écriture trop littéraire.

Un algorithme c'est une suite d'instructions pouvant résoudre un problème.
Une instruction est une opération élémentaire (déclaration, affectation, condition, boucle,...).
Une structure de contrôle c'est : une suite d'instructions séquentielle, une condition ou une boucle.

Type de données (non exhaustif) :
...Entier (byte, short, int, long)
...Flottant/Réel (float, double)
...Caractère (char)
...Chaine de caractère (string)
...booléen (bool)

Langage interprété : Le code est interprété en temps réel ligne par ligne.
Le code est réinterprété entièrement à chaque exécution donc plus lent à exécuter.

Langage compilé : Le code est entièrement compilé en binaire avant d'être exécuté.
Le code est compilé une seule fois donc plus rapide à exécuter.

Paradygmes :
Orienté objet : On utilise des classes pour construire des objets qui interagiront ensemble.
Impérative : On décrit l'algorithme étape par étape.
Déclarative : On décrit un résultat ou un objectif, et on l'obtiens via une " boîte noire ".

Un langage peut avoir un typage fort ou faible.
Dans le cas d'un typage faible, la variable prend le type de ce qu'elle contient.
Dans un typage fort il faut le préciser.

La plupart des concepts sont plus faciles à appréhender en les manipulant, c'est se faire du mal que d'essayer de tout retenir de manière uniquement théorique sans pratique.

Le 28 novembre 2021 à 22:57:57 :
P.-S. même chose, prends pas tout ce que j'ai écrit au pied de la lettre, ni quoi que ce soit d'ailleurs. Toutes les notions dont il est question sont assez floues, il y a beaucoup d'abus de langage dans tous les sens pour éviter certaines lourdeurs, y a pas mal de choses plus ou moins fausses selon comment on les perçoit.

Ce qui compte vraiment c'est l'emploi de ces termes plus que leur explication formelle. Y a beaucoup de choses qui dépendent du contexte, tu peux avoir du mal à voir la différence entre macro, procédure, fonction, programme, algorithme en lisant simplement les définitions mais en pratique tu comprendras rapidement à quel contexte on associe tous ces mots et qu'est-ce qu'on désigne exactement.

Oui, je comprend ce que tu veux dire (et je le comprendrais sûrement mieux dans le futur).

Je me permet de te demander autre chose, en lisant des tonnes et des tonnes de threads reddit et en regardant des vidéos, il y avais plusieurs choses qui revenait souvent concernant les choses à absolument connaître (un minimum) pour pouvoir être opérationnelles professionnellement parlant (en full stack par exemple).

En gros, il fallait apprendre :

À bien résoudre des problémes (et que ça venait avec un apport théorique et pratique).

Les blocs universels du code : l'algorithmique, les types de données, les structure de contrôle, les grands principes de programmation, les paradigmes de programmation, la récursion, découplage, scope, commentaire etc.

L'environnement de travail : éditeur de texte, shell, git, script en shell.

Et pleins d'annexes : network, data structures, oop basics, logical and arithmetic operators, intricacies between server and browser, learn some SQL, learn about the debuggers.

Et ensuite il fallait choisir une discipline front-end, back-end, devops etc. et tout ce qui va avec, les frameworks etc.

Qu'il fallait prendre ce chemin si on voulait faire les choses proprement, est-ce que c'est du bullshit complet ou y à quand même un semblant de vérité ?

Le 28 novembre 2021 à 23:07:58 :
Je vais reformuler tes phrases de manière plus simple à comprendre, on s'y perd à utiliser une écriture trop littéraire.

Un algorithme c'est une suite d'instructions pouvant résoudre un problème.
Une instruction est une opération élémentaire (déclaration, affectation, condition, boucle,...).
Une structure de contrôle c'est : une suite d'instructions séquentielle, une condition ou une boucle.

Type de données (non exhaustif) :
...Entier (byte, short, int, long)
...Flottant/Réel (float, double)
...Caractère (char)
...Chaine de caractère (string)
...booléen (bool)

Langage interprété : Le code est interprété en temps réel ligne par ligne.
Le code est réinterprété entièrement à chaque exécution donc plus lent à exécuter.

Langage compilé : Le code est entièrement compilé en binaire avant d'être exécuté.
Le code est compilé une seule fois donc plus rapide à exécuter.

Paradygmes :
Orienté objet : On utilise des classes pour construire des objets qui interagiront ensemble.
Impérative : On décrit l'algorithme étape par étape.
Déclarative : On décrit un résultat ou un objectif, et on l'obtiens via une " boîte noire ".

Un langage peut avoir un typage fort ou faible.
Dans le cas d'un typage faible, la variable prend le type de ce qu'elle contient.
Dans un typage fort il faut le préciser.

La plupart des concepts sont plus faciles à appréhender en les manipulant, c'est se faire du mal que d'essayer de tout retenir de manière uniquement théorique sans pratique.

Ça aussi ça m'aide beaucoup merci !

Le 28 novembre 2021 à 23:08:51 :

Le 28 novembre 2021 à 22:57:57 :
P.-S. même chose, prends pas tout ce que j'ai écrit au pied de la lettre, ni quoi que ce soit d'ailleurs. Toutes les notions dont il est question sont assez floues, il y a beaucoup d'abus de langage dans tous les sens pour éviter certaines lourdeurs, y a pas mal de choses plus ou moins fausses selon comment on les perçoit.

Ce qui compte vraiment c'est l'emploi de ces termes plus que leur explication formelle. Y a beaucoup de choses qui dépendent du contexte, tu peux avoir du mal à voir la différence entre macro, procédure, fonction, programme, algorithme en lisant simplement les définitions mais en pratique tu comprendras rapidement à quel contexte on associe tous ces mots et qu'est-ce qu'on désigne exactement.

Oui, je comprend ce que tu veux dire (et je le comprendrais sûrement mieux dans le futur).

Je me permet de te demander autre chose, en lisant des tonnes et des tonnes de threads reddit et en regardant des vidéos, il y avais plusieurs choses qui revenait souvent concernant les choses à absolument connaître (un minimum) pour pouvoir être opérationnelles professionnellement parlant (en full stack par exemple).

En gros, il fallait apprendre :

À bien résoudre des problémes (et que ça venait avec un apport théorique et pratique).

Les blocs universels du code : l'algorithmique, les types de données, les structure de contrôle, les grands principes de programmation, les paradigmes de programmation, la récursion, découplage, scope, commentaire etc.

L'environnement de travail : éditeur de texte, shell, git, script en shell.

Et pleins d'annexes : network, data structures, oop basics, logical and arithmetic operators, intricacies between server and browser, learn some SQL, learn about the debuggers.

Et ensuite il fallait choisir une discipline front-end, back-end, devops etc. et tout ce qui va avec, les frameworks etc.

Qu'il fallait prendre ce chemin si on voulait faire les choses proprement, est-ce que c'est du bullshit complet ou y à quand même un semblant de vérité ?

Y a plein d'approches possibles. Honnêtement c'est dur de te conseiller un parcours sans te connaître.

Ce qu'il faut te dire c'est qu'il y a des grands axes et qu'il faut progresser dans chaque grand axe peu importe dans quel ordre.

• L'informatique théorique : comprendre les fondements théorique de l'informatique et de la programmation, penser la programmation en dehors du cadre d'un langage donné, d'un système d'exploitation, etc. On s'abstrait totalement du cadre pratique pour ne garder que l'essence de ce qui est fait. Exemple : machines de Turing, décidabilité, classes de complexité, oracles, automates finis, déterminisme, structures de données, listes, tris, arbres, graphes, plein de choses, etc.

• Les langages de programmation : maîtriser un / des langages, comprendre comment les paradigmes employés sont implémentés, savoir s'en servir, comprendre les différences qu'il peut y avoir entre plusieurs implémentations d'un même algorithme dans un langage donné, savoir ce qui est le plus adapté à telle situation, être capable de discerner les compromis qui se présentent (en terme d'optimisation, d'abstraction, de lisibilité, de maintenabilité)

• Les paradigmes de programmation : programmation impérative, objet, fonctionnel. Quels sont les avantages et inconvénients de chacune des approches.

• L'expertise dans des problèmes spécifiques : maîtriser les bases de données, la programmation concurrentielle, multithreadée, système, réseau, l'automatisation de tâches, les techniques de rendu 2D, 3D, de synthèse audio, etc. tous les domaines d'expertise possibles en programmation en gros. Tu maîtriseras jamais tout mais tu auras sûrement tes spécialités, tu peux être très bon pour concevoir des applications graphiques mais ne pas maîtriser grand chose à la programmation réseau.

• Le développement en tant qu'artisanat : ce qu'on appellerait en anglais le craftsmanship, savoir quelles sont les bonnes pratiques du développement, savoir écrire un code lisible, maintenable, compréhensible par un maximum de gens, utiliser les bons outils, bien segmenter son code, bien organiser ses projets, bien documenter, faire les bons choix d'abstractions. Les principes SOLID, KISS, DRY.

• La sécurité : éviter les failles de sécurité les plus élémentaires, mettre en place les bonnes pratiques de sécurité. Utiliser des algorithmes recommandés pour tout ce qui touche aux mots de passe, au chiffrement de données, au hachage de fichiers, à tout ce qui touche à la cryptographie de près ou de loin.

• Les performances : maîtriser les outils de benchmarking, être capable de déterminer comment accélérer l'exécution d'un programme, d'une fonction, ne pas optimiser les mauvaises choses (1), seulement les goulots d'étranglement.

• Les différents types de projets : webapps (front-end, back-end), scripts, applications graphiques, bots, services, programmes utilitaires, drivers, programmation kernel, game dev, programmation serveur, embarqué, outils système, machine learning...

J'oublie sûrement un tas de choses mais ça te fait déjà des pistes de progression. À noter que tout ça est indicatif, tu peux très bien être un très bon dev sans avoir une idée précise de ce qu'est une machine de Turing, tout comme tu peux très bien être un bon dev sans jamais avoir ouvert un outil de profiling de ta vie. Les axes importants vont énormément dépendre des domaines dans lesquels tu travailles. Si tu codes des systèmes bancaires t'as plutôt intérêt à maîtriser la sécurité informatique, si tu codes des jeux solo 2d tu vas a priori pas en avoir grand chose à foutre de la programmation système et réseau au delà d'un certain nivaeu.

(1) "Premature optimization is the root of all evil"

Le 28 novembre 2021 à 23:35:46 :

Le 28 novembre 2021 à 23:08:51 :

Le 28 novembre 2021 à 22:57:57 :
P.-S. même chose, prends pas tout ce que j'ai écrit au pied de la lettre, ni quoi que ce soit d'ailleurs. Toutes les notions dont il est question sont assez floues, il y a beaucoup d'abus de langage dans tous les sens pour éviter certaines lourdeurs, y a pas mal de choses plus ou moins fausses selon comment on les perçoit.

Ce qui compte vraiment c'est l'emploi de ces termes plus que leur explication formelle. Y a beaucoup de choses qui dépendent du contexte, tu peux avoir du mal à voir la différence entre macro, procédure, fonction, programme, algorithme en lisant simplement les définitions mais en pratique tu comprendras rapidement à quel contexte on associe tous ces mots et qu'est-ce qu'on désigne exactement.

Oui, je comprend ce que tu veux dire (et je le comprendrais sûrement mieux dans le futur).

Je me permet de te demander autre chose, en lisant des tonnes et des tonnes de threads reddit et en regardant des vidéos, il y avais plusieurs choses qui revenait souvent concernant les choses à absolument connaître (un minimum) pour pouvoir être opérationnelles professionnellement parlant (en full stack par exemple).

En gros, il fallait apprendre :

À bien résoudre des problémes (et que ça venait avec un apport théorique et pratique).

Les blocs universels du code : l'algorithmique, les types de données, les structure de contrôle, les grands principes de programmation, les paradigmes de programmation, la récursion, découplage, scope, commentaire etc.

L'environnement de travail : éditeur de texte, shell, git, script en shell.

Et pleins d'annexes : network, data structures, oop basics, logical and arithmetic operators, intricacies between server and browser, learn some SQL, learn about the debuggers.

Et ensuite il fallait choisir une discipline front-end, back-end, devops etc. et tout ce qui va avec, les frameworks etc.

Qu'il fallait prendre ce chemin si on voulait faire les choses proprement, est-ce que c'est du bullshit complet ou y à quand même un semblant de vérité ?

Y a plein d'approches possibles. Honnêtement c'est dur de te conseiller un parcours sans te connaître.

Ce qu'il faut te dire c'est qu'il y a des grands axes et qu'il faut progresser dans chaque grand axe peu importe dans quel ordre.

• L'informatique théorique : comprendre les fondements théorique de l'informatique et de la programmation, penser la programmation en dehors du cadre d'un langage donné, d'un système d'exploitation, etc. On s'abstrait totalement du cadre pratique pour ne garder que l'essence de ce qui est fait. Exemple : machines de Turing, décidabilité, classes de complexité, oracles, automates finis, déterminisme, structures de données, listes, tris, arbres, graphes, plein de choses, etc.

• Les langages de programmation : maîtriser un / des langages, comprendre comment les paradigmes employés sont implémentés, savoir s'en servir, comprendre les différences qu'il peut y avoir entre plusieurs implémentations d'un même algorithme dans un langage donné, savoir ce qui est le plus adapté à telle situation, être capable de discerner les compromis qui se présentent (en terme d'optimisation, d'abstraction, de lisibilité, de maintenabilité)

• Les paradigmes de programmation : programmation impérative, objet, fonctionnel. Quels sont les avantages et inconvénients de chacune des approches.

• L'expertise dans des problèmes spécifiques : maîtriser les bases de données, la programmation concurrentielle, multithreadée, système, réseau, l'automatisation de tâches, les techniques de rendu 2D, 3D, de synthèse audio, etc. tous les domaines d'expertise possibles en programmation en gros. Tu maîtriseras jamais tout mais tu auras sûrement tes spécialités, tu peux être très bon pour concevoir des applications graphiques mais ne pas maîtriser grand chose à la programmation réseau.

• Le développement en tant qu'artisanat : ce qu'on appellerait en anglais le craftsmanship, savoir quelles sont les bonnes pratiques du développement, savoir écrire un code lisible, maintenable, compréhensible par un maximum de gens, utiliser les bons outils, bien segmenter son code, bien organiser ses projets, bien documenter, faire les bons choix d'abstractions. Les principes SOLID, KISS, DRY.

• La sécurité : éviter les failles de sécurité les plus élémentaires, mettre en place les bonnes pratiques de sécurité. Utiliser des algorithmes recommandés pour tout ce qui touche aux mots de passe, au chiffrement de données, au hachage de fichiers, à tout ce qui touche à la cryptographie de près ou de loin.

• Les performances : maîtriser les outils de benchmarking, être capable de déterminer comment accélérer l'exécution d'un programme, d'une fonction, ne pas optimiser les mauvaises choses (1), seulement les goulots d'étranglement.

• Les différents types de projets : webapps (front-end, back-end), scripts, applications graphiques, bots, services, programmes utilitaires, drivers, programmation kernel, game dev, programmation serveur, embarqué, outils système, machine learning...

J'oublie sûrement un tas de choses mais ça te fait déjà des pistes de progression. À noter que tout ça est indicatif, tu peux très bien être un très bon dev sans avoir une idée précise de ce qu'est une machine de Turing, tout comme tu peux très bien être un bon dev sans jamais avoir ouvert un outil de profiling de ta vie. Les axes importants vont énormément dépendre des domaines dans lesquels tu travailles. Si tu codes des systèmes bancaires t'as plutôt intérêt à maîtriser la sécurité informatique, si tu codes des jeux solo 2d tu vas a priori pas en avoir grand chose à foutre de la programmation système et réseau au delà d'un certain nivaeu.

(1) "Premature optimization is the root of all evil"

Y a tellement de choses dont je n’ai jamais entendues parler je te remercie, mais je suis plutôt d'accord sur le fait qu'il y a plein d'approches possibles puisque quand je regarde ceux qui n'ont pas abandonné en route, ils ont tous commencé par quelque chose et il rectifiait le tir au fur et à mesure de leurs apprentissages en fonction de là où se dirigeait (en général il n'avait pas un chemin défini dans le détail loin de là).