Hacker News Reader

Comment by grumpyprole | Hacker News Reader

> Where are the types?

OCaml supports type annotations practically anywhere, if you want to add them. Alternatively, you can use an editor that supports querying or showing types for bindings. VSCode and Emacs support this.

> Remember recursion? How about linked lists?

A lot of beginner material uses List to introduce algebraic data types, inductive and equational reasoning - but you don't have to use them. In fact, the standard library encourages Seq instead over List.

It's a shame the author did not get past the basics, as there are many interesting comparisons to be made. For example, OCaml 5 effect handlers are a very interesting alternative to Rust's Async.

View on HN

> A lot of beginner material uses List to introduce algebraic data types, inductive and equational reasoning - but you don't have to use them. In fact, the standard library encourages Seq instead over List.

I have repeatedly found this the hardest part of learning OCaml - it seems really difficult to find a tutorial that explains how to write OCaml as a real developer would working with production OCaml. Like, I don't need another explanation of sum types or recursion, these are things I'm already using regularly. I'm more interested in the things that OCaml does uniquely that I won't have seen in other languages.

For example, which sequence type should I be using most often? And how often should I be using refs/mutability? And there's lots of alternate stdlibs - should I be dipping into those? What does unit testing typically look like for an OCaml project (and what about other forms of testing)?

It's also very difficult to search for these sorts of things, because I feel like a lot of the results I get are for students learning OCaml as an introduction to functional programming, so questions like "how do I reverse a list" are answered by showing a clever recursive function that reverses a list, as opposed to the List.rev function.

I am not the author, but I'm in a similar situation (right down the Rust background and trying out OCaml for AoC), and I'd love to get past the basics, but it's very difficult trying to find worthwhile resources to do that with.

Some of your questions might be answered in this book (free online version): https://dev.realworldocaml.org/

Cool to see I'm not the only one in this situation...

I want to like the language very much, so that is helping. That CIS310something or other course that is on Youtube is pretty cool, although a little slow for me (this is usually my issue with tutorials) but I did find the book online and that is great. I definitely hear you on the search results thing...

I started declaring all my types manually just because that's what I'm used to but switched back just because I feel like matching the 'standard'. I will definitely admit to a dodgy AOC solution (hard-coding with magic values).. but overall I'm enjoying it quite a bit.

I would personally recommend trying out F#. :) Answers below are for F#.

> For example, which sequence type should I be using most often?

You should basically default to list. If you need assignment and indexing or a 2D structure, use array. If you're writing generic processing code, use sequences if you can. Use sequence if you need lazy sequences.

> And how often should I be using refs/mutability?

Only when you need. I most often use mutability when interacting with unmanaged code, translating some Python or other imperative code before transitioning it to be more functional, and inside classes to manage internal state. Otherwise, I don't.

> And there's lots of alternate stdlibs - should I be dipping into those?

I'm not familiar enough with the OCaml ecosystem, but F# doesn't have this problem. F# has its own core library and for everything else, you just reach out to .NET.

> What does unit testing typically look like for an OCaml project (and what about other forms of testing)?

I personally use FsUnit, specifically the XUnit flavor. https://fsprojects.github.io/FsUnit/xUnit.html. FsUnit is an F# DSL over NUnit and XUnit, so it fits in well with F# and functional thinking but also plugs into the IDEs and `dotnet test`.

> In fact, the standard library encourages Seq instead over List.

Uhu? Never heard about Seq before! Seems to have been introduced in 4.07 which was released 5 years ago, which is basically yesterday in terms of stdlib api. Set and Map, sure, but Seq? Lists are ubiquitous and they are indeed a central data structure in ocaml code. For anybody also wondering, Seq is a datatype for iterators (ie thunked lists).

The Seq module has more functions than the List module. There are also more of_seq functions than of_list throughout. 5 years ago the compiler standard library was not a serious proposition, it is becoming more so now.

> the compiler standard library was not a serious proposition, it is becoming more so now.

This is actually one of my grief with OCaml. I wish I didn't have to use Core. I don't look much at the std library anymore.

My other grief is async (Lwt or Async). It forces to use monads which don't look very pretty in OCaml. That being said, I haven't looked at what OCaml 5.0 bring to the table on that front. This was my experience 5 years ago basically...

For 5.0+ you might want to look at https://github.com/ocaml-multicore/eio for how effects can make async much more pleasant

There will also be DynArrays in the stdlib from 5.2: https://github.com/ocaml/ocaml/pull/11882

Author here: Totally hear you there, the post was literally just like it says 'first impressions'. Will most definitely be posting a few updates as I progress farther and try to make some comparisons :)

Glad to hear there is more to come! I do think OCaml 5 not only keeps the language relevant but also makes it even more interesting.

Right but in practice most OCaml code does not have explicit types.

Using an editor that shows type inlays (e.g. VSCode) helps a lot but not fully because a lot of types are inferred as generics.

