jeudi 24 juillet

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Articles précédents : Développeur

Liens connexes

Ocsigen (1503 hits)
OCaml (544 hits)

Dépêche modérée par

Floxy

Dépêche éditée par

Développeur : Ocsigen 1.0.0 : une nouvelle approche de la programmation Web

Posté par Vincent Balat (). Modéré le 09 avril 2008.

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.

Ocsigen (1503 hits)
OCaml (544 hits)

> Lire la dépêche (57 commentaires, moyenne: 2,2).

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 !

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Interessant mais...

Posté par pasBill pasGates () le 09/04/2008 à 07:06. (lien). Évalué à 6.

C'est un concept effectivement assez original, mais je me demandes un peu comment vous ce systeme va etre "vendu" aux gens qui font aujourd'hui du dev. web.

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 (page perso, ) le 09/04/2008 à 08:04. (lien). Évalué à 4.
Interessant mais.... si si c'est pas si mal de pouvoir faire du développement web avec une approche plus fortement typée, et d'avoir un langage fonctionnel aussi puissant sous la main c'est un atout indéniable. Peut être pas pour tout de suite en production sur des gros sites... mais sait-on jamais. Il leur faudra d'abord améliorer la connectivité SGBD (c'est un des points de développement).

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 (page perso, ) le 09/04/2008 à 10:41. (lien). Évalué à 1.
  Mais microsoft va-t-il sortir un jour ASP.NET for F#, pour concurrencer ocsigen ??
  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 ;)
  
  --
  MonoFrance

[^]Re: Interessant mais...

Posté par kaouete (page perso, ) le 09/04/2008 à 08:07. (lien). É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 () le 09/04/2008 à 08:09. (lien). Évalué à 3.
C'est vrai que le gain ne saute pas aux yeux, il faut sans doute creuser plus.

# 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 kaouete (page perso, ) le 09/04/2008 à 08:33. (lien). Évalué à 3.
  Un élément de réponse :
  
  # 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 (page perso, ) le 09/04/2008 à 09:17. (lien). Évalué à 3.
  Il y aurait besoin d'explication sur ce concept de "Continuation-based Web programming".
  
  cf. http://en.wikipedia.org/wiki/Continuation#Continuations_in_W(...)
  - [^]Re: Interessant mais...
    
    Posté par desfrenes () le 09/04/2008 à 09:26. (lien). Évalué à 0.
    Merci ! :-)
- [^]Re: Interessant mais...
  
  Posté par smc () le 09/04/2008 à 11:24. (lien). Évalué à 1.
  # 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 ?
  
  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 () le 09/04/2008 à 13:02. (lien). Évalué à 3.
    Eliom (en fait le module XHTML.M) ne permet pas de faire un "typage XML" à propremment parler, mais il utilise les types polyvariants d'ocaml qui permettent de construire une représentation d'une structure hierarchique "à la xml", tout en empêchant l'imbrication d'éléments incompatibles. Donc il est impossible de construire des documents non valides (sans tricher). Mais est-ce qu'il est possible de constuire tous les documents valides ou la structure de XHTML.M est plus rigide que la norme xhtml ? (Vincent ?).
    
    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 () le 09/04/2008 à 13:41. (lien). Évalué à 3.
      Mais est-ce qu'il est possible de constuire tous les documents valides ou la structure de XHTML.M est plus rigide que la norme xhtml ? (Vincent ?).
      
      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 () le 09/04/2008 à 14:59. (lien). Évalué à 1.
    fort bien... mais alors pourquoi seulement "very close" ?
    - [^]Re: Interessant mais...
      
      Posté par smc () le 09/04/2008 à 15:17. (lien). Évalué à 2.
      Vincent Balat a répondu juste à côté...

[^]Re: Interessant mais...

Posté par FantastIX () le 09/04/2008 à 12:25. (lien). Évalué à 2.
Je suis rassuré de voir bien des efforts consacrés à la validité des pages car c'est un point qui m'a toujours agacé profondément, par exemple, lorsque je vois des sites avec un logo [X]HTML et que le code est particulièrement médiocre (pour rester poli). La pierre ne doit pas forcément être jetée au développeur ou à l'outil mais j'ai déjà abordé plusieurs produits et aucun [de ceux que j'ai évalués] ne permet [d'emblée] de renforcer ni de mettre l'accent sur la conformité.

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 (page perso, ) le 09/04/2008 à 09:35. (lien). Évalué à 2.

