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 <oli...@opsb.co.uk> 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 <oli...@opsb.co.uk> > 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 elm-discuss+unsubscr...@googlegroups.com. > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
