Moi j'ai commencé sur calculatrice, en ti basic, puis je me suis mis au C au bout d'un certain temps, j'avais un peu essayé le python mais j'ai décroché dès le début je ne sais plus trop pourquoi, et après un certain temps en C, j'ai essayé le C++ et j'ai bien aimé toutes les nouveautés sauf la POO (bref, l'essentiel de la différence entre C et C++), depuis, je reste sur du C, et en ce moment, j'attaque l'assembleur x86, l'ultime langage pour vraiment savoir ce qu'on fait avec son pc.

Pour un débutant, se contenter du python est une idée, car le C a certains aspects rebutants et difficiles à digérer pour un grand débutant alors qu'un type qui aura fait même du python saura déjà mieux se débrouiller car les concepts simples (variables, boucles, incrémentations, etc...) sont là.

Si je peux me permettre une remarque annexe, je ne pense pas qu'on puisse réellement dire que la syntaxe ou la sémantique des pointeurs en C soit compliquée. Plus précisément, je pense que, bien expliquée, elle ne devrait pas présenter de grandes difficultés à un débutant.

Mon modèle mental des pointeurs est simple et peut s'expliquer en un paragraphe. Je ne suis pas spécialiste du C (donc je peux me tromper) mais je pense qu'il est relativement précis et conforme à la spécification du langage. L'idée est que la syntaxe *foo a une signification différente selon qu'il est en position de lvalue, qui décrit un emplacement modifiable, ou de rvalue qui décrit une valeur à placer dans un emplacement. Dans l'assignation *foo = *bar; on a une lvalue à gauche du signe égal, et une rvalue à droite. Ici *foo désigne l'emplacement situé à l'adresse foo. *bar désigne la valeur placée à l'emplacement d'adresse bar. La signification est différente mais symétrique. Enfin, en position de déclaration et de type, int *baz définit une variable baz contenant une adresse vers un entier, et le type int * représente les adresses vers des entiers. Il me semble que dans chacun des cas, la signification de * est la seule possible/raisonnable dans ce contexte, donc elle est facile à retrouver. Le plus difficile est de comprendre les rôles différents de lvalue et rvalue.

Une fois qu'on a bien compris ça (et fait l'effort de faire quelques exercices pour bien comprendre pratique comment on stocke des adresses dans des variables, la différence entre modifier une variable (qui désigne un emplacement mémoire) et l'emplacement à l'adresse qu'elle contient, etc.), pour moi le plus difficile est de retenir les questions de priorité des opérateurs, par exemple ce que signifie *foo++.

Cette dernière remarque me rappelle que j'ai aussi lu dans ce fil que la différence entre ++i et i++ est compliquée. Pour moi il suffit de remplacer dans sa tête par quelque chose comme, grosso modo, (i += 1; return i) et (int j = i; i += 1; return j).


PS: bien sûr une partie de la difficulté avec les pointeurs, que je n'ai peut-être pas bien détaillée ici, est qu'ils demandent au débutant de s'être construit un bon modèle mémoire du langage. Une méconception courante, et véhiculée dans certains cours, est de confondre variable (un concept syntaxique) et emplacement modifiable (concept sémantique) désigné par cette variable.

Citation : bluestorm

Si je peux me permettre une remarque annexe, je ne pense pas qu'on puisse réellement dire que la syntaxe ou la sémantique des pointeurs en C soit compliquée.

Hum, c'est ce qu'on peut dire APRÈS, une fois qu'on a compris. Il y a plusieurs degrés de compréhension d'une notion. Par exemple, on peut te raconter une histoire drôle, tu en comprends tous les mots, tous les termes et pourtant tu ne ris pas donc tu n'as rien compris tout en ayant tout compris.

Pour les pointeurs, tu n'as fait qu'esquisser les nombreuses difficultés que l'on peut rencontrer et que tu ne peux peut-être même pas imaginer. J'ai encore gardé le livre où j'avais appris ça il y a 6 ans et que j'avais annoté. En plus c'est un livre considéré comme particulièrement posé pour les débutants. Je suis resté longtemps bloqué sur le fait que si on avait

int *i;

et par analogie avec

int j;

alors on déclarait une variable qui s'appelait *i, autant te dire que j'étais mal barré. Et puis l'auteur parlait de pointeur sans jamais définir ce qu'est un pointeur (ie la nature d'un pointeur) qui finissait pas devenir pour moi un concept complètement nébuleux. Bon et puis au début, tu comprends mal les pointeurs car tu vois pas à quoi ça sert, tu déréférences des pointeurs pour obtenir des valeurs dont tu disposes déjà, genre

int x=42;
int *p;
p=&x; /* Truc que j'ai mis un temps fou à comprendre */
printf("%d\n", *p);

et tu vois s'afficher 42, quel intérêt puisqu'on a déjà cette valeur de 42 vu qu'on l'a placé en x.

Bon, une fois qu'on a compris les anomalies dont tu parles (en particulier l'abérration int *p=&x; où tu lis que *p qui est un int est affecté par une adresse et qui est donc de type différent), tu rencontres tout un tas d'autres difficultés, moi ça a été les pointeurs vers les structures suivies des listes chaînées, le qualifieur const (et son cortège d'horreurs en tous genres et de warning du compilo), le rôle fondamental du passage de pointeur en paramètre d'une fonction (mais en C, les passages se font par valeur..., expression qui m'a demandé pas mal de temps avant d'être comprise) et puis bien sûr, la distinction entre tableaux et pointeurs (et tout ce qui suit, dont l'arithmétique des pointeurs) et dont la non-compréhension est rédhibitoire. Après la grosse-grosse étape ça a été de vraiment bien comprendre l'intérêt d'un pointeur vers un pointeur et de le manipuler aisément. Et tant que t'as pas vraiment compris les pointeurs, tu peux rien faire de souple en C (toutes les lib utilisent des pointeurs, l'allocation dynamique c'est des pointeurs, etc). Après cette étape, il y en a d'autres, genre const et les pointeurs, les pointeurs vers des fonctions, les pointeurs génériques.

Citation : bluestorm

pour moi le plus difficile est de retenir les questions de priorité des opérateurs,

