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

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?

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.

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.

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.

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

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.

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.

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?

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.

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.

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.

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.

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.

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.

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

Bueno, tal vez F # se vuelva popular.

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.

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

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

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