13:08 <discocaml> <lowlowcode_96272> Hello guys, Im struggling to use a file watcher in Ocaml any suggestions ? Fswatch doesnt works on debian, the package is broken...

13:34 <discocaml> <aantron> I'm currently looking into using Cohttp in Dream. In case it helps planning or prioritizing the work

13:34 <discocaml> <aantron> Mainly because cohttp-eio itself has a direct-style API

13:34 <discocaml> <aantron> In how it reads and writes streams

15:33 <discocaml> <lukstafi> Anyone using François Pottier's visitors? There's a few packages that depend on visitors, but not many. Anyone here having considered visitors decided against using them?

15:38 <discocaml> <otini_> Haven’t seen much content about them, but did you check this out? https://www.lexifi.com/blog/ocaml/dune-watch-mode-windows/# maybe the code is reusable

15:39 <gooby323> What's the point of visitors in a functional language x)

15:40 <companion_cube> sometimes visitors are convenient on large sum types (ASTs)

15:40 <discocaml> <lukstafi> Inheritance of default functionality.

15:40 <gooby323> companion_cube: to avoid manually matching you mean?

15:40 <companion_cube> yeah

15:40 <companion_cube> especially, like @lukstafi says, in cases where you have default functionality on 90% of cases

15:41 <gooby323> Right fair enough

15:41 <companion_cube> e.g. a mapper that rebuilds a term as is, except for one case that you want to change

15:43 <discocaml> <otini_> is the AST mapper used in the compiler a visitor? It’s implemented with a record of functions and open recursion

15:43 <companion_cube> yeah

15:44 <companion_cube> it's just a hand-made visitor

15:44 <companion_cube> (AST mapper, AST iterator, etc. — I forget the exact name of the latter)

15:45 <gooby323> It's kinda like OOP recursion schemes in a sense x)

15:47 <discocaml> <lukstafi> Right, hand-made is an option, using classes from `@@deriving visitors` might not buy much.

15:47 <discocaml> <andreypopp> Handmade with copilot

15:49 <discocaml> <gooby_clown> Tbf, since the LSP has the `destruct` command, it could do the same but recurse on subterms as well

15:50 <discocaml> <lukstafi> Hand-made visitors example: slides 13-17 https://ii.uni.wroc.pl/~lukstafi/pmwiki/uploads/Functional/functional-lecture06.pdf

15:53 <discocaml> <lukstafi> The visitors package automates this (and more) but using classes.

16:00 <companion_cube> `visitors` seems nice, but it's another dep, yada yada

16:00 <companion_cube> my biggest qualm with fpottier's libraries is the absence of semver

16:01 <companion_cube> I kind of hate it

16:12 <discocaml> <lukstafi> 😅

16:23 <discocaml> <lukstafi> If we popularized `visitors`, they would become more familiar, which would make using them easier...

16:24 <discocaml> <lukstafi> They solve some issues where Haskell boasts it's better than OCaml.

16:31 <discocaml> <gooby_clown> Such as?

16:44 <discocaml> <lukstafi> Functions that are polymorphic wrt. data shapes, e.g. applicatives.

17:09 <discocaml> <otini_> Do you mean applicative functors? I fail to see how ocaml doesn’t have them (altough my mental model of an applicative functor is `'a option`, so I may be wrong)

17:17 <discocaml> <lukstafi> What `visitors` does, you can do in Haskell by some combination of type classes and kinds... E.g. you can write a function that collects strings from values of various ADT types.

17:29 <discocaml> <anmonteiro> Not really but thanks. There are a few production users outside Dream who’ve asked for releases

17:36 <discocaml> <lukstafi> E.g. https://hackage.haskell.org/package/base-4.20.0.1/docs/Data-Traversable.html

17:40 <companion_cube> can't represent Traversable at all, oh well

17:40 <discocaml> <lukstafi> and `Foldable`

17:46 <discocaml> <gooby_clown> If I'm understanding well, this would force us to either define our types as classes, or wrap our existing types in classes similarly to how we do with modules atm, no? I am not much of a fan of either options to be honest. This also kind of reminds me of F#, where each AST is a class underneath, so you can attach static methods and have a general operator look them up, mimicking higher kinded polymorphism in a sense

18:50 <discocaml> <lukstafi> That's in response to my answer where I claim `visitors` can do these things (sort of, with a stretch) -- so the datatypes remain ADTs and records, but work is done at code generation time. So it's more in the C++ vein.

19:52 <discocaml> <gabyfle> Hey, would you say that the super dope typing system in OCaml makes you weaker in other languages ?

19:52 <discocaml> <gabyfle> In my school we don't learn any OCaml and I'm focus on AI so I have lot of projects in Python

19:53 <discocaml> <gabyfle> The problem is that I love so much OCaml that all my personal projects are done with this language, and when I'm switching to Python, I end up debugging my algorithms so much more than in OCaml because of typing