Le retenir, c'est pas vraiment le problème et puis sinon, tu imprimes le tableau de priorité des opérateurs qui est dans K&R et tu l'affiches pour l'avoir tout le temps sous les yeux. Le plus dur pour moi ça a été de comprendre au delà du mot-à-mot ce qu'était la priorité des opérateurs (et de l'associativité) et comment fonctionne l'algorithme de placement artificiel des parenthèses de priorité ie par exemple *t[N] équivaut à *(t[N]).

Citation : bluestorm

Pour moi il suffit de remplacer dans sa tête par quelque chose comme, grosso modo, (i += 1; return i)

Ben non justement :

int main(void)
{
int i=42;
printf("%d\n", i++);

    return 0;
}

42

(moi je comprends que tu dis que ça devrait retourner 43).

Citation : bluestorm

Pour moi il suffit de remplacer dans sa tête par quelque chose comme, grosso modo, (i += 1; return i) et (int j = i; i += 1; return j).

Moi, ce qui m'a gêné c'est cette d'histoire d'incrémenter avant (préfixe) ou après (postfix). Avant ou après quoi ? Or en fait, c'est plus compliqué que ça. D'après la norme elle-même, le plus simple c'est ++E qui est équivalent à (E+=1), ya pas d'avant ou d'après. Par contre, E++ la modification de l'opérande a bien lieu après et avant quelque chose, et ce quelque chose est un truc qui n'est pas évident à comprendre, c'est ce que la Norme appelle un point de séquencement, c'est expliqué en annexe dans la Norme.

Citation : bluestorm

Une méconception courante, et véhiculée dans certains cours, est de confondre variable (un concept syntaxique) et emplacement modifiable (concept sémantique) désigné par cette variable.

Je ne comprenais pas pourquoi dans les forums C de usenet, les intervenants n'employaient jamais le terme de variable (le Norme non plus d'ailleurs). Le problème est que ce terme est très ambigu. Donc je préfère qu'on parle tantôt d'identificateur, tantôt d'objet, tantôt d'opérandes, etc

Citation

Et puis l'auteur parlait de pointeur sans jamais définir ce qu'est un pointeur (ie la nature d'un pointeur) qui finissait pas devenir pour moi un concept complètement nébuleux.

C'est typiquement le genre de problèmes qui proviennent d'un mauvais support d'apprentissage. Si les gens qui apprennent n'ont pas un bon modèle mental de ce qu'on leur enseigne (c'est-à-dire, s'ils croient des choses fausses qui survivent longtemps aux explications de l'enseignant), ils vont forcément avec des difficultés importantes.

Je pense qu'il y a aussi une question de rigueur dans la présentation d'une notion. Quelqu'un même avec une formation mathématique minimale (je dirais un élève motivé au lycée) saura apprécier qu'on définisse précisément une notion avant de l'utiliser. S'il accepte (et c'est une formation à la rigueur) de construire son modèle mental sur cette définition précise, au lieu d'en ignorer tout ce qui est, justement, précis et de se dire "je comprendrai bien après", je ne pense pas qu'il considère les pointeurs comme un concept difficile. Par contre, si on essaie de deviner la signification à partir d'un exemple ou de plusieurs exemples, on va au devant d'un grand nombre de difficultés parce que la distinction lvalue/rvalue n'est pas facile à deviner, et les débutants vont donc souvent se construire des modèles mentaux partiels et incohérents au lieu de comprendre cette règle dans sa généralité.

Note bien que je ne prend pas position sur le débat "définition avant exemples" ou "exemples avant définition"; j'ai moi-même plutôt un style "exemples avant définition", car je préfère motiver une notion en montrant qu'elle répond à un besoin. La question est de savoir à quel moment le débutant doit *comprendre* la notion : en lisant les exemples, ou en lisant la définition ? Je pense que, pour un aspect d'un langage de programmation, il vaut mieux donner une définition précise et insister pour que le débutant la comprenne, plutôt que de le livrer à lui-même en le laissant "deviner" la notion par les exemples seulement.

Bien sûr, cette approche marche mieux avec des débutants qui ont déjà une formation scientifique, car ils sont déjà habitués à cette forme de rigueur. Mais si c'est souvent plus difficile pour les autres, c'est justement parce qu'il faut leur apprendre cela en même temps, et pas à cause de la programmation elle-même.

Citation

Ben non justement

(i += 1; return i) et (int j = i; i += 1; return j) sont les "équivalents grosso modo" (en pratique ce n'est pas du C valide à cause de `return`) de ++i et i++ respectivement. (i += 1; return i) correspond à ++i; je n'ai pas mis (i += 1) seulement parce que je ne pense pas que ce soit plus clair.


PS: je reformule mon affirmation initiale. Je suis d'accord sur le fait que les pointeurs¹ sont plus difficiles à apprendre que d'autres fonctionnalités du C. Mais je pense qu'avec un bon support d'enseignement, qui a pris soin de ne pas laisser les débutants construire un mauvais modèle du langage (par exemple la confusion variable/emplacement, qu'il faut éviter en présentant les structures ou les tableaux avant d'aborder les pointeurs pour avoir un exemple non-variable de lvalue), cette notion peut être comprise dès la première fois, et faire couler nettement moins de sueur et de larmes que ce qu'on lui attribue généralement.
Cela dit, je préfère utiliser un langage comme Caml (sans sa couche objet) qui n'a pas de notion de lvalue. En comparaison je trouve l'usage des références en C++ encore plus difficile que celui des pointeurs en C, du fait de son aspect implicite dans les appels de fonction.

¹: après il faut voir ce qu'on entend par "pointeur", pour moi il s'agit seulement de définir le comportement de *; l'arithmétique sur les pointeurs et les pointeurs de fonctions sont des sujets à part. Par contre, ça comprend aussi les pointeurs sur pointeurs par exemple.

Citation : bluestorm

Citation

Et puis l'auteur parlait de pointeur sans jamais définir ce qu'est un pointeur (ie la nature d'un pointeur) qui finissait pas devenir pour moi un concept complètement nébuleux.

C'est typiquement le genre de problèmes qui proviennent d'un mauvais support d'apprentissage. Si les gens qui apprennent n'ont pas un bon modèle mental de ce qu'on leur enseigne (c'est-à-dire, s'ils croient des choses fausses qui survivent longtemps aux explications de l'enseignant), ils vont forcément avec des difficultés importantes.

Je pense que ça provient en effet d'un mauvais support d'apprentissage mais je ne crois pas que ça soit parce que celui qui apprend à un mauvais modèle mental et qu'il croient des choses fausses même si occasionnelement ça peut jouer, par exemple si on connait un autre langage Y et qu'on importe inconsiemment dans le langage X à apprendre des éléments de Y. En réalité, quand tu commences les pointeurs, tu n'as aucun modèle mental car c'est tout nouveau et que c'est une notion abstraite.

Citation : bluestorm

Quelqu'un même avec une formation mathématique minimale (je dirais un élève motivé au lycée) saura apprécier qu'on définisse précisément une notion avant de l'utiliser.

Alors ça par contre j'y crois pas du tout car c'est tout simplement impossible et au total c'est même encore pire. Bien sûr, il faut nuancer en fonction du profil de celui qui apprend. Pourquoi c'est impossible ? Parce que pour le C, tu en viendrais à faire la Norme du langage. Tu veux définir rigoureusement un pointeur ? et bien bon courage ! Regardons la seule et l'unique définition, celle donnée par la Norme(elle définit les implémentations du langage). Un pointeur ça n'existe pas, ce qui existe c'est un type (à définir donc) et c'est un type dit dérivé à partir d'un type objet, incomplet ou fonction (qu'il faut aussi avoir défini avant). Ensuite, même la Norme ne te définit pas rigoureusement un type pointeur. Une définition mathématique est équivalente à un "si et seulement si" (il existe aussi des définition récursive). La Norme n'ira jamais aussi loin. Elle dit :


A pointer type describes an object whose value
provides a reference to an entity of the referenced type. A pointer type derived from
the referenced type T is sometimes called ‘‘pointer to T’’. The construction of a
pointer type from a referenced type is called ‘‘pointer type derivation’’.


Tu vois le vague de cette définition : Un type pointeur décrit (décrire ce n'est pas être). Et puis une référence c'est quoi ? (ben il parait qu'en toute rigueur ce n'est pas une adresse, bon et qu'est-ce qu'une adresse ?). Et c'est une référence vers une entité, mais une entité c'est quoi ? Tout ça ce sont des mots qui ne sont même pas définis dans la Norme (la Norme définit dans son début un certain nombre de termes comme bit, character, alignement, object, etc) avec plus ou moins de précision et ne définit pas d'autres termes primitifs).


Et là encore, tu n'as qu'une définition mais après tu as la syntaxe et la sémantique à définir, et c'est encore plus compliqué (vu l'ubiquité des pointeurs en C).


Bref, c'est pour moi une très mauvaise méthode : on obtient un exposé pseudo rigoureux et abscon.

Les textes utilisant cette méthode sont d'ailleurs très rares. Par exemple, le livre de Xavier Dupré sur Python est sur ce modèle et ça n'empêche pas son exposé d'être souvent très peu clair et c'est alors d'autant plus agaçant de le voir proposer ses pseudos définitions qui ne t'apprennent rien (tu ne VOIS rien en les lisant).


Il faut bien sûr beaucoup de rigueur quand on expose la programmation dans un langage donné mais c'est loin de suffire. Pour en revenir à mon expérience, quand j'ai vu que le livre que j'utilisais avait une rigueur défaillante, j'en ai choisi un autre, censé être beaucoup plus rigoureux, qui donnait des exemples à caractères mathématiques par exemple. Et en fait il comportait à peu près les mêmes défauts qui font que tu ne VOIS pas : exposé abstrait, exemples décontextualisés et incomplets, appui sur des prérequis qui en fait n'ont pas été exposés (traduction : le bonhomme n'a pas fait un tri topologique).

