8 ms·

Introduction to OCaml

229 points by jxub 8y ago

foobaw 8y ago
OCaml was a required course in school for me. It was immensely useful and allowed me to think differently about programming (I only knew Java,C,C++ at the time).
SniperOwl 8y ago
more like introduction to getting a job at Jane Street
- gaius 8y ago
  more like introduction to getting a job at Jane Street I interviewed at Jane Street years ago, back when I was quite active in the OCaml community, got to the on-site rounds but didn't get an offer (a lucky escape it turns out, tho' I was pretty disappointed at the time). Anyway - OCaml wasn't even mentioned during their process. I think they just assume they'll have to teach it anyway.
  - devmunchies 8y ago
    > a lucky escape it turns out How so?
    - gaius 8y ago
      How so? Well, I didn't even think to ask about this, but a friend of mine turned down their offer because they have no remote working. Like me, he didn't actually WFH that often but the lack of an option to do so occasionally was a deal-breaker for him, and it would have been massively inconvenient for me too. I ended up joining a very similar firm who were a bit more relaxed about it (who worked in C++ and Python mostly).
      - mi_lk 8y ago
        Would you mind sharing the company's name? In terms of size, engineering culture and industry, I can only think of twosigma who is similar to janestreet.
        gaius 8y ago
        I've already doxxed myself enough for one day ;-)
meritt 8y ago
In addition to books/tutorials/etc, I've found reading the source to unison [1] was a great way to see a more tangible example of using OCaml to create software [1] https://github.com/bcpierce00/unison https://github.com/bcpierce00/unison
zumu 8y ago
Awesome. I've been getting into OCaml lately, and it's great to see new resources. This bodes well for future adoption. For those looking for a slightly more comprehensive source, check out https://dev.realworldocaml.org/ https://dev.realworldocaml.org/ (no affiliation).
kasajian 8y ago
where's the PDF version?
- Normal_gaussian 8y ago
  The wonderful thing about a (relatively) plaintext site like this is you can 'print' it into whatever random format you want.
- dmbaturin 8y ago
  It will appear when (and I hope it's when rather than if) I complete the series. Then I'll typeset it properly and release the source under CC-BY-SA or another free license and make PDFs from it.
therein 8y ago
My compilers course in college was taught in OCaml. The first semester of the course was spent on teaching functional programming and OCaml and the second semester was spent on implementing a compiler that compiled a restricted subset of OCaml. It is a pleasure to write a tokenizer and a lexer in OCaml.
- howenterprisey 8y ago
  Did you use parser combinators or what?
  - nv-vn 8y ago
    I assume OCamllex and OCamlyacc (or the various other alternatives like Sedlex and Menhir). The OCaml standard distribution is very compiler-writing-oriented, so to speak, and comes with tools for parsing out of the box. A lot of newer projects use parser combinators, but there are far fewer examples of how to use them (like the plZoo) and most people are already familiar with lex/yacc, so I imagine most courses would choose to use those.
    - therein 8y ago
      Correct, good guess. :)
kccqzy 8y ago
Do not forget the Real World OCaml book! I personally found it to be very well written. Available both online and as a printed book published by O'Reilly: https://v1.realworldocaml.org/v1/en/html/index.html https://v1.realworldocaml.org/v1/en/html/index.html
- mi_lk 8y ago
  You probably want to go with https://dev.realworldocaml.org/ https://dev.realworldocaml.org/ , which is a in-progress rewrite of v1.
  - laylomo2 8y ago
    The v1 version has not aged well unfortunately. I _highly_ recommend just reading the dev version.
  - wrycoder 8y ago
    This is a key piece of information. Thank you!!
