Les boucles ......

[kwariz]

Tu as certainement raison, comme je te le disais je ne suis ni pédagogue ni enseignant. Tu as certainement raison d'introduire le goto pour dire ne pas l'utiliser, tout comme tu as certainement raison de parler de pile, de uC à pile limitée, de problèmes qui se poseront sans aucun doute à frequi1. Tu as certainement raison de vouloir préférer introduire les while(1) et while(0) (qui sont dangeureux pour le néophyte qui peut toujours s'en passer, d'ailleurs frequi1 s'en passait bien).
Sur ce je vais essayer de ne plus alourdir ce hors-sujet plus loin.
-----

[PA5CAL]

d'ailleurs frequi1 s'en passait bien

Note qu'il s'en passait en refaisant inutilement deux fois les mêmes tests. Preuve que cela a en fait une utilité bien réelle.

Ce qui est dangereux pour le néophyte, c'est justement de se laisser enfermer dès le départ dans des dogmes académiques souvent injustifiés, avec le risque de ne pas acquérir les bons réflexes (comme celui de s'assurer systématiquement qu'on sort des boucles qu'on programme) ou d'exclure certaines pratiques du champ de ses possibilités (comme redémarrer ou sortie d'une boucle en cours de route) à cause du « formatage » subi (et dont l'entourage professionnel subira les conséquences - et là je parle d'expérience).

Par ailleurs, il se trouve que l'instruction « forever », qu'on trouve sous la forme « while(1) » ou « for(; » en langage C, répond à des besoins algoritmiques spécifiques très concrets, et corrige en quelque sorte une carence syntaxique du langage C. Ce serait donc une hérésie que de la cacher ou d'interdire son utilisation aux débutants.

[PA5CAL]

Oups... il faut lire « for(;;) » et non pas « for(; » (satané smiley automatique !)

[kwariz]

Note qu'il s'en passait en refaisant inutilement deux fois les mêmes tests. Preuve que cela a en fait une utilité bien réelle.

Ce qui est dangereux pour le néophyte, c'est justement de se laisser enfermer dès le départ dans des dogmes académiques souvent injustifiés, avec le risque de ne pas acquérir les bons réflexes (comme celui de s'assurer systématiquement qu'on sort des boucles qu'on programme) ou d'exclure certaines pratiques du champ de ses possibilités (comme redémarrer ou sortie d'une boucle en cours de route) à cause du « formatage » subi (et que l'entourage professionnel subira par contrecoup - et là je parle d'expérience).

