Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Real World OCaml – 2nd Edition (2021)

dev.realworldocaml.org

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Real World OCaml – 2nd Edition (2021)

#71

Post by jolux »

yawaramin wrote: post #11
jolux wrote: post #7

Earlier quoted context omitted.

The standard library is quite small and not very usable for modern production applications. As an example a lot of the list manipulation functions are not tail-recursive because the tail-recursive implementation is less elegant.

For the pedagogical purposes of the book, you don't really need Jane Street Base/Core though. Plus it ignores some pretty widespread community libraries (like Lwt) and pushes its own Jane Street version, Async (which incidentally doesn't support Windows). Anyway, this has all been hashed out before.

Yes, I’m aware it’s been hashed out. I was just explaining for the benefit of people not versed in the community why Core is so popular and used in this book, which is focused directly on practical applications of the language.

Re: Real World OCaml – 2nd Edition (2021)

#72

Post by jolux »

yawaramin wrote: post #70
jolux wrote: post #69

Earlier quoted context omitted.

> There is actually a practical justification–simplicity of the implementation. For a function that is going to be written once and called innumerable times, this is a bad justification. You should optimize for the consumers of your library, not for yourself. > For a data structure not meant to be used for large datasets, why optimize for that use case? Because it’s not the job of a standard library to be opinionated…

> Because it’s not the job of a standard library to be opinionated about how people use data structures. Well, they're not being opinionated about it per se, they're just not supporting (up until now at least) highly-optimized use of lists. There are tradeoffs to consider here beyond what we have discussed in this thread. Check the OCaml forum threads on optimizing list mapping for the various considerations.

You characterized this deficiency in light of your own belief that lists should not be used, so I was responding to that part that I disagree with. It’s like Python purposefully crippling lambdas to discourage their use. If you don’t think people should use a feature, just don’t add it.

Incidentally I agree with you about lists and only meant to use it as an example of a place where the stdlib authors chose a simple implementation over one that does what you expect. As soon as I started reading the stdlib source and seeing things like that, I immediately understood why Core exists and realized I wouldn’t be able to trust the stdlib in production. It violates the principle of least surprise. It’s one thing to do stuff like this in Haskell where it makes sense because of lazy evaluation, it’s another to do it in an eager language which acknowledges the need to make concessions to practical usage.

Re: Real World OCaml – 2nd Edition (2021)

#73

Post by yawaramin »

jolux wrote: post #72
yawaramin wrote: post #70

Earlier quoted context omitted.

> Because it’s not the job of a standard library to be opinionated about how people use data structures. Well, they're not being opinionated about it per se, they're just not supporting (up until now at least) highly-optimized use of lists. There are tradeoffs to consider here beyond what we have discussed in this thread. Check the OCaml forum threads on optimizing list mapping for the various considerations.

You characterized this deficiency in light of your own belief that lists should not be used, so I was responding to that part that I disagree with. It’s like Python purposefully crippling lambdas to discourage their use. If you don’t think people should use a feature, just don’t add it. Incidentally I agree with you about lists and only meant to use it as an example of a place where the stdlib authors chose a simple…

Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use.

Also,

> violates the principle of least surprise

I suppose yes if you don't read the docs which point out that it's not tail-recursive, and a few lines below a tail-recursive alternative `rev_map` is given.

Re: Real World OCaml – 2nd Edition (2021)

#74

Post by jolux »

yawaramin wrote: post #73
jolux wrote: post #72

Earlier quoted context omitted.

You characterized this deficiency in light of your own belief that lists should not be used, so I was responding to that part that I disagree with. It’s like Python purposefully crippling lambdas to discourage their use. If you don’t think people should use a feature, just don’t add it. Incidentally I agree with you about lists and only meant to use it as an example of a place where the stdlib authors chose a simple…

Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use. Also, > violates the principle of least surprise I suppose yes if you don't read the docs which point out that it's not tail-recursive, and a few lines below a t…

> Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use.

The point is that this pattern makes sense in a lazy-evaluated language, not that everything Haskell does makes sense. I think it's a less defensible choice than OCaml in most cases.

> I suppose yes if you don't read the docs which point out that it's not tail-recursive, and a few lines below a tail-recursive alternative `rev_map` is given.

I read the docs and I still disagree with the choice made here. There's no need to include two functions when one will do. This is not pragmatism, it's laziness.

Re: Real World OCaml – 2nd Edition (2021)

#75

Post by yawaramin »

jolux wrote: post #74
yawaramin wrote: post #73

Earlier quoted context omitted.

Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use. Also, > violates the principle of least surprise I suppose yes if you don't read the docs which point out that it's not tail-recursive, and a few lines below a t…

> Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use. The point is that this pattern makes sense in a lazy-evaluated language, not that everything Haskell does makes sense. I think it's a less defensible choice th…

> There's no need to include two functions when one will do. This is not pragmatism, it's laziness.