stcredzero 8y ago
Do not make it REPL-centric. Real life programs are not developed in the REPL. Include examples of complete programs. In certain environments/languages, real programs are developed in the REPL. Real programs, managing billion dollar portfolios, natural gas scheduling, and the payroll of Fortune 500 companies have essentially been "developed in the REPL."
- dan-robertson 8y ago
  Ocaml is not one of those environments. The repl is of limited value in ocaml as the language is not dynamic enough to use it. Much of the language is built on its module system and the repl requires one to write an entire module and (it’s signature) at once. This makes the repl very much inferior to compiled ocaml. The article suggests that the repl is of use for finding the type of things. This is only half true. Consider the following: type 'a my_extra_args = foo -> bar -> 'a val some_fn : (int -> unit) my_extra_args Now suppose you want to know the type of the function so you ask at the repl: utop> some_fn;; val - : (int -> unit) my_extra_args And now if you want to know how to call this function you need to try to guess arguments until a type error expands the type. Alternatively you could use compiled ocaml, write your programs in a sensible editor and then query the type using Merlin (a program to provide ide-like features to editors for ocaml) On the other hand, I would expect a Common Lisp tutorial to talk about the repl as real world programs are written with the repl (but also in files)
- jorge-fundido 8y ago
  I interpreted that as not making his "intro to ocaml" REPL-centric, so that things like the build tooling gets covered.
- Scarbutt 8y ago
  I read that as do not make your program depend on REPL features.
- SomeHacker44 8y ago
  I sort of lost interest in what else the author had to say at this early point, despite having been interested in OCaml for many years. (Referring, for context, to the "Do not make it REPL-centric" comment in the article.) In Common Lisp, Clojure, Scheme/Racket and Haskell, I constantly develop with the REPL. I also use it in other languages such as Ruby which are not necessarily REPL-centric. I find that I write much better (less buggy) code, faster, in a language with great support for a REPL.