Citation : bluestorm

PS: je reformule mon affirmation initiale. Je suis d'accord sur le fait que les pointeurs¹ sont plus difficiles à apprendre que d'autres fonctionnalités du C. Mais je pense qu'avec un bon support d'enseignement, qui a pris soin de ne pas laisser les débutants construire un mauvais modèle du langage (par exemple la confusion variable/emplacement, qu'il faut éviter en présentant les structures ou les tableaux avant d'aborder les pointeurs pour avoir un exemple non-variable de lvalue), cette notion peut être comprise dès la première fois, et faire couler nettement moins de sueur et de larmes que ce qu'on lui attribue généralement.

Je ne croit pas trop à cela. Tu te limites trop à la rigueur pure et dure et tu ignores l'aspect sens (meaningfulness). Il faut beaucoup de temps et avoir vu beaucoup de choses avant de comprendre que, oui, les pointeurs finalement ça sert à quelque chose et c'est très efficace et que s'il fallait s'en passer, il faudrait écrire des choses très compliquées voire on ne pourrait pas.

Citation : bluestorm

¹: après il faut voir ce qu'on entend par "pointeur", pour moi il s'agit seulement de définir le comportement de *;

Ce n'est qu'un aspect de la notion de pointeur et qui en plus contient plusieurs aspects (* c'est le déréférencemment donc l'accès au contenu mais c'est aussi le contenant quand tu fais une déclaration de pointeur). Mais les pointeurs, c'est toute une ambiance que tu ne peux réduire à *.

Citation : bluestorm

C'est typiquement le genre de problèmes qui proviennent d'un mauvais support d'apprentissage. Si les gens qui apprennent n'ont pas un bon modèle mental de ce qu'on leur enseigne (c'est-à-dire, s'ils croient des choses fausses qui survivent longtemps aux explications de l'enseignant), ils vont forcément avec des difficultés importantes.

Pas évident, je n'ai jamais trouvé de définition claire concernant les pointeurs, si tu penses avoir une meilleure explication sur l'intérêt des pointeurs, le pourquoi de cette syntaxe affreuse qui décourage les débutants, alors tu m'enlèves une sacré épine du pied.

Normalement dans une syntaxe il y a toujours une logique du pourquoi et du comment celle-ci existe.

int x=42;
int *p;
p=&x; /* Truc que j'ai mis un temps fou à comprendre */
printf("%d\n", *p);

Comme Candide ce genre de syntaxe est totalement illogique, j'ai eu du mal à m'y faire aussi et encore on arrive pas dans le cas des tableaux et pointeurs, là c'est le brouillard complet.

Citation : bluestorm

Bien sûr, cette approche marche mieux avec des débutants qui ont déjà une formation scientifique, car ils sont déjà habitués à cette forme de rigueur. Mais si c'est souvent plus difficile pour les autres, c'est justement parce qu'il faut leur apprendre cela en même temps, et pas à cause de la programmation elle-même.

Je ne suis pas d'accord, pour maîtriser les pointeurs une formation mathématique de haut niveau est inutile par exemple.

Je pense que comme tout langage, ça se travaille, beaucoup d'exercices, de lectures de code et de motivation. Il faut en bouffer! Mais c'est peut-être de cette rigueur dont tu parles, donc dans ce cas je suis d'accord.

Citation : candide

Je ne croit pas trop à cela. Tu te limites trop à la rigueur pure et dure et tu ignores l'aspect sens (meaningfulness). Il faut beaucoup de temps et avoir vu beaucoup de choses avant de comprendre que, oui, les pointeurs finalement ça sert à quelque chose et c'est très efficace et que s'il fallait s'en passer, il faudrait écrire des choses très compliquées voire on ne pourrait pas.