If providing two slightly different ways to do something is laziness, then pretty much every language is guilty of that. Also, Larry Wall: 'Laziness is a virtue' ;-)

Re: Real World OCaml – 2nd Edition (2021)

#76

Post by sweeneyrod »

pkilgore wrote: post #67
cemerick wrote: post #55

Earlier quoted context omitted.

I think there's a lot of strawmen here, many quite analogous to those used to (unfairly IMO) criticize OCaml itself. Complaining about sexprs, when one's baseline is the completely ad-hoc nature of go.mod files, or cargo toml files, is pretty silly. Further, sexprs are a very common general-purpose serialization path for OCaml values, so dune's selection here is hardly arbitrary. Yes, `dune build`, `dune runtest`, an…

I'm trying not to make this just about dune. Dune is curtainly BETTER than, say Make n friend to newcomers. But there's a market for programming languages that OCaml is objectively losing. Can we really not agree that the most popular/recommended build tool requiring you to write a lisp to do basic config probably isn't helping draw new user into the fold? I doesn't have to be cargo. But the more it rhymes with that…

I agree that dune is worse in many important ways than the build systems of languages like Rust and Go (where they were developed at the same time as the language, rather than 20 years later). But dune config files aren't lisp. They're s-expressions, which have the same syntax as lisp but are just static data like json/yaml/toml (and once you get used to them, I think most people prefer them to those).

Re: Real World OCaml – 2nd Edition (2021)

#77

Post by jolux »

yawaramin wrote: post #75
jolux wrote: post #74

Earlier quoted context omitted.

> Well, if you bring up Haskell, let's remember that String is defined as a list of Char, and in production most people seem to use a variety of other replacement string types and everyone will tell you not to use Haskell String for any serious production use. The point is that this pattern makes sense in a lazy-evaluated language, not that everything Haskell does makes sense. I think it's a less defensible choice th…

> There's no need to include two functions when one will do. This is not pragmatism, it's laziness. If providing two slightly different ways to do something is laziness, then pretty much every language is guilty of that. Also, Larry Wall: 'Laziness is a virtue' ;-)

But again that's not a justification. There's no reason for there to be two functions here, other than that it's easier for the implementers. I'm being serious when I say I don't think I've ever seen another standard library that prioritizes ease of maintenance over ease of consumption. Quite possible that I'm missing something! Maybe Common Lisp or another language nobody uses?

Re: Real World OCaml – 2nd Edition (2021)

#78

Post by mirekrusin »

seanstrom wrote: post #60
mirekrusin wrote: post #19

This is great live/github based book. Other great resources are Michael R. Clarkson's (from Cornell) videos [0] and book-like format [1]. I took a lot of inspiration from it when playing with rb-trees [2] and functional, ocaml-looking typescript in general [3]. [0] https://www.youtube.com/playlist?list=PLre5AT9JnKShBOPeuiD9b... [1] https://cs3110.github.io/textbook/cover.html [2] https://github.com/preludejs/rb-tree…

Awesome resources! On a side note have you tried the Rescript [0] or Reason [1] programming languages? They both are based on OCaml and compile to JavaScript. [0] https://rescript-lang.org/ [1] https://reasonml.github.io/

Yes, both are very interesting.

Re: Real World OCaml – 2nd Edition (2021)

#79

Post by yawaramin »

jolux wrote: post #77
yawaramin wrote: post #75

Earlier quoted context omitted.

> There's no need to include two functions when one will do. This is not pragmatism, it's laziness. If providing two slightly different ways to do something is laziness, then pretty much every language is guilty of that. Also, Larry Wall: 'Laziness is a virtue' ;-)

But again that's not a justification. There's no reason for there to be two functions here, other than that it's easier for the implementers. I'm being serious when I say I don't think I've ever seen another standard library that prioritizes ease of maintenance over ease of consumption. Quite possible that I'm missing something! Maybe Common Lisp or another language nobody uses?

Well, you're extrapolating from one example where the standard library doesn't behave as you want, and characterizing the entire library as 'lazy'. I don't agree with that characterization, and as I already said, the justification has been given. You just don't agree with it, that's fine. It's still a valid justification.

Re: Real World OCaml – 2nd Edition (2021)

#80

Post by yawaramin »

_benj wrote: post #45
pkilgore wrote: post #21

The design of OCaml/Reason is the sweet spot of functional programming for me but every time I must deal with Dune after working with the tooling of Go or Rust I want to stab myself in the face repeatedly and I think that maybe that might just be related to the general concept of "masses" + OCaml.

I haven't spent enough time with dune to form an opinion (go and cargo are absolutely marvelous though) but a quick search[0] reveals that dune is not the only option. [0] https://github.com/ocaml-community/awesome-ocaml#package-man... >

The better place to get tooling info is the OCaml Platform page: https://ocaml.org/docs/platform

There you can see that dune is the only actively maintained viable build system for OCaml. The others are all in maintenance mode or deprecated.

Post reply on HN