Journal Psychology of programming

Posté par (page perso) .
Tags : aucun
28
28
août
2010
En recherchant quelques docs sur les langages de programmations, je suis tombé sur un thème dont j'avais intuitivement soupçonné l'existence, sans jamais vraiment la vérifier : La recherche sur la psychologie de la programmation.

Il se trouve qu'un site http://www.ppig.org , abrite une conférence annuelle se tenant depuis environ 20 ans sur ce sujet. La plupart des papiers sont accessibles en PDF.
On y trouve des papiers absolument passionnants.

Je vais vous en introduire quelques uns parmi les plus intéressants que j'ai trouvé, bien que je n'ai pas fini d'écumer tout ce qui s'y trouve.
Pour la plupart je n'ai lu que l'abstract et la conclusion

Divers aspects sont abordés : la compréhension de la programmation par les novices, l'enseignement de la programmation, l'étude de méthodes comme l'extreme programming, l'analyse de la doc des programmes, des analyses comparatives de langage, sans compter des problématiques plus théoriques.

Quelques papiers

Metaphors we Program By : Space, Action and Society in Java : Ce papier analyse la doc, le code et diverses utilisation de java.util et java.bean et analyse les représentations mentales qui se trouvent derrière le code de façon latente. Les auteurs découvrent avec surprise que le code est métaphoriquement structuré par des agent BDI sans le D (Belief, Desire, Intention, modèle agent implémenté dans AgentSpeak par exemple, voir son implémentation ).
En particulier, le vocabulaire utilisé dans la Javadoc pour décrire les lib a été analysé et classé en terme de champ lexical, il y apparait plusieurs catégories :
- Borrowings, context, conventional, generic action, mentalistic, physical, society.

J'avoue particulièrement aimer ce papier car il me conforte dans mon projet de concevoir un langage intégralement agent.


A Loop is a Compression est une analyse de la perception de novice en programmation lorsqu'on leur apprend les bases des paradigme impératifs.
Il y est par exemple analysé le code suivant qu'un novice doit comprendre :

x := 0
input n
while n is not equal to -99 {
   if n > x then x := n
   input n
}
output x

Un extrait de la conversation (l'étudiant est en italique):

So what do you think that program would do?
Basically, because x was already set to zero, and then the while loop, n is bigger than zero, its
going to be put here, .. er.. (15 second pause) I wouldn't know, I'm not sure (12 second pause)

You're not sure?
No it kind of gets me confused, if..
So the interviewer introduces the idea of considering input values. The student needs a lot of help:
OK OK if we.. one way to work this out is thinking what would happen if we put different
numbers into it, so, x equals 0, input n, let's suppose we typed in 4, OK, so n would be 4,
Which is, err which is more than x
OK so it says 4 is greater than x, so
x is going to be 4,
OK so if we just jot that down, x is 4, yeah? Then input another value of n, so lets suppose we
put in 6, OK? What will happen? It will loop around, and say n is not equal to -99, so we'll do
it again,
Is it just going to print out 4?
We haven't got there yet. If n is greater than x, so 6 is greater than x, yes it is, x becomes 6.
And we input another value. Now suppose we input 2, this time.
Still going to, x is going to be 2, its bigger than zero,
OK but x now is 6


Pour conclure l'auteur de l'article conclut que le pattern est toujours le même :
  • L'étudiant lit le code avec précaution sans parvenir à le comprendre
  • Etudie quelques traces de l'algorithme
  • Parvient à comprendre ce qui se passe

La conclusion finale de l'auteur est qu'il vaut mieux expliquer une boucle en montrant une trace d'exécution, expliquer comment la "comprimer", puis présenter la boucle en elle même.

Gotos Considered Harmful and Other Programmers' Taboos Recense les tabous qui ont cours chez les programmeurs, comme le goto, l'assembleur, les diagrammes... Assez marrant à lire ;-)

An Experiment on the Effects of Program Code Highlighting on Visual Search for Local Patterns étudie l'impact de différents types de coloration syntaxique. Très utile pour clouer le bec à un troll...

Evaluating a new programming language propose une méthode pour évaluer un nouveau langage de programmation, ici C# (ça vient de Microsoft Research)

Citons Users' participation to the design process in a Free Open Source Software online community qui vous intéressera surement...