+1000

Le fait de savoir qu'on pouvait éviter les pointeurs dans un sens m'avait un peu plus motivé pour apprendre le langage, une fois avoir progressé un peu, j'ai essayé de comprendre les pointeurs, mais le tuto, malgré tout le mal que s'est donné M@teo21 était trop théorique.

On devrait au départ éviter au débutant l'utilisation des pointeurs tant qu'il n'a pas un minimum d'expérience dans le langage.

La difficulté, est de savoir quand est-qu'un débutant est capable ou non d'ingérer cette notion de pointeur.

Citation : candide

Mais les pointeurs, c'est toute une ambiance que tu ne peux réduire à *

Encore d'accord avec ça, si les pointeurs se réduisaient à cela, ça serait simple pour tout le monde.

Attention, quand je parle de définitions précise je ne parle pas forcément de définition "formelle". De plus, on n'a pas besoin de tout dire; il faut que ce qu'on dise soit cohérent avec ce qu'on veut faire faire aux gens, ne pas utiliser des simplifications qui sont incompatibles avec ce que le débutant fera, et ça demande de la précision. Donc on n'est pas obligé de répéter la norme qui mentionne plein de choses qui ne font pas partie du sous-ensemble du langage qu'on enseigne.

Enfin, la définition d'une notion peut être raffinée incrémentalement. On peut laisser les gens croire que `x = t;` modifie la variable x, et non pas l'objet désigné par la variable x, tant qu'on n'a pas introduit d'autre lvalues que les variables (de toute façon une distinction qui ne distingue rien est impossible à retenir). Mais il faut faire le travail d'expliquer ensuite précisément pourquoi `x[i] = t;` ou `x.f = t;` sont aussi valides, au lieu de ne rien dire et laisser le débutant "deviner" que "ça se comporte comme une variable". Bref, on peut présenter une notion (ici le comportement de l'assignation et les lvalues) incrémentalement, ce qui permet de combiner précision (relative) et clarté.


Je suis d'accord avec toi sur le fait que la précision n'est pas du tout le seul ingrédient nécessaire à une bonne pédagogie. Il y a beaucoup d'autres aspects à travailler et de pièges à éviter. Tu as raison en particulier d'insister sur l'insistance des exemples. Je ne pense pas que ce soit contradictoire.

Auu début j'avais un peu de mal avec les pointeurs, mais on finit pas comprendre, moi ce que j'ai compris:

int* pointeur1;
double* pointeur2;
char* pointeur3;

sont des variables permettant de contenir l'adresse d'un élément dans la RAM. Ces éléments ont eux-même une adresse, comme toutes les variables, et sont stockés de la même manière que les autres, à la différence qu'ils sont faits pour contenir des adresses, et non des valeurs numériques classiques.

int nb1;
double nb2;
char nb3;

sont des variables qui contiennent une valeur numérique classique, stockée dans la RAM. Ces éléments ont une adresse, comme toutes les variables.

On a ainsi:

int nombre = 5; // variable qui stocke un nombre
int* adresse; // variable qui stocke l'adresse d'un int (pointeur pour int) 

adresse = &nombre; // on stocke l'adresse de 'nombre' dans 'adresse' 

int nombre2 = *adresse; /* on stocke ce qui se trouve à l'adresse 'adresse' 
et on met cette valeur numérique dans la variable nombre2*/

Il faut bien faire attention à ne pas confondre le * lors de la déclaration d'un pointeur:

float* pointeur;

avec le * qui permet de récupérer le contenu d'une adresse:

float nombre = *pointeur;

Ce qui m'a aussi gêné est que je n'avais pas compris qu'en fait, un pointeur était juste une variable qui contient une adresse, donc une adresse, si je l'avais compris plutôt, ça aurait été plus vite.

Sinon, une fois qu'on a compris, ça va déjà mieux...

La discussion est très intéressante mais je pense que vous écartez un peu le sujet la. Je pense qu'un autre topic serais plus adapté.

Beh nan c'est pas hs, les pointeurs, c'est bien ce qui refoule le plus de programmeurs en C, et c'est pour ça que des langages de haut niveau existent, car tout le monde n'a pas envie de se prendre la tête avec ça.

Peut-être, mais ce sujet sert à discuter des choix de pédagogie (langage à utiliser pour débuter, aspects des langages qui les rendent adaptés ou non à l'apprentissage...), et pas forcément à donner des cours sur une notion en particulier.

Je pense que la discussion sur les pointeurs est intéressante tant qu'elle concerne des points de pédagogie qui sont généralisables à d'autres situations. Dans ce contexte les réponses de candide sont très intéressantes. Par contre ton message est un peu trop spécialisé et profiterait effectivement d'être dans un sujet à part.

Si tu as envie d'apprendre pourquoi il est mauvais d'écrire int* pointer1, je t'invite à créer un topic sur les pointeurs en C. Je serai ravi de venir discuter du sujet.

Il faut aussi noter que la programmation est un outil de plus en plus utilisé, en entreprise par exemple, tous n'ont pas forcément besoin du lot de difficulté apporté par le C, et bien souvent, c'est je Java qui l'emporte car il a l'avantage d'être moins un casse-tête et est donc plus populaire.

Quant au Python, c'est un langage prisé en mathématiques ou en algorithmique, puisqu'il permet de se concentrer sur l'essentiel du problème, même s'il a des spécificités qui lui sont propres et qui l'éloignent des langages "classiques" (C, Java, C++,...), il reste un bon compromis, surtout pour un débutant, qui n'aura pas une montagne de connaissances et de compréhension à assimiler pour programmer.

Pour le C, ce qu'il a de bien, c'est qu'il fait à peu près tout, avec de meilleurs performances que des langages interprétés, tout en gardant une syntaxe assez simple, une fois qu'on la maîtrise. Certes, quelques concept rebuttants peuvent décourager le débutant, mais avec persévérance, on peut y arriver, je ne pense pas que ce soit le meilleur langage pour commencer.

Mais il y a d'autres langages, et après, une fois un langage maîtrisé, le programmeur peut passer d'un langage à un autre aisément. Et rien empêche un aguerri du C d'apprendre le Python, ça ne va pas dans un seul sens.

Citation : Bin-R

Quant au Python, c'est un langage prisé en mathématiques ou en algorithmique

C'est une blague ?

Je pense qu'il y a effectivement des mathématiciens qui utilisent Sage (même si l'idée de faire des expérimentations sur ordinateur reste limitée à certaines personnes dans certains domaines), même si je pense qu'ils l'utiliseraient aussi si c'était codé dans un autre langage.

Citation : anmee

Je crois qu'il y a une distinction importante à faire entre langage simple et langage facile.

Un langage est simple s'il contient un nombre de concepts assez limité, et qu'on peut apprendre tout ce qu'il y a à savoir sur le langage en lui-même (syntaxe, sémantique) en peu de temps. Cela ne veut pas dire qu'il est facile. Le brainfuck est un langage des plus difficiles, mais aussi l'un des plus simples. Le C est un langage relativement simple (plus simple que Python, en fait) mais aussi relativement difficile (plus difficile que Python).

Je plussoie.

Citation : anmee

[...] Dans la première optique, OCaml est intéressant, Python également (ce dernier étant plus facile, mais moins adapté à l'apprentissage de l'algorithmique).

Citation : anmee

Citation : Bin-R

Quant au Python, c'est un langage prisé en mathématiques ou en algorithmique

C'est une blague ?

Je ne sais pas ce que tu appelles ici algorithmique, mais sincèrement je ne vois aucune raison pour que ce soit une blague. Pourquoi donc pense tu que python soit moins adapté à l'apprentissage de l'algorithmique, et surtout de quel type d'apprentissage parles tu ?

De plus, quel langage pense tu être prisé en algorithmique ? Si tu penses à OCaml, je ne crois pas que ce soit un langage très prisé du tout (comparé à Scheme, par exemple). C'est d'ailleurs l'une des raisons principales qui me décourage de continuer d'apprendre ce langage (j'ai commencé un jour) : le langage n'a pas l'air très viable*... Détrompe moi si j'ai tort, je t'en prie.

* A part en France, à quel point OCaml est il utilisé dans le monde ? Il ne figure même pas sur l'index TIOBE des 50 langages les plus utilisés...

L'algorithmique, c'est en quelque sorte (attention, définition très simpliste) trouver un 'chemin' pour résoudre un problème donné ; en général, on souhaite aussi que ce chemin soit optimal, ou du moins le plus adapté à ce que l'on recherche. En tout cas, ce n'est pas juste savoir comment structurer un programmer et utiliser des boucles (un nombre d'internautes étonnamment élevé pense cela).

L'apprentissage de l'algorithmique passe d'une part par l'étude de ce qu'est un algorithme, et pourquoi certains sont mieux que d'autres. Dans le SICP par exemple, il est montré au débutant comment on peut calculer naïvement une puissance ; ensuite la méthode d'exponentiation rapide est exposée, pour comparer.

La deuxième part de l'apprentissage, pour moi, ce sont les structures de données. Je n'envisage pas d'apprendre l'algorithmique à un débutant sans lui présenter les structures de données courantes telles que les listes, les tableaux, les arbres... puisque choisir la bonne structure de donnée est essentiel lorsque l'on veut un algorithme efficace.

C'est suffisant pour me dissuader de faire de l'algorithmique avec Python (structures de données louches...). Il y en a d'autres (récursivité terminale non gérée, etc.), mais je ne vais pas m'étendre trop longtemps là-dessus. Je ne doute pas que Python ait par ailleurs d'autres qualités, et qu'il soit un langage assez robuste pour développer des applications. Mais pour l'algorithmique, on repassera.

Citation : yoch

De plus, quel langage pense tu être prisé en algorithmique ? Si tu penses à OCaml, je ne crois pas que ce soit un langage très prisé du tout (comparé à Scheme, par exemple). C'est d'ailleurs l'une des raisons principales qui me décourage de continuer d'apprendre ce langage (j'ai commencé un jour) : le langage n'a pas l'air très viable*... Détrompe moi si j'ai tort, je t'en prie.

Tout langage qui permet d'écrire des algorithmes de façon plutôt classique (évitons Forth par exemple ), et qui propose des structures de données comme les listes et les tableaux, en ne masquant pas au programmeur la complexité de ces structures, peut être utilisé pour apprendre l'algorithmique. OCaml, Scheme, C peuvent faire l'affaire, mais les deux premiers valent mieux que le dernier, car celui-ci demande trop de se concentrer sur des détails techniques qui gênent l'apprentissage de l'algorithmique.

À propos de Caml en particulier, je ne peux pas te dire beaucoup de choses dessus, n'utilisant pratiquement pas ce langage. Cela dit, je ne comprends pas ce que tu veux dire quand tu dis "le langage ne m'a pas l'air très viable". Les rares fois où j'ai fait de l'OCaml, j'ai trouvé ce langage au contraire très robuste, avec une implémentation efficace ; il a tout pour durer. Un projet écrit en OCaml a d'ailleurs plus de chances d'être viable qu'un autre en Scheme (dont les standards sont assez faibles ; en général les programmeurs Scheme se limitent à une implémentation particulière du langage, mais si celle-ci arrête d'être maintenue... ouch). Le fait qu'il soit assez peu utilisé ne veut pas dire grand chose. Internet Explorer est plus utilisé que Firefox, bien que ce soit objectivement un navigateur de moins bonne qualité.

EDIT : OCaml fait partie des 50 langages les plus utilisés selon TIOBE. Regarde bien, il y est sous le nom ML.

Citation : anmee

La deuxième part de l'apprentissage, pour moi, ce sont les structures de données. Je n'envisage pas d'apprendre l'algorithmique à un débutant sans lui présenter les structures de données courantes telles que les listes, les tableaux, les arbres... puisque choisir la bonne structure de donnée est essentiel lorsque l'on veut un algorithme efficace.

C'est suffisant pour me dissuader de faire de l'algorithmique avec Python (structures de données louches...). Il y en a d'autres (récursivité terminale non gérée, etc.), mais je ne vais pas m'étendre trop longtemps là-dessus.

Bon, je comprends finalement ton point de vue. C'est vrai que c'est gênant, même si l'on peut aller très loin dans ce que tu appelles l'algo (et moi aussi d'ailleurs ) avec python, une fois ces "bizarreries" maitrisées.

Citation : anmee

Les rares fois où j'ai fait de l'OCaml, j'ai trouvé ce langage au contraire très robuste, avec une implémentation efficace ; il a tout pour durer. Un projet écrit en OCaml a d'ailleurs plus de chances d'être viable qu'un autre en Scheme (dont les standards sont assez faibles ; en général les programmeurs Scheme se limitent à une implémentation particulière du langage, mais si celle-ci arrête d'être maintenue... ouch). Le fait qu'il soit assez peu utilisé ne veut pas dire grand chose. Internet Explorer est plus utilisé que Firefox, bien que ce soit objectivement un navigateur de moins bonne qualité.

Attention, je n'ai absolument pas dit qu'OCaml est un langage de mauvaise qualité. Je ne le connais pas du tout assez pour cela. Simplement j'ai le sentiment qu'il n'est pas du tout soutenu industriellement, donc peut-être voué à disparaitre ou remplacé par une autre variante ML (sait on jamais)...

Citation : anmee

EDIT : OCaml fait partie des 50 langages les plus utilisés selon TIOBE. Regarde bien, il y est sous le nom ML.

Bizarre, il me semblait avoir cherché aussi ml. Mea culpa.

On parlait dans le cadre de l'apprentissage de l'algorithmique. Dans ce contexte-là, qu'OCaml ne soit pas très soutenu industriellement n'a aucune importance. De plus, ML est activement utilisé dans la recherche et l'enseignement, il n'y a pas de raisons donc pour qu'il meure si vite. C'est tout de même un langage de l'INRIA !

Citation : bluestorm

Attention, quand je parle de définitions précise je ne parle pas forcément de définition "formelle".

Je ne suis pas du tout convaincu par la nécessité de donner des définitions, précises ou pas. Le mode d'exposition d'un langage de programmation n'a rien à voir au mode d'exposition axiomatique et pyramidal de notions de mathématiques où il est relativement bien accepté.
D'ailleurs, un des défauts majeurs que je vois dans les cours de programmation traditionnels est la prédominance de l'explication textuelle, c'est-à-dire qu'on explique des notions par des paquets linéaires de texte, de la terminologie et des phrases complexes. Or je pense que c'est un mode très peu efficace et qui ne permet pas de comprendre facilement des processus. En fait comprendre comment programmer, c'est comprendre comment s'exécutent certaines actions qui se superposent (l'écriture du code, la corrélation entre le code-source et le flux des instructions lors de l'exécution, la modification de la mémoire. Il faut faire comprendre un scénario, avec des acteurs (les fonctions, les pointeurs, etc), des espaces (la mémoire, mon code-source, la bibliothèque statique, etc). Je trouve que l'explication textuelle unidimensionnelle (en général des paquets de texte) est peu efficace pour faire comprendre une dynamique. Je ne vois pas pourquoi la compréhension de situations dynamiques devrait passer par une description verbale (et souvent verbeuse). Moi je crois beaucoup plus à la présentation d'exemples (finement choisis) de code à mettre en action accompagnés de leur exécution et de commentaires sobres. Tiens, je ne sais pas s'il existe des serious game destinés à faire apprendre certains éléments du langage C.

Citation : bluestorm

De plus, on n'a pas besoin de tout dire; il faut que ce qu'on dise soit cohérent avec ce qu'on veut faire faire aux gens, ne pas utiliser des simplifications qui sont incompatibles avec ce que le débutant fera, et ça demande de la précision.

Je ne sais pas s'il faut s'arquer sur ces questions de précision. Comme tu le dis implicitement, il faut cacher certaines notions au public, à partir de là, la précision en prend un sacré coup. Il faut accepter de donner des définitions à géométrie variable, évolutive. Quant à ce qu'on veut faire faire au gens, on ne le sait qu'à court ou moyen terme.

Citation : bluestorm

On peut laisser les gens croire que `x = t;` modifie la variable x, et non pas l'objet désigné par la variable x, tant qu'on n'a pas introduit d'autre lvalues que les variables (de toute façon une distinction qui ne distingue rien est impossible à retenir).

Certainement. Mais moi j'irais beaucoup plus loin, je m'abstiendrais autant que possible de définir un concept aussi délicat que celui de lvalue (rien que le terme est assez barbare). L'idée de lvalue peut sembler assez simple (grosso modo, ce qui peut être à gauche d'une affectation) mais quand on regarde les chose plus en détails, c'est plus compliqué (il y a les lvalues et les lvalues modifiables) et ...

Citation : bluestorm

Mais il faut faire le travail d'expliquer ensuite précisément pourquoi `x[i] = t;` ou `x.f = t;` sont aussi valides, au lieu de ne rien dire et laisser le débutant "deviner" que "ça se comporte comme une variable".

... c'est même pas un bon concept puisque tu vas devoir dire quand telle expression est une lvalue et quand elle ne l'est pas, c'est d'ailleurs ce que fait la Norme quand elle écrit blablabla is not an lvalue, blablabla is an lvalue. Je ne vois pas comment, avec un certain degré de généralité et tout en restant clair et limiter la verbosité des explications, tu vas pouvoir exposer que toto.a est une lvalue puisque parfois ce n'en est pas une (il faut que toto soit elle même une lvalue ce qui n'est pas forcément le cas, imagine seulement que toto soit le résultat de l'appel d'une fonction qui renvoie une structure). Bref, plutôt que de faire de la pseudo rigueur, je préfère en dire moins (et à la limite mentir par omission) que dire des choses fausses ou très abstraites (et en fait surtout très flous) et je préfère me limiter à une batterie d'exemples bien choisis (en particulier bien dégraissés), représentatifs et sobrement bien commentés.

Citation : anmee

L'algorithmique, c'est en quelque sorte (attention, définition très simpliste) trouver un 'chemin' pour résoudre un problème donné

L'algorithmique est un domaine à la fois assez vaste, assez flou à la fois autonome et transversal à des displines variés (songe aux métaheuristiques venant de la physique ou des sciences du vivant) . Si tu regardes les origines, tu verras que cette notion a existé bien avant l'apparition de calculateurs (songe à l'algorithme d'euclide, voir au 5ème postulat d'Euclide, songe à la résolution des équations polynomiales) et il est encore possible d'en faire finalement en se tenant à l'écart d'implémentation machine voire de pseudo-code. Souvent l'algorithmique est juste un renforcement de la culture générale scientifique.

Citation : anmee

La deuxième part de l'apprentissage, pour moi, ce sont les structures de données. Je n'envisage pas d'apprendre l'algorithmique à un débutant sans lui présenter les structures de données courantes telles que les listes, les tableaux, les arbres... puisque choisir la bonne structure de donnée est essentiel lorsque l'on veut un algorithme efficace.

Pour moi, il n'y a aucune obligation à coupler l'algorithmique à l'apprentissage de structures de données comme celles que tu as citées), ça dépend fondamentalement du public auquel on s'adresse, de son niveau, de sa motivation, de son background.

Citation : anmee

C'est suffisant pour me dissuader de faire de l'algorithmique avec Python (structures de données louches...). Il y en a d'autres (récursivité terminale non gérée, etc.), mais je ne vais pas m'étendre trop longtemps là-dessus. Je ne doute pas que Python ait par ailleurs d'autres qualités, et qu'il soit un langage assez robuste pour développer des applications. Mais pour l'algorithmique, on repassera.

C'est vraiment n'importe quoi de raconter ça. Les structures de données en Python sont suffisantes et mêmes beaucoup plus riches (et souples) que celles du C. La récursivité terminale en C est une possibilité offerte par le compilateur, seulement offerte et qui ne figure nullement dans le langage. Et puis, de par ma pratique, j'ai l'impression que la récursivité terminale est assez rare, même factorielle ne l'est pas. Donc, ce n'est pas vraiment gênant.


Très franchement, je pense que si on veut utiliser un langage juste pour faire de l'algo, le choix de ce langage est indifférent, on peut prendre Python, ou Caml, ou Maple, voire C, ça dépend encore du public, des goûts et aptitudes de celui qui l'enseigne.

Citation : anmee

Tout langage qui permet d'écrire des algorithmes de façon plutôt classique (évitons Forth par exemple ), et qui propose des structures de données comme les listes et les tableaux, en ne masquant pas au programmeur la complexité de ces structures, peut être utilisé pour apprendre l'algorithmique. OCaml, Scheme, C peuvent faire l'affaire, mais les deux premiers valent mieux que le dernier, car celui-ci demande trop de se concentrer sur des détails techniques qui gênent l'apprentissage de l'algorithmique.

Oui, et même donc Python et pourquoi pas C++ ou Java, si tu regardes par exemple les langages les plus utilisés dans des concours de programmation, c'est souvent le C++ qui l'emporte largement (normal, il est rapide et il a une lib standard plus riche que celle du C et pour faire de l'algorithmique basique, il est peut-être plus simple que le C).

Citation : candide

Pour moi, il n'y a aucune obligation à coupler l'algorithmique à l'apprentissage de structures de données comme celles que tu as citées), ça dépend fondamentalement du public auquel on s'adresse, de son niveau, de sa motivation, de son background.

Quoi ? J'imagine mal quelqu'un réfléchir à l'efficacité de son algorithme s'il ne sait même pas choisir une structure de donnée. De plus, tu sais aussi bien que moi que ce ne sont pas des jouets théoriques : dans la pratique, tout projet un peu conséquent utilise ces structures de données. J'imagine mal quelqu'un se lancer dans le développement d'une application sans savoir ce qu'est un tableau et une liste chaînée.

Citation : candide

C'est vraiment n'importe quoi de raconter ça. Les structures de données en Python sont suffisantes et mêmes beaucoup plus riches (et souples) que celles du C.

Ne deviens pas agressif, s'il te plaît. Je n'ai jamais dit que les structures de données pythoniques n'étaient pas riches ni souples (en pratique elles sont très utilisables). Ce que je dis, c'est qu'elles masquent de la complexité à l'utilisateur. C'est gênant si l'on veut approcher l'algorithmique.

Citation : anmee

Ce que je dis, c'est qu'elles masquent de la complexité à l'utilisateur. C'est gênant si l'on veut approcher l'algorithmique.

Tu as dit qu'elles étaient louches, quel argument ! Maintenant je n'ai pas réagi à ce masquage de la complexité à l'utilisateur. En effet, pourrais-tu nous dire ce que tu entends par là (c'est quoi cette complexité qui ne nous est pas montrée ?) et même nous donner un exemple ?

Citation

Ne deviens pas agressif, s'il te plaît. Je n'ai jamais dit que les structures de données pythoniques n'étaient pas riches ni souples (en pratique elles sont très utilisables). Ce que je dis, c'est qu'elles masquent de la complexité à l'utilisateur. C'est gênant si l'on veut approcher l'algorithmique.

Est-ce que quelqu'un pourrait me donner le rapport entre structures de données et algorithme?

Citation

Tu as dit qu'elles étaient louches, quel argument ! Maintenant je n'ai pas réagi à ce masquage de la complexité à l'utilisateur. En effet, pourrais-tu nous dire ce que tu entends par là (c'est quoi cette complexité qui ne nous est pas montrée ?) et même nous donner un exemple ?

Soit, un exemple. En Scheme, la première structure de donnée que l'on apprend au débutant, c'est la paire : (cons a b). Ensuite on montre que l'on peut accéder (en temps constant) aux éléments de la paire en utilisant car et cdr : (car (cons a b)) retourne a et (cdr (cons a b)) retourne b. Ensuite on introduit les listes, en montrant que ce ne sont finalement que des paires imbriquées : (list a b c) est en fait équivalent à (cons a (cons b (cons c '()))). Le débutant comprend alors facilement pourquoi accéder au premier élément de la liste est plus rapide qu'accéder au dernier. Il comprend la vraie nature des listes, et pourquoi dans certains cas c'est une structure de donnée adaptée et dans d'autres non. On aurait pu également lui montrer la même chose en C ; en revanche, en Python, ça me semble plus difficile.

