Je me suis récemment donné pour objectif d'apprendre de manière autodidacte les bases de la programmation afin d'accéder à différent type de formation afin de me reconvertir professionnellement. J'hésite entre la cybersécurité ou la programmation d'interface d'application, mais je touche à peine à la surface et je pense encore devoir me renseigner pour véritablement faire un choix.
Ma question est donc, est il nécessaire de connaitre le langage C à la perfection afin de s'orienter vers d'autres langage plus adaptés pour les domaines que j'ai cité ? Et enfin avez vous des conseils, références, livres, afin de m'épanouir dans le domaine?
Je vous remercie à l'avance pour les réponses que je lirais avec attention.
Minimalement quand je vois certaines vidéos ou exemple j'en comprend la logique et le sens, et je pense que les exemple que je vois sont généralement du html ou python, mais voilà je débute et n'affirme rien. Python est le langage qui me revient le plus souvent, mais ma crainte est de bruler les étapes.
Pour moi, plutôt que d'apprendre à programmer, il faut d'abord apprendre à écrire des algorithmes corrects "en français", et ensuite, une fois que l'algorithme fonctionne, le mettre en oeuvre en Python, C, Java que sais-je .
Connecte-toi à des sites comme Codingame, FranceIOI ou d'autres pour résoudre leurs exercices. Codingame est bien fait, il y a une bonne gradation dans la difficulté des problèmes.
PS Je ne sais pas comment tu envisages d'utiliser la programmation, mais il y a autre chose que Python C, java : les langages fonctionnels Haskell, Scheme, F# aussi un peu. Regarde aussi Prolog qui est un monde à part mais fascinant. Même si tu n'utiliseras pas ces langages, ils sont bons à connaître, surtout Prolog.
- Edité par joel76 28 septembre 2024 à 10:11:49
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Merci je vais regarder à ça. Vous m'avez apporté pas mal d'éléments qui vont déjà m'avancer je pense .
Pour ce que je compte en faire, concrètement, laisser libre cours à mes idées, et comme je l'ai dit également a la création du sujet, me reconvertir professionnellement si j'atteins mon objectif.
- Edité par CédricSpadari 28 septembre 2024 à 18:58:21
Pour moi, plutôt que d'apprendre à programmer, il faut d'abord apprendre à écrire des algorithmes corrects "en français", et ensuite, une fois que l'algorithme fonctionne, le mettre en oeuvre en Python, C, Java que sais-je .
N'est-ce pas mieux d'apprendre un langage en même temps ? Écrire des algorithmes sans les mettre en œuvre, c'est comme apprendre le solfège sans apprendre en même temps un instrument.
(Ah, mais tu parles de mettre en œuvre l'algorithme juste après l'avoir écrit, donc en fait tu ne dis pas qu'il faut apprender à écrire des algorithmes avant d'apprendre à programmer, ou alors tu n'es pas très clair... )
De plus, Python dispose de bibliothèques permettant de faire des trucs dans plein de domaines. Le point important pour le débutant, c'est la motivation. Apprendre à programmer, certes, mais programmer quoi ? Des trucs utiles / amusants / intéressants ?
Pour ce qui est de connaître C "à la perfection", faut revoir les ambitions. La norme qui décrit le langage fait (de l'ordre de) un millier de pages, et c'est pas des pages de baratin. Même le comité de normalisation ne le connaît pas à la perfection.
C'est utile d'être familier avec plusieurs langages, pour comprendre les ressemblances et différences. Dans les trucs de notre époque côté imperatif/objets, y aurait aussi C++, Java, javascript/typescript, PHP (beh!), etc. Mais on peut pas tout faire à la fois. La première étape c'est d'arriver à décomposer les problèmes pour arriver à un programme qui marche, et apprendre à gérer les erreurs (*) qu'on ne manque pas de faire en programmant. C'est un savoir faire qui n'est pas facile à acquérir, mais qui est tout à fait transposable à d'autres langages ensuite.
(*) de nos jours, il y a la démarche préventive consistant à bien décomposer sous forme de fonctions ayant un rôle bien clair, en écrivant des tests pour chacune etc.
- Edité par michelbillaud 29 septembre 2024 à 9:18:55
Pour moi, plutôt que d'apprendre à programmer, il faut d'abord apprendre à écrire des algorithmes corrects "en français", et ensuite, une fois que l'algorithme fonctionne, le mettre en oeuvre en Python, C, Java que sais-je .
N'est-ce pas mieux d'apprendre un langage en même temps ? Écrire des algorithmes sans les mettre en œuvre, c'est comme apprendre le solfège sans apprendre en même temps un instrument.
(Ah, mais tu parles de mettre en œuvre l'algorithme juste après l'avoir écrit, donc en fait tu ne dis pas qu'il faut apprender à écrire des algorithmes avant d'apprendre à programmer, ou alors tu n'es pas très clair... )
- Edité par robun il y a environ 14 heures
Il me semble que j'ai écrit
Pour moi, plutôt que d'apprendre à programmer, il faut d'abord apprendre à écrire des algorithmes corrects "en français", et ensuite, une fois que l'algorithme fonctionne, le mettre en oeuvre en Python, C, Java que sais-je .
C'est assez clair il me semble, non ?
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Et tu ne considères pas que ça fait partie de l'apprentissage de la programmation ? En disant « plutôt que d'apprendre à programmer », tu sembles dire que non. C'est pour ça que le début de ton texte me donnait l'impression que tu préconises dans un premier temps l'apprentissage des algorithmes à la place de la programmation (« plutôt que »).
(J'aurais dit : apprendre à programmer, c'est aussi apprendre à écrire des algorithmes corrects etc.)
Il est beaucoup trop facile, pour un débutant de s'auto-persuader qu'une idée d'algorithme fonctionne. Ecrire des algorithmes qui marchent, c'est une tâche qui demande une rigueur que peu de gens ont à priori. Même les mathématiciens ont du mal, qui ont pourtant l'habitude de rédiger des preuves censées être "béton" (et pourtant, avec des "on voit bien que" :-) et quelques mois plus tard un autre papier pour corriger) Quant à développer conjointement un algorithme et sa preuve formelle, c'est pas un truc de débutant.
La programmation de l'algorithme, normalement, apporte une validation qui est en réalité indispensable, et permet de corriger. A condition d'avoir testé sur suffisamment de cas représentatifs pour que les bugs aient eu une occasion de se produire.
En pratique, le travail sur l'algorithme et sa programmation ne sont donc pas des étapes successives. La programmation et les tests fournissent un feedback qui permet de corriger l'algorithme. Ca ne veut bien sur pas dire qu'il ne faut pas réfléchir avant de programmer.
- Edité par michelbillaud 29 septembre 2024 à 18:22:51
> Pour moi, plutôt que d'apprendre à programmer, il faut d'abord apprendre à écrire des algorithmes corrects "en français", et ensuite, une fois que l'algorithme > fonctionne, le mettre en oeuvre en Python, C, Java que sais-je . Comment sais-tu que ton algorithme fonctionne si tu ne le testes pas? Bien sûr, il y a le papier et le crayon, mais ça ne suffit pas toujours.
Le Tout est souvent plus grand que la somme de ses parties.
L'expérience montre que quand les débutants "testent" leurs propres programmes, ils ont souvent la berlue quant à l'exactitude des résultats qui s'affichent sous leur nez. Ca affiche des trucs, ça doit être juste.
On voit beaucoup plus facilement les erreurs produites par les programmes écrits par un autre ! (et pareil pour chercher les erreurs dans du code)
- Edité par michelbillaud 29 septembre 2024 à 18:42:57
Pour moi, l'important c'est l'écriture de l'algo en français en le testant bien sur sur des exemples de données. (c'est en tout cas comme ça que j'ai appris à programmer, en bouffant du tant que et du si alors sinon..., mais c'était l'ancient temps sans doute!).
La traduction, (le mot me parait important) dans un langage, si elle est réussie est gratifiante, mais c'est tout. Le langage on peut l'apprendre sur internet, pas la résolution de problèmes. Peut-être que je pense comme ça parce que j'ai d'abord commencé à programmer pour mon plaisir, et mon plaisir c'était d'écrire des algos corrects, je n'ai pas appris à programmer pour en faire mon métier.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Pour trier les éléments d'un tableau, il y a plusieurs algorithmes possibles. J'imagine qu'il y a des gens très intelligents qui visualisent le fonctionnement d'un algorithme rien qu'en le lisant. Pas moi : j'ai besoin d'un crayon et d'un papier pour essayer sur des exemples. Je trouve que mettre en œuvre un de ces algorithmes, en insérant des affichages pour les étapes intermédiaires, est encore plus efficace que le crayon et le papier. C'est une aide importante pour comprendre comment fonctionne l'algorithme, donc utile dès l'apprentissage.
Joel76 : je crois que je comprends mieux ton point de vue. Mais tu ne considères pas que la traduction dans un langage, c'est le but ? Peut-être pas en phase d'apprentissage ?
Je pense que pour l'apprentissage d'un langage, il n'y a pas le choix: il faut coder. Bien souvent, des conneries, mais il faut en passer par là. Et à la limite, si le programme s'exécute (sans se casser la gueule) mais ne donne pas le bon résultat, ce n'est (trop) grave. Et quand viendra le moment d'écrire un programme un tant soit peu sérieux, le langage étant "connu", ce sera le moment de se pencher sur l'algorithme. Car écrire un algorithme sans pouvoir le tester, ça ne sert pas à grand chose.
Quand j'étais étudiant (sur les bancs de l'école, je ne suis plus tout jeune [si pas plus jeune du tout]), nous avions un cours d'algorithmie (tris, listes chainées, hashage, etc....) et des cours sur les différents langages (à l'époque asm imb360 [ou 370 ?], pl/1, cobol). Et les profs (de langages) s'arrangeaient (régulièrement, mais pas que) pour donner des exercices en relation avec le cours d'algorithmie.
- Edité par edgarjacobs 29 septembre 2024 à 20:27:44
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Joel76 : je crois que je comprends mieux ton point de vue. Mais tu ne considères pas que la traduction dans un langage, c'est le but ? Peut-être pas en phase d'apprentissage ?
Oui bien sur, si on veut en faire son métier. Moi au départ ce n'était pas mon cas, je suis peut-être un peu à part parmi vous. Ceci dit j'ai adoré pratiquer le C, et bien d'autres langages.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Même chose pour les tris, il est facile de vérifier si ça sort en ordre.
A condition de s'en donner la peine. Une situation classique : un exercice où on demande
De générer un tableau de 100 nombres aléatoires
De l'afficher
De l'ordonner
De l'afficher
On est à peu près sûr que le débutant, tout content de voir s'afficher des nombres qui ont l'air d'être dans l'ordre, ne va absolument pas vérifier que ce sont les mêmes qu'au départ.
Alors que - erreurs classiques - des indices hors bornes peuvent introduire des valeur parasites, et que des erreurs peuvent dupliquer des valeurs.
Openclassrooms ayant drastiquement reduit la visibilité du forum, on a beaucoup moins de débutants venus chercher du secours pour leur programme de tri, mais souvent la démarche était de les convaincre d'essayer leur programme sur des tableaux de 2 ou 3 éléments pour trouver un exemple simple qui déconne manifestement, et de faire ensuite l'exécution à la main pour voir pourquoi ça se barre en saucisse.
Ps il faudrait être plus spécifique ici quand on parle d'algorithmes. Y a les petits, comme la somme d'un tableau, et des plus gros, comme chercher un cycle dans un graphe.
- Edité par michelbillaud 30 septembre 2024 à 9:50:22
Le "problème" quand on apprend l'algorithmique c'est que c'est souvent la même chose, les tris, les choix avec conditions...
On peut s'intéresser à d'autres problèmes plus compliqués. Je viens de voir passer sur Codingame par exemple un exo sur le nombre de fois qu'on écrit un chiffre donné lorsqu'on écrit tous les nombres de 1 a 157894 par exemple. Ca tu le fais au brouillon, en français (en tout cas moi) et après tu écris la solution. Autre chose intéressante aussi, résous-tu le problème de manière impérative (C, Java ...) ou déclarative (Prolog) ?
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le "problème" quand on apprend l'algorithmique c'est que c'est souvent la même chose, les tris, les choix avec conditions...
On peut s'intéresser à d'autres problèmes plus compliqués. Je viens de voir passer sur Codingame par exemple un exo sur le nombre de fois qu'on écrit un chiffre donné lorsqu'on écrit tous les nombres de 1 a 157894 par exemple. Ca tu le fais au brouillon, en français (en tout cas moi) et après tu écris la solution. Autre chose intéressante aussi, résous-tu le problème de manière impérative (C, Java ...) ou déclarative (Prolog) ?
J'aurais tendance à écrire l'algorithme sous forme de commentaires (*), qui font partie du code :-)
int nb_apparitions_chiffre_dans_intervalle(int chiffre, int min, int max)
{
int total = 0;
// pour chaque nombre n de debut à fin
// ajouter à total le nombre d'apparitions du chiffre dans n
// TODO
return total;
}
un algorithme naïf de comptage, avec deux boucles imbriquées et sélection, c'est pas bien méchant comme algorithme.
Ce qui serait plus coton, c'est de trouve un algo plus analytique, qui soit par exemple en log de la taille du nombre max.
(*) évidemment, du temps fort lointain où j'étais jeune, on ne pouvait pas vraiment se servir des cartes perforées comme bloc de brouillon. On réfléchissait donc très fort sur le papier avant de rédiger le code qu'on allait taper ensuite, dans l'idée qu'en principe, ça devrait marcher du premier coup puisqu'on avait pensé à tout.
.
- Edité par michelbillaud 30 septembre 2024 à 12:06:40
Concrètement de tout ce que je peux lire, le meilleur moyen d'apprendre à coder, peux importe le langage, c'est en pratiquant. Sans connaissance je voyais le langage C comme " la base " avant de m'aventurer sur d'autres. Je vais continuer à suivre les conseils, mais j'en suis au stade l'enfant qui apprend tout juste à ramper. Pour vous situer j'ai été jusqu'à regarder et suivre des exercices sur des sites normalement dédiés aux enfants ( scratch, makecode ) .
J'ai regardé un peu scratch quand mes petits enfants (eh oui!) ont fait de la prog dans leurs cours de techno. C'est pas mal fait et ça donne une idée correcte de la prog.
Pour ma part, j'ai commencé la prog par traduire mes algos en C. C'est bien au départ, mais on est assez vite confronté à des problèmes de gestion mémoire pénibles qui sont évités avec les langages plus modernes.
Bon courage !
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Joel76 : je crois que je comprends mieux ton point de vue. Mais tu ne considères pas que la traduction dans un langage, c'est le but ? Peut-être pas en phase d'apprentissage ?
Oui bien sur, si on veut en faire son métier. Moi au départ ce n'était pas mon cas, je suis peut-être un peu à part parmi vous. Ceci dit j'ai adoré pratiquer le C, et bien d'autres langages.
Je suis encore plus à part : je suis « programmeur du dimanche ». J'adore la programmation et j'adore en discuter, d'où ma présence ici.
Alors si tu programmes pour le plaisir, plonge toi vers Prolog tu verras c'est passionnant. On résout autrement les problèmes, on peut s'intéresser aux énigmes logiques, c'est vraiment autre chose. Quelqu'un disait, "si tu entres en Prolog, oublie tout ce que tu sais !"
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
J'ai eu une initiation (très courte) au Prolog pendant mes études (de maths appliquées, pas d'informatique), ça ne m'a pas marqué. J'ai fait aussi du Lisp, et celui-là je l'ai bien aimé. Mais à vrai dire, ce qui me passionne n'est pas d'apprendre de nouveaux langages, mais tout ce que je peux faire avec un programme.
Si on va du côté des langages fonctionnels, c'est peut être plus intéressant de voir des langages où le programmeur peut construire des types (par induction)
#type expr =
| Nb of float
| Add of expr * expr
| Soust of expr * expr
| Mult of expr * expr
| Div of expr * expr
| Opp of expr;;
et les utiliser pour définir des fonctions "par pattern matching"
#let rec eval = function
| Nb n -> n
| Add (e1, e2) -> (eval e1) +. (eval e2)
| Soust (e1, e2) -> (eval e1) -. (eval e2)
| Mult (e1, e2) -> (eval e1) *. (eval e2)
| Div (e1, e2) -> (eval e1) /. (eval e2)
| Opp n -> -. (eval n);;
eval : expr -> float = <fun>
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le Tout est souvent plus grand que la somme de ses parties.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le Tout est souvent plus grand que la somme de ses parties.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Le Tout est souvent plus grand que la somme de ses parties.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le Tout est souvent plus grand que la somme de ses parties.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !