¿Por qué OCaml no es más popular?

86

Siempre he escuchado que C es el lenguaje de elección para usar en sistemas embebidos, o cualquier cosa que necesite ejecutarse a la máxima velocidad. Nunca desarrollé una afición por C, principalmente porque no me gusta la aritmética de punteros y el lenguaje apenas es un peldaño por encima del ensamblador.

Por otro lado, los lenguajes ML son lenguajes funcionales, recolectados de basura, y OCaml incluso tiene un modelo de objeto, sin embargo, tienen la reputación de ser tan rápidos como C.Los lenguajes ML tienen la abstracción que cualquiera podría pedir para escribir de alto nivel, conciso código, pero conserva la velocidad necesaria para escribir aplicaciones de alto rendimiento.

OCaml, en particular, se puede usar en cualquier lugar en el que C se use tradicionalmente, como dispositivos integrados, controladores de gráficos, sistemas operativos, etc. lo usé

Esta es una pregunta subjetiva, pero ¿por qué OCaml y ML otros lenguajes han permanecido tan oscuros, mientras que C y otros lenguajes se han vuelto populares?

Julieta
fuente

Respuestas:

82

La primera respuesta es que nadie sabe realmente por qué los idiomas se vuelven populares, y cualquiera que diga lo contrario está engañado o tiene una agenda. (A menudo es fácil identificar por qué un idioma no se vuelve popular, pero esa es otra pregunta).

Con ese descargo de responsabilidad, aquí hay algunos puntos que son sugerentes, los más importantes primero:

  • El primer compilador de C maduro apareció en 1974; El primer compilador OCaml maduro apareció a fines de la década de 1990. C tiene una ventaja de 25 años.

  • C se envió con Unix, que era la "aplicación asesina" más grande de todos los tiempos. Durante mucho tiempo, todos los departamentos de CS en el mundo tuvieron que tener Unix, lo que significaba que cada instructor y todos los que tomaban un curso de CS tuvieron la oportunidad de exponerse a C. OCaml y ML todavía están esperando su primera aplicación asesina. (MLdonkey es genial, pero no es Unix).

  • C llena su nicho tan bien que dudo que nunca haya otro lenguaje de bajo nivel dedicado únicamente a la programación de sistemas. (Para ver la evidencia a favor, lea el artículo de Dennis Ritchie sobre la historia de C de HOPL II.) Ni siquiera está claro cuál es el nicho de OCaml, y el nicho de Standard ML es solo un poco más claro. Entonces, Caml y ML tienen bastantes competidores, mientras que C mató a su único competidor (BLISS).

  • Una de las grandes fortalezas de C es que su modelo de costos es muy predecible: es fácil observar que cualquier fragmento pequeño de código C puede obtener instantáneamente una idea precisa de qué operaciones de la máquina deberán realizarse para ejecutar ese código. El modelo de costos de OCaml es mucho menos claro, especialmente porque la asignación de memoriaes mucho menos explícito, y el costo general de la asignación de memoria (es igual al costo de la asignación más los costos incurridos durante la recolección de basura) depende de las propiedades emergentes, como cuánto tiempo viven los objetos y qué objetos se refieren a otros objetos. El resultado neto es que el rendimiento es difícil de predecir e incluso difícil de analizar después del hecho. (Las herramientas de creación de perfiles de memoria de OCaml no son lo que deberían ser). Como resultado, OCaml no es bueno para aplicaciones donde el rendimiento debe ser muy predecible, como los sistemas integrados.

  • C es un lenguaje con un estándar y muchos compiladores. OCaml es un artefacto de software: el único compilador es de una sola fuente, y el compilador es el estándar. Y ese estándar cambia con cada lanzamiento. Para las personas que valoran la estabilidad y la compatibilidad con versiones anteriores, un lenguaje de fuente única puede representar un riesgo inaceptable.

  • Cualquier persona con un curso de compilación de pregrado medio decente y mucha persistencia puede escribir un compilador de C que funcione más o menos y con un rendimiento adecuado. Hacer que OCaml o ML se implementen requiere mucha más educación, y obtener un rendimiento comparable al de un ingenuo compilador de C requiere mucho más trabajo. Esto significa que hay muchos menos aficionados a jugar con lenguajes como OCaml, por lo que es más difícil para la comunidad desarrollar una comprensión profunda sobre cómo explotarlo.