Citation : fred1599

Citation

Ne deviens pas agressif, s'il te plaît. Je n'ai jamais dit que les structures de données pythoniques n'étaient pas riches ni souples (en pratique elles sont très utilisables). Ce que je dis, c'est qu'elles masquent de la complexité à l'utilisateur. C'est gênant si l'on veut approcher l'algorithmique.

Est-ce que quelqu'un pourrait me donner le rapport entre structures de données et algorithme?

L'algorithme manipule une information, la structure de données la stocke. Ainsi, l'étude des algorithmes est liée à celle des structures de données. Par exemple, si je veux stocker dans une liste des nombres dans l'ordre croissant : on retrouve ici l'algorithme et la structure. L'exemple n'est pas trop parlant, mais oui il y a un rapport.

Personnellement (désoler je ne continue pas votre trucs mais je reviens à l'OP), j'aime pas trop python dû à sa syntaxe que je trouve moins bien que le C ou le C++ (vous pourrez dire ce que vous voulez, le simple fait d'utiliser des accolades nous aident bien (ainsi que l'indentation que nous gérons nous même).

Sinon je trouve aussi que python ben ne donne pas de superbe bonnes habitudes (un exemple tout bête :

pour un une boucle do...while, ont doit faire ceci :

while True:

if net teste : break

Brefs vous voyez que ce n'est pas super quoi (je ne parle pas de multiple autre chose comme pouvoir gérez nous même les types des variables).

Pour ma part, j'ai d'abord commencé par le C puis, une fois terminer la partie 2, j'avais fais le C++ où tout le gros brouillard que j'avais c'est dissipé. Mieux encore, je pouvais réfléchir par moi même et comprendre à une rapidité que je n'aurais penser atteindre. Cela m'a aussi permis de comprendre énormément de langage EN GROS au simple fait de le lire (j'insiste sur le EN GROS ).

Citation : FirstZero

ainsi que l'indentation que nous gérons nous même

En Python, tu gères toi-même l'indentation. Les seules restrictions sont qu'elle est obligatoire et qu'elle doit être cohérente.

Citation : FirstZero

Sinon je trouve aussi que python ben ne donne pas de superbe bonnes habitudes [...]

Basé sur un seul exemple ? Effectivement, les boucles do...while n'existent pas en Python, ce n'est ni une mauvaise habitude, ni une raison pour généraliser.

J'ai plutôt l'impression que tu n'aimes pas Python, ce n'est pas plus mal, mais c'est ridicule de le déconseiller pour des raisons totalement subjectives ("j'aime pas la syntaxe", par exemple).

Je voulais surtout parler du while True: qui était une mauvaise habitude

Après j'ai préciser pourquoi le C ainsi que le C++. Certes en lisant le C t'auras un gros brouillard. C'est pas grave si t'a pas tout compris de suite. Tu verras qu'une fois deux trois applications consoles faites (pas très grandes ) et surtout ton passage au C++, tout va s'éclarcir (en tout cas sa a été mon cas).

Python, c'est vrai que j'ai du mal avec lui (m'en voulez pas trop ) puis pour la syntaxe, je la trouve vraiment moins lisible

Au pire, je comprends que le C/C++ sont très compliqué, je ne peux pas le nier. Je vais donc te conseiller autre chose (à part si t'a été d'accord ). Cette autre chose est le Java. Sa syntaxe est clair, tout est objet DÈS LE DÉPART (très important) et puis c'est suffisament bas niveau pour que tu puisse tout gérer

Citation : anmee

Le débutant comprend alors facilement pourquoi accéder au premier élément de la liste est plus rapide qu'accéder au dernier. Il comprend la vraie nature des listes,

Je ne vois pas en quoi l'implémentation d'une liste (chaînée donc) me ferait mieux comprendre en quoi l'accès au dernier élément est moins rapide que l'accès premier, ce qui est complètement trivial et découle de la définition même d'une liste chaînée. D'autre part, je n'ai pas besoin de savoir comment est implémentée la liste, ça ne change rien à la complexité des algorithmes qui utilisent la structure de données. Au contraire ça ajoute une couche artificielle de complexité pour l'utilisateur.

Citation : anmee

On aurait pu également lui montrer la même chose en C ; en revanche, en Python, ça me semble plus difficile.

Le C ne contient nativement aucune structure de liste chaînée. Si tu veux des listes chaînées, il faut te les construire de A à Z, ce qui est assez casse-gueule, surtout si tu veux des listes chaînées génériques. Implémenter soi-même une liste en C est une question qui n'a aucun intérêt algorithmique (on apprend rien de plus sur la nature d'une liste en la codant), c'est un exercice très laborieux et technique, et qui n'est pas à la portée de tout le monde (surtout si la liste est générique).

Python contient une structure de liste qui est en fait une structure de tableau (ainsi que le signale bluestorm dans son tuto). Néanmoins, Python propose les opérations usuelles sur les listes, suppression, insertion [mais qui sont d'un coût de O(n)] donc d'un point de vue de l'algorithme, on peut faire «comme si», naturellement les performances réelles peuvent s'effondrer. Ainsi le terme de list est incorrect, pour le reste, Python et C sont à égalité (et je ne vois donc pas pourquoi tu valides l'un et pas l'autre). Il est néanmoins un peu dommage qu'un langage aussi haut niveau que Python ne propose pas par défaut de vraies listes (il faut dire qu'en pratique c'est peu utile). Maintenant, il est assez facile de créer soi-même une classe listes chaînées, une classe noeud et de créer les méthodes insérer, supprimer, etc. c'est BEAUCOUP plus facile qu'à faire en C.

Citation : FirstZero

j'aime pas trop python dû à sa syntaxe que je trouve moins bien que le C ou le C++

Bon, je trouve pas que la syntaxe soit tellement différente.

Citation : FirstZero

vous pourrez dire ce que vous voulez, le simple fait d'utiliser des accolades nous aident bien (ainsi que l'indentation que nous gérons nous même).

Franchement gérer proprement l'indentation d'un code, ya qu'un programme qui peut le faire (indent ou astyle par exemple).

Citation : FirstZero

pour un une boucle do...while, ont doit faire ceci :

while True:

if net teste : break

Mauvaise habitude, bof. Moi en C j'utilise presque systématiquement du while(1) (et c'est très fréquent dans du code reconnu), ça permet d'économiser des neurones.