Par ailleurs, il se trouve que l'instruction « forever », qu'on trouve sous la forme « while(1) » ou « for(; » en langage C, répond à des besoins algoritmiques spécifiques très concrets, et corrige en quelque sorte une carence syntaxique du langage C. Ce serait donc une hérésie que de la cacher ou d'interdire son utilisation aux débutants.

Bon, allons-y ...
Des dogmes académiques ? Il ne s'agit que de bonnes pratiques. Son tuto le met en garde contre les boucles infinies, autant suivre la démarche et accompagner frequi1. À mon sens il lui serait plus profitable de d'abord comprendre la démarche

continuer := vrai
tant que continuer
  ...
  reponse:=0
  faire
    demander "on continue ? (1=oui, 2=non)" reponse
    si reponse<>1 et reponse<>2
     afficher "mauvaise reponse !"
  tant que reponse<>1 et reponse<>2
  si reponse=1
    continuer=vrai
  sinon
    continuer=faux
  fin si
fin tant que

C'est très personnel, mais je préfère cette méthode à l'utilisation injustifiée d'une boucle sans fin. Partant de là on peut lui faire découvrir comment et pourquoi on peut n'utiliser qu'une boucle, par exemple ; de là à prouver l'utilité réelle d'une boucle sans fin dans ce cas est un pas que je ne franchis pas ...
Deplus frequi1 commence à programmer sans avoir de bases an algo, ce qui à mon sens est un handicap qu'il pourra combler par la suite mais qui ne l'incite pas à avoir de bon reflexes.

On ne peut penser en dehors de la boîte que quand on en connait les limites et tout apprentissage passe par l'acquisition de bonnes pratiques que l'on doit admettre avant de les comprendre.

Mais bon, après c'est aussi en grande partie une question de style et de background.
Quant à la carence de la boucle «forever» ce n'en est pas une ... tout au plus pourrais-tu te plaindre d'un manque de sucre syntaxique (qui manque dans la plupart des langages que je connais par ailleurs ...).
Le grand problème de la boucle sans fin, dans ce cas de figure, est qu'elle n'améliore (j'irais jusqu'à dire détériore) la lisibilité du code.

[kwariz]

Oups... il faut lire « for(;;) » et non pas « for(; » (satané smiley automatique !)

j'avais traduit
ah ... ces smileys automatiques !!! une plaie sur un forum info

[PA5CAL]

C'est très personnel, mais je préfère cette méthode à l'utilisation injustifiée d'une boucle sans fin.

Préjuger de son utilité et de sa dangerosité pour ne pas l'utiliser, puis s'embêter à faire autrement (en plus compliqué et introduisant de nouvelles sources d'erreurs - frequi1 n'a d'ailleurs pas manqué de se tromper) afin de prouver qu'elle est inutile, c'est assurément une mauvaise démarche. En suivant le même raisonnement, on pourrait éliminer une bonne partie des instructions du C (« for », « do...while », « switch...case », « ++ », « -- », « ...?...:... », « ...= », etc.), qui font justement tout le succès et l'intérêt de ce langage.

Comme je l'ai indiqué, la boucle sans fin (dite « forever ») avec des sortie en cours de boucle (« break ») est parfaitement justifiée d'un point de vue algorithmique. Elle permet la généralisation de la notion de boucles, qui en pratique n'ont pas à se limiter à une condition de sortie testée seulement avant la première étape ou après la dernière étape du groupe d'opérations qu'elles contiennent. Mieux, elle permet de distinguer clairement la notion de test de condition de sortie.

Au lieu de réaliser ceci en multipliant les tests :

  reponse:=0
  faire
    demander "on continue ? (1=oui, 2=non)" reponse
    si reponse<>1 et reponse<>2
     afficher "mauvaise reponse !"
  tant que reponse<>1 et reponse<>2

on s'autorise à réaliser ceci :

  reponse:=0
  faire
    demander "on continue ? (1=oui, 2=non)" reponse
    si reponse<>1 et reponse<>2
     afficher "mauvaise reponse !"
     recommencer (faire)
    (fin si)
  (fin faire)

qui est finalement beaucoup plus proche du traitement nature (humain) de ce type de problème.

[PA5CAL]

Partant de là on peut lui faire découvrir comment et pourquoi on peut n'utiliser qu'une boucle

Et partant, on lui cache l'intérêt d'utiliser plusieurs boucles imbriquées. L'utilisation d'une seule boucle exécutée de bout en bout est une possibilité permanente† qui s'avère souvent inefficace, du point de vu des performances du travail de codage et de celles du produit réalisé (†: à la limite, tout programme aussi complexe soit-il pourrait n'être constitué que d'une grande boucle unique, avec une multitude d'exécutions conditionnelles « if()... »)

Deplus frequi1 commence à programmer sans avoir de bases an algo, ce qui à mon sens est un handicap qu'il pourra combler par la suite mais qui ne l'incite pas à avoir de bon reflexes.

On ne peut penser en dehors de la boîte que quand on en connait les limites et tout apprentissage passe par l'acquisition de bonnes pratiques que l'on doit admettre avant de les comprendre.

C'est justement ce que je reproche à l'approche « académique », et qui est pour moi une erreur ou un défaut fondamental : fixer dès le départ des limites, qui s'avèrent finalement très artificielles, mais qu'on a ensuite du mal à dépasser.

L'espace d'apprentissage et de raisonnement n'est pas comme une boîte fermée, mais plutôt comme un vaste territoire inconnu qu'on explore de proche en proche, dans lequel le matériel pédagogique devrait plutôt servir de carte d'orientation que d'enclos.

Les cours collectifs (et plus généralement la scolarité) sont inadaptés à ce point de vue, car pour des raisons pratiques tous les élèves doivent se retrouver au même point au même moment... au contraire de l'apprentissage autodidacte. Or, ici on se trouve dans ce dernier cas.


À mon sens, il est important d'avoir déjà de bonnes bases en algorithmie avant de programmer. À défaut, on peut se servir des exemples de code pour apprendre, et mener ainsi de front son apprentissage avec celui du codage. Mais dans le fond, il faut toujours savoir ce qu'on veut faire avant de pouvoir le réaliser.

Bien entendu, il faut aussi avoir une idée de ce qu'on peut faire. Mais s'enquérir des limites des possibilités du codage mène à restreindre le champ des algorithmes réalisables. Or, algorithmie et codage sont deux sciences indépendantes, qui ne devraient trouver leur point commun qu'au moment de la production d'un programme.

Il est donc particulièrement dommageable d'apprendre l'algorithmie au travers d'un langage limité, à plus forte raison lorsque ces limites ne sont pas techniques mais seulement de nature dissuasive.


Toutefois, un certain nombre de « bonnes pratiques » ont assurément leur utilité, car elles permettent de maintenir un bon niveau de qualité de la production, en réduisant le coût global des erreurs potentielles.

Mais elles ne sont « bonnes » que relativement à une situation et à des objectifs définis.

Or, chez des praticiens très au fait des conditions l'utilisation des boucles « forever » et œuvrant dans des environnements où l'oubli d'une sortie de boucle peut être rapidement détecté et corrigé, et il n'est aujourd'hui vraiment pas pertinent de mettre cet élément sur la liste noire des pratiques de codage, d'autant que l'absence de formation en la matière l'adoption de solutions alternatives expose finalement à des risques plus importants.

Le grand problème de la boucle sans fin, dans ce cas de figure, est qu'elle n'améliore (j'irais jusqu'à dire détériore) la lisibilité du code.

La lisibilité est en premier lieu un problème d'éducation.

Interdire ou passer sous silence une pratique informatique pourtant courante, c'est un peu comme arracher des pages dans un dictionnaire : il ne faut pas s'étonner ensuite que les élèves qui s'y réfèrent n'arrivent pas à lire certains textes.

C'est en apprenant les figures algorithmiques qu'on parvient ensuite à les reconnaître dans le code. S'interdire certaines figures ne peut mener qu'à compliquer la lecture des codes qui les mettent en œuvre.

De même, c'est en se familiarisant dès le départ avec les toutes les possibilités d'écriture du C qu'on apprend réellement à le lire. Or, bien souvent, comme son enseignement académique est calqué sur celui de langages plus simples, sa compréhension s'y limite mécaniquement, et sa lecture reste durablement un déchiffrage laborieux.

[frequi1]

Je suis désolé de voir que deux bon forumeur ne soit pas d'accord sur les bases de l'apprentissage de la programmation en C.
Personnellement j'ai découvert le langage sur "le site du zéros" qui m'as bien appris progressivement en partant vraiment de zéros. je me suis donc achetez le livre du langage C. Et si on regarde ou commence le chapitre sur les boucles et les condition (chapitre 6 page 75 sur 520) c'est quand meme relativement tôt (d'après vous).

Point de vu algorithme j'ai aussi un bouquin "Algorithmique Application en C" qui stipule bien que pour comprendre au mieux cet ouvrage on devais déjà avoir un niveau confortable en C.

Je trouve que PA5CAL m'a bien orienter durant mes petites galères, sans jamais me donner la réponse a mon problème mais en me dirigeant vers l'erreur
Sachez que je ne poste une discussion qu'une fois que je me suis pris la tête un bon petit moment, et le post me donne l'impression d'avoir baisser les bras
Au fur et a mesure que j'avance dans les chapitres, je modifie mon ancien code pour le rendre plus "Pro". (j'avance quoi ! ..... doucement mais j'avance...

Merci a toutes les personnes qui m'ont répondu et m'ont permis d'avancer en assimilant au fur et à mesure de mes erreurs, le fonctionnement du langage.

[kwariz]

...

Bonjour,

PA5CAL, je ne cherchais pas du tout à t'impliquer personnellement, si tu as pris mes propos dans ce sens sache que telle n'était pas mon intention,
Ton niveau en c est bon, mais tu as des réflexes qui ne matchent pas l'apprentissage que suit frequi1 qui ne fai tque ses tout premier pas en c.
Je n'ai jamais cherché à interdire des techniques qui pour toi semblent être la base du c alors qu'en réalité ce sont des concepts qui sont difficile parfois à intégrer quand on apprend : cela va de la différence essentielle entre pointeurs et tableaux (que beaucoup de bons programmeurs ne comprennent pas) ou de la manière d'utiliser la mémoire implicitement et explicitiment jusqu'à l'utilisation de la libc (quels programmeurs utilisent les argz ou les obstacks ?) sans aller jusqu'aux différentes normes et leurs différences.
Quand tu regardes le tuto que suit frequi1, tu t'aperçois qu'il y a une démarche, une progression. Je ne partais que du principe à suivre un minimum le tuto pour ne pas embrouiller frequi1.

[kwariz]

Je suis désolé de voir que deux bon forumeur ne soit pas d'accord sur les bases de l'apprentissage de la programmation en C.
Personnellement j'ai découvert le langage sur "le site du zéros" qui m'as bien appris progressivement en partant vraiment de zéros. je me suis donc achetez le livre du langage C. Et si on regarde ou commence le chapitre sur les boucles et les condition (chapitre 6 page 75 sur 520) c'est quand meme relativement tôt (d'après vous).