Norman Ramsey
fuente
55
OCaml es un dialecto ML relativamente reciente, nacido casi al mismo tiempo que Java. Sin embargo, ML se remonta a 1973 con el primer dialecto importante, SML se desarrolló en 1978. Los dialectos de ML encontraron un nicho en la prueba e investigación de teoremas, pero desde entonces han sido el estándar de la industria en las instituciones financieras.
Julieta el
15
No llamaría a ML el "estándar de la industria en las instituciones financieras". (Y no digo esto porque escribo aplicaciones financieras en Haskell. :-)) En el mundo comercial, mientras que la industria financiera probablemente ha tenido una mayor aceptación de la programación funcional que ninguna otra, todavía no se usa tanto : en mi experiencia, C ++ y Java dominan. Empresas como Jane Street son la excepción, no la regla.
8
Perl es un "artefacto de software", la única definición de Perl es "el lenguaje que perl (1) interpreta", y sin embargo es bastante popular. Python y Ruby fueron "artefactos de software" durante mucho tiempo.
55
@ Chris: OMI, esta es una de las razones por las que Perl está perdiendo la mentalidad.
Norman Ramsey
55
En cuanto a la previsibilidad, creo que OCaml realmente supera a C en ese ámbito, con el nivel de optimización que se espera de los compiladores de C y la fragilidad de muchas de esas optimizaciones. El compilador de OCaml es muy literal sobre en qué compila su código.
63

Creo que el problema con OCaml es que no es demasiado útil "fuera de la caja". La razón eventual por la que las personas usan un idioma es porque tiene bibliotecas que necesitan. Sin embargo, sin nada "listo para usar", nadie se adentra lo suficiente en un proyecto para darse cuenta de que necesita escribir una biblioteca. El resultado es un lenguaje sin bibliotecas, lo que dificulta la escritura de "aplicaciones reales".

Creo que esto es lo que sufre OCaml: nadie se molesta en comenzar "proyectos reales" porque todo lo que hay es un lenguaje de programación. Sí, puedo agregar dos y dos e imprimir el resultado. El resultado es una colección de bibliotecas que son principalmente abandonware académico (el autor obtuvo su doctorado y siguió adelante), lo que no es demasiado útil para los programadores en ejercicio.

(Sé que se está trabajando para cambiar esto, con proyectos como "Baterías incluidas". Vuelva aquí en 5 años, y quizás OCaml sea más popular).

Hay algunas excepciones a esta regla. Java comenzó sin bibliotecas, pero Sun pagó a la gente para que las escribiera todas en casa, y luego lo comercializaron. Certificación de Java, hardware específico de Java, libros de Java, clases de Java, etc. Luego, incluso convenció a la mayoría de las universidades para que lo enseñen exclusivamente, a pesar de que no es un muy buen lenguaje para la programación de aprendizaje.

El resultado fue la popularidad. El dinero puede resolver muchos problemas.

En el campo del lenguaje funcional, podemos ver que Haskell se está volviendo bastante popular. Creo que la mayor parte de la popularidad se debe a personas como dons que escriben bibliotecas útiles y nunca dejan de comercializar el idioma. Todos los días ves algunos artículos de Haskell sobre Programación Reddit. Esto lo mantiene atascado en la mente de las personas hasta que finalmente deciden: "Voy a probar Haskell". Cuando lo hacen, ven cosas útiles como marcos web, bases de datos de objetos, bibliotecas OpenGL y bibliotecas de procesamiento XML. Esto significa que en realidad pueden hacer algo útil "en este momento". Entonces, entre el potencial para ser productivo y escuchar mucho sobre esto, Haskell ha ganado mucha popularidad.

