I remember a documentary about learning things to kids, and in order to optimise learning efficiency the optimal ratio for difficult questions should be 1/4. So the children continue to feel good about themselves, while still improving.
So I guess this ratio about easy vs difficult question should be a parameter in such spaced repetition algorithms.
Seeing "Powers of Ten" on TV is an early childhood memory, it really made a lasting impression. Of course I did not remember its name, but now I finally could watch it again! Thank you!
I remember there were data loss, but my account appears to have been recovered. You may try to login again, and with luck, like me you will get back your history.
One thing I really appreciate with gptel is that it is very easy to switch from Claude to something else like a local llm (via ollama or gpt4all for example). And the interface will be similar.
"Purely Functional Programming", I guess mostly Haskell/Purescript.
So this only really mean:
Purely Functional Programming by default.
In most programming languages you can write
"hello " + readLine()
And this would intermix pure function (string concatenation) and impure effect (asking the user to write some text). And this would work perfectly.
By doing so, the order of evaluation becomes essential.
With a pure functional programming (by default).
you must explicitely separate the part of your program doing I/O and the part of your program doing only pure computation. And this is enforced using a type system focusing on I/O. Thus the difference between Haskell default `IO` and OCamL that does not need it for example.
in Haskell you are forced by the type system to write something like:
do
name <- getLine
let s = "Hello " <> name <> "!"
putStrLn s
you cannot mix the `getLine` directly in the middle of the concatenation operation.
But while this is a very different style of programming, I/O are just more explicit, and they "cost" more, because writing code with I/O is not as elegant, and easy to manipulate than pure code. Thus it naturally induce a way of coding that try to really makes you conscious about the part of your program that need IO and the part that you could do with only pure function.
In practice, ... yep, you endup working in a "Specific to your application domain" Monad that looks a lot like the IO Monad, but will most often contains IO.
Another option is to use a free monad for your entire program that makes you able to write in your own domain language and control its evaluation (either using IO or another system that simulates IO but is not really IO, typically for testing purpose).
This is a good write up. Thank you for it. My experience with Haskell only comes from university and the focus there was primarily on the pure side of the code. I'll have a look at how Haskell deals with the pure/inpure split for some real-world tasks. The Lisp way of doing it just seems weird to me, too ad hoc, not really structured.
For being an Haskell and Clojure dev. Data manipulation in Clojure requires a mind shift coming from Haskell. But it feels a lot more straightforward in Clojure. Even if `lens` is incredible. This is like Haskell lenses was were included in the core language if you want. Of course, not type-safe.
This is just that, solving problems in Haskell or in Clojure does not really require the same approach. But both ways are delightful. And personally, Clojure has always felt more natural, even though, I also love the Haskell approach.
One part of the joy that came with using Clojure is that there isn't really any bad choice. For example, I wanted a quick and dirty internal web application for admin purposes. I went with reframe. Why? Because I wanted to try it. And I knew, that I could get things done with it.
This is probably not the easiest "framework" (not sure this is a good name for it) but it was very fun. I think, if I had to progress from just a toy to a really strong, user facing UI, I think it would still be a pretty good choice. If some feature is missing, or something doesn't work as I would have liked, I know it will not be difficult to correct it myself.
I know that this could feel overwhelming, but this is freedom in a world where you expect there exists a single "best practice". As long as the tool is powerful enough it will be fine. On my end, I appreciate the fact there is not a single "web framework" in Clojure. Instead you have tons of libs you can use that work well together because they are all tied with a few common concepts (like ring for example). If you don't like to choose the libs. There are a few people that provide a starter pack with somewhat nice bundle of libs in a single system like pedestal or luminus for only citing two of them.
My recommendation is to not lose too much time looking for the best choice. Most of them will be good.
So I guess this ratio about easy vs difficult question should be a parameter in such spaced repetition algorithms.