What do you find about bringing it into production? Is it the actual language patterns or the tools? I've done Haskell in production for over a decade now so I am not sure what challenges newcomers face.
I don't agree with the repeated mantra that technology is neutral because the creation, maintenance and promotion of technology requires lots of resources and a lot of choices. A lot of conscious effort goes into creating things, and to change the thing after someone uses it. Make it better, make it safer, make it easier to use, etc. That doesn't feel neutral to me.
That sounds really nice. I have a couple of Haskell servers running on VMs, but the build requirements really slow down the process. I have to use dockers to help cache dependencies and avoid recompiling things that have not changed, but it is still slow and puts out large binaries.
The idea of having a language with most the batteries for a web server built-in is nice. I've never considered Golang, but it is compelling. I'll have to check it out. Though Rust keeps catching my eyes.
> I have to use dockers to help cache dependencies and avoid recompiling things that have not changed, but it is still slow and puts out large binaries.
This is actually the biggest pain point I am running into as well, which significantly slows down the speed of deployment.
> For some reason the very concept of extended families and community engenders deep anger and hostility from some Americans
I think because excessive individualism plays into the hands of large companies. There is an individualist culture that has naturally grown over time in the US, but it has also been pushed by big corporations because if you can't depend on your neighbors and extended family, you need to spend money to fill the gaps.
That's fine for a library or locally run executable, but I've worked on distributed systems in Haskell and you really need logging in place to track what is going on.
Of course, you will have IO somewhere in a executable where you can handle logging so just separate pure and IO and make sure you have good tests for the pure functions. Also, linting to catch partial functions and dangerous lazy ones (or use an alternative prelude).
Sure you want logging and tracing (in the RPC sense not Debug.Trace.trace).
Most of this can still be done from IO places where the pure functions collect enough error information bubbling up (e.g. content and line/col of parser errors etc.) to not need ad hoc print statements for debugging.
Eh sure. But you can always collect/carry decisions in something like an Either. When using arrows or your own monadic bindings it is even possible to abstract this away from view.
I like how your comment can be interpreted in two completely opposite manners. Either it is depressing that coding by hand is something curious, worthy of blogging about, or you are an AI-maximalist deriding lowly meat powered coding. Based on your post history I'll assume the former interpretation :)
Thank you! Noticed you're interested in similar areas. I've also previously done some work on maths problem generation. Similar to letterpaths, the core lib can then be used to power games/other educational apps. As I'm sure you've found as well, It's surprisingly difficult to generate random maths problems aligned to a curriculum!
Core lib is UK-focussed:
https://github.com/RobinL/maths-game-problem-generator
Thanks for taking the time to look. My biggest focus right now is own Numerikos. I hope I can make a better math learning platform. Math games are fun too. There are some nice ideas in the examples you have shared here.