Por qué amo OCaml (2023)

• Un desarrollador que valora la programación funcional y las garantías estáticas aprecia el diseño equilibrado de OCaml después de haber pasado por varios lenguajes
• Frente al sistema de tipos complejo y la compilación lenta de Haskell, OCaml ofrece simplicidad y practicidad al mismo tiempo
• Se parece a Go en su compilación rápida y runtime conciso, pero conserva fortalezas de los lenguajes funcionales como pattern matching y tipos suma
• Con builds rápidos, binarios estáticos y herramientas de documentación abundantes (odig, utop), ofrece alta productividad y accesibilidad
• El mayor atractivo de OCaml se presenta como el equilibrio entre simplicidad y expresividad, junto con un diseño de lenguaje refinado

---

Experiencia y comparación entre lenguajes de programación

• A partir de la experiencia desarrollando software amateur y profesional en varios lenguajes, se resumen las características de un buen lenguaje
  • Se señalan como factores importantes la velocidad de compilación, un runtime simple, fuertes garantías estáticas, componentes funcionales, buen rendimiento y calidad de la documentación
• Haskell enseñó una forma de pensar propia de la programación funcional, pero se señalan como problemas su sintaxis compleja y compilación lenta
  • La tendencia de la comunidad a buscar más complejidad y problemas de runtime como los space leaks dificultan el mantenimiento
• Go permite simplicidad, compilación rápida, buenas herramientas y entender código de forma concisa
  • Sin embargo, se mencionan como límites su diseño conservador, el manejo verboso de errores y la ausencia de verificaciones explícitas de null, lo que aumenta la posibilidad de bugs y resulta incómodo
  • También se menciona como limitación la ausencia de un REPL y una actitud negativa hacia las ideas funcionales

Principales fortalezas de OCaml

• OCaml es evaluado como un lenguaje que cumple con la mayoría de los criterios anteriores
  • Fuertes garantías estáticas: soporte para tipos suma, variantes polimórficas y pattern matching
  • Runtime simple: usa recolección de basura, pero funciona como un lenguaje de nivel de sistema
  • Velocidad de compilación rápida: con el sistema de build Dune, es más rápido que Haskell o Rust
  • Generación de un único binario enlazado estáticamente, lo que facilita el despliegue
  • Excelentes herramientas de documentación: odig (exploración de documentación offline), utop (REPL), y la estructura separada de archivos de interfaz e implementación
• La inferencia automática de tipos mejora la eficiencia al escribir código
  • La estructura que define tipos en archivos de interfaz ayuda a explorar el código con claridad

Diseño del lenguaje e impresión general

• OCaml es un lenguaje antiguo, pero mantiene una sensación de diseño refinado
  • Algunas funciones orientadas a objetos o bibliotecas complejas se consideran innecesarias
• En conjunto, el equilibrio entre simplicidad y expresividad y un buen ecosistema de documentación y herramientas son el atractivo central de OCaml
• El autor valora mucho a OCaml como un lenguaje simple pero expresivo, y menciona una satisfacción difícil de encontrar en otros lenguajes

[GN⁺]

Comentarios en Hacker News

