Pourquoi OCaml n'est-il pas plus populaire?

J'ai toujours entendu dire que C était le langage de choix à utiliser pour les systèmes embarqués, ou pour tout ce qui doit fonctionner à une vitesse maximale. Je n'ai jamais développé d'attrait pour C, principalement parce que je n'aime pas l'arithmétique des pointeurs et que le langage est à peine un assemblage au-dessus de l'assembleur.

Par contre, les langages ML sont fonctionnels et OCaml a même un modèle objet, mais ils ont la réputation d’être aussi rapides que C. Les langages ML ont l’abstraction que quiconque pourrait demander d’écrire de haut niveau et de manière concise. code, mais conserve la vitesse nécessaire à l’écriture d’applications hautes performances.

OCaml en particulier peut être utilisé partout où C est traditionnellement utilisé, par exemple pour les périphériques intégrés, les pilotes graphiques, les systèmes d'exploitation, etc. Par tous les droits, OCaml aurait déjà dû conquérir le monde, mais personne n'a encore entendu parler de cette langue utilisé.

C'est une question subjective, mais pourquoi OCaml et ML sont-ils restés si obscurs alors que C et d'autres langues sont devenus populaires?

La première réponse est que personne ne sait vraiment pourquoi les langues deviennent populaires et quiconque dit le contraire est trompé ou a un agenda. (Il est souvent facile d'identifier pourquoi une langue ne devient pas populaire, mais c'est une autre question.)

Avec cet avis de non-responsabilité, voici quelques points suggestifs, les plus importants en premier:

• Le premier compilateur C mature est apparu en 1974; Le premier compilateur OCaml mature est apparu à la fin des années 90. C a une avance de 25 ans.

• C livré avec Unix, qui était la plus grande "application tueur" de tous les temps. Pendant longtemps, tous les départements CS du monde ont dû disposer d'Unix, ce qui signifie que chaque instructeur et chaque participant à un cours CS a eu l'occasion d'être exposé à C. OCaml et ML attendent toujours leur première application tueur. (MLdonkey est cool, mais ce n'est pas Unix.)

• C remplit si bien son créneau que je doute qu’il n’y ait jamais un autre langage de bas niveau consacré uniquement à la programmation système. (Pour consulter les éléments de preuve favorables, lisez l'article de Dennis Ritchie sur l'histoire de C issu de HOPL II.) On ne sait même pas quel est le créneau d'OCaml et le créneau de Standard ML n'est qu'un peu plus clair. Caml et ML ont donc pas mal de concurrents alors que C a tué son seul concurrent (BLISS).

• L'un des grands avantages du C réside dans le fait que son modèle de coût est très prévisible: il est facile de regarder tout petit fragment de code C qui permet d'avoir une idée précise des opérations à exécuter sur la machine pour exécuter ce code. Le modèle de coût d'OCaml est beaucoup moins clair, notamment parce que l' allocation de mémoireest beaucoup moins explicite, et le coût global de l'allocation de mémoire (égal au coût de l'allocation plus les coûts encourus lors de la récupération de place) dépend de propriétés émergentes telles que la durée de vie des objets et les objets faisant référence à d'autres objets. Le résultat final est que les performances sont difficiles à prévoir et même à analyser après coup. (Les outils de profilage de la mémoire d'OCaml ne sont pas ce qu'ils devraient être.) En conséquence, OCaml n'est pas adapté aux applications où les performances doivent être très prévisibles, à l'instar des systèmes embarqués.

• C est un langage avec un standard et de nombreux compilateurs. OCaml est un artefact logiciel: le seul compilateur provient d'une source unique, et le compilateur est la norme. Et cette norme change avec chaque version. Pour les personnes qui attachent de la valeur à la stabilité et à la compatibilité ascendante, un langage à source unique peut représenter un risque inacceptable.