CL tiene muchas de las mismas bibliotecas que Haskell y es casi tan rápido, pero nadie habla de eso, por lo que "se siente muerto". De hecho, #lisp es mucho más silencioso que #haskell, pero Lisp sigue siendo un lenguaje muy productivo con muchas bibliotecas. Ningún otro idioma tiene SLIME. Pero el marketing es muy importante, y Haskell lo hace mejor que Lisp u OCaml (y compite por la misma base de usuarios).

Finalmente, algunas personas nunca "obtendrán" la programación, por lo que romper su modelo mental (las variables son cuadros con valores, el código se ejecuta de arriba a abajo) asegurará que no usen su lenguaje. Este tipo de programador es un gran porcentaje de la población de programación, por lo que esto limita aún más la posible base de usuarios de lenguajes abstractos como Lisp, Haskell y OCaml.

jrockway
fuente
45
Esto tal vez era cierto hace 10 años. Avíseme cuando pueda "cabal instalar" una biblioteca OCaml. De todos modos, solo porque dije algo malo sobre tus idiomas favoritos no significa que tengas que dejar de usarlo. Así que no hay necesidad de emocionarse.
55
No, me refería a la programación en general. Si no puede entender la programación funcional, probablemente tampoco pueda entender los otros conceptos.
8
Yo no compro esto. OCaml tiene muchas bibliotecas para la programación básica del día a día, y si se hiciera más popular, la gente escribiría más. Cada idioma comenzó con pocas bibliotecas.
8
¿Qué tal un enlace a estas bibliotecas?
44
¿Por qué más de 0 personas votaron a alguien que afirma que un idioma no tiene una implementación de tabla hash utilizable? No soporto los idiomas que se basan en basura inútil como expresiones regulares y diccionarios en ellos, un lenguaje debe estar lo más desacoplado posible de las bibliotecas, para mantener bajo el TCB crítico. Un lenguaje que se basa en los diccionarios para hacer cualquier cosa es una mierda.
Longpoke
22

Me gusta mucho OCaml como idioma. PERO...

El soporte de herramientas simplemente no está allí. El depurador solo funciona bien, pero no funciona en Windows (la última vez que lo verifiqué) y simplemente no hay tantas herramientas de desarrollo disponibles para él.

Su sistema de tipos es, a veces, demasiado fuerte. Para alguien que no comprende cómo funciona la inferencia de tipos o el sistema de tipos ML en general, el hecho de que no pueda agregar un número entero a un flotante es un gran desvío de inmediato.

La biblioteca estándar a veces puede tener una sensación inconsistente.

El modelo de objetos parece un poco pegado y la biblioteca estándar apenas lo usa, optando por bibliotecas basadas en módulos.

Hay muchas otras cosas que básicamente significan que el idioma no se siente "pulido" y que aleja a las personas durante el período crítico cuando están aprendiendo un idioma y tratando de decidir si les gusta o no.

Creo que su legado más importante será que, junto con otros dialectos de ML, ha tenido una influencia muy fuerte en otros lenguajes funcionales. La mayoría de los lenguajes funcionales de la generación actual toman los mejores elementos de los dialectos de ML y refinan algunas de las molestias.


fuente
3
No diría que su sistema de tipos es demasiado fuerte, sino que no es lo suficientemente expresivo, la clase de letra ala Haskell ayudaría mucho.
2
Sí, pero la mayoría de estos comentarios sobre no sentirse pulido se aplican aún más fuertemente a C ++. Siento que esto debilita un poco tu argumento (aunque estoy de acuerdo con él).
Hasta el
2
El depurador OCaml es el único que conozco que puede retroceder y avanzar.
ocodo
21

Los sistemas integrados a menudo requieren dos cosas: velocidad y determinismo. OCaml puede proporcionar velocidad, pero el hecho de que tenga un recolector de basura lo hace inherentemente no determinista, y para un sistema en tiempo real, eso no funcionará.

