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 eastwind☯ . Évalué à 4.
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 )
[^] # Re: philosphie unix
Posté par Pol' uX (site web personnel) . Évalué à 6.
Adhérer à l'April, ça vous tente ?
[^] # Re: philosphie unix
Posté par eastwind☯ . Évalué à 2.
# Programming without Code
Posté par hsyl20 (site web personnel) . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 4.
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 gUI (Mastodon) . Évalué à 5.
... n'oublie pas de déposer pleins de brevets et de monter une startup !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Programming without Code
Posté par imr . Évalué à 3.
[^] # Re: Programming without Code
Posté par Ontologia (site web personnel) . Évalué à 3.
« 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 pikapika . Évalué à 3.
http://www.codinghorror.com/blog/2006/07/separating-programm(...)
# Programmation impérative...
Posté par hsyl20 (site web personnel) . Évalué à 3.
x := 0 input n while n is not equal to -99 { if n > x then x := n input n } output xC'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 aPour 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 :[^] # Re: Programmation impérative...
Posté par Maclag . Évalué à 10.
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 hsyl20 (site web personnel) . Évalué à 5.
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) : 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 yellowiscool . Évalué à 5.
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 hsyl20 (site web personnel) . Évalué à 5.
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 lasts . Évalué à 5.
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 Zarmakuizz (site web personnel) . Évalué à 4.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# drôle de conclusion
Posté par Gabin . Évalué à -1.
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 Batchyx . Évalué à 6.
[^] # Re: drôle de conclusion
Posté par Gabin . Évalué à -1.
[^] # Re: drôle de conclusion
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10.
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 imr . Évalué à 10.
C'est vrai, mais c'est la faute à microsoft.
[^] # Re: drôle de conclusion
Posté par Gabin . Évalué à 2.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Non, car je connais l'existence du syndrome depuis fort longtemps…
[^] # Re: drôle de conclusion
Posté par claudex . Évalué à 2.
« 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 Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
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 claudex . Évalué à 4.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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 claudex . Évalué à 1.
« 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 Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Tant que tu ne m'en trouveras pas « beaucoup, » je ne te croirai pas.
[^] # Re: drôle de conclusion
Posté par claudex . Évalué à 1.
« 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 Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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 suJeSelS . Évalué à 1.
# et la psychologie du développeur ?
Posté par julien . Évalué à 7.
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.
[^] # Re: et la psychologie du développeur ?
Posté par daimrod . Évalué à 10.
[^] # Re: et la psychologie du développeur ?
Posté par Sébastien B. . Évalué à 8.
[^] # Re: et la psychologie du développeur ?
Posté par morphalus . Évalué à 8.
[^] # Re: et la psychologie du développeur ?
Posté par lasher . Évalué à 4.
[^] # Re: et la psychologie du développeur ?
Posté par Sylvain Sauvage . Évalué à 6.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.