Point de vu algorithme j'ai aussi un bouquin "Algorithmique Application en C" qui stipule bien que pour comprendre au mieux cet ouvrage on devais déjà avoir un niveau confortable en C.

Je trouve que PA5CAL m'a bien orienter durant mes petites galères, sans jamais me donner la réponse a mon problème mais en me dirigeant vers l'erreur
Sachez que je ne poste une discussion qu'une fois que je me suis pris la tête un bon petit moment, et le post me donne l'impression d'avoir baisser les bras
Au fur et a mesure que j'avance dans les chapitres, je modifie mon ancien code pour le rendre plus "Pro". (j'avance quoi ! ..... doucement mais j'avance...

Merci a toutes les personnes qui m'ont répondu et m'ont permis d'avancer en assimilant au fur et à mesure de mes erreurs, le fonctionnement du langage.

Bonjour,

oui c'est un grand problème. Pour «bien» programmer il est indispensable d'avoir des bases en algorithme (du basique échanger les valeurs de deux variables, aux classiques comme trier un tableau, trouver un minimum, aux plus complexes utiliser une structure de données avec des algorithmes adaptés pour améliorer certaines performances ...).
Pour «bien» comprendre l'algorithmique, bah il faut aussi avoir des bases pratiques en programmation (savoir ce qu'on peut faire ou ne pas faire, architecturer un minimum l'algo pour pouvoir l'implémenter facilement, ...).
Je pense, mais cela est personnel, que tu vas devoir aller de l'un à l'autre ...
Le fait que tu fasses des efforts (cela se ressent) nous donne envie évidemment de t'aider.
En tout cas bon courage et n'hésite pas

