imalex

That would've been fun too as a different challenge (I wrote the blog post). My main hesitation was that doing so might prevent me from using the built-in VM/hardware emulators they provide, so I wouldn't be able to easily run my solution.

Wow, that is indeed way cooler than what I knew! Thanks a lot for sharing (I wrote the blog post).

As for square roots, the reason why you can't use the underlying architecture is that it only works on the native i16 type. That's why I had to reimplement integer square root in the Int32 and then fixed point square root using that.

If you're saying that I could just ignore the Int32 part of the code and implement square roots just for the fixed point using the underlying architecture, that's definitely doable, but I'd be concerned about Newton's method (specifically the squaring of x_n) overflowing the fixed point. Maybe it'd work and I haven't thought it through enough. Thanks for the suggestion :D

We built everything by hand. Cordova is our glue to the native side, but React is what really makes the chat stuff tick.

As for the Ruby/JSON stuff, that was also built by hand (actually the very first thing we built before we even had the UI in place). Whenever a conversation is started, the client gets the entire syntax tree from the server and evaluates it to make the conversation happen. We actually thought that pushing the state to the client actually made things easier since the server no longer has to manage the status of many concurrent conversations. It also means faster responses in poor network conditions.

I think the main reason for chatbot platforms to push things to the server is out of necessity because they work across many clients (Messenger, etc) where they don't control the client, and because they may be doing some heavy lifting with NLP that can only be done on the server.

100% agreed. Yet another benefit of a single endpoint is that we rarely have to worry about backwards compatibility. It's a huge tax on engineering time to support those few users who're using a client that's six months old. We don't have that issue.

Yup, Penny tries to focus on your discretionary spending since that's where you have the most agency. She tells you both your non-bills spending (assuming bills are mandatory) and your total spending, so you can get a sense of your spending that isn't basic needs. We also have spending goals which are curated to be mostly discretionary spending (eating out, department stores, etc).

Yup, though our emphasis is more on making finances as relatable and friendly as possible. The chat interface isn't just a skin on top of existing data (which some other chat interfaces can feel like), but completely dictates the entire experience. This is super relevant for our goal of coaching people to better financial health—chat is a great medium for coaching, but a traditional UI would probably be more difficult.