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

61–70 of 82 posts

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

#61

Post by dunefox »

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…

A couple of years ago I gave myself two evenings to setup and start to learn Ocaml. I gave up due to the tooling. Nothing worked, many things weren't obvious or explained. This is much better with Haskell, Rust, F#, ...

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

#62

Post by dunefox »

LAC-Tech wrote: post #47
pkilgore wrote: post #41

Earlier quoted context omitted.

This is fair. It's also a reason the "masses" are going to pick up Go or Rust instead.

Rust has a larger ecosystem, but it's not even on the same planet as ocaml in terms of expressiveness. Kind of disappointed facebook didn't run with ocaml, instead of doing the whole Reason thing. They could have been contributing to and using ocaml directly, instead they decided that programmers will freak out if there's no curly braces.

> but it's not even on the same planet as ocaml in terms of expressiveness.

It's also not on the same planet with tooling pain points.

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

#63

Post by LAC-Tech »

dunefox wrote: post #62
LAC-Tech wrote: post #47

Earlier quoted context omitted.

Rust has a larger ecosystem, but it's not even on the same planet as ocaml in terms of expressiveness. Kind of disappointed facebook didn't run with ocaml, instead of doing the whole Reason thing. They could have been contributing to and using ocaml directly, instead they decided that programmers will freak out if there's no curly braces.

> but it's not even on the same planet as ocaml in terms of expressiveness. It's also not on the same planet with tooling pain points.

I think it is on the same planet. Maybe not wrt ecosystem, but apart from rust having a testing built into the language I find them both about the same.

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

#64

Post by baby »

LAC-Tech wrote: post #48
baby wrote: post #42

Earlier quoted context omitted.

Horrible doc, the configuration files are a made-up language with no extension, it is completely detached from managing the versions of your dependencies, or their source of origin (package manager? vendored? patched? internal?), horrible CLI, transitive dependencies are imported by default and it's hard to not do that, etc. And then you try to use it in combination with opam and you want to blow your head.

- thought the docs were good. Same level as cargo or npm or anything else I've used. - the 'made up langauge' is just s-expressions, not any more made up than NPM using a json file. There's no standard file extension for them though, which is fair. - I'll take your word on the rest of them, I didn't do anything heavy duty

> - I'll take your word on the rest of them, I didn't do anything heavy duty

TBH, that's why you thought the docs were good

> - the 'made up langauge' is just s-expressions, not any more made up than NPM using a json file. There's no standard file extension for them though, which is fair.

The lack of extension is really the problem, as your editor will not format it or add syntax highlighting. It's very 90's

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

#65

Post by Zababa »

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…

> Why else would it be done that way?

My guess would be ease of maintenance. OCaml has a small team of people working on it that are already bringing improvements to the language that are multi year projects (multicore recently, modular implicits may be next and will take a long time too).

On the other hand, from what I understand, they also added to the compiler something to solve this problem for every class of problem that looks like this: https://v2.ocaml.org/manual/tail_mod_cons.html.

That leaves the question: why not fix the stdlib List.map while waiting for the tail modulo constructor? I honestly don't know. My guess would be that it was easy for everyone that wanted to replace it to either do it or use an array, but that's just a guess.

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

#66

Post by Zababa »

baby wrote: post #43
Zababa wrote: post #31

Earlier quoted context omitted.

Dune is a great "window" in my experience with OCaml, it forces you to do more than with every other language but you end up with a better understanding of everything.

I spent so much time reading the horrible documentation of Dune and I don't think I learned much about the internals of OCaml.

I didn't learn about the internals of OCaml either, I learned about dunea and how it works. I feel like I know it better than npm or cargo since I had to do a bit more manually.

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

#67

Post by pkilgore »

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…

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 degree of user experience, the more the "masses" will discover the things that make ocaml great.

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

#68

Post by wink »

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?

Easy to answer for me personally. I don't specifically care about the syntax family of the language, but I found Haskell (and functional Scala) to be pretty much unreadable. I have no problems with Lisp dialects or ML, or C-family or a lot of others... but Haskell with its heavy use of symbols instead of words... nope. I seem to need a certain 'instant hook' from which I can learn. If there are only symbols it won't work. Maybe that's also why I always found reading and writing math much harder than grasping the concepts. (I studied Computer Science, not real Math ;))

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

#69

Post by jolux »

yawaramin wrote: post #54
jolux wrote: post #53

Earlier quoted context omitted.

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_mo…

> 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 about how people use data structures. It’s the standard library’s job to do what is asked of it as efficiently as possible. The best implementation would be specialized for small Ns but they don’t do that either.

Good to hear about TRMC, I haven’t been a daily user of OCaml since 4.07, but it’s good to hear that they’re addressing some of these pain points. I still think Core and Base are a better starting point for real-world applications in general.

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

#70

Post by yawaramin »

jolux wrote: post #69
yawaramin wrote: post #54

Earlier quoted context omitted.

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_mo…

> 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.

Post reply on HN