• Toute personne ayant suivi un cours de compilateur de premier cycle à mi-parcours décent et faisant preuve de beaucoup de persévérance peut écrire un compilateur C qui fonctionne plus ou moins et avec des performances suffisantes. Obtenir une implémentation d'OCaml ou de ML nécessite plus de formation et une performance comparable à celle d'un compilateur C naïf nécessite beaucoup plus de travail. Cela signifie qu'il y a beaucoup moins d'amateurs à jouer avec des langages comme OCaml. Il est donc plus difficile pour la communauté de développer une compréhension approfondie de la manière de l'exploiter.

Je pense que le problème avec OCaml est qu’il n’est pas très utile "out of the box". La raison éventuelle pour laquelle les gens utilisent un langage est parce qu'il a des bibliothèques dont ils ont besoin. Avec rien "out of the box", cependant, personne ne va assez loin dans un projet pour se rendre compte qu'ils ont besoin d'écrire une bibliothèque. Le résultat est un langage sans bibliothèques, ce qui rend difficile l'écriture de "vraies applications".

Je pense que c’est ce dont souffre OCaml - personne ne l’ennuie à démarrer de "vrais projets", car il n’ya qu’un langage de programmation. Oui, je peux en ajouter deux et deux et imprimer le résultat. Le résultat est une collection de bibliothèques qui sont principalement des logiciels abandonnés académiques (l'auteur a obtenu son doctorat et est passé au suivant), ce qui n'est pas très utile pour les programmeurs.

(Je sais que des travaux sont en cours pour changer cela, avec des projets tels que "Batteries Included". Revenez ici dans 5 ans et peut-être qu'OCaml sera plus populaire.)

Il y a quelques exceptions à cette règle. Java a commencé avec pas de bibliothèques, mais Sun a payé les gens pour les écrire tous en interne, puis ils en ont vendu l'enfer. Certification Java, matériel spécifique à Java, livres Java, classes Java, etc. Puis même convaincu la plupart des universités de l’enseigner exclusivement, même si ce n’est pas un très bon langage à utiliser pour apprendre la programmation.

Le résultat était la popularité. L'argent peut résoudre beaucoup de problèmes.

Dans le domaine des langages fonctionnels, nous pouvons constater que Haskell est en train de devenir très populaire. Je pense que la plus grande partie de la popularité est due à des gens comme des artistes qui écrivent des bibliothèques utiles et ne cessent jamais de commercialiser le langage. Chaque jour, vous voyez quelques articles de Haskell sur la programmation Reddit. Cela le garde dans l’esprit des gens jusqu’à ce qu’ils décident enfin: «Je vais essayer Haskell». Lorsqu'ils le font, ils voient des éléments utiles tels que des infrastructures Web, des bases de données objet, des bibliothèques OpenGL et des bibliothèques de traitement XML. Cela signifie qu'ils peuvent réellement faire quelque chose d'utile "Right Now". Donc, entre le potentiel de productivité et l’écoute fréquente, Haskell a acquis une grande popularité.

CL a beaucoup des mêmes bibliothèques que Haskell et est presque aussi rapide, mais personne n'en parle, donc il se sent "mort". En effet, #lisp est beaucoup plus silencieux que #haskell, mais Lisp reste un langage très productif avec beaucoup de bibliothèques. Aucune autre langue n'a SLIME. Mais le marketing est très important et Haskell le fait mieux que Lisp ou OCaml (et est en concurrence avec la même base d’utilisateurs).

Enfin, certaines personnes ne "connaîtront" jamais la programmation, alors casser leur modèle mental (les variables sont des boîtes avec des valeurs, le code s'exécute de haut en bas) garantira qu'elles n'utilisent pas votre langage. Ce type de programmeur représente un pourcentage élevé de la population de programmation, ce qui limite d'autant la base d'utilisateurs possibles de langages abstraits tels que Lisp, Haskell et OCaml.

J'aime OCaml beaucoup comme langue. MAIS...

Le support d'outils n'est tout simplement pas là. Le débogueur ne fonctionne que correctement mais ne fonctionne pas sous Windows (la dernière fois que j'ai vérifié) et il n'y a tout simplement pas beaucoup d'outils de développement disponibles.

Son système de types est parfois un peu trop fort. Pour quelqu'un qui ne comprend pas le fonctionnement de l'inférence de type ou du système de type ML en général, le fait qu'il ne puisse pas ajouter un entier à un flottant est tout de suite un inconvénient majeur.

La bibliothèque standard peut parfois avoir une apparence incohérente.

Le modèle objet semble quelque peu intégré et la bibliothèque standard l'utilise à peine, optant plutôt pour des bibliothèques basées sur des modules.

Il y a beaucoup d'autres choses qui font que la langue ne se sent pas "polie" et qui éloigne les gens pendant la période très critique où ils choisissent une langue et essaient de décider s'ils l'apprécient ou non.

Je pense que son héritage le plus important sera qu’il a, avec d’autres dialectes du ML, exercé une très forte influence sur d’autres langages fonctionnels. La plupart des langages fonctionnels de la génération actuelle utilisent les meilleurs éléments des dialectes ML et affinent certains inconvénients.

Les systèmes embarqués exigent souvent deux choses: la rapidité et le déterminisme. OCaml peut fournir de la vitesse, mais le fait qu’il dispose d’un ramasse-miettes le rend intrinsèquement non déterministe, ce qui ne convient pas à un système temps réel.

Ceci est un peu une comparaison de pommes à oranges. OCaml est une langue assez jeune [1] et aucun effort sérieux et soutenu n'a été déployé pour l'intégrer (sauf le travail actuel de Microsoft avec F #). Contrairement à C, ce n'est pas la lingua franca du système d'exploitation d'entreprise le plus largement pris en charge et imité (c'est-à-dire UNIX). Contrairement à Java, aucune grande entreprise ne l'a poussée à devenir une plate-forme informatique de nouvelle génération. Contrairement à Perl, Python et Ruby, il ne s’est pas imposé dans un créneau influent (son créneau étant le langage de programmation et la recherche de raisonnement automatique, peu visible par rapport au développement Web). Par conséquent, ce n'est pas super populaire.

[1] En toute justice, le langage original du ML existe depuis les années 70. Mais OCaml n’est pas apparu avant 1996 et n’a pas hérité des bibliothèques Standard ML. En pratique, il s’agit d’un langage plus jeune que C, C ++, Java, Python, Haskell ou même Ruby.

La communauté OCaml n'a pas réussi à développer une bibliothèque standard large et fiable (au-delà de ce qui existe aujourd'hui avec OCaml) facilitant le développement d'applications. Il y a plusieurs tentatives pour résoudre le problème, mais jetez simplement un coup d'œil à Python ou à Ruby pour voir ce qui manque. OCaml est un excellent langage si vous souhaitez résoudre un problème algorithmique qui ne dépend pas trop d'interaction avec des modules standard avancés tels que XML, la mise en réseau, le calcul de données, etc., que vous préférez ne pas implémenter vous-même.

Je pense que le problème réside en partie dans la façon dont les modules sont mappés dans les fichiers par OCaml: conceptuellement, tous les fichiers * .ml résident dans le même espace de noms et les répertoires n’ont aucune signification. Cela rend difficile pour une communauté de faire évoluer une bibliothèque. Si le compilateur mappait les hiérarchies de répertoires en hiérarchies de modules, j'aurais plus de chances qu'une bibliothèque standard évolue. Cela nécessiterait toutefois des efforts considérables de la part des développeurs du compilateur principal. (Je suis au courant de l’emballage des modules mais je pense que c’est un kludge.)

Un autre problème de bibliothèque est la compatibilité binaire entre les versions du compilateur. Il est assez prudent de dire que tout le code de la bibliothèque doit être recompilé après la mise à niveau du compilateur. Cela rend difficile la fourniture de versions binaires de modules ou de bibliothèques.

Probablement parce que trop de gens ont appris le ML dans le cadre d'une introduction à des notions théoriques étranges et déroutantes sur les types. C'est ce qui m'est arrivé.

On m'a montré ML et Smalltalk à peu près au même moment. Smalltalk avait juste l' air sacrément cool, et on comprenait tout de suite à quoi servait OO et comment créer de jolis objets interactifs dans cet environnement. ML concernait des choses mathématiques abstraites qui ne semblaient pas pertinentes pour ce que je voulais faire. Et contrairement à C, ne m'a pas promis de me laisser écrire des jeux rapides sur des micros 16 bits.

Ceci est, bien sûr, profondément injuste et subjectif. Mais c'est probablement l'histoire vraie pour la plupart des gens.

Ces jours-ci, je suppose que la question serait la suivante: maintenant, j'estime avoir besoin de connaître cette théorie théorique étrange et déroutante sur les types, pourquoi devrais-je choisir ML plutôt que Haskell ou Erlang?

Je crois que le problème principal est l’absence d’une véritable bibliothèque standard. D'où le projet OCaml Batteries Inclus , qui devrait grandement améliorer la situation. Il est censé entrer en phase bêta dans quelques jours, vous devrez donc poser la question de nouveau dans un an environ.

Je conviens que le faible support de Windows, une courbe d’apprentissage abrupte et une bibliothèque standard mince ont tous étouffé la participation de OCaml dans le passé, mais j’ajouterais qu’il ya eu un manque énorme d’informations de tutoriel (par exemple, des livres) sur OCaml par rapport aux langages classiques tels que Java.

En outre, les types de personnes connaissant des langues telles que OCaml sont extrêmement hétérogènes. Parmi les programmeurs Web, peut-être qu'un sur 1 000 aura entendu parler d'OCaml. Parmi les personnes qui font de l'informatique scientifique à l'Université de Cambridge, environ 90% des personnes que je connais connaissaient bien OCaml. En effet, j'ai été l'un des derniers parmi mes amis à apprendre OCaml. Nous avons même lancé OCaml sur notre supercalculateur à 256 CPU ...

Je devrais également mentionner que ces problèmes sont rapidement résolus. OCaml s'est récemment réinventé dans la programmation Web avec des projets comme Ocsigen et a déjà au moins deux grandes réussites industrielles dans ce contexte. Un autre nouveau livre sur OCaml est sorti. La communauté collabore à une bibliothèque standard complète appelée "batteries incluses", qui vient de passer à la version bêta et qui a un look fantastique. Une version multicoeur de OCaml est sur le point d'être publiée. La dernière version d'OCaml comprend également de nombreuses nouvelles fonctionnalités telles que les modèles paresseux et les bibliothèques de code natif OCaml chargées dynamiquement.

Je pense qu'une partie du problème réside dans le fait que la programmation fonctionnelle n'est tout simplement pas un moyen naturel de penser (et je le dis en tant que personne qui a un grand intérêt pour la programmation fonctionnelle et qui l'apprécie). À cela s’ajoute le fait que la grande majorité des programmeurs ont aujourd’hui commencé à apprendre la programmation procédurale (les langages POO les plus populaires sont toujours centrés sur la procédure) et qu’il est donc difficile de s’adapter aux langages fonctionnels au départ.

Quand j'ai commencé l'université, je connaissais déjà une quantité raisonnable de BASIC, C ++ et Java et un peu de langage d'assemblage Pascal et x86. J'étais loin d'être un expert, mais j'avais atteint la conclusion (légèrement naïve) selon laquelle tous les langages de programmation étaient fondamentalement les mêmes avec une syntaxe légèrement différente. Notre introduction au cours de programmation utilisait le langage ML, ce qui m'a rapidement fait perdre conscience de cette notion. J'ai eu du mal à comprendre l'esprit de ML à ce stade de ma carrière en programmation et je ne voyais pas vraiment l'intérêt de la programmation fonctionnelle. Je pense qu'il faut un peu plus d'expérience avec certains des problèmes de programmation procédurale pour vraiment apprécier les avantages d'une approche fonctionnelle.

Notre conférencier principal a souvent affirmé qu'il était plus naturel et plus simple d'exprimer des problèmes de manière récursive que d'utiliser des boucles ou d'autres concepts procéduraux. Je n'ai jamais été convaincu par cette affirmation et je ne l'achète toujours pas. Les fonctions récursives peuvent parfois apporter des solutions particulièrement élégantes et concises aux problèmes, mais je trouve tout de même une façon non naturelle de penser aux problèmes. Peut-être que si vous avez un très bon bagage mathématique, cela semble plus intuitif, mais je ne pense pas qu'il soit facile pour la plupart des gens de penser de manière récursive. Compte tenu de la centralité des fonctions récursives dans le paradigme de la programmation fonctionnelle, je pense que cela peut également expliquer la moindre popularité des langages fonctionnels.

La popularité de la langue a également un effet de rétroaction. Quand j'ai commencé à programmer, je voulais savoir comment programmer des effets graphiques et des jeux. Après avoir appris un peu BBC BASIC, puis QBASIC, j’ai naturellement cherché à savoir quels étaient les langages les plus couramment utilisés par les développeurs et les programmeurs de jeux. De nos jours, certains nouveaux programmeurs voudront peut-être savoir comment créer des applications Web et s’orienteront donc vers l’apprentissage de PHP, Ruby ou C #. Il y a très peu de domaines d'application pour les programmeurs débutants motivés pour lesquels la réponse à la question «Quel est le meilleur langage à apprendre pour programmer quelque chose comme X» sera «Ocaml».

De nombreuses raisons pratiques expliquant la popularité limitée d’Ocaml (manque de bibliothèques matures, de débogueurs, d’IDE, etc.) sont abordées dans le support officiel de Microsoft pour F # en tant que langage .NET de première classe. Il sera intéressant de voir si F # contribue à accroître le niveau de popularité de la programmation fonctionnelle.

Je crois que le coeur du problème est la politique. Les développeurs d’Ocaml sont principalement intéressés par la recherche et ne disposent pas des ressources nécessaires pour fournir et maintenir une bibliothèque riche. Cependant, ils ne veulent pas non plus laisser le contrôle du produit à la communauté qui dispose de ces ressources. En conséquence, plusieurs tentatives de résolution de ce problème reposent sur une coopération et un financement inexistants de bibliothèques tierces. Ces tentatives ont échoué. Les batteries échoueront pour la même raison, à moins que les développeurs d’Ocaml ne changent d’attitude.

J'utilise Ocaml pour développer mon produit et ma règle est simple: minimiser la dépendance au code tiers. Lorsqu'un élément tiers est utile, dans la mesure du possible, incorporez les codes source directement dans le package. Par exemple, OCS Scheme et Dypgen sont des composants essentiels de l’analyseur Felix. Ils sont donc copiés dans nos sources afin que nous puissions les contrôler. Le contrôle est quelque peu illusoire (du moins Dypgen est si complexe qu'il est peu probable que nous puissions le conserver, mais au moins nous en avons une copie qui, nous le pensons, fonctionne :)

Je n'utiliserai pas de piles car la licence est restrictive. Je ne peux donc pas copier la source. Je ne crois pas en la possibilité à long terme de l'utiliser comme produit autonome: le seul moyen de l'utiliser est le cas. incorporé directement dans la distribution standard d’Ocaml.

Dans le monde C ++, je pourrais simplement envisager d’utiliser Boost: bien qu’il s’agisse d’une bibliothèque tierce ne faisant pas partie de la norme, elle bénéficie d’un soutien important de la part de la communauté et est parfaitement synchronisée avec le processus de développement de normes. Les idées développées et testées dans Boost deviennent le type de pratique existante qui peut être normalisé, et le processus de normalisation est suffisamment ouvert pour permettre la participation de la communauté.

Ocaml a obtenu la popularité dont il jouit réellement car il s'agit d'un produit de qualité, mais cela ne suffit pas pour lui permettre de devenir une langue dominante. Java est crud, il a été rendu populaire avec des milliards de dollars de marketing et de développement de bibliothèques, mais a finalement dû être rendu public pour que la communauté puisse survivre.

J'ai aimé coder à la fois en ML et en C pour une grande variété de projets. La chose qui m'empêche d'utiliser ML dans des projets intégrés (dont la plupart ont des contraintes de temps réel et nécessitent une validation) est la récupération de place.

Il existe des recherches sur la gestion de la mémoire avec les régions (voir MLKit ), mais la complexité des implémentations et la formation requise pour les utiliser correctement (et les risques qui y sont associés ) ont été un obstacle à leur utilisation.

IMHO, je pense qu'un gros problème d'OCaml n'est pas dans la langue (c'est génial) mais dans les gens qui le développent et par conséquent, sa licence:

http://caml.inria.fr/ocaml/license.fr.html

Ils utilisent la licence Q Public pour le compilateur! Oui, la licence ex-Trolltech utilisée pour les bibliothèques Qt! Oubliez toute contribution avec une telle licence.

Si vous vérifiiez Language Shootout ( http://shootout.alioth.debian.org/ ) il y a environ 7 à 8 ans, OCaml était juste derrière C et C ++ pour la rapidité d'exécution. Dans le même temps, d'autres langages (comme Haskell) ont eu un meilleur compilateur (grâce à une approche de communauté différente, je suppose) et maintenant la vitesse d'exécution d'OCaml n'est pas aussi grande que par le passé.

Bientôt, je n’utiliserais pas OCaml, car je ne vois pas où cela irait mieux sans de très bons pirates informatiques qui créeraient un compilateur OCaml doté d’une licence VRAIMENT open source et d’une communauté ayant un comportement VRAI open source.

Eh bien, s’il s’agit d’argent, comme le dit @jrockway, nous verrons si F # gagnera en popularité comme java ou C #.

Pour moi, je suppose que les développeurs ne se sentent pas à l'aise avec la manière fonctionnelle de faire les choses (cela vient de la session F # de techdays 2009 où environ 10 personnes ont déclaré connaître la programmation fonctionnelle parmi près de 100 personnes).

J'ai démarré OCAML cette année, je ne me suis jamais mis à la tâche avec la programmation fonctionnelle, mais maintenant, j'apprends toujours de nouvelles choses, grâce à OCAML et à la manière fonctionnelle de résoudre les problèmes (mais je ne peux pas dire que j'abandonnerai le C #. utiliser OCAML :)).

Eh bien, peut-être que F # devient populaire.

Cela n'aide pas que c-> ocaml soit une transition mentale plus grande que c-> lisp. J'ai examiné ocaml à plusieurs reprises et j'ai toujours constaté que le rapport coût / bénéfice n'existait tout simplement pas pour moi, alors remettez-le de côté. Ce ne sont pas les concepts qui ont rendu cela dur, mais ceux-ci avaient l'air vraiment super. Il essayait d'apprendre un sens totalement différent pour "!". Lisp a au moins l'air si différent qu'il est facile d'éviter de mal interpréter de petits morceaux comme c.

Si vous souhaitez qu'une langue soit utilisée dans des systèmes embarqués temps réel, vous avez besoin de pointeurs et vous ne pouvez vous permettre un GC.

Je pense que la raison principale est que trop peu de développeurs connaissent OCaml.

Et quand je parle à d’autres développeurs (ceux qui ont entendu parler d’Ocaml), j’ai toujours l’impression qu’ils voient en OCaml un langage "uniquement éducatif" ... triste mais vrai

J'aime beaucoup O'caml ... J'ai implémenté un tas de choses en l'utilisant, compilateur, interprètes, système pour communiquer avec C ...

Lorsque je l’ai appris, le principal problème était que les messages d’erreur ne sont pas vraiment clairs ... Ainsi, au début, je ne savais pas vraiment quand mettre ";" et c'était vraiment difficile de trouver cela réellement le; était égaré ...