03:17 <discocaml> <darrenldl> noob1: no inherent issues - for computer science, you can find open source curriculum that looks on par with what uni provides, if just for programming, then you'll find plenty of resources online

03:20 <discocaml> <darrenldl> there's debate on which lang is best as your first programming lang, and people seem to lean toward "mainstream" ones with very large community, e.g. python, java, but i think ocaml is a pretty alright choice

03:28 <discocaml> <Kali> if i was going to teach someone how to program who didn't know anything about programming, i would likely choose lua or ocaml

03:28 <discocaml> <uberpyro181> personally i think ocaml is quite good educationally, but if you are trying to get a programming job then a more mainstream language may provide more opportunities

03:30 <discocaml> <Kali> ^

09:14 <discocaml> <vompura> Does anyone here think object oriented programming sucks?

09:15 <discocaml> <vompura> I don't mean simply not liking it, but thinking that it is actually bad from a technical point of view?

09:16 <discocaml> <octachron> `sucks` is too broad and pointlessly agressive.

09:17 <discocaml> <vompura> I worked as a Java developer for 7 years and the more experienced I became the closer I was getting to a functional style with heavy use of immutability and closures etc.

09:18 <discocaml> <vompura> Sure, I don't mean to be aggressive, I don't take it that way. I am not a purist either

09:18 <discocaml> <octachron> I tend to think that many OO programming languages ended up accidentally mixing up separate concerns in a non-ideal way while trying to get away from imperative programming languages.

09:20 <discocaml> <octachron> Neither abstraction, nor modularity, nor polymorphism should be tied to an object system.

09:21 <discocaml> <octachron> And I don't know how to characterize the lack of algebraic types and pattern matching.

09:22 <discocaml> <vompura> You make good points

09:22 <discocaml> <vompura> One thing that I think about is how OO seems like a natural progression from imperative

09:23 <discocaml> <vompura> For example in C you often will have a data structure and a file with a load of mehods for manipulating the structure, taking a pointer to the structure as the first argument

09:24 <discocaml> <vompura> So C++ classes would be a natural extension of it, and this makes sense. In this way of thinking, I can't see a huge difference between imperative and OO

09:25 <discocaml> <vompura> Of course OO added all kinds of stuff like inheritance

09:25 <discocaml> <vompura> Inheritance really seems like a bad idea in most cases

09:26 <discocaml> <octachron> Having a bunch of functions manipulating a main data type and taking it as a first main parameter is also how OCaml modules are organized.

09:26 <discocaml> <vompura> We were taught to think how to make code fit into inheritance hierarchies to "reuse" code, but I quickly learned it was an absolute mess

09:27 <discocaml> <vompura> Yeah, in that sense it feels a bit OO-like

09:29 <discocaml> <octachron> I disagree, that's one the point where modularity + abstraction is conflated with objects in OO systems.

09:32 <discocaml> <vompura> What do you mean?

09:32 <discocaml> <octachron> There is no reason to add all other features of object system to solve a code organization problem.

09:36 <discocaml> <vompura> Do you think functional programming produces better results than OO for a given project? Assuming both are well-implemented?

09:39 <discocaml> <octachron> I don't know, even more so when `well-implemented` is doing a lot of heavy lifting.

09:40 <discocaml> <octachron> I prefer to think that functional programming strikes a better balance of expressiveness, complexity and nudging towards correctness.

09:41 <discocaml> <bluddy5> There are things OOP handles better. For example, any time you want to let the users expand functionality, functional programming has a hard time dealing with it.

09:41 <discocaml> <bluddy5> OOP's bundling of code and data, however, while nice in theory, is almost always too constraining.

10:15 <adrien> I'm starting to use alcotest and I'm running processes which write to stderr; is there a way to get that (when a test fail)?

10:19 <adrien> hmmm, that's maybe lwt

10:42 <adrien> yeah, that was lwt: Lwt_process.open_process_full was taking precedence on reading stderr, and Lwt_process.open_process doesn't default to `Keep for ?stderr

10:45 <adrien> ok, that last part was too weird and I can't reproduce it: ?stderr indeed defaults to `Keep

14:09 <reynir> I think I had success with adding %!, but my memory is fuzzy and it may have been something else

14:39 <mithromdir> I was hoping someone might help me with this: https://stackoverflow.com/questions/76574240/is-there-a-way-to-do-interactive-programming-in-ocaml

16:41 <adrien> another alcotest question: is it possible to check that a call to Lwt functions raise an exception?

22:10 <discocaml> <xavierm02_> It there a way to tell the compiler "trust me it's fine" when there is an error `Error: Cannot safely evaluate the definition of the following cycle of recursively-defined modules: Self -> F_Self -> Self. There are no safe modules in this cycle (see manual section 12.2).`?

22:19 <discocaml> <xavierm02_> (I have a module type `Calculus = sig type t val uid : t Type_equal.Id.t ... end` , and am building the calculus obtained by iterating a functor `F : Calculus -> Calculus`, and the `uid` can not simply be added at the end because it is used to simplify coercions. I know I could just have `val uid : unit -> t Type_equal.Id.t`, but I'd prefer just disabling the safety check (locally if possible).

22:19 <discocaml> <xavierm02_> (I have a module type `Calculus = sig type t val uid : t Type_equal.Id.t ... end` , and am building the calculus obtained by iterating a functor `F : Calculus -> Calculus`, and the `uid` can not simply be added at the end because it is used to simplify coercions. I know I could just have `val uid : unit -> t Type_equal.Id.t`, but I'd prefer just disabling the safety check (locally if possible).)