Pourquoi OCaml n'est-il pas plus populaire?


86

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?

Réponses:


82

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.


5
OCaml est un dialecte ML relativement récent, né à peu près au même moment que Java. Cependant, ML remonte à 1973 avec le premier dialecte majeur, SML étant en cours de développement en 1978. Les dialectes ML ont trouvé une niche dans la démonstration de théorèmes et la recherche, mais sont depuis devenus le standard de l’industrie dans les institutions financières.
Juliette

15
Je n'appellerais pas ML la "norme de l'industrie dans les institutions financières". (Et je ne dis pas cela parce que j'écris des applications financières en Haskell. :-)) Dans le monde commercial, alors que l'industrie financière a probablement eu une plus grande adoption de la programmation fonctionnelle que toute autre, elle n'est pas encore largement utilisée. : dans mon expérience, C ++ et Java dominent. Des entreprises comme Jane Street sont l'exception et non la règle.

8
Perl est un "artefact logiciel" - la seule définition de Perl est "le langage que Perl (1) interprète" - et pourtant, il est plutôt populaire. Python et Ruby étaient des "artefacts logiciels" pendant longtemps.

5
@Chris: IMO c'est l'une des raisons pour lesquelles Perl perd son opinion.
Norman Ramsey

5
En ce qui concerne la prévisibilité, je pense qu'OCaml bat réellement le C dans ce domaine, avec le niveau d'optimisation attendu des compilateurs C et la fragilité de bon nombre de ces optimisations. Le compilateur d'OCaml est très littéral sur ce en quoi il compile votre code.

63

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.


45
C'était peut-être vrai il y a 10 ans. Faites-moi savoir quand je pourrai "installer la cabale" une bibliothèque OCaml. Quoi qu'il en soit, ce n'est pas parce que j'ai dit quelque chose de mauvais à propos de vos langues préférées que vous devez cesser de l'utiliser. Donc pas besoin de s'émouvoir.

5
Non, je voulais dire la programmation en général. Si vous ne comprenez pas la programmation fonctionnelle, vous ne pourrez probablement pas non plus comprendre les autres concepts.

8
Je n'achète pas ça. OCaml dispose de nombreuses bibliothèques pour la programmation quotidienne, et si elle devenait plus populaire, les gens écriraient davantage. Chaque langue a commencé avec peu de bibliothèques.

8
Que diriez-vous d'un lien vers ces bibliothèques?

4
Pourquoi plus de 0 personnes ont-elles voté quelqu'un qui prétend qu'une langue n'a pas d'implémentation de table de hachage utilisable? Je ne supporte pas les langages qui construisent des conneries inutiles, comme les expressions régulières et les dictionnaires, un langage devrait être aussi découplé que possible des bibliothèques, afin de garder le TCB critique. Une langue qui repose sur les dictionnaires pour tout faire est de la merde.
Longpoke

22

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.


3
Je ne dirais pas que son système de types est trop fort, mais plutôt pas assez expressif, la classe de types ala Haskell aiderait beaucoup.

2
Oui, mais la plupart de ces commentaires sur le fait de ne pas se sentir affecté s’appliquent encore plus fortement au C ++! Je pense que cela affaiblit un peu votre argumentation (bien que je sois d’accord avec lui).
Yttrill

2
Le débogueur OCaml est le seul que je connaisse qui puisse revenir en arrière et avancer.
jeudi

21

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.


1
Bien sûr, mais Java et PHP sont populaires et vous ne pouvez pas les utiliser dans des systèmes embarqués. La convivialité dans les systèmes embarqués n’a pas beaucoup d’influence sur la popularité de la langue.

3
La question initiale concernait les systèmes embarqués et j'ai donc fourni une raison précise pour laquelle ils pourraient ne pas être utilisés. Et en guise de remarque, vous pouvez utiliser Java - mais pas pour le temps réel (idem pour C #).

2
Java lui-même n'est pas en temps réel. Rien avec un mécanisme de collecte des ordures ne peut pas être.

3
@ctacke: Ce n'est tout simplement pas vrai. Il existe de nombreux éboueurs en temps réel. Les implémentations Java les utilisent et Java est utilisé dans les applications en temps réel.
Jon Harrop


18

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.


Selon Wikipedia, ML n'est pas beaucoup plus jeune, il a seulement un an de moins (1972 pour C v. 1973 pour ML). Le reste de votre explication, je pense, est juste sur l'argent.

1
Huh. Je sortirais avec C à la fin des années 60 et ML au début des années 80 (et OCaml, en particulier, à la fin des années 90 ... plus jeune que Java, Python et même Ruby), mais je suppose que je suis un peu en retrait.

ML date de 1973, OCaml date de 1996.
date du

15

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.


vraiment bon point
cnd

11

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?


