Discussion :

[james-mi]

Je souhaite m'essayer à la programmation fonctionnelle, après avoir fait un peu de python et de ruby, pour le plaisir.

je suis attiré par OCaml (et Anubis, mais c'est une autre histoire et fera l'objet d'un autre post), mais je me pose des questions sur la "qualité" justement, et la productivité. Cela tourne autour de l'existence d'outils de qualité et productivité comme :
-PyLint
-la documentation incluse dans les sources, quelle maturité chez OCaml ?
-le développement "Test Driven" - voire "Documentation driven", avec les tests inclus dans les sources

un excellent article exposant les difficultés qu'un développeur affronte quand il arrive sous OCaml, devant le manque d'outils de ce type : http://www.cs.ubc.ca/~kdvolder/CPSC5...06_07/mike.pdf
Cela me fait un peu peur pour ma propre "conversion" ... néanmoins l'auteur est très factuel et positif en même temps

[gorgonite]

-PyLint

pas sûr qu'un tel outil existe pour OCaml...

-la documentation incluse dans les sources, quelle maturité chez OCaml ?

tu peux rapidement obtenir ceci à partir de commentaires dans ton source...
http://till.varoquaux.free.fr/projects/yappi/

(nb : ce n'est pas mon site )

-le développement "Test Driven" - voire "Documentation driven", avec les tests inclus dans les sources

souvent, il peut être plus simple de bien choisir les types utilisés, et la compilation et le méchanisme de typage peuvent déjà "certifiés" pas mal de choses
après pas sûr qu'il existe un "OCaml Unit"

[Jedai]

Tu parles de OCaml et d'Anubis, mais as-tu considéré Haskell ?

Pour quelqu'un qui vient comme toi de Python, le système de "layout" (indentation significative) d'Haskell devrait t'être familier, par ailleurs, du point de vue outils et communauté, Haskell est peut-être un peu plus riche.

Je ne connais pas d'équivalent de Pylint, par contre Haddock permet d'incorporer sa documentation au code, et HUnit permet de faire du test unitaire, tandis que Quickcheck offre une autre façon de tester, particulièrement efficace dans certains cas.

La mailing-list Haskell-Café est très active et le canal IRC #haskell sur Freenode est beaucoup plus fréquenté et réactif que #ocaml.

Le système de type d'Haskell est plus riche et complexe que celui d'OCaml et permet la surcharge des fonctions de façon parfaitement contrôlée (si tu as déjà fait du Caml, tu as déjà dû rencontrer les "+.", "/." pour les flottants, en Haskell le + marche pour tous les types numériques (mais sans autoriser les mélanges dangereux). Ceci peut être à la fois un avantage et un désavantage, car il y a plus de chose à apprendre (principalement les classes de type) et le système de type n'est pas complètement décidable, ce qui veut dire que dans de très rare cas, l'inférence n'est pas capable de déterminer le type.
Egalement, Haskell sépare plus nettement les aspects impératifs et fonctionnels que OCaml (qui est plutôt multiparadigme), cela ajoute à la sécurité mais déconcerte au premier abord. Haskell est un langage paresseux ce qui offre d'intéressantes possibilités mais également quelques surprises à un débutant.

Les deux langages sont hautement efficients, compilés et beaucoup plus sûr que la plupart des langages impératifs (on exclura ADA).

--
Jedaï

[SpiceGuid]

-PyLint
-la documentation incluse dans les sources, quelle maturité chez OCaml ?
-le développement "Test Driven" - voire "Documentation driven", avec les tests inclus dans les sources

Toutes les librairies standards sont très bien documentées en ligne, signature, description, exceptions, rien ne manque.

Pour le reste, c'est l'approche fonctionnelle qui se charge de l'assurance qualité, ainsi que l'interpréteur interactif, et bien sur les assert, bien davantage que des outils. Mon tutoriel donne quelques exemples d'algorithmes sophistiqués développés en OCaml, sans autre aide que l'interpréteur et un éditeur à coloration syntaxique.

[LLB]

De même, tu pourrais considérer F#. Les points forts cités dans le papier sont valables dans F#, et plusieurs ponts faibles disparaissent. Notamment, le système objet est plus classique et mieux intégré au langage. Il y a un éditeur plus riche (Visual Studio - avec vérification du code au moment de la frappe, un mode interactif, un débuggueur...). Il existe un outil pour les tests (nunit), assez sympa et basé sur la réflexion. Il y a aussi un générateur de documentation. Enfin, F# possède une bibliothèque beaucoup plus importante (.NET) et me semble un peu plus abordable que Caml.

Mais après, tout dépend de tes besoins et de tes projets (à noter que F# est légèrement moins portable que Caml et que la communauté est - pour le moment - plus réduite).

mais je me pose des questions sur la "qualité" justement, et la productivité

Quel que soit ton choix, tu auras un gros gain de qualité par rapport à Ruby / Python et (avec un peu d'expérience) tu ne perdras pas en productivité.

[james-mi]

De même, tu pourrais considérer F#. Les points forts cités dans le papier sont valables dans F#, et plusieurs ponts faibles disparaissent. Notamment, le système objet est plus classique et mieux intégré au langage. Il y a un éditeur plus riche (Visual Studio - avec vérification du code au moment de la frappe, un mode interactif, un débuggueur...). Il existe un outil pour les tests (nunit), assez sympa et basé sur la réflexion. Il y a aussi un générateur de documentation. Enfin, F# possède une bibliothèque beaucoup plus importante (.NET) et me semble un peu plus abordable que Caml.

Ce serait exactement ce que je veux, mais je suppose que tout cela n'est pas Open Source : j'ai oublié de préciser que je recherche des outils libres ... et sous Linux, point de F# je pense ?

Mon tutoriel donne quelques exemples d'algorithmes sophistiqués développés en OCaml, sans autre aide que l'interpréteur et un éditeur à coloration syntaxique.

Oui, j'ai déjà regardé, je vais creuser. Mais des tests unitaires seraient aussi très utiles je pense.

Tu parles de OCaml et d'Anubis, mais as-tu considéré Haskell ?

Pour quelqu'un qui vient comme toi de Python, le système de "layout" (indentation significative) d'Haskell devrait t'être familier, par ailleurs, du point de vue outils et communauté, Haskell est peut-être un peu plus riche.

Je ne connais pas d'équivalent de Pylint, par contre Haddock permet d'incorporer sa documentation au code, et HUnit permet de faire du test unitaire, tandis que Quickcheck offre une autre façon de tester, particulièrement efficace dans certains cas.

Sur ton conseil, je viens de passer la soirée dessus. Cela ressemble de près à ce que je recherche. J'hésite car, évidemment, comme toujours, il y a des avantages et des inconvénients :
avantages d'Haskell :

citation du wiki d'Haskell.org
Haskell offers you:

* Shorter, clearer, and more maintainable code.
* Fewer errors, higher reliability.
* A smaller "semantic gap" between the programmer and the language.
* Shorter lead times.

Haskell is a wide-spectrum language, suitable for a variety of applications. It is particularly suitable for programs which need to be highly modifiable and maintainable.

mais en contrepartie :

being purely functional is a terrible hassle in most real cases

Donc dans ma liste, je ne sais pas qui de Haskell ou d'Ocaml est premier, et qui 2ème, mais Anubis vient de passer 3ème (projet pas très explicite quand à son futur, modèle de développement et licence peu clairs... ah si c'était de l'Open Source ...).

Egalement, Haskell sépare plus nettement les aspects impératifs et fonctionnels que OCaml (qui est plutôt multiparadigme)

La présence de la couche objet de OCaml a tendance à me rassurer, même si je me suis juré de ne pas l'utiliser ....

Les deux langages sont hautement efficients, compilés et beaucoup plus sûr que la plupart des langages impératifs (on exclura ADA).

--
Jedaï

Excluons aussi Eiffel qui est remarquable (et un avatar récent : Cobra)

[james-mi]

mais en contrepartie :
Citation:
being purely functional is a terrible hassle in most real cases

justement, si quelqu'un pouvait m'éclairer sur ce point :
-mon application consiste à lire des fichiers de données
-à faire des calculs et des stats sur les tableaux issues de ces fichiers, via des boucles
-puis à écrire les résultats dans d'autres fichiers.

Le côté *purement* fonctionnel d'Haskell est il un gros inconvénient ici ? ( C'est ce que semble suggérer http://haskell.org/pipermail/haskell...er/013403.html qui pour cette raison opte pour OCaml )

[alex_pi]

justement, si quelqu'un pouvait m'éclairer sur ce point :
-mon application consiste à lire des fichiers de données
-à faire des calculs et des stats sur les tableaux issues de ces fichiers, via des boucles
-puis à écrire les résultats dans d'autres fichiers.

Pourquoi cherches-tu à te tourner vers un langages fonctionnel dans ce cas ? Ca ressemble quand même à une bonne application pour des langages spécifiques orientés calculs non ? Tu es sûr que matlab (ou octave) ne serait pas même mieux adaptés ?

Et pour info, dans un langage fonctionnel pure, on n'a pas de boucle, que des récursions.

[Jedai]

justement, si quelqu'un pouvait m'éclairer sur ce point :
-mon application consiste à lire des fichiers de données
-à faire des calculs et des stats sur les tableaux issues de ces fichiers, via des boucles
-puis à écrire les résultats dans d'autres fichiers.

Le côté *purement* fonctionnel d'Haskell est il un gros inconvénient ici ? ( C'est ce que semble suggérer http://haskell.org/pipermail/haskell...er/013403.html qui pour cette raison opte pour OCaml )

Bof, je ne sais pas trop ce qu'il veut dire par "manque de support pour les boucles", dans IO tu peux faire les mêmes boucles que dans n'importe quel langage, en dehors, les combinateurs comme fold ou map les remplace avantageusement (pas de problème de bornes, traduction plus immédiate de l'intention que l'utilisation de variables mises à jour à chaque itération, ...). Les tableaux de Haskell sont un peu plus compliqués à aborder que ceux de OCaml, parce qu'il y en a plus de types. Au niveau des performance, il est vrai qu'Haskell est souvent légèrement en-dessous de OCaml, dû au surcout de l'évaluation paresseuse, mais la différence s'est réduite significativement depuis 2005 (Haskell est même légèrement meilleur que OCaml au classement du shootout, ce qui n'est pas vraiment significatif, par contre ce qui l'est plus, c'est que les deux langages sont classés parmi les plus rapides).
Venant de langage comme Python ou Ruby, les performances seront de toute façon sans commune mesure.

Un autre avantage d'Haskell par rapport à OCaml, c'est la concurrence et le parallélisme, Haskell est bien plus avancé qu'OCaml dans le domaine. GHC permet d'avoir des threads utilisateurs gérés automatiquement sur des threads systèmes. Les API de parallélisme sont franchement intéressantes.

--
Jedaï

[Jedai]

Pourquoi cherches-tu à te tourner vers un langages fonctionnel dans ce cas ? Ca ressemble quand même à une bonne application pour des langages spécifiques orientés calculs non ? Tu es sûr que matlab (ou octave) ne serait pas même mieux adaptés ?

Ca m'a plutôt l'air en plein dans le domaine d'application de R.

--
Jedaï

[LLB]

Ce serait exactement ce que je veux, mais je suppose que tout cela n'est pas Open Source : j'ai oublié de préciser que je recherche des outils libres ... et sous Linux, point de F# je pense ?

Ca dépend de ce que tu mets derrière le terme "open source". Ce n'est pas libre selon la définition de la FSF, mais : c'est gratuit, tu as accès au code source, tu peux le recompiler et le modifier (je l'ai déjà fait). En revanche, tu n'as pas le droit de le revendre le logiciel.

Quant à Linux, je l'ai utilisé de temps en temps avec F#. J'utilise aussi régulièrement F# sous FreeBSD. Je n'ai jamais rencontré de problème. Il y a un an, j'avais écrit un projet de taille moyenne en F#, sous Windows (sans me poser aucune question, je n'avais même pas songé à la potrabilité). Plus tard, je l'ai compilé sous Linux, il n'y a pas eu la moindre différence (ni la moindre ligne de code à changer). Plusieurs utilisateurs de F# sont sous Mac, et ça marche bien aussi.

Les toutes dernières fonctionnalités de .NET ne doivent pas être portées et je crois que les Windows Forms ne sont pas compatibles à 100%.

Si tu lis des fichiers et calcule des statistiques, tu ne devrais pas rencontrer de problème.

Donc dans ma liste, je ne sais pas qui de Haskell ou d'Ocaml est premier, et qui 2ème

Ca va être dur de te conseiller, tout en restant objectif. Il existe des livres gratuits pour les deux langages, tu peux les survoler et faire ton choix par toi-même.

-mon application consiste à lire des fichiers de données
-à faire des calculs et des stats sur les tableaux issues de ces fichiers, via des boucles
-puis à écrire les résultats dans d'autres fichiers.

Pourquoi ne pas rester sur Ruby / Python ? Ce sera le plus simple et le plus rapide pour toi, je pense. Les performances sont-elles vraiment importantes pour cette application ?

[james-mi]

Ca m'a plutôt l'air en plein dans le domaine d'application de R.

Merci du conseil, je vais jeter un coup d'oeil. Si il y a une librairie OCaml ce serait parfait (pas trouvé, ni Haskell d'ailleurs) !

Ca va être dur de te conseiller, tout en restant objectif. Il existe des livres gratuits pour les deux langages, tu peux les survoler et faire ton choix par toi-même.

oui c'est ce que je vais faire

Pourquoi ne pas rester sur Ruby / Python ? Ce sera le plus simple et le plus rapide pour toi, je pense. Les performances sont-elles vraiment importantes pour cette application ?

Pour des bonnes raisons, et une mauvaise :

les bonnes :
-les perf sont importantes pour mon application (mais je pourrai rester en impératif avec Eiffel, beau langage OO)
-la sécurité (de calcul) est importante, en impératif je me retrouve avec plein d'indices à gérer, je compte sur l'approche fonctionnelle pour me simplifier la vie (Eiffel pourrait m'aider à atteindre cela avec les contrats, qui est une invention simple et géniale)
-étant donné que j'applique des fonctions à des tableaux et des sous-tableaux etc, je pense que l'approche fonctionnelle est la meilleure

la mauvaise raison, la plus importante :
-j'ai envie d'apprendre le fonctionnel !

[gorgonite]

Quant à Linux, je l'ai utilisé de temps en temps avec F#. J'utilise aussi régulièrement F# sous FreeBSD. Je n'ai jamais rencontré de problème. Il y a un an, j'avais écrit un projet de taille moyenne en F#, sous Windows (sans me poser aucune question, je n'avais même pas songé à la potrabilité). Plus tard, je l'ai compilé sous Linux, il n'y a pas eu la moindre différence (ni la moindre ligne de code à changer). Plusieurs utilisateurs de F# sont sous Mac, et ça marche bien aussi.

perso, je n'ai jamais réussi à le faire marcher... j'y ai passé une ou deux heures sans résultat, depuis j'ai un peu laché l'affaire ^^


[HS]ce serait une jolie entrée pour une FAQ [/HS]