Discussion :

[Jamatronic]

Le défi en question est expliqué dans cette courte vidéo :

Je ne sais pas s'il y a des habitués aux forums de developpez.com qui pourraient être intéressés.

Je ne savais pas non plus où poster cette discussion. Il y a peut-être plus pertinent que la "taverne" ?

[Invité]

Un vidéo sans image, c'est de l'audio, non ?

[Invité]

Un vidéo sans image, c'est de l'audio, non ?

Oui. Et même plus : de l'audio où il y a juste quelqu'un qui parle, c'est du texte...

[Jamatronic]

Non, puisque du texte "tout seul", on ne l'entend pas.

[Invité]

Ok, formidable.

Et sinon dans la vidéo sur les fonctions, tu traites encore les développeurs de cons ? Parce que perso, me faire insulter gratuitement et injustement, c'est pas trop mon truc.

https://www.youtube.com/watch?v=2ou_...youtu.be&t=860

[Jamatronic]

tu traites encore les développeurs de cons ?

Oh je suis désolé pour toi si tu fais partie de ceux qui étaient visés :-)

[Invité]

Il se trouve que tu vises "les développeurs, les pros et les autres". Donc à peu près tout le monde sur ce forum.

Et comme, je le dis dans mon message précédent : "injustement". Perso, je n'ai jamais critiqué Lisp et l'énorme majorité des développeurs que je connais non plus, contrairement au bashing généralisé que tu sembles dénoncer.

[Jamatronic]

je n'ai jamais critiqué Lisp

Donc tu n'étais pas visé.

J'ai insulté ceux qui crachent sur un langage alors qu'il n'ont aucune idée de ses fonctionnalités.

(Accessoirement, cela n'a rien à voir avec mon petit "défi".)

[Invité]

C'est celle-là la vidéo ?

J'ai autre chose à faire que de répondre à des défis mais j'aime bien regarder des vidéos de programmation de temps en temps (quand elles ne font pas trop d'insultes).

[Auteur]

Non, puisque du texte "tout seul", on ne l'entend pas.

bah, si le texte est lu, il est entendu ? Par contre, si le son est coupé que le texte soit lu ou non, il n'est pas entendu

[Jamatronic]

@SimonDecoline : oui c'est celle-ci

[Invité]

@SimonDecoline : oui c'est celle-ci

Après avoir regardé la vidéo, je suis un peu déçu (en même temps quand on annonce une "bombe", c'est difficile de ne pas décevoir).
Sur la forme, les "gros feutres" ce n'est pas très lisible mais surtout il y a régulièrement des bugs d'affichage où l'image devient complètement illisible.
Sur le fond, je trouve que ça part un peu dans tous les sens. Déjà je ne suis pas fan de faire la distinction entre fonction et procédure car ce n'est pas fondamental et beaucoup de langages ne font pas explicitement la différence. Enfin, je ne vois pas vraiment l'intérêt de parler des widgets, des boucles avec break et continue, des retours multiples en lisp... Quitte à parler de notions plus avancées, j'aurais plutôt mentionné la récursivité.
Mais après, chacun sa façon d'expliquer, c'est aussi une question de goût.

[Jamatronic]

Merci pour ton retour !

il y a régulièrement des bugs d'affichage où l'image devient complètement illisible.

Je n'ai pas vu cela.


Pour le reste, garde à l'esprit que c'est une vidéo destinée aux débutants, donc :

je ne vois pas vraiment l'intérêt de parler des widgets,

C'est hors sujet et c'est pour les préparer psychologiquement à la suite.

des boucles avec break et continue,

Beaucoup d'étudiants en informatique, ou de lycéens qui ont choisi ISN ont du mal à comprendre à quel moment une fonction s'arrête. (et si tu veux me contredire sur ce point je précise que c'est ce que je constate depuis 2001, début de ma "carrière" de prof d'info) J'ai donc fait une page sur ce sujet dans la vidéo. J'étais bien obligé d'évoquer d'abord les break et les continue des boucles, car dès qu'il y a des boucles dans des fonctions, la question "à quel moment la fonction s'arrête" devient un peu plus compliquée.

des retours multiples en lisp...

il y a toujours des langages qui s'écartent de mon propos principal. En général je l'évoque. C'est ainsi dans toutes mes vidéos. Et c'est aussi pour préparer à la suite.

Quitte à parler de notions plus avancées, j'aurais plutôt mentionné la récursivité.

Hé non ! A des débutants à qui tu expliques comment écrire leurs premières fonctions, tu ne parles pas tout de suite de récursivité... sinon il y a des têtes qui fument

PS : il y a déjà une personne qui a relevé le défi :

[f-leb]

Bonsoir à tous,

booléen est_trié (tab : tableau de T)
    Pour i allant de 1 à longueur(tab) – 1
        si tab[i] < tab[i-1]
            alors retourner Faux

    retourner Vrai

Il y a des choses qui me titillent dans cet algo "bonus" à la fin de la vidéo (quand on s’adresse à des grands débutants j’entends)…

• Plusieurs return: parce que justement il est moins facile de savoir quand l’algo se termine quand il y a plusieurs return disséminés dans la fonction.
• Quand on apprend la boucle "Pour", on explique souvent qu’on l’utilise lorsque l’on sait à l’avance le nombre de fois où le bloc est exécuté. Si on peut quitter à n’importe quel moment avec un return (ou un break, un truc qui n'est pas fondamental aux débutants pour ma part) dans la boucle, cela devient contradictoire.

Ma préférence va ainsi pour l’écriture suivante :

booléen est_trié (tab : tableau de T)
    tableau_trié ← Vrai
    i ← 1
    tant que i < taille(tab) et tableau_trié
        tableau_trié ← tab[i] >= tab[i-1]
        i ← i + 1
    fin tant que

    retourner tableau_trié

Si tu veux la preuve de terminaison de ton algo, on sait que le nœud du problème est dans la répétitive "tant que" et il y a un variant évident (fonction de terminaison : f(i) = taille(tab)-i).

Après je donne seulement mon avis... c’est pas moi qui viendrait sur le forum raconter que ce que j’écris est "de la bombe" et défier tout le monde de faire mieux

[foetus]

Ma préférence va ainsi pour l’écriture suivante :

Bof ce n'est pas terrible non plus (on affecte à chaque tour de boucle 1 valeur qui sera quasiment toujours la même)

booléen est_trié (tab : tableau de T)
    tab_size ← taille(tab)
    i ← 1

    tant que (i < tab_size) et (tab[i] >= tab[i-1])
        i ← i + 1
    fin tant que

    retourner (i == tab_size)

[Barsy]

Comment on fait le défi si on n'a pas accès aux vidéos ?

@f-leb : Je préfère l'écriture avec une boucle "for" plutôt qu'avec un "while". Le while rend l'écriture moins lisible et moins intuitive pour quelqu'un qui devra reprendre le code derrière. Un "for" est plus adapté lorsque l'on parcourt un tableau

Si le but est de ne pas avoir plusieurs "return" dans la méthode (ce que je préfère aussi), on peut faire la chose suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
booléen est_trié (tab : tableau de T)
    resultat ← Vrai

    Pour i allant de 1 à longueur(tab) – 1 faire
        si tab[i] < tab[i-1] alors
            resultat ← Faux
            Sortir

    retourner resultat