ctacke
fuente
1
Claro, pero Java y PHP son populares, y no puedes usarlos en sistemas integrados. La usabilidad en sistemas integrados no tiene mucha influencia sobre la popularidad del lenguaje.
3
La pregunta original se refería a los sistemas embebidos, así que proporcioné una razón específica por la que podría no usarse. Y como nota al margen, puede usar Java, solo que no en tiempo real (lo mismo ocurre con C #).
2
Java en sí no es en tiempo real. Cualquier cosa con un mecanismo de recolección de basura no puede ser.
3
@ctacke: Eso simplemente no es cierto. Hay muchos recolectores de basura en tiempo real. Las implementaciones de Java los usan y Java se usa en aplicaciones en tiempo real.
Jon Harrop
18

Esta es una comparación entre manzanas y naranjas. OCaml es un lenguaje bastante joven [1] y nunca ha habido un esfuerzo serio y sostenido para llevarlo a la corriente principal (excepto el trabajo actual de Microsoft con F #). A diferencia de C, no es la lengua franca del sistema operativo empresarial más ampliamente soportado e imitado (es decir, UNIX). A diferencia de Java, no ha tenido una gran corporación que lo impulse como una plataforma informática de próxima generación. A diferencia de Perl, Python y Ruby, no se ha afianzado en un nicho influyente de alto perfil (es decir, su nicho es el lenguaje de programación y la investigación de razonamiento automatizado, no de muy alto perfil en comparación con el desarrollo web). Por lo tanto, no es súper popular.

[1] Para ser justos, el lenguaje original de ML ha existido desde los años 70. Pero OCaml no apareció hasta 1996 y no heredó las bibliotecas Standard ML. Es, en términos prácticos, un lenguaje más joven que C, C ++, Java, Python, Haskell o incluso Ruby.

Chris Conway
fuente
Según Wikipedia, ML no es mucho más joven, solo es un año más joven (1972 para C v. 1973 para ML). El resto de su explicación, creo que está bien en el dinero.
1
Huh Saldría con C a finales de los 60 y ML a principios de los 80 (y OCaml, en particular, a fines de los 90 ... más jóvenes que Java, Python e incluso Ruby), pero supongo que estoy un poco apagado.
ML data de 1973, OCaml es de 1996.
ocodo
15

La comunidad OCaml no pudo desarrollar una biblioteca estándar grande y confiable (más allá de lo que viene con OCaml hoy) que facilita el desarrollo de aplicaciones. Hay varios intentos para resolver el problema, pero solo eche un vistazo a Python o Ruby para ver qué falta. OCaml es un gran lenguaje si desea resolver un problema algorítmico que no depende demasiado de tener que interactuar con módulos estándar avanzados como XML, redes, cálculo de datos, etc., que prefiere no implementar.

Creo que parte del problema es cómo OCaml asigna los módulos a los archivos: conceptualmente, todos los archivos * .ml viven en el mismo espacio de nombres y los directorios no tienen significado. Esto hace que sea difícil para una comunidad desarrollar una biblioteca. Si el compilador mapeara las jerarquías de directorios en las jerarquías de módulos, vería una mejor oportunidad de que evolucionara una biblioteca estándar. Sin embargo, esto requeriría un esfuerzo considerable por parte de los desarrolladores del compilador principal. (Soy consciente de los módulos de embalaje, pero creo que esto es un error).

Otro problema de la biblioteca es la compatibilidad binaria entre las versiones del compilador. Es bastante seguro decir que todo el código de la biblioteca debe volver a compilarse después de una actualización del compilador. Esto hace que sea difícil proporcionar versiones binarias de módulos o bibliotecas.

Christian Lindig
fuente
muy buen punto
cnd
11

Probablemente porque a muchas personas se les enseñó ML como parte de una introducción a cosas teóricas extrañas y confusas sobre los tipos. Eso es lo que me pasó.

Me mostraron ML y Smalltalk al mismo tiempo. Smalltalk se veía increíblemente genial, y fue inmediatamente comprensible para qué era OO y cómo se podían hacer cosas bonitas e interactivas en este entorno. ML era sobre cosas matemáticas abstractas que no parecían relevantes para lo que quería hacer. Y a diferencia de C, no prometió dejarme escribir juegos rápidos en micros de 16 bits.

Esto es, por supuesto, profundamente injusto y subjetivo. Pero esa es probablemente la historia real para la mayoría de las personas.

En estos días supongo que la pregunta sería: ahora siento que necesito saber estas cosas teóricas extrañas y confusas sobre los tipos, ¿por qué elegiría ML sobre Haskell o Erlang?

interestar
fuente
Bueno, puede elegir Haskell sobre ML porque Haskell es, en muchos sentidos, solo un ML mejorado. No estoy seguro de por qué elegirías Erlang sobre: ​​No estoy seguro: Erlang no está estáticamente tipado y, en cuanto a mí, después de algunas experiencias frustrantes con él, me haría cargo de ML cualquier día.
Me enseñaron ML estándar en 1996 en la Universidad de Cambridge y realmente no me gustó en parte porque los ejemplos eran todos de informática teórica (y yo soy físico) y porque sus implementaciones apestaron (cuando me quejé me dieron 100kLOC de fuente del compilador de ML eso ni siquiera compiló y me dijo que lo arreglara yo mismo). Recogí OCaml después de mi doctorado y descubrí que era mucho más viable. En cuanto a ML vs Haskell / Erlang, depende de qué ML. OCaml obviamente tiene muchas características de las que carecen Haskell y Erlang. Además, esas características resultan ser esenciales en la práctica.
Jon Harrop
9

Creo que el problema principal es la falta de una biblioteca estándar real. Por lo tanto , se incluyen las baterías OCaml del proyecto , que se espera que mejoren en gran medida la situación. Se supone que entrará en la fase Beta dentro de unos días, por lo que tendrá que hacer la pregunta nuevamente en aproximadamente un año.


fuente
10
Dos años después, OCaml no parece más popular.
55
Cuatro años después, OCaml no parece más popular.
Camilo Martin
8

Estoy de acuerdo en que el pobre soporte de Windows, una curva de aprendizaje empinada y una biblioteca estándar delgada han sofocado la aceptación de OCaml en el pasado, pero agregaría que ha habido una gran falta de información tutorial (por ejemplo, libros) sobre OCaml en comparación con lenguajes convencionales como Java.

Además, los tipos de personas que conocen idiomas como OCaml son muy heterogéneos. Entre los programadores web, tal vez 1 de cada 1,000 haya oído hablar de OCaml. Entre las personas que realizan computación científica en la Universidad de Cambridge, aproximadamente el 90% de las personas que conocía hablaban con fluidez OCaml. De hecho, fui uno de los últimos entre mis amigos en aprender OCaml. Incluso ejecutamos OCaml en nuestra supercomputadora de 256 CPU ...

También debo mencionar que estos problemas se están abordando rápidamente. OCaml se ha reinventado recientemente para la programación web con proyectos como Ocsigen y ya tiene al menos dos grandes historias de éxito industrial en ese contexto. Ahora hay otro libro nuevo sobre OCaml. La comunidad está colaborando en una biblioteca estándar integral llamada "baterías incluidas" que acaba de entrar en la versión beta y se ve fantástica. Está a punto de lanzarse una versión amigable multinúcleo de OCaml. La última versión de OCaml también incluye muchas nuevas características excelentes, como patrones perezosos y bibliotecas OCaml de código nativo cargadas dinámicamente.

Jon Harrop
fuente
"una curva de aprendizaje empinada": ¿Cuánto tiempo lleva dominar C ++ a partir de 0? Creo que si OCaml fuera más popular, a más personas les resultaría normal hacer un esfuerzo por aprenderlo.
Giorgio
@Giorgio "Creo que si OCaml fuera más popular, a más personas les resultaría normal hacer un esfuerzo para aprenderlo". Creo que más personas aprenden Python y Ruby porque son relativamente fáciles de aprender.
Jon Harrop
Por supuesto, las personas prefieren aprender idiomas más simples (por cierto, no creo que Ocaml sea mucho más complejo que Ruby y definitivamente menos complejo que C ++), el punto es que una vez que un idioma es convencional / popular, el hecho de que sea complejo es ya no se ve como un gran problema. OCaml no es popular y, por lo tanto, la gente no cree que valga la pena aprenderlo.
Giorgio
Estoy de acuerdo, excepto que ciertamente he percibido que la complejidad de C ++ ha sido un problema importante y creo que la mayoría de las personas que he conocido también se han convencido de esto. En particular, la dificultad de manipular mediante programación el código C ++ es una gran pérdida de oportunidades.
Jon Harrop
Encuentro su afirmación "Entre las personas que realizan computación científica en la Universidad de Cambridge, aproximadamente el 90% de las personas que conocía hablaban con fluidez OCaml". Muy sorprendente. Como físico que modela mucho, vi colegas usar muchos lenguajes diferentes: C, C ++, Fortran, Java, Python, Perl, MATLAB, Mathematica, R con bastante frecuencia, y algunos otros también. Pero nunca he visto a nadie usar OCaml. Escuché a personas hablando de tal vez aprenderlo, pero nunca he visto a nadie usarlo . Buscar en scicomp.stackexchange.com da casi nada de nuevo. Su defensa de este uso de ML lo hizo ...
Szabolcs
6

Creo que parte del problema es que la programación funcional no es una forma natural de pensar para la mayoría de las personas (y lo digo como alguien que tiene un gran interés y aprecio por la programación funcional). Esto se ve agravado por el hecho de que la gran mayoría de los programadores de hoy comenzaron a aprender programación procedimental (los lenguajes OOP más populares todavía son procesales) y, por lo tanto, los lenguajes funcionales son difíciles de ajustar inicialmente.

Cuando comencé la universidad ya conocía una cantidad razonable de BASIC, C ++ y Java y un poco de lenguaje ensamblador Pascal y x86. Estaba lejos de ser un experto, pero había llegado a la conclusión (ligeramente ingenua) de que todos los lenguajes de programación eran básicamente los mismos con una sintaxis ligeramente diferente. Nuestra introducción al curso de programación usó ML que rápidamente me deshabilitó de esa noción. Tuve problemas para entender ML en esa etapa de mi carrera de programación y realmente no entendí el punto de la programación funcional. Creo que se necesita un poco más de experiencia con algunos de los problemas de la programación de procedimientos para apreciar realmente los beneficios de un enfoque funcional.

Nuestro profesor de ML a menudo afirmó que expresar los problemas de forma recursiva era más "natural" y más fácil que usar bucles u otros conceptos de procedimiento. Esa afirmación nunca me convenció y todavía no la compro. Las funciones recursivas a veces pueden proporcionar soluciones particularmente elegantes y concisas a los problemas, pero todavía me parece una forma poco natural de pensar sobre los problemas. Tal vez si tiene una base matemática muy sólida, parece más intuitiva, pero no creo que sea fácil para la mayoría de las personas pensar recursivamente. Dada la centralidad de las funciones recursivas para el paradigma de programación funcional, creo que esto también puede ser una razón para la menor popularidad de los lenguajes funcionales.

También hay un efecto de retroalimentación en la popularidad del idioma. Cuando comencé a programar, quería saber cómo programar efectos gráficos y juegos. Después de aprender un poco de BBC BASIC y más tarde QBASIC, naturalmente investigué cuáles eran los lenguajes más comunes utilizados por la escena de demostración y los programadores de juegos y comencé a aprender sobre el ensamblaje C ++ y x86. Hoy en día, algunos programadores nuevos pueden querer saber cómo producir aplicaciones web y, por lo tanto, gravitarán hacia el aprendizaje de PHP, Ruby o C #. Hay muy pocas áreas de aplicación para programadores principiantes automotivados donde la respuesta a 'cuál es el mejor lenguaje para aprender a programar algo como X' será 'Ocaml'.

El soporte oficial de Microsoft para F # como lenguaje .NET de primera clase aborda muchas de las razones prácticas dadas para la popularidad limitada de Ocaml (falta de bibliotecas maduras, depuradores, IDEs, etc.). Será interesante ver si F # ayuda a lograr un mayor nivel de popularidad para la programación funcional.

Mattnewport
fuente
Las relaciones de recurrencia son una de las cosas que siempre se asignan muy bien a FP.
Jon Harrop
3
"La programación funcional no es una forma natural de pensar para la mayoría de las personas": la programación estructurada no era una forma natural de pensar mientras programara en Basic. Luego me mudé a Pascal. La programación orientada a objetos no era una forma natural de pensar mientras programaba en Pascal y C. Luego me mudé a C ++ y Java. La programación funcional también me pareció extraña hasta que comencé a aprender Haskell y otros lenguajes FP, y ahora C ++ se ve tan incómodo para ciertas tareas. :-)
Giorgio
6

Creo que el núcleo del problema es la política. Los desarrolladores de Ocaml están principalmente interesados ​​en la investigación y no tienen los recursos para proporcionar y mantener una biblioteca rica. Sin embargo, tampoco están dispuestos a liberar el control del producto a la comunidad que tiene estos recursos, el resultado es que varios intentos de resolver este problema se basaron en la cooperación y financiación inexistentes de bibliotecas de terceros y estos intentos fallaron. Las baterías fallarán por la misma razón, a menos que los desarrolladores de Ocaml cambien su actitud.

Utilizo Ocaml para desarrollar mi producto, y tengo una regla simple: minimizar la dependencia del código de terceros. Cuando un artículo de un tercero sea útil, si es posible, incorpore los códigos fuente directamente en el paquete. Por ejemplo, OCS Scheme y Dypgen son partes esenciales del analizador Felix, por lo que se copian en nuestras fuentes para que tengamos algún control sobre ellos. El control es algo ilusorio (dado que Dypgen al menos es tan complejo que es poco probable que podamos mantenerlo, pero al menos tenemos una copia que creemos que funciona :)

No usaré baterías porque la licencia es restrictiva, por lo que no puedo copiar la fuente y no tengo fe en la viabilidad a largo plazo de la misma como un producto independiente: la única forma en que podría usarla es si fuera incorporado directamente en la distribución estándar de Ocaml.

En el mundo de C ++, podría considerar usar Boost: aunque es una biblioteca de terceros que no forma parte del Estándar, tiene un gran apoyo de la comunidad y en realidad está excelentemente sincronizado con el proceso de desarrollo de los Estándares. Las ideas desarrolladas y probadas en Boost se convierten en el tipo de práctica existente que se puede estandarizar, y el proceso de estándares es lo suficientemente abierto como para permitir la participación de la comunidad.

Ocaml ha obtenido la popularidad que realmente tiene porque es un producto tan bueno, pero eso no es suficiente para permitir que se convierta en un lenguaje convencional. Java es crud, se hizo popular con miles de millones de dólares en marketing y desarrollo de bibliotecas, pero al final tuvo que ser liberado a la comunidad para sobrevivir.

Yttrill
fuente
5

Disfruté codificando en ML y C para una amplia variedad de proyectos. Lo que me impide usar ML en proyectos integrados (la mayoría de los cuales tienen restricciones de tiempo real y requieren validación) es la recolección de basura.

Se está investigando la gestión de la memoria con regiones (ver MLKit ), pero la complejidad de las implementaciones y la capacitación requeridas para usarlas adecuadamente (y los riesgos asociados) han sido un impedimento para usarlas.

Doug Currie
fuente
3

En mi humilde opinión, creo que un gran problema de OCaml no está en el lenguaje (eso es genial) sino en las personas que lo desarrollan y, en consecuencia, su licencia:

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

¡Usan la licencia Q Public para el compilador! ¡Sí, la licencia ex-Trolltech utilizada para las bibliotecas Qt! Olvídate de obtener cualquier contribución con dicha licencia.

Si estaba revisando Language Shootout ( http://shootout.alioth.debian.org/ ) hace unos 7-8 años, OCaml estaba justo detrás de C y C ++ en cuanto a velocidad de ejecución. Mientras tanto, otros idiomas (como Haskell) obtuvieron un mejor compilador (debido a un enfoque comunitario diferente, supongo) y ahora la velocidad de ejecución de OCaml no es tan grande como en el pasado.

En breve, no usaría OCaml, porque no veo que vaya a ningún lado mejor sin que algunos hackers realmente buenos creen un compilador OCaml que tenga una licencia REALMENTE de código abierto y una comunidad con un comportamiento REALMENTE de código abierto.

Patrizio Rullo
fuente
Hubo una discusión en una lista de correo hace un tiempo sobre el desempeño aparentemente pobre de OCaml en Language Shootout. Sorprendentemente, los lenguajes tipo C pueden usar asignadores de memoria no estándar, mientras que los lenguajes recolectados de basura no pueden sintonizar sus propios recolectores de basura ... Y la configuración predeterminada de IIRC OCaml estaba un poco apagada para las CPU actuales.
bltxd
3

Bueno, si se trata de dinero como dice @jrockway, veremos si F # ganará la popularidad como java o C #.

Para mí, supongo que los desarrolladores no se sienten cómodos con la forma funcional de hacer las cosas (eso es de la sesión de F # en techdays 2009 donde unas 10 personas dijeron que conocen la programación funcional entre casi 100 personas).

Comencé OCAML este año, nunca me ensucié las manos con la programación funcional, pero ahora realmente aprendo cosas nuevas siempre de OCAML y la forma funcional de resolver problemas (pero no puedo decir que renuncie a C # usar OCAML :)).

0xFF
fuente
Hace 10 años, habría sido más como 1 de cada 100 personas que conocen FP. ;-)
Jon Harrop
2

Bueno, tal vez F # se vuelva popular.


fuente
2

No ayuda que c-> ocaml sea una transición mental más grande que c-> lisp. He considerado Ocaml un par de veces, y siempre descubrí que el costo / beneficio simplemente no estaba allí para mí, así que déjelo a un lado nuevamente. No fueron las construcciones las que lo hicieron parecer difícil, en realidad se veían realmente bien. Estaba tratando de aprender un significado completamente diferente para '!'. Lisp al menos se ve tan diferente que es fácil evitar malinterpretar pequeñas piezas como c.


fuente
2

Si desea utilizar un lenguaje en sistemas integrados en tiempo real, necesita punteros y no puede permitirse un GC.

Nemanja Trifunovic
fuente
1

Creo que la razón principal es que muy pocos desarrolladores conocen OCaml.

Y cuando hablo con otros desarrolladores (aquellos que escucharon algo sobre Ocaml) siempre tengo la impresión de que piensan en OCaml como un lenguaje "solo educativo" ... triste pero cierto

Chris
fuente
Creo que ahora hay 2 empresas con más de 20 desarrolladores OCaml (Jane St. y Citrix).
Jon Harrop
3
¡Guauu! ¿Un total de dos empresas? :)
Yttrill
0

Me gusta mucho O'caml ... He implementado un montón de cosas usándolo, compilador, intérpretes, sistema para comunicarse con C ...

cuando lo aprendí, el principal problema era que los mensajes de error no eran realmente claros ... así que, por ejemplo, al principio no estaba muy seguro de cuándo poner ';' y eso fue realmente difícil de encontrar que realmente el; estaba fuera de lugar ...

LB40
fuente