Hacker News Reader

Comment by wh0knows | Hacker News Reader

I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying to be presented.

This article is most readable to those who already understand OCaml code, and if you can already read OCaml code you already understand these concepts.

View on HN

You claim that OCaml programmers are already versed in category theory but that’s not correct. The first exposure usually comes with concurrency libraries such as Lwt which isn’t very old nor in the standard library, and it provides syntax sugar so you can start being productive right away.

You can write perfectly fine production OCaml programs without knowing what a monad is. Some may, but a lot of OCaml devs don’t care about them.

This is correct, and in contrast to Haskell, where monads are a core part of the language (they are used in the definition of do-notation and list comprehensions) and currently the mainstream way to do IO.

This is misleading. There's no place in the specification of Haskell that specifically defines monads as part of the language. They aren't a language feature. They are a pattern which happens to be expressible in Haskell, and which is supported by libraries:

"Haskell's built in support for monads is split among the standard prelude, which exports the most common monad functions, and the Monad module, which contains less-commonly used monad functions. The individual monad types are each in their own libraries and are the subject of Part II of this tutorial."

https://wiki.haskell.org/All_About_Monads#Monad_support_in_H...

The fact that monads are used to implement parts of the language doesn't make them a core part of it. Techniques used in implementation aren't the same as language features.

I don't think this is true, do notation (see https://www.haskell.org/onlinereport/haskell2010/haskellch3....) specifically depends on the Monad typeclass and exists as syntactic sugar for monadic operators:

> A do expression provides a more conventional syntax for monadic programming

Is do notation a language feature?

it's syntactic sugar

A pedantic distinction without a practical difference. Everyone who learns Haskell learns about Monads.

The Haskell 2010 Report mentions monads all over the place, both in the language and library sections. A Monad instance is literally the only way to do IO in standard Haskell. Monads get special syntax in the form of do-notation and, in an extension, monad comprehensions. It's undeniably a core feature of the language.

By this definition Monads are also a core part of C#, they're not used to do IO but the async/await, IEnumerable, null-safe operators ('?.') are all implementations of Monads (not by coincidence), and above all you have the Linq syntax that you can extend to all of them and any other Monads you care to define.

Yet I imagine most C# programmers have little to no formal understanding of Monads (although quite a few probably do at least know about the link).

That's true, it's just that it's culturally inappropriate to use the full power of monads in C# outside specific scenarios like Linq.

Well that really depends on who's working on it. In my opinion Linq isn't so much the only appropriate way to use monads but rather the most convenient way to demonstrate their full power.

Sorry, I'm only vaguely familiar with C#, but maybe you're right, if they get sugar in the form of LINQ syntax. But regarding async/await, (?.), etc., a language doesn't have special support for vector spaces just because it has many vector spaces in it - and every language has many vector spaces in it.

You can also use monads without knowing anything about categories. It's just a convenient programming pattern.

It's plainly obvious that the GP poster made no such claim about category theory, and the OP post states several times that category theory is merely tangential to the topic.

OCaml (Reason) was my entry point into Typed FP (after a few failed attempts at learning Haskell). The best thing about OCaml is that it allows side-effects, so one can go a long way without having to touch advanced FP.

It is only recently that I've started getting comfortable with concepts cogently explained in this post, so to me it is quite valuable.

As an aside, I think OCaml/Reason/Elm should become the de-facto Typed FP entrypoint for programmers instead of Haskell. That'll help drive more adoption for the paradigm because the ecosystem is a lot more approachable and one wouldn't feel overwhelmed to even begin.

I would add F# to that list, which is an ML language as well.

It works on almost any platform, be it web, mobile, desktop or server via Fable, Xamarin or .NET Core.

It can work as an object-oriented language as well, which makes it easier to interface with C# code, but the documentation makes it very clear that functional is the way to go for F#.

For UIs there are libraries like Fabulous and Elmish, that provide a very similar programming model as Elm does.

