Ocsigen est un projet de recherche visant à développer de nouvelles techniques de programmation Web. Il a abouti après plus de trois ans de travail à l'implémentation d'un serveur Web complet et extensible, et d'un module pour programmer des sites dynamiques en utilisant des concepts de haut niveau. Parmi les fonctionnalités-clés, notons :
- 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.).
Ceci est rendu possible par le choix du langage
Objective Caml, pour son expressivité et son système de types. Cette version 1 clôt une première phase de développement. Le projet cherche maintenant des contributeurs et développeurs de sites.
Le serveur Web comporte notamment un module pour exécuter des
CGI, un
reverse proxy. Il supporte la compression des données, le contrôle d'accès, etc. Il est écrit de manière modulaire et extensible, ce qui rend très simple l'ajout de nouvelles fonctionnalités.
Le module de création de sites, appelé Eliom, est la partie la plus novatrice du projet. C'est une bibliothèque qui permet d'écrire des sites de grande taille de manière concise et fiable, en évitant l'effet «
usine à gaz » des traditionnels langages de scripts. En particulier :
- le typage statique permet de garantir à la compilation que les pages générées seront conformes aux recommandations du W3C,
- l'utilisation d'un concept abstrait de « service » permet d'assurer (à la compilation) l'absence de liens cassés,
- la programmation par services au lieu de la traditionnelle programmation « par page » permet d'implémenter en très peu de lignes des comportements complexes très courants sur les sites Web. Eliom utilise notamment le concept de continuation pour gérer proprement le bouton « back » des navigateurs.
Eliom n'est pas un système de gestion de contenu (
CMS), ni un outil de génération automatique de code ou un langage de templates, mais il fournit une base pour créer de tels outils. Il est déjà utilisé pour plusieurs projets (Nurpawiki, Lambdium, etc.). La version 1 n'est qu'une première étape du travail. Les prochaines versions devraient faciliter beaucoup la génération de code à exécuter sur le client. Le langage utilisé à la fois pour le développement du serveur Web et des sites avec Eliom est Objective Caml. Il a été choisi car c'est l'un des rares langages avec une expressivité suffisante et un système de types assez riche pour permettre l'implémentation de ces concepts.
Ocsigen est un projet du laboratoire PPS de l'université Paris-Diderot (Paris 7) et
CNRS. Il est organisé sous la forme d'un projet collaboratif ouvert. Toutes les idées et contributions sont les bienvenues !
Aller plus loin
# Interessant mais...
Posté par pasBill pasGates . Évalué à 6.
Le gars qui programme en PHP/ASP/JSP/... qui ne connait rien a OCaml, qui utilise Apache/IIS, qui utilise un validateur XHTML pour tester ses pages, il a quoi comme raison d'investir un temps non negligeable a changer de serveur web, apprendre un nouveau langage et potentiellement refaire son site ouaib ?
De ce que je vois(mais je peux me tromper, le dev web c'est pas mon truc, et OCaml encore moins), le truc principal qu'il gagne c'est le test de liens automatique, le reste existe deja a peu pres meme si ce n'est pas un tout unifie.
J'ai peut-etre rate un truc, mais il me semble que ca tient plus de l'exercice de style que du soft pouvant reellement changer les choses du point de vue dev. web.
[^] # Re: Interessant mais...
Posté par let antibarbie = xp <- xp - 1 . Évalué à 4.
Et aussi... enfin un bon gros projet qui met en avant la puissance d'OCAML !
C'est un peu comme de nos jours (attention je m'auto-flagelle, mais je vais dire du bien d'un produit M$) le developpement web avec C# c'est pas si mal que ça, car c'est un langage de "haut niveau" loin des atrocités d'un développement ASP. Là ils proposent de mettre la barre encore plus haut (même s'ils en sont encore loin).... Mais microsoft va-t-il sortir un jour ASP.NET for F#, pour concurrencer ocsigen ??
Je pense qu'Ocsigen mérite d'être creusé un peu plus, mais leur site web n'est pas pas assez vendeur AMHA.
signé,
Un adepte du Ocaml, qui malheureusement développe en C++/C#/Delphi et autres co..... pour être payé à la fin du mois.
[^] # Re: Interessant mais...
Posté par TImaniac (site web personnel) . Évalué à 1.
Ben c'est déjà possible :)
http://tomasp.net/articles/aspnet-fsharp-intro.aspx
C'est quand même le but de .NET de pouvoir partager le même framework (web ou autre) entre plusieurs langages...
Et puis bon avec C# 3 on peut déjà faire pas mal de fonctionnel ;)
[^] # Re: Interessant mais...
Posté par Victor . Évalué à 4.
De ce que je vois(mais je peux me tromper, le dev web c'est pas mon truc, et OCaml encore moins), le truc principal qu'il gagne c'est le test de liens automatique, le reste existe deja a peu pres meme si ce n'est pas un tout unifie.
Je pense que ça va plus loin que ça, ce ne sont pas juste les liens, mais les pages qui sont valides xhtml, tout comme ton compilateur C# te certifie qu'il n'y aura pas d'erreur avec les affectations de variable grâce au typage statique.
Et justement, en plus, ça apporte un typage statique qui evite beaucoup d'erreur de programmation. Surtout que le typage de OCaml est un typage à inférence, donc pas besoin de déclarer *tout* les types pour chaque variable :)
(enfin j'm'y connais pas super bien en OCaml non plus, c'est peut-être pas exactement ça :)
J'ai peut-etre rate un truc, mais il me semble que ca tient plus de l'exercice de style que du soft pouvant reellement changer les choses du point de vue dev. web.
Au contraire, je pense que ça prépare des changements possibles. Si personne ne recherche de nouvelles idées pour la programmation web, alors on avancera jamais. Peut-être que celle-ci ne percera pas, mais il y en aura peut-être une autre qui s'appuiera dessus.
Bien sur personne en entreprise n'utilise vraiment tout les vieux et nouveaux langages de recherche, mais ça n'empêche pas que même C# va y récupérer des trucs (exemple : delegates et le lambda calcul).
À mes yeux ce concept est super, et j'espère qu'il va intéresser des contributeurs :)
[^] # Re: Interessant mais...
Posté par desfrenes (site web personnel) . Évalué à 3.
# la garantie que les pages générées sont en xhtml valide ;
Une garantie de quel genre ? Du genre qui corrige les erreurs toute seule ou du genre qui ne laisse pas passer le code non valide ? En tout cas la documentation est moins catégorique que ça:
"Eliom uses an advanced type system that guarantees that your web site will be valid (or very close)."
Very close ?
# le typage des formulaires et des paramètres ;
La différence avec une classe de validation de formulaire ? (Formol, Zend_Form, etc)
# une gestion simplifiée de l'interaction Web à l'aide de concepts dédiés (continuations, etc.).
Il y aurait besoin d'explication sur ce concept de "Continuation-based Web programming".
"Today, most web sites are written using old technologies, such as CGI scripts or (untyped) scripting languages embedded in html."
J'ose espérer que ça appartient déjà au passé... à part les indécrottables...
"Eliom considers each URL as a function taking arguments and producing a web page."
Tout comme la majorité des frameworks web. (http://monsite/monModule/monController/methode/arg1/arg2)
à quel type d'ORM Ocsipersist appartient ?
[^] # Re: Interessant mais...
Posté par Victor . Évalué à 3.
# le typage des formulaires et des paramètres ;
La différence avec une classe de validation de formulaire ? (Formol, Zend_Form, etc)
La différence c'est que la validation de formulaire c'est usine à gaz, avec OCaml c'est fait à la compilation par le compilateur.
[^] # Re: Interessant mais...
Posté par Vivi (site web personnel) . Évalué à 3.
cf. http://en.wikipedia.org/wiki/Continuation#Continuations_in_W(...)
[^] # Re: Interessant mais...
Posté par desfrenes (site web personnel) . Évalué à 0.
[^] # Re: Interessant mais...
Posté par smc . Évalué à 1.
Une garantie de quel genre ? Du genre qui corrige les erreurs toute seule ou du genre qui ne laisse pas passer le code non valide ?
Ben le typage valide XHTML/XML est garanti parce qu'il utilise le système de types d'OCaml qui est prouvé mathématiquement. Qui dit typage XML valide dit document XML bien formé (dans ce cas, c'est XHTML). Qu'est-ce que tu crois que ça veut dire "garantir"?
Une page générée par une application utilisant Eliom ne peut pas être non conforme au schéma de XHTML, et c'est une propriété prouvée et statique quand tu compiles ton application. C'est quelque chose de plus dont le développeur n'a pas à se soucier... tout comme en OCaml le programmeur n'a pas à se soucier de segfaults, alors qu'en C, il peut les éviter mais ce n'est pas une propriété du langage (ou d'un subset utilisable dans 99% des programmes).
[^] # Re: Interessant mais...
Posté par benja . Évalué à 3.
Par contre, si l'on désire un "vrai" typage xml, ocsigen (ou plutot Eliom) permet de s'interfacer avec ocamlduce* qui permet alors de tirer parti d'un typage xml. Il devient alors super facile de générer, lire ou transformer n'importe quel type de document xml, avec la sûreté d'un typage statique à la compilation ! Ce point est peu mis en avant mais c'est un "must" à mon sens.
*: ocamlduce est une fusion du compilateur ocaml avec CDuce qui est une implémentation du langage XDuce en ocaml. Cela augmente le language ocaml "d'expressions XML" tout en restant pleinement compatible avec ocaml. cf. http://www.cduce.org/ocaml.html
[^] # Re: Interessant mais...
Posté par Vincent Balat . Évalué à 3.
XHTML.M permet de construire n'importe quel document xhtml valide. Il vérifie l'imbrication des balises (pas possible de mettre un <p> dans un <head> par exemple). Il impose la présence des balise obligatoires (<head> doit contenir un <title> par exemple, ou encore : une table doit contenir au moins une ligne). En revanche certaines petites choses ne sont pas vérifiées (par exemple on peut mettre deux fois le même attribut, ou bien un lien peut contenir un texte qui contient un autre lien). En général ce typage est très largement suffisant.
Eliom laisse le choix du module de sortie, et on peut aussi utiliser aussi OcamlDuce, qui comme tu le dis, est la solution propre. Cela permet d'utiliser d'autres formats de sortie XML, et en plus de la vérification du xml généré, il permet de faire du filtrage (pattern matching) sur des documents xml entrants (résultats d'une requête faite par le serveur à un autre serveur par ex). Défauts : la syntaxe est un peu plus lourde et il faut s'habituer au système de type (mais ça vient vite).
Parmi les utilisateurs d'Eliom, certains utilisent XHTML.M, d'autres OCamlDuce (à peu près à égalité). Je n'ai jamais vu personne utiliser la sortie texte non typée.
[^] # Re: Interessant mais...
Posté par desfrenes (site web personnel) . Évalué à 1.
[^] # Re: Interessant mais...
Posté par smc . Évalué à 2.
[^] # Re: Interessant mais...
Posté par FantastIX . Évalué à 2.
En général on fait ce qu'on veut dans le code et les modèles, ce qui ouvre la porte à toutes les dérives. Le code généré n'est pas nécessairement nettoyé et c'est au développeur ou au rédacteur de prendre lui-même les dispositions adéquates. Et si le développeur n'est pas au courant qu'il doit nettoyer ses pages et améliorer la conformité... D'autant que bien des outils sont faits pour que n'importe qui puisse concevoir ou modifier du contenu en deux temps/trois mouvements, sans qu'aucune connaissance ne soit nécessaire.
Vite fait... mal fait bien souvent.
On ne peut décemment exiger de chaque intervenant sur un site Internet qu'il connaisse parfaitement les contraintes à respecter. On ne peut demander à tous les rédacteurs ou à tous ceux qui pourraient intervenir dans la gestion de contenu d'une entreprise, par exemple, de connaître toutes ces choses-là.
Ici, c'est le soft qui garantit la conformité. On ne pouvait rêver mieux.
# Le retour en force du fonctionnel ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Ce retour est à constater d'abord par l'ajout d'une touche fonctionnelle dans des langages comme Python, Ruby, C#, ...
Puis, la remonté de Smalltalk qui a une approche fonctionnelle, au travers de squeak, seaside et OpenCroquet.
L'intérêt suscité à nouveau d'Haskell (très intéressant car il supporte le typage de Cook (typage du second degrès)).
L'introduction de F# dans .NET.
Sans parler de Scala un langage objet-fonctionnel qui prend de plus en plus dans la communauté Java, en attendant son apparition sur la plate-forme .NET. (Note : j'ai déjà un peu programmé avec Scala et c'est du vrai bonheur pour des perfs égales ou proches à du Java). Et en plus il se base non seulement sur le lambda-calcul mais aussi sur du pi-calcul (enfin plus exactement sur du join-calcul) !
[^] # Re: Le retour en force du fonctionnel ?
Posté par ddevito (site web personnel) . Évalué à 1.
* Thoughts about Java, C# future and OCaml (?) relationships :
http://jroller.com/page/dmdevito?entry=thoughts_about_java_c_future
* More ramblings on programming languages :
http://jroller.com/page/dmdevito?entry=more_ramblings_on_programming_languages
En gros, je voyais et je vois tjrs une évolution de Java et C# vers qque chose qui ressemblerait à OCaml. Déjà Scala se rapproche plus encore que Java de ce que l'on peut voir dans OCaml.
Bref, de plus en plus de langages se dotent notamment de traits fonctionnels.
Un papier intéressant à lire est :
* The Next Mainstream Programming Language: A Game Developer's Perspective, from Tim Sweeney (Epic Games) :
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
Il a été écrit par un professionnel de l'industrie des jeux, qui, face à la complexité croissante du développement logiciel (en particulier, du fait des CPU multi-coeurs), a envisagé notamment d'utiliser Haskell pour la programmation ! Etonnant, non ? Comme quoi, les langages impératifs ne sont pas le fin du fin et face à la complexité croissante du logiciel, les concepteurs de langage ont tendance à copier ce qui marche chez le voisin.
PS : à propos, Microsoft est membre du consortium OCaml. Je me dis qu'ils ont du repérer une pépite dont ils pouvaient tirer qques enseignements...
[^] # Re: Le retour en force du fonctionnel ?
Posté par TeXitoi (site web personnel) . Évalué à 1.
Microsoft utiliserait OCaml pour la certification des drivers de Windows.
Dans .NET, on trouve beaucoup d'idée venant d'OCaml, notamment l'inférence de type et le typage statique. .NET possède même un clône d'OCaml : F#.
[^] # Re: Le retour en force du fonctionnel ?
Posté par pasBill pasGates . Évalué à 0.
Perso j'en doutes enormement(on a une tres forte tendance a utiliser les technos qu'on cree et eviter les trucs externes), et je sais que ce n'est en tout cas pas le cas pour les drivers de carte reseau.
L'interet pour OCaml vient certainement de la division developpement qui s'occupe de CLR, C#, etc... , pas de la division Windows.
[^] # Re: Le retour en force du fonctionnel ?
Posté par Gilles G. . Évalué à 6.
http://caml.inria.fr/about/successes.fr.html
Le projet SLAM a débuté à Microsoft Research début 2000. Son but était de vérifier automatiquement qu'un programme C utilise correctement l'interface d'une bibliothèque extérieure. Pour répondre à cette question, SLAM utilise de manière novatrice des idées provenant de la vérification symbolique de modèles, de l'analyse statique de programmes et de la démonstration automatique. Le moteur d'analyse SLAM est au coeur d'un nouvel outil appelé SDV (Vérification Statique de Drivers) qui analyse systématiquement le code source des drivers (pilotes de périphériques) Windows et vérifie leur conformité vis-à-vis d'un ensemble de règles qui caractérisent les interactions correctes entre un driver et le noyau du système d'exploitation Windows.
Dans le rapport technique MSR-TR-2004-08, T.Ball, B.Cook, V.Levin and S.K.Rajamani, les auteurs de SLAM, écrivent: “The Right Tools for the Job: We developed SLAM using INRIA's OCaml functional programming language. The expressiveness of this language and robustness of its implementation provided a great productivity boost.”
[^] # Re: Le retour en force du fonctionnel ?
Posté par pasBill pasGates . Évalué à 0.
La version originale etait peut-etre sous OCaml, la version de production elle ne l'est pas.
[^] # Re: Le retour en force du fonctionnel ?
Posté par anocka . Évalué à 3.
# Mouais, faudrait ptetre...
Posté par Ontologia (site web personnel) . Évalué à 2.
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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Mouais, faudrait ptetre...
Posté par Victor . Évalué à 1.
[^] # Re: Mouais, faudrait ptetre...
Posté par rewind (Mastodon) . Évalué à 7.
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...
Posté par benja . Évalué à 1.
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...
Posté par Ontologia (site web personnel) . Évalué à 1.
J'ai parlé de Lisaac ici ?
Non.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Mouais, faudrait ptetre...
Posté par Ontologia (site web personnel) . Évalué à 2.
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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Mouais, faudrait ptetre...
Posté par Bob . Évalué à 3.
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...
Posté par benoar . Évalué à 5.
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...
Posté par Ontologia (site web personnel) . Évalué à 2.
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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Mouais, faudrait ptetre...
Posté par benoar . Évalué à 3.
[^] # Re: Mouais, faudrait ptetre...
Posté par smc . Évalué à 5.
[^] # Re: Mouais, faudrait ptetre...
Posté par TImaniac (site web personnel) . Évalué à 1.
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.
[^] # Re: Mouais, faudrait ptetre...
Posté par TeXitoi (site web personnel) . Évalué à 5.
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...
Posté par TImaniac (site web personnel) . Évalué à 2.
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.
[^] # Re: Mouais, faudrait ptetre...
Posté par TeXitoi (site web personnel) . Évalué à 3.
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...
Posté par TImaniac (site web personnel) . Évalué à 2.
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 ;)
[^] # Re: Mouais, faudrait ptetre...
Posté par benoar . Évalué à 2.
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...
Posté par TImaniac (site web personnel) . Évalué à 1.
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.
[^] # Re: Mouais, faudrait ptetre...
Posté par TeXitoi (site web personnel) . Évalué à 1.
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...
Posté par TImaniac (site web personnel) . Évalué à 1.
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.
[^] # Re: Mouais, faudrait ptetre...
Posté par TeXitoi (site web personnel) . Évalué à 1.
[^] # Re: Mouais, faudrait ptetre...
Posté par TeXitoi (site web personnel) . Évalué à 1.
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...
Posté par TImaniac (site web personnel) . Évalué à 1.
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".
[^] # Re: Mouais, faudrait ptetre...
Posté par _ . Évalué à 0.
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...
Posté par fmaz fmaz . Évalué à 4.
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...
Posté par _ . Évalué à 0.
[^] # Re: Mouais, faudrait ptetre...
Posté par reno . Évalué à 4.
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..
# Links
Posté par maikeul (site web personnel) . Évalué à 1.
http://groups.inf.ed.ac.uk/links/
# Utilisation
Posté par timid . Évalué à 1.
[^] # Re: Utilisation
Posté par zul (site web personnel) . Évalué à 1.
Il faut à mon avis voir ça comme la proof du concept que ca marche et que c'est bien. Rien n'empeche de rajouter une couche par dessus qui encapsulera complétement la notion de html / formulaire / lien, mais en profitant des avantages existant déjà, en particulier la conformité.
[^] # Re: Utilisation
Posté par petitdragon . Évalué à 1.
- qu'il faut bien programmer ces frameworks "évolués". Ocsigen est plus bas niveau et permet de faire ça proprement
- que même ces frameworks ont besoin de validation (sauf s'ils mettent tout dans des div, ce qui est moche)
- Ocsigen fait beaucoup beaucoup d'autre chose que la validation du html...
[^] # Re: Utilisation
Posté par Ontologia (site web personnel) . Évalué à 3.
A savoir :
- Un développement indépendant du web => On peut potentiellement porter son application n'importe où (web, client lourd, etc...)
- Quoi qu'il arrive, on a d'ors et déjà un client riche, pas de Html/XML à générer.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Utilisation
Posté par timid . Évalué à 2.
# OCaml vs. PHP
Posté par gadm . Évalué à 1.
Je veux bien qu'on me dise que l'I/O est plus important que le processeur dans la programmation web, mais avec une telle différence, j'ai vite fait mon choix.
(vs Python: http://shootout.alioth.debian.org/debian/benchmark.php?test=(...) )
# Et une interface "normalisée" avec la base de données ?
Posté par ddevito (site web personnel) . Évalué à 1.
Est-ce que OCaml offre une telle interface ? Si oui, cela va devenir plus business-friendly.
Sauf erreur, Eliom doit avoir "normalisé" en OCaml à peu près l'équivalent de la couche servlet. Si les autres couches de Java EE sont aussi normalisées du fait de la communauté, alors on verra émerger l'équivalent de Java EE en Java. Cool.
Toujours pas de CPAN pour OCaml ;-( ?
[^] # Re: Et une interface "normalisée" avec la base de données ?
Posté par Olivier Faurax (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.