[frequi1]

Le fait que tu fasses des efforts (cela se ressent) nous donne envie évidemment de t'aider.
En tout cas bon courage et n'hésite pas

Je ne peux répondre que : Merci

je suis encore loin de la fin...... Vous avez pas fini d'entendre parler de moi

[PA5CAL]

PA5CAL, je ne cherchais pas du tout à t'impliquer personnellement, si tu as pris mes propos dans ce sens sache que telle n'était pas mon intention,

Mais je n'ai absolument pas mal pris tes propos. On est sur une forum de discussion, et on discute en confrontant des opinions différentes, chacun présentant la sienne et soulignant ses points de désaccord avec celles des autres. Rien que de très normal en somme.

tu as des réflexes qui ne matchent pas l'apprentissage que suit frequi1 qui ne fai tque ses tout premier pas en c.

En fait, ma démarche repose beaucoup sur mon expérience (succès et échecs), et ma manière de présenter les choses découle principalement des facilités et des difficultés que j'ai pu rencontrer à mes début, quand j'apprenant en autodidacte (j'ai en effet commencé à me perfectionner dans l'électronique et l'informatique bien avant de recevoir mes premiers cours dans ces matières à l'école, pour en faire finalement une partie importante de mon métier en les officialisant par des diplômes), et des comparaisons que j'ai pu faire avec les collègues qui ont suivi un cursus plus classique (notamment dans le cadre d'études visant à améliorer les méthodes de travail et de production).

J'ai eu plusieurs fois l'occasion d'épauler des amis dans leur apprentissage du C ou du C++ en suivant ce point de vue, avec une efficacité qu'ils ont eux-mêmes reconnu et, avec le recul, des résultats très satisfaisants. Je n'oserais pas prétendre que je suis forcément dans le vrai, et encore moins que c'est la panacée, mais je pense que ce qui a bien marché pour certains a quelques chances de marcher encore pour d'autres.