You can even share code between all your target platforms:

https://github.com/retendo/FSharp-CrossPlatform

Similar for me. Tried to get into typed FP multiple times with no luck, but then I built a couple of web services with F# + Giraffe and an app in Bolero. It let me take my time getting into FP concepts and incorporate them along the way

I learned typed FP from Haskell, coming from JS, and I'm glad I started there.

It was a bit of a slog, but there are some wonderful books out there. I don't think we should discount the amount of pedagological resources that are available in the language. My favorite is the "First Principles" book.

As a side effect, I found that once I had learned most of Haskell (minus some of the language extensions aimed at type level programming). You pretty much won't find anything in any other typed language that will surprise you.

I understand your point of view and I also don't think my understanding of Typed FP would be complete without sufficient immersion in Haskell. But even with the learning materials, it is too steep a climb for beginner programmers for whom the love of the subject is secondary to their day jobs and regular life.

For people from dynamically typed or static OO background, being able to write functional code with records and sum types alone is a huge quality of life improvement. They should be able to get there with the least amount of effort. Haskell however demands far too much understanding and effort before it can be confidently used in a commercial setting. That excludes mainstream programmers who could otherwise most benefit from the paradigm.

What would you say are some of the main benefits you gained with your journey with Haskell, beyond coming across a lot of abstract concepts?

I'm struggling to justify spending more time on picking up Haskell myself as I can't see clearly what's at the end of that tunnel.

I love Haskell, I find it a joy to write. If you don't really enjoy it then there isn't much reason to spend time on it. It's probably not going to help you with employment. As a side benefit, it's helped me solidify many PLT and CS concepts. That's enough for me to see value in it.

> if you can already read OCaml code you already understand these concepts.

This is a mistake. There are plenty of functional programmers who aren't familiar with these concepts. It's hardly a topic in introductory OCaml...

Yeah this is a common problem. And the real problem is few people both understands the subject but remember the stumbling blocks to learning that subject. There is a Haskell book by Christopher Allen where I think he tested the book out on a friend who didn't know Haskell so that he could be sure that it made sense. That's probably the best way to create material like this.

I majored in math so I was already familiar with some of the concepts, but OCaml is so different from any language I’ve worked in I couldn’t understand how any of it was being applied.

I can try to explain this to you from a math perspective, if you want, but I need to know your math background. Are you familiar with the lambda calculus and its relationship to category theory?

When I first learned Haskell it took a very long time before I started figuring out what monads, applicatives and category theory were, and even then I only ever took a deep dive into monads specifically, basically so that I could do side effects.

For a long time in the beginning I was just learning about the basics, like list manipulation functions, and typeclasses. There was quite a journey in between beginning Haskell and even starting to look at the learning material for monads/functors etc.

As someone who's only spent about an hour reading an intro to Haskell (and none reading about OCaml), I was able to mostly get the gist of what was being said. Not completely. I had to look up the * operator (effectively a comma between arguments, as opposed to a currying arrow), but I would consider the article to have been useful, even if it could've been more useful.

The OCaml type 'a * 'b is the equivalent of the Haskell type (a, b). This type is known as the Cartesian product type, and it's written with a multiplication symbol in type theory (hence the asterisk in OCaml syntax).

The product type is the type of pairs. It's definition is

    x : A
    y : B
    --------------
    (x, y) : A * B

meaning that if x has type A and y has type B, then (x, y) has type A * B.

- Product type on Wikipedia: https://en.wikipedia.org/wiki/Product_type - Product type on the nLab (which is a math-heavy resource): https://ncatlab.org/nlab/show/product+type

I found it useful (or at least educational). I've used Haskell before, but not much OCaml -- the let+, and+, and let* forms were new to me.

If I recall, they are very new to OCaml too.

In your opinion, is this article less helpful than the functor/monad tutorials that predominantly use Haskell?

Reply on news.ycombinator.com