I agree with you. FP was hard for me to approach even in F#, which doesn't have category theory abstractions built-in. This is sortof the missing manual I wish I had when learning F#.
I use FP for, to borrow again from Scott Wlaschin, BLOBAs or Boring Line of Business Applications. No fancy scientific or math-focused work, just standard business web apps. And it is has been a huge maintainability improvement over previous efforts in VB, C#, and Javascript.
If you haven't already, you should definitely check out MVU. Elm probably has the best beginner docs out there, but I prefer to use F# Elmish nowadays. MVU has a way to handle/isolate side effects that doesn't require hearing the M word. I am working on an article about adapting that to server-side processes as well.
"...previous efforts in VB, C#, and Javascript." -- I'm curious what you did with the JavaScript portion? I've haven't found F# creep into that arena for me yet. It seems very SPA driven and I find BLOBA's best fulfilled by hybrid apps.
Our apps were initially desktop VB apps. Then server-side web apps using WebForms. These sprang up organically over time and often there would be overlap in functionality, which lead to code duplication with subtle differences and heisenbugs. So we started to try to centralize the logic into an API. We also at times had some perf problems due to WebForms regenerating the whole page on every interaction. Between that and WebForms kindof hiding the HTML from us in aspx tags, which meant we had to reverse engineer things like how to style elements, we wanted more direct control over the HTML. SPAs were catching fire at that time, so we migrated to using the front-end/back-end division for our web apps. Which moved us more into the Javascript world for front end. We used jQuery and Angular v1 for a while, then Elm, and now F# (Fable Elmish) for front end apps. For the back-end we used C#, and now F#.
Most of what I described above is for our custom internal system. But we have moved more toward creating cloud-based products, which we also happen to use for ourselves.
Started with Giraffe. They changed the API to chase performance, and I didn't really like where it landed. I experimented with my own over a weekend and that went well enough that we use it in our products. repo link
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you. FP was hard for me to approach even in F#, which doesn't have category theory abstractions built-in. This is sortof the missing manual I wish I had when learning F#.
I use FP for, to borrow again from Scott Wlaschin, BLOBAs or Boring Line of Business Applications. No fancy scientific or math-focused work, just standard business web apps. And it is has been a huge maintainability improvement over previous efforts in VB, C#, and Javascript.
If you haven't already, you should definitely check out MVU. Elm probably has the best beginner docs out there, but I prefer to use F# Elmish nowadays. MVU has a way to handle/isolate side effects that doesn't require hearing the M word. I am working on an article about adapting that to server-side processes as well.
"...previous efforts in VB, C#, and Javascript." -- I'm curious what you did with the JavaScript portion? I've haven't found F# creep into that arena for me yet. It seems very SPA driven and I find BLOBA's best fulfilled by hybrid apps.
Our apps were initially desktop VB apps. Then server-side web apps using WebForms. These sprang up organically over time and often there would be overlap in functionality, which lead to code duplication with subtle differences and heisenbugs. So we started to try to centralize the logic into an API. We also at times had some perf problems due to WebForms regenerating the whole page on every interaction. Between that and WebForms kindof hiding the HTML from us in aspx tags, which meant we had to reverse engineer things like how to style elements, we wanted more direct control over the HTML. SPAs were catching fire at that time, so we migrated to using the front-end/back-end division for our web apps. Which moved us more into the Javascript world for front end. We used jQuery and Angular v1 for a while, then Elm, and now F# (Fable Elmish) for front end apps. For the back-end we used C#, and now F#.
Most of what I described above is for our custom internal system. But we have moved more toward creating cloud-based products, which we also happen to use for ourselves.
Very cool. On the server, are you guys using giraffe? Suave? Freya? MVC?
Started with Giraffe. They changed the API to chase performance, and I didn't really like where it landed. I experimented with my own over a weekend and that went well enough that we use it in our products. repo link