1,452 karma · joined February 20, 2017
Authentication Stuff: hnchat.com:0m9YzMwf4kdLeEnrHt2n 547e7b5026bc47ac8302bf3d213909be [ my public key: https://keybase.io/supermdguy; my proof: https://keybase.io/supermdguy/sigs/fHS654nzPCSpfpoOPNrHUJrgc2jOy21zNsnFwyeLDfs ]
[0]: https://www.nber.org/system/files/working_papers/w34255/w342...
I could have one function that pulls the wallet balance for all users, and then passes it to a pure function that returns an object with flags for each user indicating what action to take. Then another function would execute the effects based on the returned flags (kind of like the example you gave of processing a pending charges table).
The value of that level of abstraction is less clear though. Maybe better testability? But it's hard to justify what would essentially be tripling the lines of code (one function to pull the data, one pure function to compute actions, one function to execute actions).
Additionally, there's a performance cost to pulling all relevant data, instead of being able to progressively filter the data in different ways depending on partial results (example: computing charges for all users at once and then passing it to a pure function that only bills customers whose billing date is today).
Would be great to see some more complex examples of "functional core imperative shell" to see what it looks like in real-world applications, since I'm guessing the refactoring I have in my head is a naive way to do it.
Does anyone have any good resources on how to get better at doing "functional core imperative shell" style design? I've heard a lot about it, contrived examples make it seem like something I'd want, but I often find it's much more difficult in real-world cases.
Random example from my codebase: I have a function that periodically sends out reminders for usage-based billing customers. It pulls customer metadata, checks the customer type, and then based on that it computes their latest usage charges, and then based on that it may trigger automatic balance top-ups or subscription overage emails (again, depending on the customer type). The code feels very messy and procedural, with business logic mixed with side effects, but I'm not sure where a natural separation point would be -- there's no way to "fetch all the data" up front.
I usually start by adding an error type that will be overused by the LLM, and use that to gain visibility into the types of ambiguities that come up in real-world data. Then over time you can build a more correct schema and better prompts that help the LLM deal with ambiguities the way you want it to.
Also, a lot of the chain of thought issues are solved by using a reasoning model (which allows chain of thought that isn’t included in the output) or by using an agentic loop with a tool call to return output.
https://artofproblemsolving.com/wiki/index.php/AMC_historica...
Tech Stack:
Text-To-Speech: ElevenLabs/OpenAI
Speech-To-Text: Faster-Whisper (I used the tiny.en model, about 0.5s latency on my M1 mac)
Language Model: ChatGPT (I used gpt-3.5-turbo-1106)
Others: PyWebView, Silero VAD
Also gradient updates from all nodes would need to get combined at least every few training steps, and it would take a while to sync all gradient updates across the network.