• Probé un poco OCaml y tuve varios problemas
  El soporte para Windows es pésimo, y recién con OCaml 5 mejoró a algo “bastante malo”
  La sintaxis es difícil de leer para humanos, y cuando hay un error de sintaxis, con meter mal un solo carácter te salen 1000 líneas de error
  Ocamlfmt hasta convierte sentencias match complejas en una sola línea, lo que perjudica la legibilidad
  La documentación también es demasiado concisa y casi no tiene ejemplos
  OPAM se ve bien en teoría, pero en la práctica tiene muchos bugs, e incluso hubo uno donde no podía encontrar curl si pertenecías a más de 32 grupos de Unix
  Como las anotaciones de tipo en las firmas de funciones son opcionales, se reduce la ventaja del tipado estático
  El ecosistema también es pequeño, y ni siquiera hay una función integrada para copiar archivos
  Esa obsesión con las listas enlazadas simples también es ineficiente
  Aun así, me parece mejor que C o Python, pero no creo que lo elegiría por encima de Rust

  • Si vas a usar OCaml en Windows, mejor recomiendo F#
    Como apunta al CLR, el despliegue es mucho más fácil, y puedes aprovechar tal cual el ecosistema de .NET
    Puedes usar casi tal cual bibliotecas NuGet para C# o VB.NET, así que el ecosistema es enorme
    La documentación de F# es mucho más abundante y tiene más ejemplos
    Enlaces de referencia: F# Language Reference, F# Core Docs, F# Cheatsheet
  • Me pregunté si el bug de curl en OPAM existía de verdad y lo busqué; lo confirmé en issue #5373
    En realidad era un problema relacionado con musl, y ocurría porque OPAM había sido compilado con ese binario
  • La mayor parte es un tema de curva de aprendizaje, pero incluso cuando te acostumbras, la fragmentación del ecosistema sigue ahí
    ocamlformat mejora mucho frente al valor por defecto si lo configuras con el perfil janestreet
    El tema de las anotaciones de tipo en las firmas se resuelve si proporcionas archivos .mli, pero la mayoría no lo hace
    A cambio, el plugin de OCaml para VS Code ofrece la mejor experiencia para principiantes
  • Coincido con lo de la obsesión por las listas enlazadas simples
    Con el hardware actual, me hace pensar que la colección por defecto debería ser un vector
  • Estoy totalmente de acuerdo en que el soporte para Windows es malo
    Antes ni siquiera se podía instalar directamente desde ocaml.org, y había que pasar por mingw o wsl
    Así que, en la práctica, era como si no existiera OCaml para Windows

• Está claro por qué los diseñadores de Go casi no adoptaron ideas de la programación funcional
  Como dijo Rob Pike, la mayoría de los desarrolladores en Google eran jóvenes y estaban acostumbrados a lenguajes de la familia C, así que necesitaban un lenguaje fácil de aprender
  Como cambiar al modo de pensar de un lenguaje funcional toma mucho tiempo, Go quiso evitar ese costo

  • De hecho, también hay muchos Googlers descontentos con las decisiones del equipo de Go

• Cada vez que veo la palabra “ML”, todavía se me acelera el corazón, y luego me decepciono al darme cuenta de que no significa Meta Language, sino Machine Learning

  • ML significa Meta Language, y LLM significa el grupo de investigación Languages and Logic Montreal
  • Aun así, creo que esa confusión es preferible
    Últimamente me molesta más el abuso de la palabra “AI”
    Ojalá no usaran el término AI hasta que exista una AGI de verdad
  • La primera vez que usé ML, a fines de los años 80 en una máquina 80286, realmente me impactó
  • Antes publiqué un comentario parecido y me llenaron de downvotes, así que me alegra ver que esta vez la reacción fue buena

• Si ves la charla de Richard Feldman, explica bien por qué los lenguajes funcionales no lograron masificarse
  Tienen que ser el lenguaje monopolístico de una plataforma, o tener una aplicación matadora, o contar con una enorme inversión en marketing
  Python también creció de forma explosiva porque se convirtió en el lenguaje central del ecosistema de AI
  Yo también aprendí programación funcional con OCaml e hice proyectos con Haskell y Zig, pero al final uno vuelve a la realidad de “usar las herramientas que sí puedes usar”
  OCaml, Rust y Haskell son populares como lenguajes que la gente quiere aprender, pero no como lenguajes de uso realmente extendido

  • No estoy de acuerdo con la idea de que Python sea popular por AI
    Torch originalmente estaba basado en Lua, y luego se movió a Python, que ya era popular
  • Creo que la razón de que la programación funcional no se volviera dominante fue una actitud elitista
    El mundo FP fue indiferente a los cambios tecnológicos del mundo real, y mientras tanto lenguajes como C, Pascal, Perl y Tcl se quedaron con el mercado
    Al final, FP se quedó como “los sacerdotes dentro de la catedral”, mientras los lenguajes imperativos se ganaron al público