En effet, je suit un peu l'actualité des langages de programmations et je remarque que les langages fonctionnels reprennent du poil de la bête. Ce qui ne m'étonne guère étant donné qu'avec ses langages on se focalise plus sur le 'quoi' que le 'comment' et que donc ils permettent d'appréhender plus facilement la complexité qui va en grandissant sur les projets.

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 (page perso, ) le 09/04/2008 à 19:00. (lien). Évalué à 1.
Oui, j'ai posté qques notes là-dessus (putain, en 2005, merde, comme le temps passe vite, j'ai l'impression que c'était hier...) :

* 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 (Jabber id, page perso, ) le 09/04/2008 à 19:06. (lien). Évalué à 1.
  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...
  
  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 () le 09/04/2008 à 22:12. (lien). Évalué à 0.
    Microsoft utiliserait OCaml pour la certification des drivers de Windows.
    
    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. () le 10/04/2008 à 09:18. (lien). Évalué à 6.
      Vu sur:
      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 () le 10/04/2008 à 19:21. (lien). Évalué à 0.
        Oui, mais le truc a savoir c'est que Microsoft Research developpe ses projets de recherche dans les langages qu'il veut, cependant une fois que le projet passe au stade production, l'equipe prend le code des chercheurs et d'habitude le reecrit en bonne partie si ce n'est tout dans une forme qui est maintenable, plus propre, ...
        
        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 () le 10/04/2008 à 19:33. (lien). Évalué à 3.
        Je ne sais pas si tu as déjà programmé en dans un language fonctionnel, mais la puissance et l'expressivité d'ocaml font qu'il est très difficile de reprendre du code dans ce language pour le refaire dans un autre... J'ai déjà vu de des fonctions de 20 lignes se refaire en 5 dans un language fonctionnel. Donc en pratique une telle chose me parait très peu probable.

Mouais, faudrait ptetre...

Posté par Ontologia (page perso, ) le 09/04/2008 à 11:03. (lien). Évalué à 2.

...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...

Posté par kaouete (page perso, ) le 09/04/2008 à 12:24. (lien). Évalué à 1.
Et tu aurais des liens à nous proposer à propos des "langages de programmation sémantiques à ontologie" ?

[^]Re: Mouais, faudrait ptetre...

Posté par rewind () le 09/04/2008 à 12:58. (lien). Évalué à 7.
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...
  
  Posté par benja () le 09/04/2008 à 13:19. (lien). Évalué à 1.
  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...
  
  Posté par Ontologia (page perso, ) le 09/04/2008 à 13:58. (lien). Évalué à 1.
  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...
  
  Posté par Ontologia (page perso, ) le 09/04/2008 à 14:20. (lien). Évalué à 2.
  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...
  
  Posté par Bob () le 09/04/2008 à 16:41. (lien). Évalué à 3.
  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...

Posté par benoar (Jabber id, ) le 09/04/2008 à 14:11. (lien). Évalué à 5.
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...
  
  Posté par Ontologia (page perso, ) le 09/04/2008 à 14:24. (lien). Évalué à 2.
  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...
    
    Posté par benoar (Jabber id, ) le 09/04/2008 à 14:38. (lien). Évalué à 3.
    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...
      
      Posté par smc () le 09/04/2008 à 14:57. (lien). Évalué à 5.
      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...
    
    Posté par TImaniac (page perso, ) le 09/04/2008 à 15:42. (lien). Évalué à 1.
    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...
      
      Posté par TeXitoi (Jabber id, page perso, ) le 09/04/2008 à 15:56. (lien). Évalué à 5.
      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...
        
        Posté par TImaniac (page perso, ) le 09/04/2008 à 16:03. (lien). Évalué à 2.
        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...
        
        Posté par TeXitoi (Jabber id, page perso, ) le 09/04/2008 à 16:16. (lien). Évalué à 3.
        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...
        
        Posté par TImaniac (page perso, ) le 09/04/2008 à 16:44. (lien). Évalué à 2.
        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...
        
        Posté par benoar (Jabber id, ) le 09/04/2008 à 16:51. (lien). Évalué à 2.
        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...
        
        Posté par TImaniac (page perso, ) le 09/04/2008 à 17:11. (lien). Évalué à 1.
        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...
        
        Posté par TeXitoi (Jabber id, page perso, ) le 09/04/2008 à 17:22. (lien). Évalué à 1.
        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...
        
        Posté par TImaniac (page perso, ) le 09/04/2008 à 18:22. (lien). Évalué à 1.
        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...
        
        Posté par TeXitoi (Jabber id, page perso, ) le 09/04/2008 à 18:57. (lien). Évalué à 1.
        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...
        
        Posté par TeXitoi (Jabber id, page perso, ) le 09/04/2008 à 17:18. (lien). Évalué à 1.
        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...
        
        Posté par TImaniac (page perso, ) le 09/04/2008 à 17:58. (lien). Évalué à 1.
        . 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...
        
        Posté par paul brauner () le 11/04/2008 à 22:03. (lien). Évalué à 0.
        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...
        
        Posté par fmaz fmaz () le 15/04/2008 à 07:34. (lien). Évalué à 4.
        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...
        
        Posté par paul brauner () le 23/04/2008 à 19:00. (lien). Évalué à 0.
        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...