frisco 8y ago
OCaml is a great language. We looked really seriously at using it at my startup for some critical things a while ago, when the company was very young, because some of the team knew it and we were inheriting a small code base in it. Ultimately immaturity of tooling (eg ocamlp4 vs ppx) and near total lack of library support killed it for us. (We ultimately went with C++.) Good luck trying to use gRPC in it, for example: there are like three different "protocol buffers" libraries that all implement different parts of it and which are incompatible with each other. While Clojure and Scala have their weaknesses, being on the JVM and being able to re-use all of that Java infrastructure was such a massive advantage. OCaml seems awesome and I wish I could use it more, but don't underestimate how much time you'll spend fighting with opam (and a lot of things just aren't in opam at all, or the opam version isn't compatible with your OS, but there's an apt package for it, but oh no what is going on) and just trying to get to talk to the rest of your stack.
- nikofeyn 8y ago
  i am curious if you considered f#.
  - frisco 8y ago
    We didn’t. I’ve heard good things about it, but my understanding is it’s windows/mono, and we run all Linux in production, which seems like a pain to navigate. (F# is CLR right?) Maybe this isn’t that big of an issue in reality but we had a reason to specifically consider OCaml, and once we passed on it, had strong biases to otherwise avoid things considered exotic.
    - systems 8y ago
      F# runs fine on Linux, and it compatible with dotnet core, and have a very good emacs mode If you have more questions on F# i recommend the community forum http://forums.fsharp.org/ http://forums.fsharp.org/ I am not an expert, yet, but F# is missing several of the more sophisticated OCaml features, but on the positive side, you have the .net core ecosystem
georgewfraser 8y ago
The ML family languages are still so far ahead of "mainstream" languages in many ways. The first language I ever really learned was SML, my freshman year of college, and I swear there's still a part of me that reaches for "case", even after 15 years and about 1m lines of Java. I've been playing around with an implementation of the ML semantics+type system, using the Go AST as a compilation target. Golang makes a surprisingly great compilation target for a functional language, because Go itself doesn't have any object-oriented baggage. I think there's real potential for a functional companion to Go, much like F#::C# and Scala::Java.
- kornish 8y ago
  Totally agree, and would love to see something with Go interop gain serious adoption. Thought it might have been Oden [1] for a while, but the project seems to have petered out. [1]: http://oden-lang.github.io/ http://oden-lang.github.io/
  - tybit 8y ago
    That’s a real shame. Everything about the go runtime is great, which is in complete contrast to the language itself imo.
- jnbiche 8y ago
  > I've been playing around with an implementation of the ML semantics+type system Sounds cool. Is it open source? I've attempted to write some ML interpreters and compilers, but I've always hit a brick while when I try to move from a basic "mini-ML" type of language -- which is relatively straight forward -- to one including pattern matching.
  - georgewfraser 8y ago
    It's here [1]. I've made some good progress on the typechecker while on vaca. Still looking for a better name : ) [1] https://github.com/georgewfraser/funlang https://github.com/georgewfraser/funlang
- 8y ago
nv-vn 8y ago
For those considering learning OCaml, I thought I'd share my (admittedly biased) thoughts about the language as a long-time user (well... roughly 4.5 years). Out of all the languages I've learned, OCaml is one of the few that I would consider to be a "sweet spot" language. A lot of people seem to have one language that they tend to fall back to when they're not sure what else to use because they find it most practical, whether or not they enjoy using it as a language. Out of the languages I know, it's pretty much between Java and OCaml for me, with OCaml being much more ergonomic. Writing OCaml code is much more relaxing than most other languages I've encountered because everything is quite predictable once you know the core language, but it features a multitude of tools that you can use to approach any task (OOP, modules, functional programming, imperative, low-level, high-level, metaprogramming, etc.). I also think that OPAM is one of the best language package managers around (for example, it comes with native support for having multiple copies of the OCaml toolchain installed in parallel). Finally, Reason+BuckleScript have become really nice and for web programming I think they offer one of the best options. There's still a few things that are far from perfect, though. OCaml still lacks an equivalent to Haskell's typeclasses and that makes designing good generic libraries a pain (it's still possible using modules+functors, but it takes a little boilerplate because it's not implicit). As a side effect of this, the standard library is pretty fragmented between the official one (aka "things we used to write the compiler so you can keep them if you want"), the Batteries library (which is essentially what the standard library would be if the official one was "finished"), and Jane Street's Core library (which replaces the standard library altogether). The problem is that this extends into basically all of OCaml. For such a small language, there's little room for all the competition and that means that a lot of libraries either don't exist or aren't actively maintained. That said, most libraries are a breeze to implement and for the real-world code that I do write, they are hardly a distraction 99% of the time. The only other downside is that OPAM isn't compatible with NPM, which means that BuckleScript (the OCaml->JS compiler) has a totally separate ecosystem from the native compiler. Tl;dr, if you're looking for a very general language to learn and don't care about having to implement your own libraries, OCaml is one of the best choices out there. If you're doing JS programming, it's worth taking a look into ReasonML/BuckleScript. If you're interested, feel free to ask me any questions about the language/ecosystem/learning.
- 8y ago
alkonaut 8y ago
What are the biggest differences between OCaml and F#? If I wanted to learn/use an ML style language 2018, for what purposes should I use or learn one over the other?
- nv-vn 8y ago
  F# is very much focused on gaining real-world usage by making it compatible with .NET. It has a lot of features that heavily target this, so for example the object system is built to be compatible with the .NET style of classes/objects (but sadly, they ditched the OCaml way of doing this, which IMO is much better). This introduces many inconsistencies in the type system and some clumsy syntax, which is pretty much a deal-breaker for me. However, these features are very specific to more advanced parts of the language. If FP+.NET or library support is a must for you, F# is probably the best choice by far. Also, F# does a great job at interfacing with the GUI parts of .NET, so if you need GUI (or Windows support) it is definitely the right choice. The core language is still quite elegant and a joy to use. I think if you have the choice not to use F#, though, that OCaml is generally nicer to use. It offers a ton of features that I find myself missing in F#, like a much more powerful module system, a more advanced approach to OOP, a cool macro system, and so many more (polymorphic variants, better exceptions/soon to be an effects system, ...). In general, I find the syntax to be slightly more predictable for OCaml, but a lot of people still prefer F#'s syntax (which is indentation-based, btw) so I wouldn't focus on that point. Overall, I think they fit different niches. I've had to use F# quite a few times and it's by no means a bad language, but after using OCaml extensively I feel disappointed by F# a little bit like how I'd feel disappointed if I had to write a project in Java.
xamlhacker 8y ago
I loved OCaml as well but the lack of libraries pushed me to another ML variant: F# on .net platform. With .net core and F# tooling around it gradually maturing, it is a solid cross-platform functional language.
girzel 8y ago
I thought this was a pretty great introduction. Part 2, in particular, finally helped me understand function type signatures in ML languages: the fact that, under the hood, functions only accept a single argument, and the way the type signatures are presented are merely an aesthetic cleanup of what it actually looks like (which would include more parentheses to indicate associativity). One of the examples did refuse to compile for me, and I felt Part 1 was still too light on basic syntax. I tried to do the exercise at the end of Part 1, about prompting for, squaring, and printing an integer. This works: let this_integer = read_int () let _ = print_int (this_integer * this_integer); print_newline () But this doesn't: let this_integer = read_int () in let _ = print_int (this_integer * this_integer); print_newline () And nothing in the tutorial explains why that should be so -- at least not that I could find. I've also yet to see a really good explanation of when you need to use parentheses for grouping and when you don't -- this is the only part of the language that really feels like a "syntax error" to me. Like, "Look, ocaml is clean and doesn't need to use all this extraneous syntax! Except when it does." Anyway, good introduction.
- nv-vn 8y ago
  So the reason for this is actually because OCaml has 2 types of expressions, which is sort of confusing. The first is a top-level and the second is just a normal expression. In top-level expressions, they are implicitly put into scope. If you've seen any of the ";;" in tutorials, this indicates that you're working in the top-level (although these are pretty much always automatically inserted assuming you're not running a REPL). Now, if you're not in the top-level, you need to use the `let x = ... in ...` syntax, where the `in` is roughly analogous to a semi-colon. So the reason the first works is because the REPL runs at the top-level, and the second would only work inside of a function.
  - girzel 8y ago
    Okay, I think I get it... And if you're not at top-level, ie you're in a function definition, you actually can't use "let" without an "in". That is a little weird, but not terrible. Thanks for the explanation.
- 8y ago
gfiorav 8y ago
Super late to the party but, if you love OCaml and ML languages, check out Elixir. Runs on the Earlang machine and this inherits all its libraries. It takes more than a page from patterns and conditional method bodies. Love it.
- willtim 8y ago
  Like Erlang, Elixir is still a "dynamic" language with no static types, it would have been great if it had introduced ML semantics to the Erlang/BEAM world, but this would have been tough to retrofit.

229 points by jxub 8y ago

OCaml was a required course in school for me. It was immensely useful and allowed me to think differently about programming (I only knew Java,C,C++ at the time).

SniperOwl 8y ago

more like introduction to getting a job at Jane Street

gaius 8y ago
more like introduction to getting a job at Jane Street I interviewed at Jane Street years ago, back when I was quite active in the OCaml community, got to the on-site rounds but didn't get an offer (a lucky escape it turns out, tho' I was pretty disappointed at the time). Anyway - OCaml wasn't even mentioned during their process. I think they just assume they'll have to teach it anyway.
- devmunchies 8y ago
  > a lucky escape it turns out How so?
  - gaius 8y ago
    How so? Well, I didn't even think to ask about this, but a friend of mine turned down their offer because they have no remote working. Like me, he didn't actually WFH that often but the lack of an option to do so occasionally was a deal-breaker for him, and it would have been massively inconvenient for me too. I ended up joining a very similar firm who were a bit more relaxed about it (who worked in C++ and Python mostly).
    - mi_lk 8y ago
      Would you mind sharing the company's name? In terms of size, engineering culture and industry, I can only think of twosigma who is similar to janestreet.
      - gaius 8y ago
        I've already doxxed myself enough for one day ;-)

meritt 8y ago

In addition to books/tutorials/etc, I've found reading the source to unison [1] was a great way to see a more tangible example of using OCaml to create software [1] https://github.com/bcpierce00/unison https://github.com/bcpierce00/unison

zumu 8y ago

Awesome. I've been getting into OCaml lately, and it's great to see new resources. This bodes well for future adoption. For those looking for a slightly more comprehensive source, check out https://dev.realworldocaml.org/ https://dev.realworldocaml.org/ (no affiliation).

kasajian 8y ago

where's the PDF version?

Normal_gaussian 8y ago
The wonderful thing about a (relatively) plaintext site like this is you can 'print' it into whatever random format you want.
dmbaturin 8y ago
It will appear when (and I hope it's when rather than if) I complete the series. Then I'll typeset it properly and release the source under CC-BY-SA or another free license and make PDFs from it.

therein 8y ago

My compilers course in college was taught in OCaml. The first semester of the course was spent on teaching functional programming and OCaml and the second semester was spent on implementing a compiler that compiled a restricted subset of OCaml. It is a pleasure to write a tokenizer and a lexer in OCaml.

howenterprisey 8y ago
Did you use parser combinators or what?
- nv-vn 8y ago
  I assume OCamllex and OCamlyacc (or the various other alternatives like Sedlex and Menhir). The OCaml standard distribution is very compiler-writing-oriented, so to speak, and comes with tools for parsing out of the box. A lot of newer projects use parser combinators, but there are far fewer examples of how to use them (like the plZoo) and most people are already familiar with lex/yacc, so I imagine most courses would choose to use those.
  - therein 8y ago
    Correct, good guess. :)

kccqzy 8y ago

Do not forget the Real World OCaml book! I personally found it to be very well written. Available both online and as a printed book published by O'Reilly: https://v1.realworldocaml.org/v1/en/html/index.html https://v1.realworldocaml.org/v1/en/html/index.html

mi_lk 8y ago
You probably want to go with https://dev.realworldocaml.org/ https://dev.realworldocaml.org/ , which is a in-progress rewrite of v1.
- laylomo2 8y ago
  The v1 version has not aged well unfortunately. I _highly_ recommend just reading the dev version.
- wrycoder 8y ago
  This is a key piece of information. Thank you!!

stcredzero 8y ago

Do not make it REPL-centric. Real life programs are not developed in the REPL. Include examples of complete programs. In certain environments/languages, real programs are developed in the REPL. Real programs, managing billion dollar portfolios, natural gas scheduling, and the payroll of Fortune 500 companies have essentially been "developed in the REPL."

dan-robertson 8y ago
Ocaml is not one of those environments. The repl is of limited value in ocaml as the language is not dynamic enough to use it. Much of the language is built on its module system and the repl requires one to write an entire module and (it’s signature) at once. This makes the repl very much inferior to compiled ocaml. The article suggests that the repl is of use for finding the type of things. This is only half true. Consider the following: type 'a my_extra_args = foo -> bar -> 'a val some_fn : (int -> unit) my_extra_args Now suppose you want to know the type of the function so you ask at the repl: utop> some_fn;; val - : (int -> unit) my_extra_args And now if you want to know how to call this function you need to try to guess arguments until a type error expands the type. Alternatively you could use compiled ocaml, write your programs in a sensible editor and then query the type using Merlin (a program to provide ide-like features to editors for ocaml) On the other hand, I would expect a Common Lisp tutorial to talk about the repl as real world programs are written with the repl (but also in files)
jorge-fundido 8y ago
I interpreted that as not making his "intro to ocaml" REPL-centric, so that things like the build tooling gets covered.
Scarbutt 8y ago
I read that as do not make your program depend on REPL features.
SomeHacker44 8y ago
I sort of lost interest in what else the author had to say at this early point, despite having been interested in OCaml for many years. (Referring, for context, to the "Do not make it REPL-centric" comment in the article.) In Common Lisp, Clojure, Scheme/Racket and Haskell, I constantly develop with the REPL. I also use it in other languages such as Ruby which are not necessarily REPL-centric. I find that I write much better (less buggy) code, faster, in a language with great support for a REPL.

frisco 8y ago

OCaml is a great language. We looked really seriously at using it at my startup for some critical things a while ago, when the company was very young, because some of the team knew it and we were inheriting a small code base in it. Ultimately immaturity of tooling (eg ocamlp4 vs ppx) and near total lack of library support killed it for us. (We ultimately went with C++.) Good luck trying to use gRPC in it, for example: there are like three different "protocol buffers" libraries that all implement different parts of it and which are incompatible with each other. While Clojure and Scala have their weaknesses, being on the JVM and being able to re-use all of that Java infrastructure was such a massive advantage. OCaml seems awesome and I wish I could use it more, but don't underestimate how much time you'll spend fighting with opam (and a lot of things just aren't in opam at all, or the opam version isn't compatible with your OS, but there's an apt package for it, but oh no what is going on) and just trying to get to talk to the rest of your stack.

nikofeyn 8y ago
i am curious if you considered f#.
- frisco 8y ago
  We didn’t. I’ve heard good things about it, but my understanding is it’s windows/mono, and we run all Linux in production, which seems like a pain to navigate. (F# is CLR right?) Maybe this isn’t that big of an issue in reality but we had a reason to specifically consider OCaml, and once we passed on it, had strong biases to otherwise avoid things considered exotic.
  - systems 8y ago
    F# runs fine on Linux, and it compatible with dotnet core, and have a very good emacs mode If you have more questions on F# i recommend the community forum http://forums.fsharp.org/ http://forums.fsharp.org/ I am not an expert, yet, but F# is missing several of the more sophisticated OCaml features, but on the positive side, you have the .net core ecosystem

georgewfraser 8y ago

The ML family languages are still so far ahead of "mainstream" languages in many ways. The first language I ever really learned was SML, my freshman year of college, and I swear there's still a part of me that reaches for "case", even after 15 years and about 1m lines of Java. I've been playing around with an implementation of the ML semantics+type system, using the Go AST as a compilation target. Golang makes a surprisingly great compilation target for a functional language, because Go itself doesn't have any object-oriented baggage. I think there's real potential for a functional companion to Go, much like F#::C# and Scala::Java.

kornish 8y ago
Totally agree, and would love to see something with Go interop gain serious adoption. Thought it might have been Oden [1] for a while, but the project seems to have petered out. [1]: http://oden-lang.github.io/ http://oden-lang.github.io/
- tybit 8y ago
  That’s a real shame. Everything about the go runtime is great, which is in complete contrast to the language itself imo.
jnbiche 8y ago
> I've been playing around with an implementation of the ML semantics+type system Sounds cool. Is it open source? I've attempted to write some ML interpreters and compilers, but I've always hit a brick while when I try to move from a basic "mini-ML" type of language -- which is relatively straight forward -- to one including pattern matching.
- georgewfraser 8y ago
  It's here [1]. I've made some good progress on the typechecker while on vaca. Still looking for a better name : ) [1] https://github.com/georgewfraser/funlang https://github.com/georgewfraser/funlang
8y ago

nv-vn 8y ago

For those considering learning OCaml, I thought I'd share my (admittedly biased) thoughts about the language as a long-time user (well... roughly 4.5 years). Out of all the languages I've learned, OCaml is one of the few that I would consider to be a "sweet spot" language. A lot of people seem to have one language that they tend to fall back to when they're not sure what else to use because they find it most practical, whether or not they enjoy using it as a language. Out of the languages I know, it's pretty much between Java and OCaml for me, with OCaml being much more ergonomic. Writing OCaml code is much more relaxing than most other languages I've encountered because everything is quite predictable once you know the core language, but it features a multitude of tools that you can use to approach any task (OOP, modules, functional programming, imperative, low-level, high-level, metaprogramming, etc.). I also think that OPAM is one of the best language package managers around (for example, it comes with native support for having multiple copies of the OCaml toolchain installed in parallel). Finally, Reason+BuckleScript have become really nice and for web programming I think they offer one of the best options. There's still a few things that are far from perfect, though. OCaml still lacks an equivalent to Haskell's typeclasses and that makes designing good generic libraries a pain (it's still possible using modules+functors, but it takes a little boilerplate because it's not implicit). As a side effect of this, the standard library is pretty fragmented between the official one (aka "things we used to write the compiler so you can keep them if you want"), the Batteries library (which is essentially what the standard library would be if the official one was "finished"), and Jane Street's Core library (which replaces the standard library altogether). The problem is that this extends into basically all of OCaml. For such a small language, there's little room for all the competition and that means that a lot of libraries either don't exist or aren't actively maintained. That said, most libraries are a breeze to implement and for the real-world code that I do write, they are hardly a distraction 99% of the time. The only other downside is that OPAM isn't compatible with NPM, which means that BuckleScript (the OCaml->JS compiler) has a totally separate ecosystem from the native compiler. Tl;dr, if you're looking for a very general language to learn and don't care about having to implement your own libraries, OCaml is one of the best choices out there. If you're doing JS programming, it's worth taking a look into ReasonML/BuckleScript. If you're interested, feel free to ask me any questions about the language/ecosystem/learning.

8y ago

alkonaut 8y ago

What are the biggest differences between OCaml and F#? If I wanted to learn/use an ML style language 2018, for what purposes should I use or learn one over the other?

nv-vn 8y ago
F# is very much focused on gaining real-world usage by making it compatible with .NET. It has a lot of features that heavily target this, so for example the object system is built to be compatible with the .NET style of classes/objects (but sadly, they ditched the OCaml way of doing this, which IMO is much better). This introduces many inconsistencies in the type system and some clumsy syntax, which is pretty much a deal-breaker for me. However, these features are very specific to more advanced parts of the language. If FP+.NET or library support is a must for you, F# is probably the best choice by far. Also, F# does a great job at interfacing with the GUI parts of .NET, so if you need GUI (or Windows support) it is definitely the right choice. The core language is still quite elegant and a joy to use. I think if you have the choice not to use F#, though, that OCaml is generally nicer to use. It offers a ton of features that I find myself missing in F#, like a much more powerful module system, a more advanced approach to OOP, a cool macro system, and so many more (polymorphic variants, better exceptions/soon to be an effects system, ...). In general, I find the syntax to be slightly more predictable for OCaml, but a lot of people still prefer F#'s syntax (which is indentation-based, btw) so I wouldn't focus on that point. Overall, I think they fit different niches. I've had to use F# quite a few times and it's by no means a bad language, but after using OCaml extensively I feel disappointed by F# a little bit like how I'd feel disappointed if I had to write a project in Java.

xamlhacker 8y ago

I loved OCaml as well but the lack of libraries pushed me to another ML variant: F# on .net platform. With .net core and F# tooling around it gradually maturing, it is a solid cross-platform functional language.

girzel 8y ago

I thought this was a pretty great introduction. Part 2, in particular, finally helped me understand function type signatures in ML languages: the fact that, under the hood, functions only accept a single argument, and the way the type signatures are presented are merely an aesthetic cleanup of what it actually looks like (which would include more parentheses to indicate associativity). One of the examples did refuse to compile for me, and I felt Part 1 was still too light on basic syntax. I tried to do the exercise at the end of Part 1, about prompting for, squaring, and printing an integer. This works: let this_integer = read_int () let _ = print_int (this_integer * this_integer); print_newline () But this doesn't: let this_integer = read_int () in let _ = print_int (this_integer * this_integer); print_newline () And nothing in the tutorial explains why that should be so -- at least not that I could find. I've also yet to see a really good explanation of when you need to use parentheses for grouping and when you don't -- this is the only part of the language that really feels like a "syntax error" to me. Like, "Look, ocaml is clean and doesn't need to use all this extraneous syntax! Except when it does." Anyway, good introduction.

nv-vn 8y ago
So the reason for this is actually because OCaml has 2 types of expressions, which is sort of confusing. The first is a top-level and the second is just a normal expression. In top-level expressions, they are implicitly put into scope. If you've seen any of the ";;" in tutorials, this indicates that you're working in the top-level (although these are pretty much always automatically inserted assuming you're not running a REPL). Now, if you're not in the top-level, you need to use the `let x = ... in ...` syntax, where the `in` is roughly analogous to a semi-colon. So the reason the first works is because the REPL runs at the top-level, and the second would only work inside of a function.
- girzel 8y ago
  Okay, I think I get it... And if you're not at top-level, ie you're in a function definition, you actually can't use "let" without an "in". That is a little weird, but not terrible. Thanks for the explanation.
8y ago

gfiorav 8y ago

Super late to the party but, if you love OCaml and ML languages, check out Elixir. Runs on the Earlang machine and this inherits all its libraries. It takes more than a page from patterns and conditional method bodies. Love it.

willtim 8y ago
Like Erlang, Elixir is still a "dynamic" language with no static types, it would have been great if it had introduced ML semantics to the Erlang/BEAM world, but this would have been tough to retrofit.