5 ms·

> We built an Android app in Haskell because Python was too hard for loading shared objects. Can you elaborate the process? The only reference I could only fi

> We built an Android app in Haskell because Python was too hard for loading shared objects. Can you elaborate the process? The only reference I could only find this: https://wiki.haskell.org/Android https://wiki.haskell.org/Android. How did you end up developing/deploying your UI?

shae 3y ago
We used reflex-frp, so our app was a webview that worked on localhost and Android. The docs say it also works on iOS but we don't have an iPhone. The process was learning Functional Reactive Programming, then learning reflex-frp, then getting a contract with obsidian (creators of reflex) for one hour a week where we could ask questions. ( https://github.com/reflex-frp/reflex-platform https://github.com/reflex-frp/reflex-platform ) We had a grant requirement to create a phone client for Tahoe-LAFS, a Python application with a bunch of dependencies, including ZFEC, a forward error correction library. ( https://tahoe-lafs.readthedocs.io/ https://tahoe-lafs.readthedocs.io/ ) ( https://github.com/tahoe-lafs/zfec/ https://github.com/tahoe-lafs/zfec/ ) We needed bug for bug compatibility with the Python codebase, so I ran Tahoe on localhost and tested the Haskell client against the Python server. We used servant to build the API, since it builds both client and server side from the same description. ( https://hackage.haskell.org/package/servant https://hackage.haskell.org/package/servant )
- penguin_booze 3y ago
  Thanks for your notes. Any chance your app is on the Play store so that I can check it out?
  - shae 3y ago
    I don't know if it's been approved yet, but it's open source: https://whetstone.private.storage/privatestorage/privatestoragemobile/ https://whetstone.private.storage/privatestorage/privatestor...
    - shae 3y ago
      I wrote a blog post https://shapr.github.io/posts/2023-07-25-android-app-in-haskell.html https://shapr.github.io/posts/2023-07-25-android-app-in-hask... I hope this helps
  - shae 3y ago
    I just checked, it hasn't been approved yet. Should be named "private storage" when it does show up in the app store. Even so, it won't be useful until you have a Tahoe-LAFS shared magic folder. Hopefully we'll get funding to make a default shared folder for getting started!
shae 3y ago
From my personal viewpoint the most beneficial things we did: 1. mostly pair programming, so we all knew the current state of the codebase and the path forward 2. When we didn't understand something, we wrote a separate small prototype of that feature / library / reference to teach ourselves how it worked. ( async, monad transformers, lenses, many reflex features ) 3. We paid Obsidian for a one hour a week meeting to help us when we couldn't figure it out by ourselves. ( https://obsidian.systems/ https://obsidian.systems/ ) 4. nix for cross compilation and build / dev automation 5. Several hours a week of explicit teaching each other what we knew. This might should go first in the list, as the culture of being open and teaching was a massive benefit. We had one hour a week where the nixpert taught nix, one hour a week where I taught beginning Haskell, another hour a week where I taught Advanced Haskell (things I was learning that might help). We also had two hours a week where we all got together and worked on the stickiest problem along the path to shipping. Most software dev jobs I've had want me to "do the thing" and have zero time left over for teaching / training others. I wanted to take the opposite approach and this paid off far more than my already wild hopes.
- meejah 3y ago
  I would personally keep "pair programming" at the top of the list, this _really_ helps everyone learn. Even more importantly, it tightens the loop between "write code, review code, change code, merge it finally" since you're basically doing all of that "at once" in the best case.

shae 3y ago

We used reflex-frp, so our app was a webview that worked on localhost and Android. The docs say it also works on iOS but we don't have an iPhone. The process was learning Functional Reactive Programming, then learning reflex-frp, then getting a contract with obsidian (creators of reflex) for one hour a week where we could ask questions. ( https://github.com/reflex-frp/reflex-platform https://github.com/reflex-frp/reflex-platform ) We had a grant requirement to create a phone client for Tahoe-LAFS, a Python application with a bunch of dependencies, including ZFEC, a forward error correction library. ( https://tahoe-lafs.readthedocs.io/ https://tahoe-lafs.readthedocs.io/ ) ( https://github.com/tahoe-lafs/zfec/ https://github.com/tahoe-lafs/zfec/ ) We needed bug for bug compatibility with the Python codebase, so I ran Tahoe on localhost and tested the Haskell client against the Python server. We used servant to build the API, since it builds both client and server side from the same description. ( https://hackage.haskell.org/package/servant https://hackage.haskell.org/package/servant )

penguin_booze 3y ago
Thanks for your notes. Any chance your app is on the Play store so that I can check it out?
- shae 3y ago
  I don't know if it's been approved yet, but it's open source: https://whetstone.private.storage/privatestorage/privatestoragemobile/ https://whetstone.private.storage/privatestorage/privatestor...
  - shae 3y ago
    I wrote a blog post https://shapr.github.io/posts/2023-07-25-android-app-in-haskell.html https://shapr.github.io/posts/2023-07-25-android-app-in-hask... I hope this helps
- shae 3y ago
  I just checked, it hasn't been approved yet. Should be named "private storage" when it does show up in the app store. Even so, it won't be useful until you have a Tahoe-LAFS shared magic folder. Hopefully we'll get funding to make a default shared folder for getting started!

shae 3y ago

From my personal viewpoint the most beneficial things we did: 1. mostly pair programming, so we all knew the current state of the codebase and the path forward 2. When we didn't understand something, we wrote a separate small prototype of that feature / library / reference to teach ourselves how it worked. ( async, monad transformers, lenses, many reflex features ) 3. We paid Obsidian for a one hour a week meeting to help us when we couldn't figure it out by ourselves. ( https://obsidian.systems/ https://obsidian.systems/ ) 4. nix for cross compilation and build / dev automation 5. Several hours a week of explicit teaching each other what we knew. This might should go first in the list, as the culture of being open and teaching was a massive benefit. We had one hour a week where the nixpert taught nix, one hour a week where I taught beginning Haskell, another hour a week where I taught Advanced Haskell (things I was learning that might help). We also had two hours a week where we all got together and worked on the stickiest problem along the path to shipping. Most software dev jobs I've had want me to "do the thing" and have zero time left over for teaching / training others. I wanted to take the opposite approach and this paid off far more than my already wild hopes.

meejah 3y ago
I would personally keep "pair programming" at the top of the list, this _really_ helps everyone learn. Even more importantly, it tightens the loop between "write code, review code, change code, merge it finally" since you're basically doing all of that "at once" in the best case.