Posté par reno () le 10/04/2008 à 10:17. (lien). Évalué à 4.
>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..

Links

Posté par maikeul () le 09/04/2008 à 16:42. (lien). Évalué à 1.

Sans avoir de réelle opinion sur le sujet, un autre projet de recherche dans le même domaine que j'avais vu passer :

http://groups.inf.ed.ac.uk/links/

Utilisation

Posté par Kévin FERRARE (page perso, ) le 09/04/2008 à 17:05. (lien). Évalué à 1.

Si on compare à des framework évolués comme Echo2 ou GWT qui te permettent de coder ton appli web sans avoir à te préoccuper du html, des formulaires ou des liens, je me demande si cette méthode de programmer un site n'est pas déja dépassée (Sans parler de ce projet en particulier)

[^]Re: Utilisation

Posté par zul (Jabber id, page perso, ) le 09/04/2008 à 19:41. (lien). Évalué à 1.
Ces frameworks assurent il que les pages sont valides, que les liens marchent, etc ... ?

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 () le 09/04/2008 à 23:21. (lien). Évalué à 1.
Tu oublies :
- 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 (page perso, ) le 10/04/2008 à 10:57. (lien). Évalué à 3.
Malgré que ces framework ne valident pas le code, ce qui constitue l'apport vraiment nouveau et intéressant d'Ocsigen, comme le font judicieusement remarquer les 2 réponses au dessus, je pense que ce sont des framework comme Echo2 ou GWT qui ont de l'avenir.

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.
- [^]Re: Utilisation
  
  Posté par Kévin FERRARE (page perso, ) le 10/04/2008 à 16:35. (lien). Évalué à 2.
  Dans ce type de framework le HTML est généré par du DOM en javascript, alors la validation ...

OCaml vs. PHP

Posté par gadm () le 09/04/2008 à 17:39. (lien). Évalué à 1.

Petit rappel d'un des attraits d'OCaml: http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)

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 (page perso, ) le 09/04/2008 à 18:40. (lien). Évalué à 1.

La librairie Java offre une interface JDBC normalisée avec les bases de données, à chaque fournisseur d'implémenter ces interfaces pour fournir un driver pour sa base.

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 (Jabber id, page perso, ) le 09/04/2008 à 23:10. (lien). Évalué à 2.
Un truc comme ça : http://caml.inria.fr/cgi-bin/hump.cgi ?

--
xmpp:ofaurax@jabber.fr

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : Ocsigen 1.0.0 : une nouvelle approche de la programmation Web

Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

[^]Re: Interessant mais...

Le retour en force du fonctionnel ?

[^]Re: Le retour en force du fonctionnel ?

[^]Re: Le retour en force du fonctionnel ?

[^]Re: Le retour en force du fonctionnel ?

[^]Re: Le retour en force du fonctionnel ?

[^]Re: Le retour en force du fonctionnel ?

[^]Re: Le retour en force du fonctionnel ?

Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

[^]Re: Mouais, faudrait ptetre...

Links

Utilisation

[^]Re: Utilisation

[^]Re: Utilisation

[^]Re: Utilisation

[^]Re: Utilisation

OCaml vs. PHP

Et une interface "normalisée" avec la base de données ?

[^]Re: Et une interface "normalisée" avec la base de données ?