I would love to start developing for smartphones, creating a proper #emacs client totally reimagined for the smartphone is long overdue and a project I could really sink my teeth into. You know the popup keyboard on your phone? You think Steve Jobs invented that? No he didnt, Richard Stallman did, it's called a minibuffer. Emacs was doing all this stuff in the 80s, and way better, even.
But I can't help but hate all the frameworks surrounding mobile development, ie React Native, Swift, Flutter etc, but also from my experience as a user, the apps I've tried that were made with alternative #fp frameworks like #LambdaNative, which had to downsample and skew the resolution to fit my phone's screen, so it didn't seem to even feature responsive design; maybe ok for the hospital software they designed it for but not something for creating applications that the people will use out of their own volition.
I'm pessimistic that "there is no alternative" but seeing how nicely #FDroid is coming along, I'm hoping that I may be wrong. Is there anything promising out there in the #mobile#gui#foss space?
Getting interested in #Lean upon reading that the community isn't very concerned about whether it meets constructivists' criteria for theoretical soundness
Just a friendly reminder that if you are struggling with any #Haskell issues and need assistance or someone to talk to, please feel free to join our Haskell discourse using this link: https://discourse.haskell.org. The #FP community is always happy to help!
@dpwiz I am asking because I think the #fp paradigm uniquely enables high-level composable constructs. I would love to see a visual exploration of such.
But if it were for me, I would want essentially gnu #coreutils reimplemented for graphical high-level programming like in a #nocode or #lowcode service.
If I were to write it, I would probably start with #openapi because of the broad adoption of that abstraction, and the market for api operations in small to medium business.
"The focus of my research is applying #fp, in particular #chez#scheme, to low-level problems — the type of situations that usually call for #rust or #c"
— highly recommended talk on programming with serialized data from @vollmerm @ #ELSconf
「 As the name suggests, with purely functional programming, the developer can write only pure functions, which, by definition, cannot have side effects. With this one restriction, you increase stability, open the door to compiler optimizations, and end up with code that’s far easier to reason about 」
— IEEE Spectrum
Hi! I'm a lifelong programmer with a passion for #Scala and good engineering, which has led me in the direction of #FP. As of relatively recently, I'm on the #Typelevel Steering Committee.