Some of this makes me a bit twichy. I think one of Elm's great advantages is that while its type system is good it is also simple. Having tried haskell and quickly drowned I am in favor of keeping the types as simple as possible
Zach On Thu, Nov 24, 2016 at 1:11 PM, John Orford <[email protected]> wrote: > Totally agree with that also. > > I would love a underscore or lo-dash situation where libraries could be > used as petri dishes for future language features... or just doing cool > stuff : ) > > Perhaps, you could add deprecable new features, which could only be > included in experimental packages or something... > > If the libraries or features take make sense, keep them, if not everyone > is aware of that they can be axed... > > On Thu, 24 Nov 2016 at 12:04 Oliver Searle-Barnes <[email protected]> > wrote: > >> Something that I feel isn't acknowledged is that it's ok to have a >> language with more advanced features for library authors than library >> consumers. I don't see that it follows that having more advanced features >> makes the language harder to use for beginners (I'd argue the opposite >> even). I do see your point though that allowing more powerful abstractions >> and maintaining ease of use is perhaps something that more powerful FP >> languages have failed (or not attempted even) to find and careful and >> patient thought is required. >> >> >> On Thursday, 24 November 2016 11:45:38 UTC+1, John Orford wrote: >> >> 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. >> > -- > 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. > -- Zach Kessin SquareTarget <http://squaretarget.rocks?utm_source=email-sig> Twitter: @zkessin <https://twitter.com/zkessin> Skype: zachkessin -- 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.