Citation : FirstZero

(je ne parle pas de multiple autre chose comme pouvoir gérez nous même les types des variables).

La souplesse de Python est là très appréciable (pas de déclaration)

Citation : FirstZero

Cela m'a aussi permis de comprendre énormément de langage EN GROS

sauf Python visiblement

Citation : FirstZero

Je voulais surtout parler du while True: qui était une mauvaise habitude

Ah ? Selon quels critères ? Les tiens ?

Citation : FirstZero

Après j'ai préciser pourquoi le C ainsi que le C++. Certes en lisant le C t'auras un gros brouillard. C'est pas grave si t'a pas tout compris de suite. Tu verras qu'une fois deux trois applications consoles faites (pas très grandes ) et surtout ton passage au C++, tout va s'éclarcir (en tout cas sa a été mon cas).

En quoi est-ce que cela est propre au C ou au C++ ? L'apprentissage passe par la pratique dans bien des choses, notamment dans la programmation.

Citation : FirstZero

Au pire, je comprends que le C/C++ sont très compliqué, je ne peux pas le nier.

Le C est simple (voir les messages de anmee, de mémoire). Tu confonds compliqué et complexe.

J'aimerais vraiment savoir ce que tu trouves obscur dans la syntaxe de Python. Habituellement, même les gens qui n'aiment pas Python ne nient pas que sa syntaxe est extrêmement simple à appréhender.

Citation : anmee

C'est suffisant pour me dissuader de faire de l'algorithmique avec Python (structures de données louches...).
<...>
Mais pour l'algorithmique, on repassera.

Je me demande dans quelle mesure tu n'as pas été influencé par ce que dit bluestorm dans son tuto. Il a raison de dire que si une structure de données vous propose d'être à la fois tableau et liste chaînée, il y a certainement arnaque quelque part, on ne peut pas gagner sur tous les tableaux ! Pour ce qui concerne Python, et après m'être renseigné, une liste Python est l'équivalent d'un tableau en C. À partir de là, je ne vois pas en quoi ça disqualifie Python pour faire de l'algorithmique.