Ton évaluation du langage est intéressante mais inutilement aigrie. Tous les langages ont leurs défauts, et il est important de bien en être conscient. Mais ce n'est pas une raison pour être inutilement négatif : si tu arrives à convaincre des gens par des arguments non rationnels, tu ne leur rends pas service (puisqu'ils vont faire un autre choix de langage en croyant éviter les problèmes, pour découvrir ensuite qu'ils ont les mêmes problèmes ou d'autres).
La lib standard est totalement vide.
La bibliothèque standard est minimaliste. Pas "vide", mais pas suffisante. Comme tu le dis, il existe d'autres bibliothèques de base, dont je ne sais pas si elles "règlent le problème" (elles restent moins étendues par exemple que la bibliothèque standard Python).
Sauf que c'est essentiellement un faux problème : le problème n'est pas la taille de la bibliothèque standard (qui a la plus grosse ?) mais la relative difficulté d'adoption des bibliothèques tierces. Ce qui fait la force de Perl ce n'est pas en soit la bibliothèque standard (qui dans mon souvenir n'a rien d'extraordinaire), mais le CPAN qui permet d'accéder à un énorme écosystème facilement.
Alors oui ça manque pour OCaml (par rapport à Perl, Haskell (cabal), Python etc.) mais c'est un problème de communauté plutôt que de langage. C'est en travail : GODI n'a pas su convaincre, maintenant on parie sur Oasis-DB.
Par ailleurs pour le détail, "@@" et "@$" ne sont sérieusement utilisés que par asmanur à ma connaissance (donc "tout le monde" on repassera), et ta façon de compter est un peu discutable puisque Batteries est une extension conservatrice par dessus Extlib. Tu ne comptes pas "Core" et "Core Extra" comme deux bibliothèques. Enfin je ne comprends pas "ce n'est pas une excuse", peux-tu développer ?
Pas de gestionaire de packages par défaut.
Qu'est-ce que ça veut dire ? De nos jour tout le monde utilise findlib. On juge les langages sur leur "distribution de base" maintenant ? Je pense que tu as mieux à critiquer que les choix de packaging des distributions.
Rien de plus chiant que de compiler de l'OCaml.
Forcément, quand on part d'un script qui envoie *.ml à la chaîne de compilation, c'est chiant. Par contre si on fait des choses un poil propres (oui, il faut respecter l'ordre de dépendance), il n'y a pas de problème selon mon expérience personnelle (et encore moins de problèmes depuis ocamlbuild qui, si si, possède une documentation). En particulier j'ai jamais eu à coder un tri topologique (buggué ou non :-) pour ça, et je trouve un peu douteux de projeter vos propres erreurs de conception sur le langage lui-même.
Tu pourrais répondre à ma critique d'au dessus « ocamlbuild ». Où est la doc ?
Combine l'absence de documentation à l'utilisation d'extensions syntaxiques qui ont été crées uniquement pour ce projet.
Je ne comprends pas. OCamlbuild n'utilise pas à ma connaissance d'extensions syntaxiques particulières. Tu parles de la difficulté à compiler un projet qui utilise ses propres extensions syntaxiques ? Selon mon expérience (Macaque par exemple) ce n'est encore une fois pas un problème (car contre attention à la combinaison camlp4 + ocamldoc, qui font mauvais ménage ensemble; en règle générale j'évite de préprocesser les .mli pour éviter tout soucis de ce genre).
En gros, si tu veux avoir un truc portable, tu es coincé sous 3.11.
Ben non, tu peux très bien compiler 3.12 sous windows (la raison pour laquelle personne ne se plaint c'est que la plupart des windows-users font ça; après je comprends que tu trouves ça pas cool pour les débutants). Si tu as envie de proposer un binaire un peu portable en téléchargement, fais-toi plaisir. (Bah oui c'est facile de se plaindre du manque de communauté et de tout faire dans son coin derrière)
Et si tu veux avoir un truc portable avec des Big_int, tu es donc coincé dans la mocheté à moins d'utiliser des extensions Camlp4
Bof. Depuis la 3.12 tu peux te faire tes smooth operators si ça t'amuse, et en vrai (+/) n'est pas spécialement moche (un peu lourd syntaxiquement, mais pas moins par exemple que l'émulation du pattern matching dans un langage qui ne le propose pas).
En parlant de camlp4, c'est devenu quoi camlp5 ?
Bien vu, il y a des problèmes politiques autour de camlp4/5. Je doute que ça ait une grande importance sur le langage OCaml dans son ensemble, et en tout cas ce n'est pas la question du nom du logiciel qui importe.
Pas de support des threads natifs si j'ai bien compris : tu es coincé avec un programe monothreaded car le GC n'est pas concurrent.
Marrant de mentionner ça dans une news sur Perl, à ma connaissance ni Perl ni Python ni Ruby n'ont mieux à proposer dans ce domaine. Et dans tous ces langages, comme pour OCaml, on répond en cœur aux gens d'utiliser le multi-processing, et curieusement le net n'est pas noirci de blog "c'est un scandale, les programmes python sont monothreaded". John Harrop est bon pour répandre du FUD quand ça l'arrange, mais je trouve dommage qu'ensuite les gens se focalisent là-dessus.
Il y a effectivement un choix qui a été fait de ne pas favoriser la concurrence par mémoire partagée au sein d'un même processus. Les développeurs OCaml ont évalué que le coût de développement d'un runtime concurrent était bien trop élevé par rapport aux bénéfices que ça représente, en particulier parce que (a l'époque du choix et toujours aujourd'hui) on n'a pas de bons outils de programmation de la mémoire concurrente.
Je ne vais pas écrire un pavé sur le sujet mais je pense honnêtement qu'ils ont fait le bon choix.
En pratique ça handicape certains programmes qui tiennent sur du multi-core (et n'ont pas besoin de passer à l'échelle sur un cluster par exemple) et utilisent beaucoup de partage de donnée (donc ne sont pas trop efficaces en passage de messages à la Erlang).
Ça n'est pas le cas de l'ensemble des programmes concurrents (par exemple le cas classiques des problèmes naturellement parallèles passent très bien avec du multi-processing); en réalité, seule une minorité d'usages est concernée. C'est dommage pour les gens qui veulent programmer précisément ça (et dans ce cas je leur conseille de changer de langage), mais ça n'est pas une raison pour fuir le langage pour tous les usages.
Par ailleurs, si tu veux faire de la programmation concurrente "salement" comme en C, je pense qu'un bon choix aujourd'hui pour OCaml est Netmulticore (de OCamlnet). Il manque clairement pour l'instant des bibliothèques haut niveau pour utiliser ça facilement, mais ça vient (et ça vient d'autant plus que des gens participent).
Je me permets donc de finir cette remarque par une question concrète : as-tu un exemple réel de situation où les différents outils disponibles en OCaml pour le parallélisme ne permettaient pas de résoudre un problème, alors que c'était le cas par exemple des outils Haskell ou .NET ? Je suis intéressé par un exemple que tu as réellement vécu, et pas par un lien vers John Harrop. Je ne dis pas ça pour prouver que ces exemples n'existent pas, je suis persuadé qu'il y en a, mais je pense qu'ils sont en fait assez rares (c'est à dire que certains besoins les rencontrent, mais la plupart non) et qu'il serait donc étrange de changer globalement de langage pour cette seule raison.
De nos jours Haskell est bien plus soutenu par tout le monde qu'OCaml.
C'est vrai que la communauté Haskell est plus active, et surtout que le développement est (un peu) plus communautaire. À mon avis la relative fermeture du développement est le plus gros défaut de OCaml aujourd'hui, plus sérieux que tout le reste que tu as cité.
Ce n'est pas non plus une raison pour dire n'importe quoi. De nombreuses entreprises ou institutions utilisent très sérieusement OCaml, et à ma connaissance plus que pour Haskell. Je pense par exemple au CEA, à Dassault, à la Société Générale, Jane Street que tu as cité et Lexifi, XenSource, Airbus, Microsoft (qui a utilisé OCaml pour faire de la vérification statique de drivers avant de développer F#; je crois qu'une partie de leur code est toujours en OCaml, mais je n'en sais rien)...
Toutes ces informations sont assez facilement trouvables sur le net. Je me demande comment tu as fait pour croire qu'il n'y a qu'une seule entreprise soutenant OCaml.
Par ailleurs, je ne veux pas faire une course, mais quelle entreprise visible "soutient" Haskell, à part les excellents gens de chez Galois ?
Enfin je pense qu'il y a un aspect du langage que tu as oublié de citer: le compilateur produit du code performant de base mais optimise assez peu. Par rapport à Haskell, ça a l'avantage qu'il est assez facile de prévoir les performances du programme (pas de mauvaises surprises en général), mais l'inconvénient que certaines abstractions ont un coût important qui ne disparaît pas, ce qui pousse les utilisateurs à éviter certaines choses pourtant agréables comme les bibliothèques de combinateurs.
.
Je pense que pour apprécier, aussi bien que pour critiquer, un langage, il faut avoir une idée de ce qu'on en attend et de notre besoin dans l'utilisation du langage. Tous les langages ont leurs défauts et OCaml (ou Haskell ou Python ou Perl ou...) n'est pas épargné. L'important c'est de savoir quand ces défauts seront gênants pour l'utilisation qu'on en fait (problème), et quand ça ne l'est pas. Selon mon expérience, la plupart des défauts que tu as cités ne sont un problème que pour un petit nombre d'utilisateurs.
J'ai déjà vu des gens critiquer OCaml pour ses problèmes de parallélisme par exemple, alors qu'ils ne comprenaient même pas quels cas posaient problème, et n'avaient de toute façon pas besoin d'écrire ce genre d'applications. Je crois que quand on est face à ce genre de défauts il faut savoir rester objectif au lieu de choisir le "camp" du langage qui a le moins de détracteurs bruyants.
J'apprécie beaucoup Haskell et OCaml comme langages et je pense qu'ils sont relativement complémentaires. Je comprends très bien que des gens préfèrent utiliser Haskell et je les y encourage, mais je ne suis pas persuadé qu'il y ait des "années de différence" par rapport à OCaml, et je regrette un peu cette formulation négative.
[^] # Re: Perl 6 ?
Posté par gasche . En réponse au journal Sortie de Perl 5.14.0. Évalué à 6.
Ton évaluation du langage est intéressante mais inutilement aigrie. Tous les langages ont leurs défauts, et il est important de bien en être conscient. Mais ce n'est pas une raison pour être inutilement négatif : si tu arrives à convaincre des gens par des arguments non rationnels, tu ne leur rends pas service (puisqu'ils vont faire un autre choix de langage en croyant éviter les problèmes, pour découvrir ensuite qu'ils ont les mêmes problèmes ou d'autres).
La bibliothèque standard est minimaliste. Pas "vide", mais pas suffisante. Comme tu le dis, il existe d'autres bibliothèques de base, dont je ne sais pas si elles "règlent le problème" (elles restent moins étendues par exemple que la bibliothèque standard Python).
Sauf que c'est essentiellement un faux problème : le problème n'est pas la taille de la bibliothèque standard (qui a la plus grosse ?) mais la relative difficulté d'adoption des bibliothèques tierces. Ce qui fait la force de Perl ce n'est pas en soit la bibliothèque standard (qui dans mon souvenir n'a rien d'extraordinaire), mais le CPAN qui permet d'accéder à un énorme écosystème facilement.
Alors oui ça manque pour OCaml (par rapport à Perl, Haskell (cabal), Python etc.) mais c'est un problème de communauté plutôt que de langage. C'est en travail : GODI n'a pas su convaincre, maintenant on parie sur Oasis-DB.
Par ailleurs pour le détail, "@@" et "@$" ne sont sérieusement utilisés que par asmanur à ma connaissance (donc "tout le monde" on repassera), et ta façon de compter est un peu discutable puisque Batteries est une extension conservatrice par dessus Extlib. Tu ne comptes pas "Core" et "Core Extra" comme deux bibliothèques. Enfin je ne comprends pas "ce n'est pas une excuse", peux-tu développer ?
Qu'est-ce que ça veut dire ? De nos jour tout le monde utilise findlib. On juge les langages sur leur "distribution de base" maintenant ? Je pense que tu as mieux à critiquer que les choix de packaging des distributions.
Forcément, quand on part d'un script qui envoie
*.mlà la chaîne de compilation, c'est chiant. Par contre si on fait des choses un poil propres (oui, il faut respecter l'ordre de dépendance), il n'y a pas de problème selon mon expérience personnelle (et encore moins de problèmes depuis ocamlbuild qui, si si, possède une documentation). En particulier j'ai jamais eu à coder un tri topologique (buggué ou non :-) pour ça, et je trouve un peu douteux de projeter vos propres erreurs de conception sur le langage lui-même.http://brion.inria.fr/gallium/index.php/Ocamlbuild
Je ne comprends pas. OCamlbuild n'utilise pas à ma connaissance d'extensions syntaxiques particulières. Tu parles de la difficulté à compiler un projet qui utilise ses propres extensions syntaxiques ? Selon mon expérience (Macaque par exemple) ce n'est encore une fois pas un problème (car contre attention à la combinaison camlp4 + ocamldoc, qui font mauvais ménage ensemble; en règle générale j'évite de préprocesser les .mli pour éviter tout soucis de ce genre).
Ben non, tu peux très bien compiler 3.12 sous windows (la raison pour laquelle personne ne se plaint c'est que la plupart des windows-users font ça; après je comprends que tu trouves ça pas cool pour les débutants). Si tu as envie de proposer un binaire un peu portable en téléchargement, fais-toi plaisir. (Bah oui c'est facile de se plaindre du manque de communauté et de tout faire dans son coin derrière)
Bof. Depuis la 3.12 tu peux te faire tes smooth operators si ça t'amuse, et en vrai (+/) n'est pas spécialement moche (un peu lourd syntaxiquement, mais pas moins par exemple que l'émulation du pattern matching dans un langage qui ne le propose pas).
Bien vu, il y a des problèmes politiques autour de camlp4/5. Je doute que ça ait une grande importance sur le langage OCaml dans son ensemble, et en tout cas ce n'est pas la question du nom du logiciel qui importe.
Marrant de mentionner ça dans une news sur Perl, à ma connaissance ni Perl ni Python ni Ruby n'ont mieux à proposer dans ce domaine. Et dans tous ces langages, comme pour OCaml, on répond en cœur aux gens d'utiliser le multi-processing, et curieusement le net n'est pas noirci de blog "c'est un scandale, les programmes python sont monothreaded". John Harrop est bon pour répandre du FUD quand ça l'arrange, mais je trouve dommage qu'ensuite les gens se focalisent là-dessus.
Il y a effectivement un choix qui a été fait de ne pas favoriser la concurrence par mémoire partagée au sein d'un même processus. Les développeurs OCaml ont évalué que le coût de développement d'un runtime concurrent était bien trop élevé par rapport aux bénéfices que ça représente, en particulier parce que (a l'époque du choix et toujours aujourd'hui) on n'a pas de bons outils de programmation de la mémoire concurrente.
Je ne vais pas écrire un pavé sur le sujet mais je pense honnêtement qu'ils ont fait le bon choix.
En pratique ça handicape certains programmes qui tiennent sur du multi-core (et n'ont pas besoin de passer à l'échelle sur un cluster par exemple) et utilisent beaucoup de partage de donnée (donc ne sont pas trop efficaces en passage de messages à la Erlang).
Ça n'est pas le cas de l'ensemble des programmes concurrents (par exemple le cas classiques des problèmes naturellement parallèles passent très bien avec du multi-processing); en réalité, seule une minorité d'usages est concernée. C'est dommage pour les gens qui veulent programmer précisément ça (et dans ce cas je leur conseille de changer de langage), mais ça n'est pas une raison pour fuir le langage pour tous les usages.
Par ailleurs, si tu veux faire de la programmation concurrente "salement" comme en C, je pense qu'un bon choix aujourd'hui pour OCaml est Netmulticore (de OCamlnet). Il manque clairement pour l'instant des bibliothèques haut niveau pour utiliser ça facilement, mais ça vient (et ça vient d'autant plus que des gens participent).
Je me permets donc de finir cette remarque par une question concrète : as-tu un exemple réel de situation où les différents outils disponibles en OCaml pour le parallélisme ne permettaient pas de résoudre un problème, alors que c'était le cas par exemple des outils Haskell ou .NET ? Je suis intéressé par un exemple que tu as réellement vécu, et pas par un lien vers John Harrop. Je ne dis pas ça pour prouver que ces exemples n'existent pas, je suis persuadé qu'il y en a, mais je pense qu'ils sont en fait assez rares (c'est à dire que certains besoins les rencontrent, mais la plupart non) et qu'il serait donc étrange de changer globalement de langage pour cette seule raison.
C'est vrai que la communauté Haskell est plus active, et surtout que le développement est (un peu) plus communautaire. À mon avis la relative fermeture du développement est le plus gros défaut de OCaml aujourd'hui, plus sérieux que tout le reste que tu as cité.
Ce n'est pas non plus une raison pour dire n'importe quoi. De nombreuses entreprises ou institutions utilisent très sérieusement OCaml, et à ma connaissance plus que pour Haskell. Je pense par exemple au CEA, à Dassault, à la Société Générale, Jane Street que tu as cité et Lexifi, XenSource, Airbus, Microsoft (qui a utilisé OCaml pour faire de la vérification statique de drivers avant de développer F#; je crois qu'une partie de leur code est toujours en OCaml, mais je n'en sais rien)...
Toutes ces informations sont assez facilement trouvables sur le net. Je me demande comment tu as fait pour croire qu'il n'y a qu'une seule entreprise soutenant OCaml.
Par ailleurs, je ne veux pas faire une course, mais quelle entreprise visible "soutient" Haskell, à part les excellents gens de chez Galois ?
Enfin je pense qu'il y a un aspect du langage que tu as oublié de citer: le compilateur produit du code performant de base mais optimise assez peu. Par rapport à Haskell, ça a l'avantage qu'il est assez facile de prévoir les performances du programme (pas de mauvaises surprises en général), mais l'inconvénient que certaines abstractions ont un coût important qui ne disparaît pas, ce qui pousse les utilisateurs à éviter certaines choses pourtant agréables comme les bibliothèques de combinateurs.
.
Je pense que pour apprécier, aussi bien que pour critiquer, un langage, il faut avoir une idée de ce qu'on en attend et de notre besoin dans l'utilisation du langage. Tous les langages ont leurs défauts et OCaml (ou Haskell ou Python ou Perl ou...) n'est pas épargné. L'important c'est de savoir quand ces défauts seront gênants pour l'utilisation qu'on en fait (problème), et quand ça ne l'est pas. Selon mon expérience, la plupart des défauts que tu as cités ne sont un problème que pour un petit nombre d'utilisateurs.
J'ai déjà vu des gens critiquer OCaml pour ses problèmes de parallélisme par exemple, alors qu'ils ne comprenaient même pas quels cas posaient problème, et n'avaient de toute façon pas besoin d'écrire ce genre d'applications. Je crois que quand on est face à ce genre de défauts il faut savoir rester objectif au lieu de choisir le "camp" du langage qui a le moins de détracteurs bruyants.
J'apprécie beaucoup Haskell et OCaml comme langages et je pense qu'ils sont relativement complémentaires. Je comprends très bien que des gens préfèrent utiliser Haskell et je les y encourage, mais je ne suis pas persuadé qu'il y ait des "années de différence" par rapport à OCaml, et je regrette un peu cette formulation négative.