19:53 <discocaml> <gabyfle> Usually, when I write an algorithm in OCaml and that the type checker pass, it works

19:54 <discocaml> <gabyfle> When writing in Python, my algorithm are super dumb and I pass much more time debugging them than writing them

19:56 <discocaml> <gabyfle> I'm wondering if relying to much on the strong typing is a good thing or not regarding to the logic wise. I've used Owl for some project (and I'm even building a very big one with owl), and even for machine learning or for dealing with NDarrays, I feel like when I'm doing this with OCaml its way more robust than in Python even tho I'm the same guy writing it (btw I'm not using any GPT to write my projects hehe, so the problem is really with my

19:57 <dh`> types are good

19:58 <dh`> the problem is the other languages being unsafe

19:59 <dh`> you will make roughly speaking the same mistakes, but in python you have to debug them at runtime

19:59 <discocaml> <Kali> you may be interested by some of the libraries dry-python makes https://github.com/dry-python

20:00 <dh`> it's definitely possible to become more sloppy, or conversely to specifically be more careful when writing in untyped languages

20:00 <discocaml> <Kali> in particular `returns` https://returns.readthedocs.io/en/latest/

20:00 <dh`> but the latter is also expensive and ultimately dynamically typed languages just aren't a winner

20:01 <dh`> of course, anyone here will tell you that, I'm sure you can find someone in #python or #scheme to tell you that static typing is a straitjacket

20:04 <discocaml> <Kali> dynamically typed languages have their place (easy serialization) but rarely is it much more than a really really annoying footgun when you're trying to anything other than that

20:05 <discocaml> <Kali> as much as i love lua it being dynamically typed meant that nil errors would take forever to find the source of and it was usually just something like forgetting to give an argument

20:05 <companion_cube> tbh "easy serialization" isn't even an argument now

20:05 <companion_cube> it's more "unchecked deserialization", it's not easier than serde and the likes

20:05 <discocaml> <Kali> yeah not if you have good derivers

21:50 <discocaml> <limp.biskit> i actually quite like bits of javascript but every attempt to add a more concrete type system to that language makes it worse, yet working without one is like pulling teeth on a large codebase

21:51 <discocaml> <limp.biskit> the prototype system sucks, classes are weird and typescript working at all is an engineering miracle

21:58 <discocaml> <limp.biskit> i like ruby, but that has it's fair share of issues that make me not adopt it for large codebases

23:31 <discocaml> <darrenldl> not much point in always restricting yourself to the low(est) denominator of the domain, cause otherwise what's the point of using ocaml/other language : v

23:31 <discocaml> <darrenldl>

23:31 <discocaml> <darrenldl> but yes i've found myself slow to a crawl in python, while typescript and c# are fine. dynamic typing + asinine name scoping rules makes python a really upsetting choice for me most of the time

23:35 <discocaml> <darrenldl> actually swap "otherwise what's the point of using ..." with just "what's the point"

23:36 <discocaml> <gabyfle> Damn, I'm not alone to find the name scoping in Python disturbing sometimes

23:37 <discocaml> <darrenldl> being only fluent in python does not make you a better python programmer, being pretty fluent in a few good languages makes you a better python programmer, not worse, if anything

23:38 <discocaml> <darrenldl> some colleague brought up python's import not being consistent depending on where you use it

23:38 <discocaml> <darrenldl> compared to ocaml's open and let open in which is the same wherever you use it

23:38 <discocaml> <limp.biskit> i really don’t like python and fail to understand why it endures and ruby doesn’t

23:39 <discocaml> <darrenldl> popularity of tools and languages is a lot of trial by circumstance and luck sadly : v

23:39 <discocaml> <limp.biskit> pythons tooling is horrific though

23:40 <discocaml> <darrenldl> yeah i hate python's domination likewise

23:41 <discocaml> <darrenldl> i will never not be amazed by super large code bases written in python, e.g. borgbackup, but i feel that's also the reason it's so slow in making any changes/overhaul/refactor

23:41 <discocaml> <limp.biskit> the fact pipx exists should be enough to want people to use npm or opam

23:41 <discocaml> <darrenldl> i still have zero clue which one i should use

23:42 <discocaml> <limp.biskit> i guess it’s probably lucky adoption. go has benefited from the same things, although that runtime and tooling is actually compelling

23:42 <discocaml> <darrenldl> oh yeah, python's "functional programming" facilities are also barely useful most of the time because of how few things facilitate that style

23:42 <discocaml> <limp.biskit> google is big (!)

23:46 <discocaml> <darrenldl> go also answers many modern day needs, e.g. green threads, low-level ish code

23:47 <discocaml> <limp.biskit> yeah, go’s runtime is excellent and beat most to the punch

23:49 <discocaml> <darrenldl> go also answers many modern day needs, e.g. green threads+multicore, low-level ish code

23:50 <discocaml> <limp.biskit> they’ll never have effects though 😉