Oliver, I understand. But... we are swimming in a sea of imperative programmers. A lot of FP is not obviously better for them.
>From my POV, this is Elm's greatest strength and weakness. It would be so easy to be a PureScript and corner a hardcore niche, where 'power' is everything. Elm has a larger goal - to bring FP to the masses. I am sure abstractions will come in good time, but they will be added carefully with a lot of thought. So... I totally understand, but there's not a lack of 'powerful' FP out there, there's a lack of FP for the masses. This is extremely challenging in all sorts of ways, and an open question of whether it's even possible. But this I believe is what Elm is aiming to do. Who knows whether it will fail or not. No one really knows. I know it's worth a shot though! John On Thu, 24 Nov 2016 at 11:34 Oliver Searle-Barnes <[email protected]> wrote: > I'm definitely still in the process of moving my thinking into a > functional approach (currently working through Programming Haskell and Bartosz > Milewski <https://www.youtube.com/user/DrBartosz>'s Category Theory > series on youtube, both recommended by other Elmers so thanks!). The lack > of abstraction in Elm does seem like a major stumbling point at the moment, > the problems I mentioned above are abundantly obvious for anyone that > starts to use it (I say this with big love for Elm). I want more people to > be able to enjoy Elm but these issues make it very difficult for beginners > or even mid-level developers to get going quickly. > > > On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote: > > On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes <[email protected]> > wrote: > > The fact remains though that I don't feel I can offer a sound > justification as to why it's far more complicated to do these things in > Elm. Elm strives to be easy for users to understand, in this area it is > decidedly more complicated than the existing alternatives. > > > The class of problems you described is precisely the class of problems > that Object Oriented Programming solves easily. > It is the class of problems where, as a library developer, you provide and > API and you allow the client to do multiple implementation of an interface, > (e.g. the interface of a web-component or the interface of a debounceable > app). > > Implementing something that solves this issue is non-trivial because it > can be a source of chaos (complexity). > Approaching the Expression Problem > <https://en.wikipedia.org/wiki/Expression_problem> Elm chose defer > solving it for later implementing only a few practical facilities like > toString (allows extension of cases without recompilation) > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