Citons aussi Programming without Code: A Work in-Progress Paper qui s'approche pas mal de ce que je veux faire. Ouf je suis pas le seul :-)


Bonnes lectures !
  • # philosphie unix

    Posté par . Évalué à 4.

    Y aurait t-il des études sur la programmation basé sur la philosophie unix ?

    tels que l'avait écrit le bouquin " Linux and the Unix Philosophy " de Mike Gancarz

    http://www.amazon.com/Linux-Unix-Philosophy-Mike-Gancarz/dp/(...)

    Pour moi c'est le livre le plus aboutie sur le sujet , en tant que perception des postulats épistémologique de la construction d'un type de systeme et ses effets dans le réel .

    (comparaison avec d'autre système au postulats différents )
  • # Programming without Code

    Posté par (page perso) . Évalué à 2.

    > Citons aussi Programming without Code: A Work in-Progress Paper qui s'approche pas mal de ce que je veux faire. Ouf je suis pas le seul :-)

    Est-ce que tu as regardé du côté de Scratch [ http://scratch.mit.edu/ ] ? Je ne l'ai jamais utilisé mais j'avais trouvé ce papier [ http://web.media.mit.edu/~mres/scratch/scratch-cacm.pdf ] mentionné sur LTU [ http://lambda-the-ultimate.org/node/3686 ] intéressant.

    Ça ressemble aussi un peu à un logiciel que j'utilisais quand j'avais 10 ans : Klik&Play !!! [ http://wikiclick.margasoft.fr/index.php?title=Klik%26Play ]
    • [^] # Re: Programming without Code

      Posté par (page perso) . Évalué à 4.

      J'ai joué avec Scratch il y a quelques années, et j'avoue que c'est un des outils les plus avancés et originaux que j'ai pu utiliser.

      Scratch permet de modéliser des agent dans un contexte, avec des costumes, des réactions au évènements, etc...

      On y trouve cette notion d'agent avec une contextualisation très intéressante. Mais ça reste de la programmation pour enfant orienté petit jeu vidéo. Mon but est de faire un langage qui permette de faire de l'info de "gestion" (des sites web, des applis tels, etc..). Scratch a été une très bonne influence.

      Je m'oriente plus vers un langage intégralement agent (dans lequel tu auras vraisemblablement de l'objet à proto), rédigé en langage naturel (sous ensemble grammatical strict de l'anglais, la transformation de l'anglais de base en expression logique est assez bien maîtrisé dans la recherche en IA depuis une trentaine d'années, voir http://www.linuxfr.org/~Montaigne/29873.html ).

      Quand j'aurai formalisé le tout et écrit un proof of concept dans lequel je pourrai au moins écrire le langage en logique (je suis parti pour écrire l'interpréteur en prolog), les moules de ce site seront les premières informées. Je pense que j'aurai alors besoin d'aide, mes compétences techniques et théorique ayant des limites..

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Programming without Code

        Posté par . Évalué à 5.

        Quand j'aurai formalisé le tout et écrit un proof of concept

        ... n'oublie pas de déposer pleins de brevets et de monter une startup !
        • [^] # Re: Programming without Code

          Posté par . Évalué à 3.

          Les brevets seront probablement déjà déposé à ce moment là. Ils ont pas de proof of concept à faire, eux.
        • [^] # Re: Programming without Code

          Posté par (page perso) . Évalué à 3.

          Ouais, justement j'y pensais : je vais déposer le code en GPLv3 pour protéger les utilisateurs de mes brevets, et ma boite me fera procès à moi même pur utilisation de brevet !

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # tout le monde peut il coder ?

    Posté par . Évalué à 3.

    moi qui ait des gros soucis pour programmer, j'ai été "rassuré" en lisant ça :

    http://www.codinghorror.com/blog/2006/07/separating-programm(...)
  • # Programmation impérative...

    Posté par (page perso) . Évalué à 3.

    x := 0
    input n
    while n is not equal to -99 {
       if n > x then x := n
       input n
    }
    output x
    
    C'est sûr que présenter un langage très peu déclaratif avec en plus 2 façons d'assigner des valeurs (x := 0 et input n), ça peut ne pas être forcément évident pour les débutants. Il faudrait comparer avec d'autres paradigmes. Par exemple en fonctionnel :
    loop x = do
       n <- input
       test n x
       where
          test (-99) x = return x
          test n x = loop (max n x)
    
    main = do
      a <- loop 0 
      output a
    
    Pour quelqu'un qui n'a jamais programmé mais qui a quelques notions de math (variables non ré-assignables, fonctions pures), ça peut être plus compréhensible. Pour ceux que ça intéresse, il faut ajouter ce qui suit en haut du fichier pour le compiler avec ghc :
    module Main (main) where
    import Monad
    input = (liftM read) getLine :: IO Int
    output = putStrLn . show
    
    • [^] # Re: Programmation impérative...

      Posté par . Évalué à 10.

      Bon, alors je ne suis pas un programmeur en tant que tel, mais j'ai des notions des deux aspects (fonctionnel et impératif, me suis tapé des tutoriels sur C++, python, ruby... et ocaml!).

      J'ai aussi suivi un cycle prépa avant école d'ingenieur, donc je pense que j'ai un minimum de bagage en mathématiques.

      Je peux t'assurer que le programme que tu proposes, il est peut-être plus simple à comprendre pour toi, mais pour les gens qui n'ont jamais vu la prog fonctionnelle, c'est complètement imbitable!

      Moi si je débute, je vois loop x = do, et ça risque de pas aller beaucoup plus loin!
      -Combien vaut x?
      -Il vaut do?

      La logique qui est derrière la prog fonctionnelle est plus évidente pour un matheux, mais la syntaxe, c'est tout autre chose!
      • [^] # Re: Programmation impérative...

        Posté par (page perso) . Évalué à 5.

        Ok je suis d'accord. Avec une autre syntaxe, ça passe effectivement mieux. Le même exemple en Scala :
        def loop(x: Int): Int = {
           val n = input
           if (n == -99) x else loop(max(x,n))
        }
        
        output(loop(0))
        
        Avec, toujours pour ceux que ça intéresse, le code à ajouter au début pour que ça compile (version script) :
        #!env scala 
        !#
        import scala.math.max
        def input = readLine toInt
        def output(x:Int) = println(x)
        
        Enfin tout ça pour dire que le paradigme impératif est un des moins déclaratif (voir http://www.info.ucl.ac.be/people/PVR/paradigmsDIAGRAMeng108.(...) ) donc ce n'est pas étonnant qu'il soit plus difficile à appréhender/analyser.
        • [^] # Re: Programmation impérative...

          Posté par (page perso) . Évalué à 5.

          Tes exemples utilisent une fonction récursive, ce qui n'est pas le cas de l'algorithme de base.

          En plus, la pile d'appel des fonctions peut poser problème (espace mémoire), et est inutile.

          Envoyé depuis mon lapin.

          • [^] # Re: Programmation impérative...

            Posté par (page perso) . Évalué à 5.

            Euh.. le but était d'exprimer la même chose dans un autre paradigme donc c'est normal que ce soit différent. Dans les codes que j'ai proposés, je n'utilise pas de "mutable cells" (de variables qui varient) ce qui simplifie beaucoup (normalement) la compréhension du code : dans un contexte donné, une variable a toujours la même valeur.

            Ensuite ma fonction est récursive terminale (tu peux t'en assurer en ajoutant l'annotation @tailrec, qui se trouve dans le package scala.annotation, au dessus de la définition) donc n'importe quel compilateur digne de ce nom va transformer l'appel récursif en boucle/goto/etc. Donc aucun problème avec la pile d'appel.
            • [^] # Re: Programmation impérative...

              Posté par . Évalué à 5.

              Je pense qu'on peut faire mieux cela dit...

              main = interact (show . maximum . takeWhile (/= -99) . inputs)
              On remarque qu'il n'y a plus de variable et plus de récursion. Je suis un peu habitué à ce style déclaratif, mais je pense ne pas m'avancer trop si je dis que ça se lit presque naturellement :
              Il s'agit d'un programme interactif qui affiche la valeur maximale parmi une série (terminée par la valeur spéciale -99) qui a été entrée par l'utilisateur.

              Maintenant, je ne pense pas pour autant que ce code soit facile à comprendre / implémenter pour un débutant (je ne pense pas que Haskell soit très adapté comme premier langage), mais on remarque quand même qu'on y gagne à utiliser des fonctions sémantiques (comme "max") vis à vis de l'exemple initial.

              Accessoirement, en tant qu'étudiant, je trouve ça totalement idiot de faire comprendre des programmes dont l'explication est aussi tortueuse. On devrait pouvoir trouver des exemples qui parlent plus à l'instinct, pour familiariser avec les concepts (quelque chose où le résultat semble plus utile pour un nouveau, qu'il puisse se rattacher à sa compréhension naturelle pour intégrer ce qui se passe vraiment.)

              (header nécessaire au bon fonctionnement du code précédent :)

              module Simple where
              import Data.List
              import Data.Maybe

              inputs :: String -> [Int]
              inputs = unfoldr (listToMaybe . reads)
    • [^] # Re: Programmation impérative...

      Posté par (page perso) . Évalué à 4.

      C'est plus rapide et plus propre de le faire en python…

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # drôle de conclusion

    Posté par . Évalué à -1.

    Dans le document Gotos Considered Harmful and Other Programmers' , après la lecture, somme toute intéressante, je trouve qu'il s'est légèrement vautré dans l'intro de sa conclusion

    Looking at the various taboos described above, there are two patterns that emerge. The first is clearly
    a social one – programmers pass their prejudices to other programmers, particularly teachers to
    students. This probably explains the demise of flowcharts, the blessing of open source and the
    ubiquitous hatred of Microsoft. Fashion certainly has something to do with it – the only trouble with
    fashion in programming is that you can end up with the equivalent of patching those old, flared,
    brushed denim loons for the next ten years, long after everyone else has stopped wearing them.


    C'est peut-être une boutade, mais dire que l'open-source est une mode dont la motivation principale est d'haïr Crosoft, ça fait un peu fausse note.
    Et qu'il sous-entend que l'engouement ou qualité de l'opensource irait en déclinant, renforce la bavure.

    À part ça, le document est sympa et j'avoue avoir été victime du taboo "prog bas-niveau" il y a 7ans, je finissais mon cursus sans finalement maîtriser la chose,
    Cela dit, entre temps, je n'ai pas vraiment eu le besoin d'aller si bas.

    Si on veut continuer dans le troll, on pourraît se dire que c'est la multiplicité des langages haut-niveaux à tendance OO qui ont favorisé le dédain pour ce "compliquer" la vie avec le couple C/ASM.
    • [^] # Re: drôle de conclusion

      Posté par . Évalué à 6.

      Ce n'est pas ce que je comprend. Il cite juste trois exemples de 'taboo social' dans le codage. Il ne dit dit pas qu'il y a un rapport entre eux.
      • [^] # Re: drôle de conclusion

        Posté par . Évalué à -1.

        Je parlais de l'intro de sa conclusion. Il fait volontairement un glissement, maintenant, je ne suis pas sûr de la pertinence.
    • [^] # Re: drôle de conclusion

      Posté par (page perso) . Évalué à 10.

      >> C'est peut-être une boutade, mais dire que l'open-source est une mode dont la motivation principale est d'haïr Crosoft, ça fait un peu fausse note.

      En plus, MS fait de l'Open Source, et y'a des endroits où l'Open Source est plus important que le libre (comme au Japon), et aucunement opposé à MS.

      En revanche, suffit de lire DLFP pour voir que l'anti-MS primaire est quand même bien ancré. Le « MS fait ceci, donc lol c'est des connards » est toujours très présent. Et si jamais GNU/Linux le fait aussi, on s'en fout, car de toute façon, GNU/Linux, c'est libre, c'est mieux (sauf fedora et ubuntu). Et si Google le fait, c'est mal, mais comme on utilise gmail, alors on pardonne quand même parce que gmail, c'est bien.
      • [^] # Re: drôle de conclusion

        Posté par . Évalué à 10.

        En revanche, suffit de lire DLFP pour voir que l'anti-MS primaire est quand même bien ancré.
        C'est vrai, mais c'est la faute à microsoft.
      • [^] # Re: drôle de conclusion

        Posté par . Évalué à 2.

        Mmh, toi tu présentes des symptomes du syndrome de Stockholm... :)

        MS sont effectivement des connards, non pas parce qu'ils font du proprio - libre(!sic) à eux :) - mais parce qu'ils sabotent l'interopérabilité et fausses les cartes!
        • [^] # Re: drôle de conclusion

          Posté par (page perso) . Évalué à 2.

          >> Mmh, toi tu présentes des symptomes du syndrome de Stockholm... :)

          Non, car je connais l'existence du syndrome depuis fort longtemps…
          • [^] # Re: drôle de conclusion

            Posté par (page perso) . Évalué à 2.

            Je ne vois pas en quoi ça t'empêche d'avoir des symptômes.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: drôle de conclusion

              Posté par (page perso) . Évalué à 4.

              Pas n'importe lesquels. Ceux du syndrome de Stockholm.
              Comme je connais ce syndrome, je ne peux pas l'avoir.
              Comme je le connais, je suis aussi capable de repérer ses symptômes (comportementaux). Comme je les reconnais, je suis capable volontairement de modifier mon comportement pour ne plus les avoir.

              De plus, je ne crois pas avoir dit que je considérais MS comme un ennemi initialement. Si c'est une compagnie que j'aimais depuis le début, alors ce ne sont clairement pas les symptômes du syndrome de Stockholm !
              • [^] # Re: drôle de conclusion

                Posté par (page perso) . Évalué à 4.

                Comme je le connais, je suis aussi capable de repérer ses symptômes (comportementaux). Comme je les reconnais, je suis capable volontairement de modifier mon comportement pour ne plus les avoir.

                Il faut que tu aies la volonté de ne pas les avoir et que tu te rendes compte que tu les présentes, le simple fait de les connaître ne t'en préserve pas. Je suis sûr qu'on peut trouver beaucoup de victimes du syndrome qui le connaissait.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: drôle de conclusion

                  Posté par (page perso) . Évalué à 2.

                  >> Je suis sûr qu'on peut trouver beaucoup de victimes du syndrome qui le connaissait.

                  Je suis sûr que non.

                  Il me semble bien que le syndrome de Stockholm ne peut concerner que des gens qui ne le connaissaient pas.
                  Et dans le cas extrême où il pourrait se développer toutefois, le fait que je sois en permanence entrain de peser le pour et le contre de chaque argumentaire à l'encontre du libre ou de MS (la volonté) me met dans une situation où je suis obligé de prendre en compte les réactions des autres et de les anticiper (se rendre compte).
                  • [^] # Re: drôle de conclusion

                    Posté par (page perso) . Évalué à 1.

                    En tout cas, sur http://fr.wikipedia.org/wiki/Syndrome_de_stockholm , il est écrit Il apparaît plus difficilement si les victimes potentielles sont préalablement informées de l'existence de ce syndrome. ce qui ne veut pas dire que ça n'arrive pas et rejoint ce que je disais.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: drôle de conclusion

                      Posté par (page perso) . Évalué à 1.

                      >> ce qui ne veut pas dire que ça n'arrive pas et rejoint ce que je disais.

                      Tant que tu ne m'en trouveras pas « beaucoup, » je ne te croirai pas.
                      • [^] # Re: drôle de conclusion

                        Posté par (page perso) . Évalué à 1.

                        Je n'ai pas dit qu'il y en avait beaucoup, mais que ça arrivait et que le fait que tu dises que tu connais le syndrome de Stockholm ne suffit pas à prouver que tu n'en sois pas atteint.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: drôle de conclusion

                          Posté par (page perso) . Évalué à 2.

                          > Je n'ai pas dit qu'il y en avait beaucoup

                          Tu as dit qu'on pouvait en trouver beaucoup.

                          >> Je suis sûr qu'on peut trouver beaucoup de victimes du syndrome qui le connaissait.

                          Je te demande de les trouver.

                          > et que le fait que tu dises que tu connais le syndrome de Stockholm ne suffit pas à prouver que tu n'en sois pas atteint.

                          Si Wikipedia a raison, admettons le cas général.
                          Mais dans mon cas, je dis bien plus qu'un simple « je connais, » je rajoute des hypothèses supplémentaires qui ne sont pas couvertes par l'article wikipedia.
    • [^] # Re: drôle de conclusion

      Posté par . Évalué à 1.

      Ce document date de 10 ans, les choses ont tout de même bougées depuis.
  • # et la psychologie du développeur ?

    Posté par . Évalué à 7.

    oui,
    et la psychologie du développeur ?

    - est-ce une addiction ça la programmation ?
    - pourquoi je me complais dans la réalisation de mes programmes ?
    - pourquoi.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.