• Probé F# y la concurrencia basada en actores me resultó fácil de entender
  Pero cuando aparecen los arrays mutables, se complica
  Me da curiosidad por qué alguien preferiría OCaml sobre F# en trabajo real

  • F# va perdiendo compatibilidad poco a poco por los cambios en el CLR, y además el compilador es lento y el tooling es inestable
    En cambio, OCaml tiene eliminación del lock global, compilación rápida y funciones potentes como módulos, GADT y effects
    F# todavía lleva ventaja en soporte para Windows, SIMD y tipos unboxed, pero OCaml poco a poco se está poniendo al día
  • La integración de F# con .NET es un arma de doble filo
    Hay muchas bibliotecas, pero la mayoría no se sienten como F#
    OCaml tiene un ecosistema nativo más grande
  • En mi empresa desarrollamos las partes intensivas en cómputo con F#
    La interoperabilidad con C# es buena, pero usar bibliotecas de F# desde C# era una pesadilla
    Al final terminas manteniendo una capa en C#, y la base de código se vuelve híbrida
    El ecosistema de .NET es rico, pero está muy centrado en una forma de pensar orientada a objetos, y eso choca con el estilo FP
    Visual Studio es cómodo, pero para flujos de trabajo basados en CLI resulta incómodo
    La velocidad de compilación se ha ido degradando, y las pruebas también se sienten torpes
    Cuando probé OCaml, el diseño ergonómico del lenguaje me pareció mucho más natural
  • OCaml es mucho más potente que F# en cosas como functors, módulos como valores de primera clase, GADT y sistema de objetos
    A F# lo llaman “OCaml para .NET”, pero en realidad es solo un lenguaje de la familia ML y es casi otro lenguaje distinto

• Como OCaml es un lenguaje viejo, podría pensarse que se le pueden quitar las funciones de OOP, pero yo creo que Standard ML es más completo

  • A mí también me gusta SML, pero el sistema de objetos de OCaml está subestimado
    Sirve para cosas como registros con tipado estructural, open recursion y bindings de JS como Js_of_ocaml
  • Estoy escribiendo un compilador en SML, y tiene restricciones raras como la sobrecarga de int/real o la value restriction
    También es incómodo que no soporte actualización de registros
  • Antes me gustaba más SML, pero en ese tiempo estaban de moda los “lenguajes con O”, así que OCaml terminó llamando más la atención

• Desde principios de los 2000, OCaml siempre fue un lenguaje “casi perfecto”
  Pero para cuando se resolvían esos puntos de fricción, otros lenguajes ya habían absorbido esas ideas

  • OCaml es un lenguaje como The Velvet Underground
    Poca gente lo aprende, pero todo el que lo aprende termina creando un lenguaje nuevo
    Fuente
  • Aun así, OCaml realmente opera sistemas de trading de miles de millones de dólares
  • No entiendo a qué se refieren con “fricción”
    Ya hay muchos proyectos funcionando bien con OCaml,
    y ahora hasta se le agregó un sistema de effects, así que en realidad va más adelantado todavía

• La popularidad y la calidad son cosas distintas
  popularidad ≠ excelencia, igual que en la música
  Solo lo determinan las tendencias y la inercia

  • La popularidad y el agrado más bien tienen una correlación inversa
    Cuanto más usado es un lenguaje, más gente lo odia,
    y cuanto más desconocido, más fácil es sobrevalorarlo
  • En la música lo “bueno” es subjetivo, pero en los lenguajes lo “bueno” puede objetivarse en términos de eficiencia para resolver problemas
    La razón por la que OCaml es menos popular es que el grupo de usuarios que percibe esa eficiencia es pequeño
    Y también influye la actitud dogmática del mundo FP

• Creo que Elixir es un lenguaje parecido a OCaml, pero con más posibilidades de masificarse
  Tiene ventajas de FP como inmutabilidad, pattern matching y el modelo de actores,
  y funciona de forma estable sobre el runtime BEAM
  No tiene tipado estático, pero está incorporando verificación gradual de tipos

  • En realidad, lo que más me intriga es por qué F# no es más popular
    Puede usar tal cual el ecosistema de .NET, y aun así es menos conocido que OCaml
  • Elixir tiene un ecosistema y tooling excelentes, y su sintaxis es más familiar que la de Erlang
    De hecho, hay muchas empresas que lo usan en backends de SaaS
  • Pero a la mayoría de las organizaciones les incomoda el paradigma funcional (centrado en la recursión)
    Por eso los lenguajes FP siguen siendo de nicho
  • Personalmente, Elixir me parece menos demandante mentalmente y más flexible que OCaml
  • Gleam también me parece interesante, pero un lenguaje que no compila no me sirve para mi trabajo

• OCaml se parece a Go en que es un lenguaje de sistemas con GC
  Prefiero un GC antes que la gestión manual de memoria o el borrow checking
  El GC de D también era excelente, pero el problema fue que la sola palabra “GC” asustaba a la gente