I've been trying to make this work for a few days and finally I achieved it, the most basic form of a wayland client using unix sockets, and well in other languages it was not difficult at all, I did it in hare, c, typescript (deno), and in the end I wanted to try with a language that I had never used, Haskell, and I learned many things but I still don't know what a monod is, anyway, here I leave a link to the code for those who are interested: https://gitlab.com/-/snippets/3711372 #haskell#programming#wayland
@mangoiv@kosmikus Using a var type which takes a lock makes sense. But MVar seems a bit unfiting, because it can be empty. I was wondering what the argument over atomicModifyIORef or using a TVar would be. It seems like MVar has the best ergonomics and concurrency behavior?
Yeah, It's kinda IORef but I thought that doesn't count because it has less concurrency guarantees.
But I think I get now why MVars are much more useful. I have even used TMVars myself as locks when the action I wanted to do with it contained effects.
The weirdest thing about the AI hype is the claims that computers will become sentient and human-level intelligent.
There’s zero evidence that the human brain (the only thing that we know of that is capable of human-level sentience and intelligence) works like a computer or that it could even be simulated by one.
Some neuroscience points to quantum mechanical effects being at the core of how neurons work, which basically means that we don’t have a clue how the brain really works.
@thomasfuchs Wondering if this is a hype by itself.^^
But if there is really no adequate classical approximation for how our brain works and quantum effects are fundamental to its operation that would truly be interesting.
(Just hope that no one thinks that it solves their free will problem for them.)
Would still leave the question whether some level of "human-like intelligence" can only be implemented by exactly simulating a human brain.
After extensively using the #lens#Haskell library for half a year at work I have now played around with the #optics library again. I am amazed by how much more helpful error messages are with #optics. It’s an amazing library and I would recommend it over #lens whenever you have the choice.
@mangoiv I do not know what you mean. You need to depend on optics-core to provide lenses usable with the library, just because the type of those optics is not a type alias like it is in lens.
@mangoiv Hasn’t been my impression with #optics yet. To me it feels like the type level stuff is "finished". As long as you only define and use existing types of optics you don’t need to worry about it.