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.
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).
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 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.
> 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.
> Milner received the Turing Award in 1991 in large part for his work on ML. The award citation includes this praise: "ML was way ahead of its time. It is built on clean and well-articulated mathematical ideas, teased apart so that they can be studied independently and relatively easily remixed and reused. ML has influenced many practical languages, including Java, Scala, and Microsoft's F#. Indeed, no serious language designer should ignore this example of good design."
What does 'award citation' mean in this context? Surely it can't mean the blurb around the original award back in '91.
It appears to be part of a biography that one can find for every Turing award winner. It's unclear when these blurbs were written or for what specific purpose.
OCaml 4.08 should be released quite soon with better error messaging, matter of month or two, I think. Too bad the expected GDB/DWARF integration didn't land in time. Hopefully next release...
It is really puzzling to me, but I think this is true. I saw a comment on Reddit where someone said ReasonML had a pleasant syntax. I suppose if you have always dealt with C-style syntax, ReasonML might seem more familiar. However if you have tried a LISP or even Haskell/another ML family language, the syntax will probably seem like a major impediment to your productivity. However, having witnessed people moving to ReasonML from JavaScript, I have noticed that that initial familiarity makes a difference. Meanwhile LISP flavors languish because of their "alien" syntax.
I think the ReasonML parser and formatter have numerous issues that'll keep it from being adopted more widely.
Especially with nested expressions, the inability to find mismatched parens and braces ultimately turned my team's experiment with it sour.
The base language's grammar is said to have inconsistencies, but I think Reason's 1:1 matching while keeping older constructs makes translating very difficult. There is a tool to do so, but it's lossy.
That said, I use Reason React for a small front end project at work and sort of wish that the ppx for JSX wasn't tied to Reason, so that vanilla OCaml could be used instead.
An example of lossy translation from Reason -> OCaml:
OCaml is more of a multi-paradigm language than Haskell. It's not purely functional, so you can easily fallback into imperative code if you need (you can use mutable variables, I/O, mutable arrays, hashmaps, for loops, while loops, etc.). It's also object-oriented (though this feature is not widely used) and has a very powerful module system that few other languages can compare to.
What I like about it from a learning perspective is that it makes a transition into functional programming much simpler than it would be with Haskell, where you have to completely change the way you program from the very beginning.
Ocaml is a bit easier to reason about w.r.t. performance (time/space complexity), and the code is a bit clearer if you're coming in cold after not having seen parts of a codebase for a while. Spent ~10 years at a Haskell shop, and currently at an Ocaml one, and was a Standard ML hacker prior to the Haskell job. Done some F# in there too, although for the most part that just feels like ocaml w/ some cleaned up syntax and a nice interop with the rest of the .net ecosystem.
From a nontechnical perspective, some changes in the Haskell community and ecosystem also turned me off on it starting around 2011, and I find the ocaml one to be a bit more up my alley.
I believe OCaml isn’t as strict about side-effects as Haskell, so if you don’t want the side-effect ceremony Haskell sort of forces on you, OCaml might be a good choice. Also, OCaml is strict by default and had a fairly good compiler.
> I believe OCaml isn’t as strict about side-effects as Haskell, so if you don’t want the side-effect ceremony Haskell sort of forces on you, OCaml might be a good choice. Also, OCaml is strict by default and had a fairly good compiler.
Probably anyone who's interested here knows, but it may be appropriate to point out that you are using the word 'strict' in two different senses, first in the informal sense of being restrictive, and second in the formal sense of strict evaluation (which is why it makes sense to say that OCaml is less strict, and yet strict by default).
Considering neither is the language I use for work, but just as a hobby, I often forget how to write code in these languages after a while. The amount of time to get back on track to write idiomatic OCaml is almost instantaneous as opposed to Haskell.
Disclaimer: I've written far more OCaml code than Haskell, so maybe my opinion may be biased.
Yes, writing Haskell definitely takes a mental context switch. You kind of have to abandon the traditional style of programming in order to transition into it. Pretty similar to what writing Prolog feels like for example. In contrast, it seems like there's a more direct line between languages like OCaml/Lisps versus C/Java.
Although it's very brief, they touch this topic in the intro: "OCaml does a great job of clarifying and simplifying the essence of functional programming in a way that other languages that blend functional and imperative programming (like Scala) or take functional programming to the extreme (like Haskell) do not. Having learned OCaml, you'll be well equipped to teach yourself any other functional(-inspired) language."
This course is for teaching students who know how to program but are new to functional paradigm. The way I understand the above is that OCaml is impure, so it's easier to have some parts in imperative style to get unstuck and move forward at first. That may reduce frustration for some students. Then over time, as the functional approach sinks in, you move to a purer style (with sometimes imperative parts, but well encapsulated). Haskell would be more like "let's jump at the deep end of the functional pool" --- which can work for some too.
I had hoped to use Haskell for my company, but found it much too complicated. OCaml skips a great deal of the complexity of Haskell, while still having the advantages of a static functional language. I find it exceptionally practical.
strictness by default, and a slightly more pragmatic way of life. Haskell quickly goes into categorical like composition (Traversable . Lens . Foldable). I think for the average population this is too quick. Ocaml feels like solid battle tested fast typescript (pardon the caricature :).
I'm currently developing a web app with a Haskell backend and a ReasonML (OCaml with a different syntax) frontend. I'd been interested in ReasonML for a while and so far it's been a great experience, but overall I wouldn't say I prefer it to Haskell. I've been using Haskell for many years and so the simplicity advantage isn't there for me. I also miss strongly some of the major Haskell conveniences like generic programming, type class derivation, higher kinded types, and yes Monads. I'm not a huge fan of the OCaml record system as it frequently gets confused and requires type annotations. In fact I've generally found OCaml to be substantially worse at type inference than Haskell, requiring frequent type annotations and cluttering up the code. Haskell's learning curve is steeper, but it is simpler in some ways, especially once you're familiar.
I think where ReasonML/OCaml wins hands-down is its compiler. Bucklescript (and I've heard similar things about other compilers, but can't vouch for it) is lightning quick, and the community has gone leaps and bounds to make it super easy to bootstrap (including with create-react-app). GHC can do amazing things but it's not the fastest out there, and the compiler for the JS backend is abysmally slow. The code Bucklescript produces is very high quality and performant. The library ecosystem is reasonably strong and I expect (but haven't done much testing) that because of the strictness and relative simplicity of the language, library code would tend to be pretty performant and easy to use. I've never found myself in OCaml wondering what string type I should use, or attempting to parse some absurdly complex type hierarchy in a library.
I think for a frontend project, to most programmers I would recommend ReasonML. For one thing, I think even most without experience with FP would find ReasonML to be a giant improvement over Flow (which infuriates me as a type checker), and it doesn't take a ton of time to learn. ReasonReact is a pretty sweet library and I prefer it to React even setting aside language choice. Compared to Haskell, its strictness means it doesn't require a special runtime, generate slow/impenetrable code, or hog tons of resources -- all things that are issues in frontend Haskell. For those who really want to use Haskell on the frontend I'd recommend PureScript instead (also you get the bonus of a kickass record system).
For backend, I think OCaml will get you up and running sooner, but in the long run you're going to find yourself missing the type system and language features Haskell has. GHC's speed on the backend is tolerable (especially if you use nix), and I think Haskell is competitive in performance to OCaml (perhaps better with optimization). Most importantly, I think Haskell is second to none when it comes to correct implementations of business types and logic, creating powerful and reliable abstractions, and eliminating boilerplate, and I think that forms a greater advantage in backend code.
Was there a reason you didn't go the Haskell -> Js route? Less mature but benefits of keeping the same language would have trumped the downsides? Besides compilation speed you mentioned...
I'd love to hear more on the compile to Js scene from someone experienced like you. Do you have a 'weblog'?
Ocaml has 100% less bikeshedding and no propensity for unending puritanical holy wars. It's a language for getting things done, as opposed to thinking about finding a way to do something that satisfies an obsessive compulsive desire to eliminate 100% of sides effects for no practical reason.
Except we've been waiting how many years for actual multicore support and ad-hoc polymorphism (or anything approaching it)...?
No, OCaml really isn't a language where things move forward; quite the opposite.
Also, if you had actually written any Haskell code you'd know it's not about eliminating any side effects, it's about denoting them in the type system. Your comment reeks of someone who hasn't actually used either of these languages.
Readit News
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.
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.
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.
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.
[1]: http://loup-vaillant.fr/projects/ussm/
[2]: https://github.com/LoupVaillant/Monokex
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.
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.
Advice or opinions on the topic are welcome!
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.
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.
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.
https://www.wilko.com/en-uk/wilko-graph-pad-a4-50-sheets-80g...
They are ridiculously cheap but the paper is lovely and they work fantastic with my ballpoints of choice.
I buy them 16 at a time.
And you can interop between reason and Javascript!
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.
Deleted Comment
http://dev.realworldocaml.org/toc.html
> Milner received the Turing Award in 1991 in large part for his work on ML. The award citation includes this praise: "ML was way ahead of its time. It is built on clean and well-articulated mathematical ideas, teased apart so that they can be studied independently and relatively easily remixed and reused. ML has influenced many practical languages, including Java, Scala, and Microsoft's F#. Indeed, no serious language designer should ignore this example of good design."
What does 'award citation' mean in this context? Surely it can't mean the blurb around the original award back in '91.
It appears to be part of a biography that one can find for every Turing award winner. It's unclear when these blurbs were written or for what specific purpose.
Dead Comment
Deleted Comment
Especially with nested expressions, the inability to find mismatched parens and braces ultimately turned my team's experiment with it sour.
The base language's grammar is said to have inconsistencies, but I think Reason's 1:1 matching while keeping older constructs makes translating very difficult. There is a tool to do so, but it's lossy.
That said, I use Reason React for a small front end project at work and sort of wish that the ppx for JSX wasn't tied to Reason, so that vanilla OCaml could be used instead.
An example of lossy translation from Reason -> OCaml:
https://reasonml.github.io/en/try?rrjsx=true&reason=DYUwLgBA...
> You might think this course is about OCaml. It's not.
> This course is about making you a better programmer.
What I like about it from a learning perspective is that it makes a transition into functional programming much simpler than it would be with Haskell, where you have to completely change the way you program from the very beginning.
From a nontechnical perspective, some changes in the Haskell community and ecosystem also turned me off on it starting around 2011, and I find the ocaml one to be a bit more up my alley.
Good idea to learn both, anyway :-P
Edit: compilation speed too, huge difference
Probably anyone who's interested here knows, but it may be appropriate to point out that you are using the word 'strict' in two different senses, first in the informal sense of being restrictive, and second in the formal sense of strict evaluation (which is why it makes sense to say that OCaml is less strict, and yet strict by default).
Disclaimer: I've written far more OCaml code than Haskell, so maybe my opinion may be biased.
[1] http://keleshev.com/composable-error-handling-in-ocaml
[2] https://victor.darvariu.me/jekyll/update/2018/06/19/ppx-tuto...
This course is for teaching students who know how to program but are new to functional paradigm. The way I understand the above is that OCaml is impure, so it's easier to have some parts in imperative style to get unstuck and move forward at first. That may reduce frustration for some students. Then over time, as the functional approach sinks in, you move to a purer style (with sometimes imperative parts, but well encapsulated). Haskell would be more like "let's jump at the deep end of the functional pool" --- which can work for some too.
I think where ReasonML/OCaml wins hands-down is its compiler. Bucklescript (and I've heard similar things about other compilers, but can't vouch for it) is lightning quick, and the community has gone leaps and bounds to make it super easy to bootstrap (including with create-react-app). GHC can do amazing things but it's not the fastest out there, and the compiler for the JS backend is abysmally slow. The code Bucklescript produces is very high quality and performant. The library ecosystem is reasonably strong and I expect (but haven't done much testing) that because of the strictness and relative simplicity of the language, library code would tend to be pretty performant and easy to use. I've never found myself in OCaml wondering what string type I should use, or attempting to parse some absurdly complex type hierarchy in a library.
I think for a frontend project, to most programmers I would recommend ReasonML. For one thing, I think even most without experience with FP would find ReasonML to be a giant improvement over Flow (which infuriates me as a type checker), and it doesn't take a ton of time to learn. ReasonReact is a pretty sweet library and I prefer it to React even setting aside language choice. Compared to Haskell, its strictness means it doesn't require a special runtime, generate slow/impenetrable code, or hog tons of resources -- all things that are issues in frontend Haskell. For those who really want to use Haskell on the frontend I'd recommend PureScript instead (also you get the bonus of a kickass record system).
For backend, I think OCaml will get you up and running sooner, but in the long run you're going to find yourself missing the type system and language features Haskell has. GHC's speed on the backend is tolerable (especially if you use nix), and I think Haskell is competitive in performance to OCaml (perhaps better with optimization). Most importantly, I think Haskell is second to none when it comes to correct implementations of business types and logic, creating powerful and reliable abstractions, and eliminating boilerplate, and I think that forms a greater advantage in backend code.
EDIT: this turned into quite the essay...
Our lucky day :)
Was there a reason you didn't go the Haskell -> Js route? Less mature but benefits of keeping the same language would have trumped the downsides? Besides compilation speed you mentioned...
I'd love to hear more on the compile to Js scene from someone experienced like you. Do you have a 'weblog'?
Edit: Have you tried Scala.js by any chance?
Have you ever considered js_of_ocaml (https://github.com/ocsigen/js_of_ocaml)? What were your reasons for choosing ReasonML?
Could you elaborate? Ocaml has monads? Do you mean convenient do-notation for monads, or something else?
No, OCaml really isn't a language where things move forward; quite the opposite.
Also, if you had actually written any Haskell code you'd know it's not about eliminating any side effects, it's about denoting them in the type system. Your comment reeks of someone who hasn't actually used either of these languages.
http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/bas...
Static functional ... lisp?