Développeur : Ocsigen 1.0.0 : une nouvelle approche de la programmation Web
Posté par Vincent Balat (). Modéré le 09 avril 2008.
- la garantie que les pages générées sont en xhtml valide ;
- le typage des formulaires et des paramètres ;
- une gestion simplifiée de l'interaction Web à l'aide de concepts dédiés (continuations, etc.).
![[en]](../images/en.png)
![[fr]](../images/fr.png)
> Lire la dépêche (57 commentaires, moyenne: 2,2).
Vous avez demandé le commentaire #921261.
Run by 
Cette page a été générée par Templeet en 0.0972s (dont 0.0077 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Mouais, faudrait ptetre...
...Que les chercheurs informaticiens apprennent à faire de la psychologie cognitive.
Faudrait peut être qu'ils comprennent qu'un outil de développement ne nécessite pas avant tout d'être mathématiquement beau (même si je comprend tout à fait l'importance de ce point auquel je suis assez sensible), mais d'être accessible pour le développeur moyen qui sort d'un bac+2 et qui, (souvent)par conséquent, ne comprend rien à un langage comme caml (j'étais perçu comme un extraterrestre en BTS de parler d'un tel langage).
Je vois tout à fait l'intérêt de ce genre d'approche : une fois que le compilateur a validé le code, on peut être sûr qu'on aura pas trop de surprise, contraîrement à PHP qui est un des pire langage existant à l'heure actuelle, sur cet aspect dumoins.
Mais non seulement ça perçera jamais car personne en entreprise, à part peut être quelques cas particuliers, n'utilisera ce truc, tout simplement parce qu'Ocaml est imbitable pour la plupart des développeurs. Je dis ça, j'aime Ocaml, le typage somme, c'est tout de même pied absolu, et j'en passe...
On pourra évoquer l'éducation, la fénéantise, etc... ce qu'on veut, mais c'est comme ça.
Un bon framework de dev, ne doit pas se baser son concept sur la seule puissance d'un langage, mais savoir comment l'utiliser pour s'adapter au cerveau du programmeur.
Un humain n'a par défaut pas du tout la même façon de penser qu'un ordinateur, qui reste une grosse machine à calculer. Tout le monde a surement perdu des heures à coder des concepts simple à cause de détails à la c** qui posent problème.
La question est donc, pour un logiciel, de savoir comment un humain conçoit, en son for intérieur, son logiciel. Comment le type qui spécifie, non informaticien mais orienté métier, serait amener à décrire rigoureusement son logiciel ?
Je donne un exemple : on a inventé des systèmes divers et variés, plus ou moins heureux, pour gérer les interfaces utilisateurs. On a les callback, l'évènementiel, les signaux/slots à la QT.
Le dernier est un des moins mauvais si je puis me permettre de dire.
Mais on s'est demandé ce qu'est une interface utilisateur pour un être humain ?
Eh bien c'est une machine à état.
Elle a des états, des équations d'états. Des évènements liés à l'activation d'état, à la vérification d'équation d'état, etc...
Les données, si l'on se trouve dans un modèle MVC, sont une représentation des données qui lui sont "envoyées", un filtrage sur celle-ci.
Bref, ce qu'il faudrait, je pense, cibler, est plus une approche cognitive, un peu comme le propose Scratch ou croquet ( http://www.opencroquet.org/index.php/Main_Page ) pour les enfants.
La suite de tout cela ? Les langages de programmation sémantiques à ontologie. Pour quoi faire ? Gérer l'implicite.
[^]Re: Mouais, faudrait ptetre...
Et tu aurais des liens à nous proposer à propos des "langages de programmation sémantiques à ontologie" ?
[^]Re: Mouais, faudrait ptetre...
Essayer de nous vendre Lisaac à la place de OCaml avec comme argument que personne ne comprend rien à OCaml, je dois dire que j'aurais jamais cru que tu oserais...
Les gens qui programment, ils veulent un truc qui ressemble à du C (donc C, C++, Java, PHP, C#, etc...) parce qu'ils ont appris a réfléchir avec ça et qu'ils savent résoudre 99,99% des problèmes avec ce genre de langage. C'est tout.
[^]Re: Mouais, faudrait ptetre...
Tout à fais d'accord ;-) D'ailleurs pour quelqu'un de bonne volonté le langage ocaml est bien plus facile/rapide à apprendre que le C (et ce sans avoir fait des études d'info).
Par contre, l'effet pervers de cela (si on peut dire !) c'est qu'il devient plus facile d'implémenter des choses complexes (style un compilateur ou un algorythme savant) et donc, on a plus de chances de tomber sur un code incompréhensible pour quelqu'un qui n'a pas fait de licence en math/info (mais quand même pas aussi incompréhensible que la même chose, par ex. codée en perl...).
[^]Re: Mouais, faudrait ptetre...
Essayer de nous vendre Lisaac à la place de OCaml avec comme argument que personne ne comprend rien à OCaml, je dois dire que j'aurais jamais cru que tu oserais...
J'ai parlé de Lisaac ici ?
Non.
[^]Re: Mouais, faudrait ptetre...
Et je vais en rajouter une couche :
Ocsigen aurait été fait en Lisaac, avec le même principe, j'aurai écrit la même chose, à la différence qu'avec java, les gens sont un peu plus habitués au paradigme objet, dont est Lisaac.
[^]Re: Mouais, faudrait ptetre...
Non, c'est pas tout : quand tu as l'habitude, tu cherches pas à faire autrement (oui, j'enfonce des portes ouvertes).
Par exemple, quand tu veux appliquer une fonction à tous les éléments d'un tableau, bah tu nettoies ton int i; et tu te lances... alors qu'il suffit d'appliquer la fonction map() au tableau.
Pareil quand tu veux faire un agrégat (une somme des éléments d'un tableau, par exemple), tu déclares tes variables, et tu sommes... alors qu'il suffit de faire un inject().
La façon impérative de voir les choses n'est clairement pas la plus naturelle, ni la plus lisible. Mais on a appris comme ça, pourquoi changer ?
[^]Re: Mouais, faudrait ptetre...
C'est marrant, je verrais bien l'analogie Linux/Windows.
Oui, 95% des gens sont habitués à Windows, et ne veulent pas apprendre de nouvelles manières de faire parce que leur système, même s'il n'est pas parfait, leur "convient". Mais je dirais qu'il ne se rendent pas compte de ce qu'ils loupent. Surtout si on fait la comparaison OSX/Windows.
Et bien c'est pareil en programmation. 95% des devs font du procédural/objet, et ne veulent pas faire l'effort de changer leurs habitudes. Pourtant, beaucoup des problèmes que je vois résolus chaque jour dans tout un tas de langages auraient déjà disparus depuis longtemps si un peu plus de gens s'étaient intéressé à la prog fonctionnelle. C'est dommage, car quand je montre certaines possibilités "fonctionnelles" en python (pour ne pas faire trop peur avec un vrai langage fonctionnel), pas mal de programmeurs me disent "houa, c'est génial".
Bref, ceci n'est pas un jugement mais une sorte de mise en perspective d'un problème qu'on retrouve assez souvent. Doit-on tout uniformiser et utiliser le plus petit dénominateur commun afin de satisfaire tout le monde ? Est-ce que changer d'habitudes est trop dur pour 95% des gens ? Je ne sais pas. Mais je trouve dommage cette uniformité.
Moi, j'en suis quand même à hésiter à utiliser des closures en Javascript, alors que le langage s'y prête très bien et que ça "simplifie" énormément le code et la "manière" (je trouve ça plus naturel) de coder. Bon, ça doit être sur ce point que je fais une erreur, puisque ça n'a pas l'air si naturel que ça pour pas mal d'autre gens.
[^]Re: Mouais, faudrait ptetre...
Tout à fait d'accord. Je pense que si on enseignait un langage fonctionnel en début de cursus (j'ai appris caml en deug 1, et ça n'a pas été plus difficile pour néophytes en informatique que pascal trois mois plus tôt), de manière solide, beaucoup de gens s'y mettrait et trouverait ça naturel.
J'ai moi même commencé par l'impératif (basic), mais je suis pas sûr que ce soit plus "naturel" que le paradigme fonctionnel.
[^]Re: Mouais, faudrait ptetre...
Je pense que tu as raison pour l'enseignement en début de cursus, car j'ai eu des cours de CamL en master 1, et après 3 ans de "déformation" procédurale/objet, quasiment tous mes camarades ont vomis dessus tellement ils trouvaient ça compliqué, inutile et "pour chercheurs"..
[^]Re: Mouais, faudrait ptetre...
Je pense qu'il faut faire faire du Coq aux premières années de fac (désormais Licence 1) comme ça quand on les met à OCaml après il trouveront ça super simple ;).
[^]Re: Mouais, faudrait ptetre...
Pour avoir subit un cursus "impératif" et rejoint une filière de matheux qui avait commencé par du scheme, je peux t'assurer que la galère avec OCaml était identique. A la différence que je me balaidait sur le reste (C/Java/ASM &co).
Le problème du fonctionnel c'est que ca t'oblige à être synthétique là où l'impératif te permet d'avancer pas-à-pas vers une solution même si c'est pas clair dans ta tête. Bref c'est moins "prise de tête" même si le code produit n'est pas aussi joli et pertinent.
De plus, les ordinateurs fonctionne de manière impérative : il est donc plus facile de s'imaginer le déroulement du code que t'es en train d'écrire.
MonoFrance
[^]Re: Mouais, faudrait ptetre...
Non, c'est pas parce que les ordinateurs fonctionnent de manière impérative que c'est plus facile de s'imaginer le déroulement du code que t'es en train d'écrire. C'est parce que tu es habitué à l'impératif que tu t'imagines plus facilement le déroulement du code impératif que tu es en train d'écrire.
Comprendre qu'il n'y a aucun lien entre le fait que les ordinnateurs fonctionnent de façon impérative et le fait que tu comprènes plus facilement le code impératif.
[^]Re: Mouais, faudrait ptetre...
Belle démonstration. "ce que tu dis est faux car il faut bien comprendre que ce que tu dis n'est pas exact."
Désolé mais moi quand je code en C je m'imagine très bien le déroulement du code tel qu'il est exécuté par le processeur. C'est d'ailleur très bien représenté intuitivement par les débuggueurs.
Tu peux comprendre que certains codent en pensant à la façon dont le code sera exécuté ? Je reste persuadé que c'est le cas de beaucoup de monde. Et c'est une grosse différence avec le fonctionnel où tu cherches plutôt à exprimer le résultat que tu veux obtenir. Et ca c'est beaucoup plus de réflexion de l'exprimer.
MonoFrance
[^]Re: Mouais, faudrait ptetre...
Tu penses aux transistors dans le cpu ? tu penses à la gestion des registres du processeur pour gérer ton code ? Non, je ne pense pas.
Que tu penses en impératif parce que tu y es habitué, je veux bien, mais dire que tu pense en impératif parce que ton cpu fonctionne comme ca me parrait fallacieux.
Mon avis, qui me semble plus crédible que ton avis (qui est que tu penses en impératif parce que ton ordinateur pense en impératif) est que l'on pense comme on est habitué à penser (je dirais même que l'on pense avec la langue que l'on connait, ce qui est la thèse de certains linguistes).
Perso, après avoir fait beaucoup de C, je me suis mis à OCaml. Après quelques temps à avoir du mal avec le langague, je me suis mis à penser en fonctionnel, et OCaml est devenu beaucou plus simple à utiliser. Maintenant, quand je code en C, j'ai même tendance à penser fonctionnel (sauf qu'en pratique, ca marche pas bien, et qu'on se remet à penser en impératif pour réussir à programmer ce qu'on veux).
[^]Re: Mouais, faudrait ptetre...
Tu penses aux transistors dans le cpu ? tu penses à la gestion des registres du processeur pour gérer ton code ? Non, je ne pense pas.Non je penses plutôt à sa façon d'exécution les instructions du logiciel, ce qui est encore ce que produit le développeur quoi.
je dirais même que l'on pense avec la langue que l'on connait, ce qui est la thèse de certains linguistes
Ben justement on connaît le fonctionnement de l'ordinateur pour exécuter un logiciel, et c'est cette proximité avec la représentation d'un code procédural qui fait que ce dernier est plus facile à apréhender.
Après quelques temps à avoir du mal avec le langague, je me suis mis à penser en fonctionnel, et OCaml est devenu beaucoup plus simple à utiliser. Maintenant, quand je code en C, j'ai même tendance à penser fonctionnel
Mais moi aussi je penses de plus en plus fonctionnel, ca n'empêche que je trouve que le travail intellectuel qu'il nécessite (à savoir un gros travail de synthèse et un haut niveau d'abstraction) est beaucoup plus contraignant qu'un "simple" code procédural.
qui est que tu penses en impératif parce que ton ordinateur pense en impératif
J'ai pas dit ca. J'ai dit que c'était plus intuitif de comprendre ce que fais un code impératif car sa lecture suit le déroulement de son exécution par la machine. Bref on "pense" mieux le comportement du soft.
Globalement l'argument généralement utilisé qui consiste à dire que si l'impératif est généralement considéré comme plus facile c'est parcqu'on commence par ça me paraît fallacieux (c'est moche c'est mot c'est hallucinant) : mon expérience montre qu'en commencant par le le fonctionnel, c'est pas mieux.
Il y aura toujours une difficulté à passer d'un mode à l'autre pour un débutant qui a appris d'une certaine manière, mais c'es pas pour autant que les 2 sont aussi "simples" : pour moi le mode impératif est beaucoup plus "facile" à comprendre.
Pour rigoler tiens faudrait que les notices de montages de meuble soit en fonctionnel et non en procédural et comparer après la progression des ventes chez Ikea ;)
MonoFrance
[^]Re: Mouais, faudrait ptetre...
Quand tu dis que l'impératif représente mieux ta manière de penser, je pense que c'est parce que tu connais ce qui se passe au bas niveau (tu parlais d'asm dans un de tes commentaires). Mais je ne suis pas sur que ce soit le cas de la majorité des programmeurs "impératifs". A ce moment-là, je ne vois pas en quoi ce serait plus "facile" de commencer par l'impératif.
Ha, juste une précision :
Globalement l'argument généralement utilisé qui consiste à dire que si l'impératif est généralement considéré comme plus facile c'est parcqu'on commence par ça me paraît fallacieux (c'est moche c'est mot c'est hallucinant) : mon expérience montre qu'en commencant par le le fonctionnel, c'est pas mieux.
Toi qui parlais plus haut des tournures de phrases tarabiscotées, celle-ci ne veut rien dire : pas mieux que quoi ?
[^]Re: Mouais, faudrait ptetre...
Mais je ne suis pas sur que ce soit le cas de la majorité des programmeurs "impératifs".
Ils ont tous plus ou moins cette même perception, que ce soit à travers un débuggueur ou tout simplement en constatant la façon dont le code est exécuté.
Toi qui parlais plus haut des tournures de phrases tarabiscotées, celle-ci ne veut rien dire : pas mieux que quoi ?
Ben en gros ceux qui ont commencé par le fonctionnel trouvent pas ca plus facile après avoir appris l'impératif. Qu'on ai commencé par Scheme ou Pascal, on avait les mêmes difficultés en OCaml et la même facilité en Java.
MonoFrance
[^]Re: Mouais, faudrait ptetre...
Mais je ne suis pas sur que ce soit le cas de la majorité des programmeurs "impératifs".
Ils ont tous plus ou moins cette même perception, que ce soit à travers un débuggueur ou tout simplement en constatant la façon dont le code est exécuté.
héhé... en utilisant un débuggueur d'un langague impératif, on comprend mieux comment marche notre programme impératif ? On comprend mieux comment s'exécute un programme impératif en pensant en impératif ? C'est un peu totologique, non?
[^]Re: Mouais, faudrait ptetre...
héhé... en utilisant un débuggueur d'un langague impératif, on comprend mieux comment marche notre programme impératif ?
C'est surtout que le débuggueur montre le fonctionnement et le comportement de la machine en proposant une vue des registres, des instructions machines, etc.
Bref c'est plus facile d'écrire le logiciel dans le même "mode" que celui qui l'exécute.
MonoFrance
[^]Re: Mouais, faudrait ptetre...
Quand tu mets dans un debugger un programme sans symbole, oui (et l'utilité est fortement limitée). Quand tu débuggues un programme impératif, tu es dans un contexte impératif. Quand tu débuggues un programme fonctionnel, tu te trouves dans un contexte fonctionnel. Voir http://caml.inria.fr/pub/docs/manual-ocaml/manual030.html (et encore, c'est trompeur vu que tu peux faire de l'itératif en OCaml).
[^]Re: Mouais, faudrait ptetre...
Non je penses plutôt à sa façon d'exécution les instructions du logiciel, ce qui est encore ce que produit le développeur quoi.
J'ai pas compris cette phrase, ou alors je vois pas en quoi elle contredit ce que je dis. Je crois que tu sous-entends qu'un logiciel ne se comprend qu'en impératif, ce qui n'est pas le cas.
Ben justement on connaît le fonctionnement de l'ordinateur pour exécuter un logiciel, et c'est cette proximité avec la représentation d'un code procédural qui fait que ce dernier est plus facile à apréhender.
Ma thèse, c'est le contraire : Le code procédurale est ce qui est le plus utilisé, ce qui fait que les gens pensent plus facilement en impératif (finalement, c'est pas vraiment ca ma thèse, mais l'idée est là). D'autre part, le code impératif est plus proche de la machine. Il n'y a pas de lien entre le fait qu'une machine fonctionne en impératif et le fait que les gens semblent appréhender plus facilement l'impératif. Au passage, le procédural, c'est pas vraiment proche de comment marche la machine, la machine n'a pas de procédure, juste des "goto".
J'ai dit que c'était plus intuitif de comprendre ce que fais un code impératif car sa lecture suit le déroulement de son exécution par la machine. Bref on "pense" mieux le comportement du soft.
Je ne vois pas en quoi [la] lecture [de code impérative] suit le déroulement de son exécution par la machine plus que la lecture de code fonctionnel. Et je comprends pas pourquoi tu parles de la machine ici.
pour moi le mode impératif est beaucoup plus "facile" à comprendre
Ca, je suis d'accord : tu peux trouver l'impératif plus facile à comprendre. Je suis pas d'accord avec ta justification comme quoi c'est parce que c'est proche de la machine (ou la notion que j'ai pas compris).
Par contre, à mon avis, un code impératif est plus difficile à comprendre qu'un code fonctionnel. Par contre, il est plus difficile (et donc plus long) d'apprendre et de maitriser le paradigme fonctionnel que le paradigme impératif. On en conclu donc que les gens qui ne veulent pas entendre parler du fonctionnel sont des gens pas assez fainéant : l'investissement de l'apprentissage du fonctionnel sera rapidement rentabilisé par la rapidité de lecture et d'écriture de code par la suite.
[^]Re: Mouais, faudrait ptetre...
. Je crois que tu sous-entends qu'un logiciel ne se comprend qu'en impératif, ce qui n'est pas le cas.
Je dis juste qu'une machine exécute un ensemble d'instruction de manière séquentielle. L'impératif n'est qu'une "surcouche" d'abstraction, mais le principe d'exécution est identique.
Il n'y a pas de lien entre le fait qu'une machine fonctionne en impératif et le fait que les gens semblent appréhender plus facilement l'impératif.
Ben moi je dis que y'a un lien. A plus forte raison avec les langages bas niveau comme Asm ou C.
Au passage, le procédural, c'est pas vraiment proche de comment marche la machine, la machine n'a pas de procédure, juste des "goto".
Et bien voilà on y est : même le procédural devient "compliqué" pour un développeur : combien on commencé par utiliser les goto dans tous les sens ?
Et je comprends pas pourquoi tu parles de la machine ici.
Quand je lis un algorithme écrit de manière impérative, je comprends l'état de la machine instruction après instruction, ce que contient chaque variable, etc. En procédural, il faut que j'interprête et comprenne ce qu'à exprimé le développeur. Et c'est pas aussi simple. Encore plus à pondre.
Je suis pas d'accord avec ta justification comme quoi c'est parce que c'est proche de la machine
Je dis juste que le fonctionnement de la machine est un "plus", je dis pas que c'est la raison première. D'ailleur c'est sans doute pour la même raison que les machine marche de manière impérative, c'est pour la simplicité ;)
l'investissement de l'apprentissage du fonctionnel sera rapidement rentabilisé par la rapidité de lecture et d'écriture de code par la suite.
Ca reste à prouver. La difficulté du métier n'est pas tant dans le langage mais dans la multiplicité des outils, bibliothèques, technologies, dans l'accumulation des bonnes pratiques, la mise en place de méthodes de travail, etc. Franchement le l'investissement dans un un type de langage "plus puissant" si celui-ci met la barrière plus haut pour son apprentissage et donc limite le nombre de développeurs compétents me paraît pas être un investissement "rentable".
MonoFrance
[^]Re: Mouais, faudrait ptetre...
Mais moi aussi je penses de plus en plus fonctionnel, ca n'empêche que je trouve que le travail intellectuel qu'il nécessite (à savoir un gros travail de synthèse et un haut niveau d'abstraction) est beaucoup plus contraignant qu'un "simple" code procédural.
x = f(a1 ... an);
y = g(x,b1 ..... bm);
return h(x,y,c1 ... cp);
let x = f a1 ... an in
let y = g x b1 ..... bm in
h x y c1 ... cp
[^]Re: Mouais, faudrait ptetre...
Si tu m'avais sorti un truc à coup de fold, map et autres
itérateurs, j'aurais pu comprendre mais là, c'est
franchement que de la syntaxe. Je ne nie pas que la
syntaxe, c'est important mais ce n'est plus du champ
fonctionnel/impératif.
[^]Re: Mouais, faudrait ptetre...
Pardon, je me suis mal fait comprendre. Je citais une phrase plus haut et je montrais que c'était pas très convaincant.
[^]Re: Mouais, faudrait ptetre...
>La suite de tout cela ? Les langages de programmation sémantiques à ontologie. Pour quoi faire ? Gérer l'implicite.
Tu pourrais me parler hébreux que ça serait pareil..
Ceci dit pour les langages non-universitaires, Python est un langage qui a été développé en faisant très attention aux débutants.
D'ailleurs j'ai vu sur Internet un prof qui enseigne un langage de son cru a des débutants et il a essayé deux variantes dans deux sessions différentes: l'indentation non-obligatoire avec des {} 'a la C' ou une indentation significative 'a la Python': apparemment les débutants avaient beaucoup moins de mal avec la variante 'a la Python'.
J'aime bien ce genre d'experience concrete ou on change juste une variable et on regarde le résultat sur des débutants..