Have you ever had one of those notepads with the kind of paper that made you want to write something, anything, even though you had nothing to write about? OCaml is just like that to me.
I stroll through the internet aimlessly and I find a page that mentions OCaml and my eyes light up; I see an .ml file and savor how it looks - functions written with great economy of expression, pattern matching through which data flows in well-defined pathways, abstract data types forming a network of rugged pipes and girders that makes invalid states impossible; and .mli files that presents modules like classic prose -- no hedges, contortions, or obscurities that undercut the reader's ability to understand the flow of data and the pathways through which it flows.
"Expression, carrying the elegance that comes from compressed energy, is like a perfectly tuned stringed instrument: the strings are taut to exact degrees to correspond to exact pitches that stand in exact relations to one another. The pitches and their relations exist before the strings are tuned. Each string is tuned to a pitch and the results are judged by comparison to this pre-existing reality. A musician tuning an instrument is not finished until everything is exactly right, but once it is exactly right, there is simply nothing left to do." -- Clear and Simple as the Truth: Writing Classic Prose, Thomas, Turner.
> Have you ever had one of those notepads with the kind of paper that made you want to write something, anything, even though you had nothing to write about?
That's exactly my experience with F# (not surprising, knowing how similar OCaml and F# are), but until I read your comment I didn't know how to explain this joy of reading and writing code in it.
I have a project that uses it, Meh. when people use Camlp4, it's a pain to read, the stuff is had to follow when it's a wall of text because of the level of indirection, Lwt makes everything hard.
When I was 20, I thought Ocaml was the best thing in the world, because I was writing it. Now, after years without using it, I have to maintain other people's code, my opinion changed.
I use ocaml daily for work - our core product is written in it. We actively avoid anything that deviates from the base language for reasons of clarity. No camlp4, no lwt, no fanciness other than some of the batteries libraries that improve on the std library. It does occasionally mean we type in more than we would if, say, we used extensions to give us Haskell-like do notation for monadic code, but at the end of the day we err on the side of being very conservative.
It doesn't change the issue that when people have changed the grammar, you have to find their documentation to read their code, if the library is not used you have to read the parse tree transformation code, etc.
OCaml is the coolest language I’ve ever used. It’s the backbone of Harvard’s Intro to CS II, where they explain programming language paradigms with a heavy emphasis on the functional. OCaml’s expressiveness really shines through - I remember fondly how small yet powerful the language feels.
Unfortunately, I don’t know what to build with it... I’m the kind of person that builds projects for professional advancement, which curtails my creativity. I’ve thought of making a simple web server. Or maybe learning ReasonML. Any suggestions welcome.
OCaml really shines when your problem is data in, data out, and the transformation is non-trivial. So, maybe try compiling or generating stuff. I have two examples of my own: USSM¹, a simple static web site generator, and Monokex, a secure handshake generator like the Noise explorer (except much smaller, much simpler, and very incomplete).
>OCaml really shines when your problem is data in, data out, and the transformation is non-trivial.
So do you think it would be a good choice for creating a make-like tool, in which you want to support doing transitive / hierarchical makes, like target A depends on B, and B on C, so if C is newer than A, the tool should build B from C and then A from B, and other such variations?
Working on such an idea, currently in Python, and have an interest in and am reading about OCaml, hence asking. I think the work may involve a topological sort.
Thanks for those links, will check them out. Took a quick look at Dune. Interesting that the simple examples I saw seem to use a Lisp-like syntax.
The Jane Street Incremental library idea sounds cool. I had thought of something very roughly like it, but for memory data, recently, in connection with that tool I'm working on.
Had come across Leonard's series of moving 0install from Python to OCaml earlier. Need to revisit it.
It scares me how much I relate to this but don’t have the eloquence to express it like you did.
I’ve evaluated it for a lot of smaller stuff I’ve needed to get done, but ultimately it just ends up being easier to use a framework or language that I already know.
Thanks for this (and the child comments). I was just about to post a “which functional language should I pick up” ask HN but I got most of my answer from this thread :D
I learned to program in Caml (20 years ago now... it still seems like yesterday) but switched to curly brackets land when I started working, and more recently Python. Last month I started reading Learn You a Haskell for Great Good and that made me nostalgic for FP. Haskell’s syntax and strict management of side effects is a bit of a turn-off though. The article and the comments have firmly put me in the Caml camp, but now I have to figure out which version (OCaml, F#, ReasonML) to go for.
If you're writing anything for the browser, then I'll solidly recommend Reason. It works out of the box and ReasonReact is much more ergonomic compared to vanilla React + ImmutableJS + Redux + TypeScript combo. And there is a growing community around that use case in the Reason world.
If you want to write a command-line application, you can choose either OCaml or Reason, depending on your taste of syntax - both compile to native statically linked binaries. If you're doing anything related to compilers, OCaml is particularly suited for that, and you'll be in very good hands with Menhir (see: https://pl-rants.net/posts/case-for-new-lang/). Another systems software written in OCaml is unison (https://github.com/bcpierce00/unison), which is a file synchronization tool with a clear specification.
But if you want to write database backed web application servers in OCaml, with sessions, background jobs, admin interfaces, ORMs, database migrations and all that jazz, then you might want to give F# a go, or Haskell which has a better story around it. I do have a tiny Node server written in Reason that I use as an API endpoint but if I were to build a full-fledged system, there is nothing yet in the OCaml world like Rails or Django.
I used Unison for a decade, almost everyday, and it never failed. I never experienced this level of reliability with any other software. Perhaps all the credit goes to the programmer (Benjamin Pierce), not the language, but Unison certainly piqued my interest in Ocaml.
Thanks for the feedback. At this stage the goal is purely to dabble in FP with "Advent of Code" style mini-programs, and basically opening my developer chakras.
An added benefit would be to use this new language at work, which means that the size of the ecosystem (3rd-party modules, frameworks, etc.) can be a factor - one in which I guess OCaml is behind F# and Reason?
Note that OCaml and Reason are the same language with a different syntax. So when you're learning one, you're learning the other. There are some ecosystem differences because you can target native compilation, or JavaScript compilation. But otherwise the concepts carry over.
i personally highly recommend f#. it is one of the most practically designed langauges but still does functional and oop programming fantastically. some functional programming nerds complain it doesn’t have features like ocaml or sml’s modules or typeclasses like haskell, but it has other things that those languages don’t have. to my knowledge, it has feature parity with c# regarding oop with the exception of maybe a feature or two that doesn’t seem to affect things (i don’t know c#). meanwhile, it does functional programming very well.
it has nice error messages and clean syntax. it is easily installable on any platform. i took dan grossman’s programming language course on coursera. the first part of the course uses sml, and i simultaneously used sml, f#, racket, and scala to do the homework in. f# had the shortest solutions by far if counting lines of code.
a unique feature that i really like is its active patterns. f# already has amazing pattern matching, but you can define your own pattern matching with active patterns very easily. it is sort of close to defining your own pattern matching dsl.
in my opinion, it is criminally underused and under marketed by microsoft. in a world where python is taking over, f# is very refreshing.
the oft recommended f# for fun and profit is good as a reference, but i personally haven't found it good as a tutorial. the explanations are often not expedient and show (too) many ways of doing things to get to the point. i go there when i have something very specific in mind. i often find the official microsoft f# documentation to be quite good and my go to reference.
as for books, there are a lot. none of them really fully resonate with me, although they are usually pretty good, but the book functional programming using f# by hansen and rischel is fairly nice. it is more academic in tone, although it was written a while ago against an older version of f#, so there may be some slightly out of date or style code. the book expert f# is by the language designer, and it shows some nice advanced stuff in a clear way.
i also recommend going through the little mler by translating the sml code in the book to f#. it will get you used to using types and pattern matching the way they are done in ml dialects. you will be able to do everything up until they cover the module system.
it isn't documented or to my usual style, as it is an incomplete project. i was going through the book ray tracing in one weekend by peter shirley and didn't finish. and this code was actually "ported" from racket code that i had originally started the book with. so it went from c++ -> racket -> f#. however, it shows some representative f# syntax for some numerical stuff. i have some more f# projects that show more type-based programming and pattern matching styles, but they are in private repositories.
i personally just do not like python. it feels very sloppily designed to me, and i prefer scheme-based languages like racket and ml-based languages like f#. i have only worked in python when work has compelled me to, and i hated every instance of it. a large majority of it is that python is just difficult to reason about and is sloppy. that and the ecosystem, while vast, is very sloppy. i have encountered countless dependency issues and version headaches with python. it just isn't fun. all the work to get something working in python is just not worth it and unless you are reliant on some particular library, i personally don't see a reason to use it.
meanwhile, racket and f# remain as easy to develop code as python, except that the code developed works and works well. they are just extremely nice languages to use. they are the only languages i have used where it doesn't seem they are fighting me.
if you use python's async code, check out f#'s async expressions. they are extremely easy to use.
i highly recommend dan grossman's programming languages course on coursera. the first module uses sml (you can basically directly port all the code and your own code to f# for fun and very easily). the second module uses racket. and the third module uses ruby. i recommend it for any programmer and especially for some not used to the functional style.
> Have you ever had one of those notepads with the kind of paper that made you want to write something, anything, even though you had nothing to write about?
Yup! The “official” notepads of my university are nice quality paper. They cost more but I enjoy them so much that I buy them anyhow.
Conversely, I’ve also had notepads with paper that felt so horrible to write on that I were unable to use them. Fortunately a friend of mine uses ink instead of mechanical pencil so for her using those notepads was not a problem so I gave them to her rather than having them sit in a closet or having to hand them over to recycling unused.
Yep I know the feeling. I like Ocaml (and also Clojure) so much that it's one of the few languages were I'll actually don't really care about what I'm programming on as long as I get to use the language.
Building real things is great, but honestly for me one of the most satisfying things is just programming in an expressive and clean way for its own sake. It's great when you get a language or a tool that faciliates that.
If you have any web projects, you may be able to find a place for js_of_ocaml in one of them. I use it in a web app of mine. I started out writing the client-side scripting in plain JS (as opposed to React/Vue/etc.), but I am using js_of_ocaml lately to implement some more complex logic.
I stroll through the internet aimlessly and I find a page that mentions OCaml and my eyes light up; I see an .ml file and savor how it looks - functions written with great economy of expression, pattern matching through which data flows in well-defined pathways, abstract data types forming a network of rugged pipes and girders that makes invalid states impossible; and .mli files that presents modules like classic prose -- no hedges, contortions, or obscurities that undercut the reader's ability to understand the flow of data and the pathways through which it flows.
"Expression, carrying the elegance that comes from compressed energy, is like a perfectly tuned stringed instrument: the strings are taut to exact degrees to correspond to exact pitches that stand in exact relations to one another. The pitches and their relations exist before the strings are tuned. Each string is tuned to a pitch and the results are judged by comparison to this pre-existing reality. A musician tuning an instrument is not finished until everything is exactly right, but once it is exactly right, there is simply nothing left to do." -- Clear and Simple as the Truth: Writing Classic Prose, Thomas, Turner.