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

51–60 of 82 posts

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

#51

Post by yawaramin »

jolux wrote: post #49
Zababa wrote: post #32

Earlier quoted context omitted.

> As an example a lot of the list manipulation functions are not tail-recursive because the tail-recursive implementation is less elegant. What makes you say this has to do with elegance? This sounds surprising.

Well I’m not certain that’s the case, it’s my guess because the language has a strong academic background and is also used for teaching purposes, and many functions are written like they would be in a textbook chapter on recursion, with the topmost stack frame holding a pointer to the front of the list, meaning you can blow the stack on large inputs. Why else would it be done that way? Certainly possible I’m missing…

It's not just about theoretical elegance. The list data structure is massively inefficient. Using lists large enough to blow the stack with recursion is a really good indication that something has gone really wrong and the program design needs rethinking.

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

#52

Post by Hermitian909 »

clpm4j wrote: post #28

Totally unrelated to the link/book, but sparked a question that I've had for a while (curious to hear any answers) --> when you take an initial look at a programming language that you're completely unfamiliar with, and you glance through the syntax of all the basic constructs, do you ever have a particularly strong reaction (be it negative or positive), and if so have you tried to identify why that might be the case?

1 - At a high level, I ask myself if the language is pushing me towards the pit of success or the put of failure. More concretely I ask myself "given the class of problems appropriate for this language, are good abstractions easier to create than bad abstractions?". If so, I have a positive reaction. If the reverse is true, and it's easier to make bad abstractions (think early Java where functions were not first class), then I have a negative reaction.

2 - If the language is trying to sell you on a certain paradigm? If so, is there a good escape hatch? This at least means a good FFI like that found in Erlang, but also within the language, OCaml's refs which allow you to write imperative code are a great example. Elm is a language that does this badly, 0.19 removed FFIs and the language is much reduced for it.

3. Is packaging a first class consideration of the language? This is one of the places where say, Rust shines and Python really suffers. I'm going to need packages and if managing them is hard I'm going to get mad.

4. Does the language free me from some class of problems? Big positive.

Some languages I've liked: Common Lisp, C, OCaml, Haskell, Python2, Javascript ES5, Racket, Erlang

Some languages I've disliked: Java5 and earlier, C++, Go, Python3, PHP circa 1999

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

#53

Post by jolux »

yawaramin wrote: post #51
jolux wrote: post #49

Earlier quoted context omitted.

Well I’m not certain that’s the case, it’s my guess because the language has a strong academic background and is also used for teaching purposes, and many functions are written like they would be in a textbook chapter on recursion, with the topmost stack frame holding a pointer to the front of the list, meaning you can blow the stack on large inputs. Why else would it be done that way? Certainly possible I’m missing…

It's not just about theoretical elegance. The list data structure is massively inefficient. Using lists large enough to blow the stack with recursion is a really good indication that something has gone really wrong and the program design needs rethinking.

The fact that lists are inefficient doesn’t mean that they should be processed in a maximally inefficient way. I would argue the opposite is true. There’s no practical justification for forcing the compiler to allocate a new stack frame when you can get it to use a jump instead.

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

#54

Post by yawaramin »

jolux wrote: post #53
yawaramin wrote: post #51

Earlier quoted context omitted.

It's not just about theoretical elegance. The list data structure is massively inefficient. Using lists large enough to blow the stack with recursion is a really good indication that something has gone really wrong and the program design needs rethinking.

The fact that lists are inefficient doesn’t mean that they should be processed in a maximally inefficient way. I would argue the opposite is true. There’s no practical justification for forcing the compiler to allocate a new stack frame when you can get it to use a jump instead.

There is actually a practical justification–simplicity of the implementation. For a data structure not meant to be used for large datasets, why optimize for that use case? In any case thanks to TRMC landing in OCaml 4.14+, it's a moot question, we'll be able to have our cake and eat it too. Doubtless someone will add the annotation to the standard library soon enough: https://v2.ocaml.org/releases/4.14/manual/tail_mod_cons.html

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

#55

Post by cemerick »

pkilgore wrote: post #40
rashkov wrote: post #29

Earlier quoted context omitted.

Sorry could you explain your comment some more? Genuinely curious what is bad about dune. Just started using it