You're also correct that you don't have to use lists, but again most OCaml code does.

> Using an editor that shows type inlays (e.g. VSCode) helps a lot but not fully because a lot of types are inferred as generics.

That is because they are generic most of the time.

This is also fun when using `#trace`in the REPL and all you see is `<poly>` instead of the "real" value

Right but being overly generic makes them hard to understand. Generics are kind of like "compile time dynamic types" and they have many of the downsides of runtime dynamic types:

* intent of the author not clear

* auto-complete etc. doesn't work as well

* type errors not caught as early (for generics this means you get super confusing type errors)

Obviously some functions are intended to be generic (e.g. operations on containers) but typical OCaml code seems to contain functions that are actually only called with one type - and the author only intended for them to be called with one type - yet they get inferred as generic.

> Right but being overly generic makes them hard to understand.

Oh yes, I'm not arguing against that or your other points. I just wanted to express that the types being inferred as generic is not an error, but by design.

Right, I didn't mean to imply otherwise. Just that that design has big downsides.

Actually generic types can make reasoning about code much easier. This is the opposite of runtime dynamic types. Generic types tell you what the code doesn't (and cannot) do. Any generic type basically cannot be inspected or unpacked, see the paper "Theorems for free" for examples.

> Right but in practice most OCaml code does not have explicit types.

Most OCaml code use .mli which does have types. This is the recommended practice but I noticed a lot of beginners coming from other languages are reluctant to use them (because of duplication). It's a simple idea but I think it's a strong point of OCaml and it makes easier to program "in the large" than Haskell for instance.

But .mli files do not help with the "no types in the source code" problém. You need LSP (Merlin) to "see" the types anyway. Only adding the signature in the samé (.ml) file helps against that problém.

And I did not experience any advantage of separate signature files so far, but I also haven't written anything large in OCaml (>100 kLOC).

> But .mli files do not help with the "no types in the source code" problém

It partially helps since it forces you to have types where they matters most: exported functions

> And I did not experience any advantage of separate signature files so far,

100kLoc is already quite big! I'm starting to think I'm an outlier since a lot of people don't see the benefits :)

For me, it helps because I really don't want to see the implementation when I use an API. If I need to look at the implementation, it means the interface isn't well specified. All I need should be in the interface: types, docs, (abstract) types. And no more.

Typically, an .ml file will have more than what is exported, types won't be abstract but will have a concrete implementation, and type signatures may be missing. How would it feels like to use list if only https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.ml was available, instead of https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.mli? and that's not the most compelling example since it's a simple module where the main type isn't abstract. Generally speaking, giving up mli means giving up on encapsulation which is one of the primary tools to deal with large programs.

Haskell forces you to say what is exported from a module, but the module user can only see the names. To see the signatures, you need to rely on generated doc or look it up on the code.

Arguably, since OCaml has includes, it suffers from the same problem, your ".mli" may have tons of include and it becomes harder to see what's exported without an external tool

> It partially helps since it forces you to have types where they matters most: exported functions

But the problém the OP has is not knowing the types when reading the source (in the .ml file).

> How would it feels like to use list if only https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.ml was available,

If the signature where in the source file (which you can do in OCaml too), there would be no problem - which is what all the other (for some definition of "other") languages except C and C++ (even Fortran) do.

No, really, I can't see a single advantage of separate .mli files at all. The real problém is that the documentation is often worse too, as the .mli is autogenerated and documented afterwards - and now changes made later in the sources need to be documented in the mli too, so anything that doesn't change the type often gets lost. The same happens in C and C++ with header files.

How do you do encapsulation without an mli? can you hide the type implementation to the module user? can you ensure the exported functions (which are all of them without an mli) maintain your type invariant?

> the real problém is that the documentation is often worse too, as the .mli is autogenerated and documented afterwards

Of course, that would defeat the purpose of having interfaces and is incredibly bad practice. People do that when they try to fix an already broken codebase. It's actually pretty ironic that people who care about type safety (which I is why they use OCaml in the first place) don't value (or understand) things like encapsulation.

> How do you do encapsulation without an mli?

In OCaml you can't. If I could I wouldn't care about interface files, because I wouldn't need them.

I find Rust is really effective in this regard. From my understanding of the capabilities of mli files, Rust's visibility modifiers are even more powerful in terms of effectively hiding implementation details and maintaining invariants, but they're all written inline in the source code (with the `pub` keyword).

I agree that the encapsulation capabilities of mli files are great, but I don't see why they need to be written in a separate file (apart from the obvious reason: that's how OCaml does it, and you can't just change a language's design just because you don't like one bit of it!)

> You're also correct that you don't have to use lists, but again most OCaml code does.

If the list is not being used in a critical section, what's the problem? The implication here is that OCaml is slow or inefficient. OCaml is often orders of magnitude faster than other high-level languages (e.g. Python). Arrays in OCaml can result in some very fast code.

Reply on news.ycombinator.com