Eh bien, vous pouvez choisir Haskell plutôt que ML, car Haskell n’est, à bien des égards, qu’un ML amélioré. Pourquoi choisiriez-vous plutôt Erlang? Je ne suis pas sûr: Erlang n’est pas typé de manière statique et, en ce qui me concerne, après quelques expériences frustrantes, j’utiliserais ML tout au long de la journée.

On m'a enseigné le Standard ML en 1996 à l'Université de Cambridge et je ne l'aimais vraiment pas en partie parce que les exemples étaient tous de l'informatique théorique (et je suis un physicien) et parce que ses implémentations étaient nulles (quand je me suis plaint, ils m'ont donné 100kLOC de source du compilateur ML) cela ne m'a même pas compilé et m'a dit de le réparer moi-même). Après mon doctorat, j'ai pris OCaml et je l'ai trouvé beaucoup plus viable. Quant à ML vs Haskell / Erlang, cela dépend de quel ML. OCaml a évidemment beaucoup de fonctionnalités qui manquent à Haskell et Erlang. De plus, ces caractéristiques s'avèrent essentielles dans la pratique.
Jon Harrop

9

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.


10
Deux ans plus tard, OCaml ne semble pas plus populaire.

5
Quatre ans plus tard, OCaml ne semble pas plus populaire.
Camilo Martin

8

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.


"une courbe d'apprentissage abrupte": Combien de temps faut-il pour maîtriser le C ++ à partir de 0? Je pense que si OCaml était plus populaire, plus de gens trouveraient normal de faire un effort pour l’apprendre.
Giorgio

@Giorgio "Je pense que si OCaml était plus populaire, plus de gens trouveraient normal de faire un effort pour l'apprendre". Je pense que plus de gens apprennent Python et Ruby parce qu'ils sont relativement faciles à apprendre.
Jon Harrop

Bien sûr, les gens préfèrent apprendre des langues plus simples (d'ailleurs, je ne pense pas qu'Ocaml soit beaucoup plus complexe que Ruby et certainement moins complexe que C ++). n'est plus considéré comme un gros problème. OCaml n’est pas populaire et par conséquent les gens ne pensent pas que cela vaut la peine de l’apprendre.
Giorgio

Je suis d'accord, sauf que j'ai certainement perçu la complexité du C ++ comme un problème majeur et je pense que la plupart des personnes que j'ai rencontrées en ont été convaincues également. En particulier, la difficulté de manipuler par programmation le code C ++ représente une énorme perte d’opportunité.
Jon Harrop

Je trouve votre déclaration "Parmi les personnes qui effectuent des calculs scientifiques à l’Université de Cambridge, environ 90% des personnes que je connaissais maîtrisaient parfaitement OCaml." très surprenant. En tant que physicien qui fait beaucoup de modélisation, j'ai vu des collègues utiliser de nombreux langages: C, C ++, Fortran, Java, Python, Perl, MATLAB, Mathematica, R assez communément et quelques autres également. Mais je n'ai jamais vu personne utiliser OCaml. J'ai entendu des gens parler de peut-être l' apprendre, mais je n'ai jamais vu personne l' utiliser . Rechercher sur scicomp.stackexchange.com ne donne presque plus rien. Votre plaidoyer pour cette utilisation de ML a ...
Szabolcs

6

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.


Les relations de récurrence sont l’une des choses qui correspondent toujours parfaitement à la PF.
Jon Harrop

3
"La programmation fonctionnelle n'est tout simplement pas un moyen naturel de penser pour la plupart des gens": la programmation structurée n'était pas un moyen naturel pour moi de penser aussi longtemps que je programmais en Basic. Puis je suis passé chez Pascal. La programmation orientée objet n'était pas un moyen naturel pour moi de penser aussi longtemps que je programmais en Pascal et C. Ensuite, je passais au C ++ et à Java. La programmation fonctionnelle m’a également paru étrange jusqu’à ce que j’ai commencé à apprendre Haskell et d’autres langages de PF, et maintenant, le C ++ semble tellement gênant pour certaines tâches. :-)
Giorgio

6

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.


5

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.


3

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.


Il y a quelque temps, une liste de diffusion a fait l’objet d’une discussion sur les performances apparemment médiocres d’OCaml dans Language Shootout. Étonnamment, les langages de type C sont autorisés à utiliser des allocateurs de mémoire non standard, tandis que les langages ramassés à la poubelle ne sont pas autorisés à régler leurs propres ramasse-miettes ... Et les paramètres par défaut de IIRC OCaml étaient un peu flous pour les CPU d'aujourd'hui.
bltxd

3

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


Il y a 10 ans, cela ressemblait davantage à 1 personne sur 100 connaissant la PF. ;-)
Jon Harrop

2

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


2

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.


2

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.


1

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


Je crois qu'il y a maintenant 2 entreprises avec plus de 20 développeurs OCaml (Jane St. et Citrix).
Jon Harrop

3
Hou la la! Deux sociétés entières? :)
Yttrill

0

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.