We can start with that, upon starting down the road to learning a (IMO great) but very, very different syntax than most other languages in OCaml, Dune then asks you to write a lisp file to do basic configuration and I suspect 90%+ people who want to explore just say "fuck it" the second they internalize this. I'm sure there's a crowd, especially here on HN, that views this as some sort of purity test for the language…

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`, and `dune exec ...` do "work", i.e. each command has its semantics, which are pretty extensively documented IMO. Is the complaint that they're not the same commands that one uses with cargo or whatever?

You're right that opam and dune used to not interoperate much (or at all), but that has changed a lot in the last year or so, to the point that, _if you want_, you don't have to write opam files at all (i.e. they'll be generated from metadata in your `dune-project` file). Again, well documented, at least IMO: https://dune.readthedocs.io/en/stable/opam.html

The "lockfile situation" is pretty good AFAICT. I've been using them for a year+ with good / expected results.

You're right about `dune init` not doing the right things. I believe that's been resolved very recently IIRC, but then again, I can't recall the last language/build tool I used init-like functionality with; I almost always just copy over config/structure from another project I've worked on, and tweak from there.

There are absolutely real critiques of dune, but "it's not cargo" or whatever is silly.

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

#56

Post by whb07 »

LAC-Tech wrote: post #37
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.

What's wrong with dune? I thought it was really good.

I concur as well that Dune is lacking.

Compared to Rust or NPM.

Shoot even dotnet/nugget is significantly ahead of Dune.

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

#57

Post by yawaramin »

cemerick wrote: post #55
pkilgore wrote: post #40

Earlier quoted context omitted.

We can start with that, upon starting down the road to learning a (IMO great) but very, very different syntax than most other languages in OCaml, Dune then asks you to write a lisp file to do basic configuration and I suspect 90%+ people who want to explore just say "fuck it" the second they internalize this. I'm sure there's a crowd, especially here on HN, that views this as some sort of purity test for the language…

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…

Hmm, let's dive a little deeper.

Dune itself is fine, and even great once everything is working. It's just that you have to mug through tons of documentation that's arranged in pure reference format, instead of in a task-based format, before it's up and running.

Sure, dune generates opam files...except for the (some pretty important) parts it doesn't support. I've had to fall back to opam template files in two different projects to express things that dune-project format doesn't support. It's a leaky abstraction over opam format.

The lockfile situation is incredibly rudimentary compared to Go or even to npm. Check out https://go.dev/blog/supply-chain and tell me opam has 1/5th of the capabilities of go.sum checksums and their overall supply chain security. I know this was a concern for you pretty recently: https://discuss.ocaml.org/t/opam-repository-security-and-dat...

Dune init is actually the one really good piece of UX in dune. Being able to run a command and generate a valid dune component (e.g. not having to remember the `(preprocess (pps ppx_bla))` dance and just being able to do `dune init --ppx=ppx_bla` is pretty cool. I feel like 'I just endlessly copy configs from other places' is not really a point of pride. It reminds me of the bad old days of init shell scripts before systemd :-)

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

#58

Post by [deleted] »

jasperry wrote: post #20
daenz wrote: post #14

I'm sure this book is an excellent resource (upon skimming the online version, it looks very thorough and well thought out). I think there is some confusion about who "the masses" are though. I don't think a subchapter titled "POLYMORPHIC VARIANT SUBTYPING" is necessarily for—what I consider—"the masses."

I don't necessarily begrudge the authors for including chapters on advanced topics, it's not like people have to read the whole book. But you raise a valid point. For languages like OCaml that are both large and also veer into PL research territory, some guidance about how many of the advanced topics one needs to understand to be a "real world" programmer could be a big help to the language's adoption.

[deleted]

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

#59

Post by Atalocke »

clpm4j wrote: post #28

Totally unrelated to the link/book, but sparked a question that I've had for a while (curious to hear any answers) --> when you take an initial look at a programming language that you're completely unfamiliar with, and you glance through the syntax of all the basic constructs, do you ever have a particularly strong reaction (be it negative or positive), and if so have you tried to identify why that might be the case?

I had this very experience today! I was looking at some code for markdown parsers (I'm trying to build one in Hare), and I stumbled upon a Nim example. I don't know what it was, but just seeing how complex the author made what seemed like a simple struct to me filled me with dread. I'm sure if I took the time to understand the language it would make sense, but Nim is just one of those languages you need a second glance to understand if you're not already familiar with it.

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

#60

Post by seanstrom »

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/

Post reply on HN