Pourquoi OCaml n'est-il pas plus populaire?
J'ai toujours entendu dire que C est la langue de choix à utiliser pour les systèmes embarqués, ou tout ce qui doit fonctionner à la vitesse maximale. Je n'ai jamais développé un penchant pour le C, principalement parce que je n'aime pas l'arithmétique des pointeurs et que le langage est à peine un échelon au-dessus de l'assembleur.
D'un autre côté, les langages ML sont fonctionnels, les langages récupérés 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 tout le monde pourrait demander pour écrire de haut niveau, concis mais conserve la vitesse nécessaire à l'écriture d'applications hautes performances.
OCaml en particulier peut être utilisé partout où C est traditionnellement utilisé, comme pour les périphériques embarqués, les pilotes graphiques, les systèmes d'exploitation, etc. De toute façon, OCaml aurait dû conquérir le monde à l'heure actuelle, mais presque personne n'avait entendu parler du langage pour l'instant seul utilisé.
C'est une question subjective, mais pourquoi OCaml et ML les autres langages sont-ils restés si obscurs, alors que le C et les autres langages 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 programme. (Il est souvent facile d'identifier pourquoi une langue échoue pour devenir populaire, mais c'est une autre question.)
Avec cet avertissement, voici quelques points qui sont 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 1990. C a une longueur d'avance de 25 ans.
C livré avec Unix, qui était la plus grande "application de tueur" de tous les temps. Pendant longtemps, chaque département CS du monde devait avoir Unix, ce qui signifiait que chaque instructeur et tous ceux qui suivaient un cours CS avaient la possibilité d'être exposés à C. OCaml et ML attendaient toujours leur première application de tueur. (MLdonkey est cool, mais ce n'est pas Unix.)
C remplit si bien sa niche que je doute qu'il n'y aura jamais un autre langage de bas niveau consacré seulement à la programmation des systèmes. (Pour voir les preuves en faveur, lisez l'article de Dennis Ritchie sur l'histoire de C de HOPL II.) On ne sait même pas ce qu'est la niche d'OCaml, et la niche de Standard ML n'est que légèrement plus claire. Caml et ML ont donc pas mal de concurrents, tandis que C a tué son seul concurrent (BLISS).
L'une des grandes forces de C est que son modèle de coût est très prévisible: il est facile de regarder n'importe quel petit fragment de code C qui peut instantanément avoir une idée précise des opérations de la machine qui devront être exécutées pour être exécutées. ce code. Le modèle de coût d'OCaml est beaucoup moins clair, en particulier parce que allocation de mémoire est beaucoup moins explicite, et le coût global d'allocation de mémoire (égal au coût d'allocation plus les coûts encourus lors de la collecte des ordures) dépend des propriétés émergentes comme la durée les objets vivants et quels objets se réfèrent à d'autres objets. Le résultat net est que les performances sont difficiles à prévoir et même difficiles à analyser après coup. (Les outils de profilage de la mémoire d'OCaml ne sont pas ce qu'ils devraient être.) Par conséquent, OCaml n'est pas bon pour les applications où les performances doivent être très prévisibles, comme les 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 seule source et le compilateur est le standard. Et cette norme change à chaque version. Pour les personnes qui apprécient la stabilité et la compatibilité descendante, un langage à source unique peut représenter un risque inacceptable.
N'importe qui avec un cours de compilateur de premier cycle à moitié décent et beaucoup de persévérance peut écrire un compilateur C qui fonctionne plus ou moins et avec des performances adéquates. Pour lancer une implémentation d'OCaml ou de ML, il faut beaucoup plus d'éducation et obtenir des performances comparables à 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 façon de l'exploiter.
Je pense que le problème avec OCaml est qu'il n'est pas trop utile "prêt à l'emploi". La raison éventuelle pour laquelle les gens utilisent une langue est parce qu'elle a les bibliothèques dont ils ont besoin. Avec rien "hors de la boîte", cependant, personne ne va assez loin dans un projet pour se rendre compte qu'il a besoin d'écrire une bibliothèque. Le résultat est un langage sans bibliothèque, ce qui rend difficile l'écriture de "vraies applications".
Je pense que c'est ce dont souffre OCaml - personne ne prend la peine de lancer de "vrais projets" parce que tout ce qu'il y a est un langage de programmation. Oui, je peux ajouter deux et deux et imprimer le résultat. Le résultat est une collection de bibliothèques qui sont pour la plupart des abandons académiques (l'auteur a obtenu son doctorat et est passé à autre chose), ce qui n'est pas trop utile pour les programmeurs pratiquants.
(Je sais qu'il y a du travail en cours pour changer cela, avec des projets comme "Batteries incluses". Revenez ici dans 5 ans, et peut-être OCaml sera plus populaire.)
Il existe quelques exceptions à cette règle. Java a commencé sans bibliothèque, mais Sun a payé les gens pour les écrire tous en interne, puis ils en ont fait tout le marché. Java certification, Java -spécifique matériel, Java livres, Java classes, etc.), puis a 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 l'apprentissage de la programmation.
Le résultat a été la popularité. L'argent peut résoudre beaucoup de problèmes.
Dans l'arène du langage fonctionnel, nous pouvons voir que Haskell devient très populaire. Je pense que la plus grande partie de la popularité est due à des gens comme les dons qui écrivent des bibliothèques utiles et qui ne cessent de commercialiser la langue. Chaque jour, vous voyez quelques articles Haskell sur la programmation de Reddit. Cela reste coincé dans l'esprit des gens jusqu'à ce qu'ils décident finalement: "Je vais essayer Haskell." Lorsqu'ils le font, ils voient des choses utiles comme les frameworks Web, les bases de données d'objets, les bibliothèques OpenGL et les bibliothèques de traitement XML. Cela signifie qu'ils peuvent réellement faire quelque chose d'utile "dès maintenant". Donc, entre le potentiel d'être productif et d'en entendre beaucoup parler, Haskell a gagné en popularité.
CL a plusieurs 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 est toujours 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 rivalise pour la même base d'utilisateurs).
Enfin, certaines personnes n'obtiendront jamais de programmation, donc briser leur modèle mental (les variables sont des cases 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 important de la population de programmation, ce qui limite encore davantage la base d'utilisateurs possible de langages abstraits comme 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 bien, mais ne fonctionne pas sur 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 pour cela.
Son système de typage est parfois un peu trop fort. Pour quelqu'un qui ne comprend pas le fonctionnement de l'inférence de type ou le 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 blocage majeur.
La bibliothèque standard peut parfois avoir une sensation incohérente.
Le modèle d'objet semble quelque peu cloué 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 reviennent à dire 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'aiment ou non.
Je pense que son héritage le plus important sera qu'il, avec d'autres dialectes ML, a eu une très forte influence sur d'autres langages fonctionnels. La plupart des langages fonctionnels de la génération actuelle prennent les meilleurs éléments des dialectes ML et affinent certains des désagréments.
Les systèmes embarqués nécessitent souvent deux choses: la vitesse et le déterminisme. OCaml peut fournir de la vitesse, mais le fait qu'il ait un garbage collector le rend intrinsèquement non déterministe, et pour un système en temps réel, ce n'est pas simple.
C'est un peu une comparaison pommes-oranges. OCaml est un langage assez jeune [1] et il n'y a jamais eu d'effort sérieux et soutenu pour le pousser dans le courant dominant (à l'exception du travail actuel de Microsoft avec F #). Contrairement à C, ce n'est pas le 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é à devenir une plate-forme informatique de nouvelle génération. Contrairement à Perl, Python et Ruby, il ne s'est pas installé dans un créneau influent très médiatisé (c'est-à-dire que son créneau est le langage de programmation et la recherche de raisonnement automatisée - pas très médiatisé par rapport au développement Web). Par conséquent, ce n'est pas super populaire.
[1] En toute justice, le langage ML original existe depuis les années 70. Mais OCaml n'est apparu qu'en 1996 et n'a pas hérité des bibliothèques Standard ML. C'est, en termes pratiques, 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 est fourni avec OCaml aujourd'hui) qui facilite le développement d'applications. Il y a plusieurs tentatives pour résoudre le problème, mais jetez un œil à Python ou Ruby pour voir ce qui manque. OCaml est un excellent langage si vous voulez résoudre un problème algorithmique qui ne dépend pas trop de l'interaction avec des modules standard avancés comme 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 crois qu'une partie du problème est de savoir comment les modules sont mappés aux fichiers par OCaml: conceptuellement, tous les fichiers * .ml vivent 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 des hiérarchies de répertoires dans des hiérarchies de modules, je verrais une meilleure chance qu'une bibliothèque standard évolue. Cela nécessiterait cependant des efforts considérables de la part des développeurs du compilateur principal. (Je suis conscient de l'empaquetage 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 sûr de dire que tout le code de la bibliothèque doit être recompilé après une 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 trucs théoriques étranges et déroutants sur les types. C'est ce qui m'est arrivé.
On m'a montré ML et Smalltalk à la même époque. Smalltalk juste regardé sacrément cool, et on comprenait immédiatement à quoi servait OO et comment faire de jolies choses interactives dans cet environnement. ML concernait les choses mathématiques abstraites cela ne semblait pas pertinent pour ce que je voulais faire. Et contrairement à C, ne m'avait pas promis de me laisser écrire des jeux rapides sur des micros 16 bits.
C'est, bien sûr, profondément injuste et subjectif. Mais c'est probablement la vraie histoire pour la plupart des gens.
Ces jours-ci, je suppose que la question serait: maintenant je sens que j'ai besoin de connaître ces trucs théoriques étranges et déroutants sur les types, pourquoi devrais-je choisir ML plutôt que Haskell ou Erlang?
Je crois que le principal problème est le manque d'une véritable bibliothèque standard. D'où le projet OCaml Batteries Inclus , qui devrait améliorer largement la situation. Il est censé entrer dans la phase bêta dans quelques jours, vous devrez donc poser à nouveau la question dans un an environ.
Je conviens que la mauvaise prise en charge de Windows, une courbe d'apprentissage abrupte et une bibliothèque standard mince ont tous étouffé l'adoption d'OCaml dans le passé, mais j'ajouterais qu'il y a eu un énorme manque d'informations de didacticiel (par exemple des livres) sur OCaml par rapport aux langages traditionnels comme Java.
En outre, les types de personnes qui connaissent des langues comme OCaml sont extrêmement hétérogènes. Parmi les programmeurs Web, peut-être 1 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 connaissais parlaient couramment OCaml. En effet, j'étais l'un des derniers parmi mes amis à avoir appris OCaml. Nous avons même exécuté OCaml sur notre supercalculateur 256 CPU ...
Je dois également mentionner que ces problèmes sont rapidement traités. OCaml s'est réinventé récemment pour la programmation Web avec des projets comme Ocsigen et a déjà au moins deux grandes réussites industrielles dans ce contexte. Il y a un autre nouveau livre sur OCaml maintenant. La communauté collabore sur une bibliothèque standard complète appelée "batteries incluses" qui vient d'entrer en version bêta et qui a l'air fantastique. Une version multicœur conviviale d'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 OCaml de code natif chargées dynamiquement.
Je pense qu'une partie du problème est que la programmation fonctionnelle n'est tout simplement pas un moyen naturel pour la plupart des gens de penser (et je dis cela comme quelqu'un qui a un grand intérêt et une appréciation pour la programmation fonctionnelle). Ceci est aggravé par le fait que la grande majorité des programmeurs ont commencé aujourd'hui à apprendre la programmation procédurale (les langages les plus populaires OOP sont toujours procéduraux dans l'âme) et qu'il est donc difficile de s'adapter initialement aux langages fonctionnels.
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'étais parvenu à la conclusion (légèrement naïve) que tous les langages de programmation étaient fondamentalement les mêmes avec une syntaxe légèrement différente. Notre cours d'introduction à la programmation utilisait le ML, ce qui m'a rapidement désabusé de cette notion. 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 professeur de ML a souvent affirmé que l'expression récursive des problèmes était plus "naturelle" et plus facile que l'utilisation de 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 fournir des solutions particulièrement élégantes et concises aux problèmes, mais je trouve toujours que c'est une façon peu naturelle de penser aux problèmes. Peut-être que si vous avez une formation mathématique très solide, 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. Étant donné la centralité des fonctions récursives dans le paradigme de programmation fonctionnelle, je pense que cela peut également être une raison de la moindre popularité des langages fonctionnels.
Il existe également un effet de rétroaction sur la popularité de la langue. Quand j'ai commencé à programmer, je voulais savoir comment programmer des effets graphiques et des jeux. Après avoir appris un peu de BBC BASIC et plus tard QBASIC, j'ai naturellement étudié quels étaient les langages les plus courants utilisés par la scène de démonstration et les programmeurs de jeux et j'ai commencé à apprendre C++ et l'assemblage x86. De nos jours, certains nouveaux programmeurs peuvent vouloir savoir comment produire des applications Web et vont donc se diriger 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 où la réponse à ' quelle est la meilleure langue pour apprendre à programmer quelque chose comme X 'sera' Ocaml '.
De nombreuses raisons pratiques données pour la popularité limitée d'Ocaml (manque de bibliothèques matures, débogueurs, IDE, etc.) sont traitées par 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 la popularité de la programmation fonctionnelle.
Je crois que le cœur du problème est la politique. Les développeurs d'Ocaml sont principalement intéressés par la recherche et n'ont pas les ressources 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, le résultat est que plusieurs tentatives pour résoudre ce problème reposaient sur une coopération inexistante et le financement de bibliothèques tierces et 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 j'ai une règle simple: minimiser la dépendance au code tiers. Lorsqu'un élément tiers est utile, si possible, incorporez les codes source directement dans le package. Par exemple, OCS Scheme et Dypgen sont des parties essentielles de l'analyseur Felix, ils sont donc copiés dans nos sources afin que nous ayons un certain contrôle sur eux. Le contrôle est quelque peu illusoire (puisque Dypgen au moins est si complexe qu'il est peu probable que nous puissions le maintenir, mais au moins nous en avons une copie qui, selon nous, fonctionne) :)
Je n'utiliserai pas de piles parce que la licence est restrictive, donc je ne peux pas copier la source, et je n'ai aucune confiance dans sa viabilité à long terme en tant que produit autonome: la seule façon dont je pourrais l'utiliser est si elle était intégré 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 qui ne fait pas partie de la norme, elle bénéficie d'un tel support communautaire et elle est en fait parfaitement synchronisée avec le processus de développement des normes. Les idées développées et testées dans Boost deviennent le type de pratique existante qui peut être normalisée, et le processus de normalisation est suffisamment ouvert pour permettre la participation de la communauté.
Ocaml a obtenu la popularité qu'il a réellement parce que c'est un produit si fin, mais cela ne suffit pas pour lui permettre de devenir une langue courante. Java est crud, il a été rendu populaire avec des milliards de dollars de marketing et de développement de bibliothèque, mais a finalement dû être rendu public pour survivre.
J'ai apprécié le codage en ML et C pour une grande variété de projets. La chose qui m'empêche d'utiliser ML dans les 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 de la formation nécessaires pour les utiliser correctement (et les risques qui en découlent) ont été un obstacle à leur utilisation.
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 façon fonctionnelle de faire les choses (cela vient de la session F # des techdays 2009 où environ 10 personnes ont déclaré connaître la programmation fonctionnelle parmi près de 100 personnes).
J'ai commencé OCAML cette année, je n'ai jamais mis la main sur la programmation fonctionnelle, mais maintenant j'apprends vraiment toujours de nouvelles choses à partir d'OCAML et la façon fonctionnelle de résoudre les problèmes, (mais je ne peux pas dire que j'abandonnerai C # utiliser OCAML :)).
À mon humble avis, je pense qu'un gros problème d'OCaml ce n'est pas dans le langage (c'est super) 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 d'obtenir une contribution avec une telle licence.
Si vous vérifiiez le Shootout de langue ( http://shootout.alioth.debian.org/ ) il y a environ 7 à 8 ans, OCaml était juste derrière C et C++ pour la vitesse d'exécution. Pendant ce temps, d'autres langages (comme Haskell) ont obtenu un meilleur compilateur (en raison d'une approche communautaire différente, je suppose) et maintenant la vitesse d'exécution d'OCaml n'est plus aussi grande que par le passé.
En peu de temps, je n'utiliserais pas OCaml, car je ne pense pas que ça va mieux sans que de très bons pirates créent un compilateur OCaml qui a une licence vraiment open source et une communauté avec un comportement vraiment open source.
Eh bien, peut-être que F # devient populaire.
Cela n'aide pas que c-> ocaml soit une plus grande transition mentale que c-> LISP. J'ai envisagé ocaml plusieurs fois, et j'ai toujours trouvé que le rapport coût/avantage n'était tout simplement pas là pour moi, alors mettez-le de côté. Ce ne sont pas les constructions qui ont fait que ça a l'air difficile, celles-ci ont vraiment l'air vraiment soignées. Il essayait d'apprendre une signification entièrement différente pour "!". LISP semble au moins si différent qu'il est facile d'éviter de mal interpréter de petits morceaux comme c.
Si vous voulez une langue à utiliser dans les systèmes embarqués en temps réel, vous avez besoin de pointeurs et vous ne pouvez pas 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 considèrent OCaml comme 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 ...
quand je l'ai appris, le principal problème était que les messages d'erreur ne sont pas vraiment clairs ... donc par exemple, au début je ne savais pas trop quand mettre ';' et c'était vraiment difficile de trouver qu'en fait le; était mal placé ...