4 ms·

We built an Android app in Haskell because Python was too hard for loading shared objects. We started from nothing in January, shipped the app last month. We

by shae 3y ago

We built an Android app in Haskell because Python was too hard for loading shared objects. We started from nothing in January, shipped the app last month. We have 2.5 developers.

penguin_booze 3y ago
> 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.
AndrewKemendo 3y ago
That sounds amazing, can you discuss your dev/prod environments please? Link to product? Thanks!
- shae 3y ago
  The whole thing is open source, pretty sure this is accessible without login: https://whetstone.private.storage/privatestorage/privatestoragemobile/ https://whetstone.private.storage/privatestorage/privatestor... Dev environment was our laptops, obsidian's "ob run" is friendly and helpful (but doesn't work well with haskell-language-server). Dev environment was also our Android phones. We used nix for cross compilation and build automation, lucky for me the other main dev is really good at nix.
  - AndrewKemendo 3y ago
    Ah nix! Ok thank you very much
pjmlp 3y ago
Why not Kotlin then?
- shae 3y ago
  We don't know Kotlin. We both have some prior Java experience, but it's not our preference. Since the original codebase is in Python, I would have used that if possible, but I spent eight weeks failing to load a shared object into a Python interpreter on Android. That got us to this past January. I have had a Haskell job before, though I was entirely unfamiliar with Android dev. In two days I was able to load a shared object into a Haskell interpreter on Android, so we tried that route.
  - pjmlp 3y ago
    I see, given the pain of using the NDK, and having to make use of JNI for any meanigful Android API, that approach seemed quite strange, when only having to target Android, hence the question.

by shae 3y ago

We built an Android app in Haskell because Python was too hard for loading shared objects. We started from nothing in January, shipped the app last month. We have 2.5 developers.

penguin_booze 3y ago

> 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.

AndrewKemendo 3y ago

That sounds amazing, can you discuss your dev/prod environments please? Link to product? Thanks!

shae 3y ago
The whole thing is open source, pretty sure this is accessible without login: https://whetstone.private.storage/privatestorage/privatestoragemobile/ https://whetstone.private.storage/privatestorage/privatestor... Dev environment was our laptops, obsidian's "ob run" is friendly and helpful (but doesn't work well with haskell-language-server). Dev environment was also our Android phones. We used nix for cross compilation and build automation, lucky for me the other main dev is really good at nix.
- AndrewKemendo 3y ago
  Ah nix! Ok thank you very much

pjmlp 3y ago

Why not Kotlin then?

shae 3y ago
We don't know Kotlin. We both have some prior Java experience, but it's not our preference. Since the original codebase is in Python, I would have used that if possible, but I spent eight weeks failing to load a shared object into a Python interpreter on Android. That got us to this past January. I have had a Haskell job before, though I was entirely unfamiliar with Android dev. In two days I was able to load a shared object into a Haskell interpreter on Android, so we tried that route.
- pjmlp 3y ago
  I see, given the pain of using the NDK, and having to make use of JNI for any meanigful Android API, that approach seemed quite strange, when only having to target Android, hence the question.