In my extended social circles, people often cite Dave Sirlin's "Playing to Win" on how one should play games citing the "scrub" chapter to justify any behavior allowed by the rules.
Sirlin's argument is that by having some concept of what's ok and what's "cheap", one becomes a scrub who sucks at the game. This didn't seem right at the time, and the more I've played games the less right it seems. In many games, the top players avoid "cheapness" and people who do "cheap moves" are generally bad.
@danluu This is true in rules for communities as well.
After decades of experience, I've decided the best social rule set is "Be Nice, Or Else" with an included list of explicit bad behaviors. This also requires putting in time educating new community members about acceptable behavior.
There's always a way around explicit rules.
(Source, I started the #haskell IRC channel in ~2001 and moderated the #python IRC channel for several years)
Just a friendly reminder that if you are struggling with any #Haskell issues and need assistance or someone to talk to, please feel free to join our Haskell discourse using this link: https://discourse.haskell.org. The #FP community is always happy to help!
⎧ The point is not so much that proofs are easier with Liquid Haskell, but rather that we are in front of an approach that integrates well with a programming language as is, and yet it leverages the power of tools specialized to reason about logic when verifying programs ⎭
"The benchmark results show that #Egison pattern-matching embedded in #Gauche#Scheme is faster than the original Egison interpreter written in [#Haskell]"
The #Haskell security-advisories repo is open for submissions. We will have folks at ZuriHac (and in its Discord) if you want to contribute known/historical issues or help develop our tooling. https://github.com/haskell/security-advisories
I started my show and tell at work yesterday with: “Every company has a crazy person talking about #Nix. I never imagine that one day I would be that person but here we are.”
I gave a quick demo how I could nix develop into a controlled reproducible development environment for one of our projects. Not sure if any of it stuck, but people will have at least seen it once now.
I ported @mattmight’s CPS conversion code (https://matt.might.net/articles/cps-conversion/) to #Haskell and after some fighting with the type system, it worked! To make the interpreters work with the Cont monad, I had to remove recursive lets and hence, functions being able to call themselves recursively, but the rest works fine.
The attached images show the conversion of the Fibonacci function into the CPS version.
The decision to use Ruby for Mastodon was a poor choice, to put it mildly.
The diagram below shows relative energy consumption, with values normalized to the most efficient one. So C, as the most energy efficient, has the value 1.
I wrote the fourth part of my #blog series “Implementing Co, a small programming language with coroutines”. And this time, we add support for channels in Co for inter-coroutine communication. https://abhinavsarkar.net/posts/implementing-co-4/
#Vervis the reference implementation of @forgefed just released a tech preview of their refactored codebase that is based on the Actor Model. A mirror of the codebase can be found on #Codeberg at:
Also CL folks: "I developed an entire #Haskell-like programming language in Common Lisp only to realize its lack of features found in its 50-page standard cousin #Scheme is holding the whole project back"
> The GHC developers are happy to announce the availability of GHC 9.6.2. This release is primarily a bug-fix release addressing a few issues
found in 9.6.2.
We have found a fixpoint! Finally the knot is tied! #haskell
Moving those parts of #haskell's base library that are experimental or low-level GHC interna into a separate package to have a cleaner and more stable base sounds obviously good to me, but the proposal (and related threads) has already over 300 comments: https://github.com/haskellfoundation/tech-proposals/pull/47#issuecomment-1558028287
It shows a kind of rift and distrust between the Core Library Committee and the GHC developers:
> I have little trust in GHC developers to manage changes, and this distrust is not hypothetical or speculative.