Re: [elm-discuss] Re: Moving on

This thread is really good imho. Uncomfortable? Perhaps. But everyone here has good intentions. >From my POV Elm ain't your usual throw-things-at-the-wall and see what sticks open source project, which is what makes it very very special. And therefore perhaps the community and our BDFL need to

Re: [elm-discuss] Re: Moving on

On Apr 30, 2017, at 8:43 AM, Max Goldstein wrote: > > Fourth, web components were briefly mentioned. Richard gave a talk on these > last year and it seems like everything you need already works. Specifically, on this, no. The virtual DOM API does not make the sort of

Re: [elm-discuss] Re: Moving on

> > First, I'm going to call out the air of ungratefulness and animosity in > this thread. Evan is giving you software for free, and it's software that's > good enough that you invest your time into writing it and commenting about > it. > Just to be clear, in case this is directed at me in

Re: [elm-discuss] Re: Moving on

> > I'm going to call out the air of ungratefulness and animosity in this > thread. Evan is giving you software for free, and it's software that's good > enough that you invest your time into writing it and commenting about it. > You should not expect Elm to move at the same pace as Angular

Re: [elm-discuss] Re: Moving on

This thread is too long to be productive. Please make a new thread, if you wish to continue the discussion here, with a relevant title to the particular part of this conversation you wish to continue in. When a thread gets long like this, hitting multiple topics, it's hard for anyone but those

[elm-discuss] Re: Moving on

Folks. I feel this thread is maybe not the best place to discuss certain details of topics that raised in discussion. I feel there are too much topic being actively discuss right now and it starts to be pretty hard to follow everything. I feel that understanding what others are talking about

Re: [elm-discuss] Re: Moving on

Just to play devil's advocate for a moment; Despite my suggestion, and as much as I'm an advocate for package curation I don't think that it's the right first step towards solving the problem. In my opinion the realistic solution is one that may already have been discussed in the past: 1.

Re: [elm-discuss] Re: Moving on

I think if we are working on the basis of a blessed set of modules one of the requirements should be having several people who can merge a pull request etc. Zach ᐧ On Thu, Apr 27, 2017 at 1:48 PM, Rehno Lindeque wrote: > > This grey list would be backed by a clear

Re: [elm-discuss] Re: Moving on

On Thu, Apr 27, 2017 at 1:48 PM, Rehno Lindeque wrote: > > This grey list would be backed by a clear process of getting things on the >> list that would include a checklist of mandatory things. >> This checklist would be like a rule list and breaking any of the rule >>

Re: [elm-discuss] Re: Moving on

> This grey list would be backed by a clear process of getting things on the > list that would include a checklist of mandatory things. > This checklist would be like a rule list and breaking any of the rule > would have to happen after a serious benefits analysis done under the >

Re: [elm-discuss] Re: Moving on

On Thu, Apr 27, 2017 at 12:59 PM, Wojciech Piekutowski < w.piekutow...@gmail.com> wrote: > Peter, did you mean https://github.com/gdotdesign/elm-github-install for > installing packages with missing Web APIs? > No. elm-github-install allows for too much freedom. What I had in mind was more

[elm-discuss] Re: Moving on

This Week, in April 2017: > > Elm, potential BDFL and community friction... > Just wanted to chip in my 2 cents. I think Evan as BDFL is working for Elm, and I understand and respect his desire to go slow and get it right for the long term. Its very hard to maintain that position when people

Re: [elm-discuss] Re: Moving on

> > Better javascript interop to allow the community to provide the missing > web APIs and effect managers (task ports have been mooted on several > occasions) I'd much rather have the web APIs available natively within Elm, so that javascript interops are minimal/unnecessary. On

Re: [elm-discuss] Re: Moving on

I've been using Elm for about 10 months now and have had an app in production for the last 2, I share the general feeling of this thread. I've addressed Evan directly here because it's impossible not to when discussing these topics, I hope my thoughts are taken as sincere and full of respect.

Re: [elm-discuss] Re: Moving on

Eirik, I think it's a bit unfair to call it "One Correct Way™". The idea is "One Really Good Way that is Reasonably Future-Proof™". Maybe this hasn't been communicated effectively. Also, in production we keep getting run-time errors with third-party libraries that use React, so my experience

Re: [elm-discuss] Re: Moving on

The moment Evan gave the "Let's Be Mainstream" talk and linked to it from elm-lang.org, the pretense that Elm was sheltered in a pre-1.0 world was pretty heavily undermined. Elm has been promoted as being ready for the mainstream. The fact that it bears a version number that is less than 1.0

Re: [elm-discuss] Re: Moving on

That only depends on your definition of good tool vs. bad tool. You're painting a doomsday picture here. In the context of real world usage and mainstream adoption, it isn't so black and white. Java is a hugely popular language, but it has fundamental flaws, like nullable values. Yet there are

Re: [elm-discuss] Re: Moving on

> > There is an underlying premise of Elm that there is One Correct Way™ to > solve a problem in an application written in Elm, it takes "a long time" to > discover the One Correct Way™, and Evan is the only person capable of > doing it. It's not that there's one way of doing it, but that once a

Re: [elm-discuss] Re: Moving on

I used the persistent-cache code once. I just copied the source code into my project. The library readme makes some bold statements, like "it is the right technical choice" to expose a LRU cache for localStorage in Elm. It certainly wasn't the right choice for my use case, where "least recently

Re: [elm-discuss] Re: Moving on

The thing is that this exact kind of cache (LRU) might not work for all people, so it'd be great to have barebones interface to localStorage/sessionStorage/etc. Then higher level abstractions, like persistent-cache, could be easily built on top of it. On Wed, 26 Apr 2017 at 18:24, Mark Hamburg

Re: [elm-discuss] Re: Moving on

Exactly and look at the months old comment at the top of the read me: NOT RELEASED YET — I hope to release it relatively soon, but I cannot make any promises. Until then, please use ports if you want to use localStorage. On Wed, Apr 26, 2017 at 9:22 AM Rex van der Spuy

Re: [elm-discuss] Re: Moving on

That talk was very interesting and very telling since this was a group moving from Elm to PureScript not because they wanted more sophisticated types and more squiggles but rather almost inspite of those aspects and instead because of ecosystem issues. Mark On Wed, Apr 26, 2017 at 2:07 AM

Re: [elm-discuss] Re: Moving on

On Wednesday, April 26, 2017 at 5:07:39 AM UTC-4, Wojtek Piekutowski wrote: > > > https://github.com/elm-lang/persistent-cache? > Wow, that's exactly what I need! -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group

Re: [elm-discuss] Re: Moving on

Forking is already kind of happening. Not per se, but some people decided to stick with 0.16 and FRP. And switched to PureScript for new projects. This still fresh talk covers such a case: https://www.youtube.com/watch?v=9kGoaUqcq4A Brief summary of why they didn't use Elm for other projects They

Re: [elm-discuss] Re: Moving on

On Wed, Apr 26, 2017 at 5:17 AM, John Orford wrote: > My 2c on above... > > 1) web components - once they're a standard they will be a must. > > Perhaps they feel like a necessity now (I am sold) but they're still in a > flux, browsers support bits and pieces, some things

Re: [elm-discuss] Re: Moving on

I agree with a lot of this. I.e. 1) Long standing bugs are indefensible (although interestingly not complained about by Duane). Community contributions should be encouraged 2) Communication. Thing is, Evan is a good communicator. Perhaps a weekly or monthly blogpost would be prudent 3)

Re: [elm-discuss] Re: Moving on

> > This will evolve, but see above, the constraint is that Elm remains > reliable... Which the lack of attention to bug fixes undermines. How long were there warnings that arrays had problems? How long has Elm sometimes generated bad code for cyclic definitions leading to runtime crashes? The

Re: [elm-discuss] Re: Moving on

My 2c on above... 1) web components - once they're a standard they will be a must. Perhaps they feel like a necessity now (I am sold) but they're still in a flux, browsers support bits and pieces, some things haven't been finalised yet. Angular / Reacts / Vue's ad hoc implementations for their

[elm-discuss] Re: Moving on

I have felt very much as Duane describes, powerless and at the mercy of the whims of a few unreachable No Red Ink devs. I could not contribute my elm-audio library and found myself frustrated by the lack of progress along many fronts. However, I have since come to reconsider this. The point is,

Re: [elm-discuss] Re: Moving on

On Tue, Apr 25, 2017 at 7:42 PM, Eirik Sletteberg wrote: > Since you mention pitch forks... > Maybe there's a potential for an Elm fork. > There are so many unexplored options that don't need any kind of fork of Elm. Reaching for something as drastic as a fork of the

Re: [elm-discuss] Re: Moving on

It's easy to be a silent observer when none of a thread applies to you. But I feel like I need to throw in here that Elm has been working great for the SPA I've been building. I transitioned to Elm from Ember 3 months ago and couldn't be happier. I also recognize that Elm is still a pre-1.0

[elm-discuss] Re: Moving on

I haven't found interop or missing FFI to be as problematic as some others it seems. First of all I don't think it makes much sense to embed Elm to JS if you can't reasonably shape surrounding JS system and it's API to elm. We're using svgs as well a lot for charting. Anyway since it's quite

Re: [elm-discuss] Re: Moving on

> > Does anybody has an idea how other languages/platforms manage to get > community involved? The elm community will grow organically if it's given the chance. However, to have a thriving and exciting community, at a minimum, developers need to be able to actively write, contribute and

Re: [elm-discuss] Re: Moving on

I was late to the Lua community — Lua 4.0 verging on 5.0 — but in some ways at a similar point or earlier to where Elm is trying to be given that at the time Lua conferences and talks at other conferences were not a common thing. Lua the language is controlled by three people with the

Re: [elm-discuss] Re: Moving on

On Tue, Apr 25, 2017 at 4:39 AM, Noah Hall wrote: > Open an issue here: https://github.com/elm-community/manifesto and we'll > discuss > Opened: https://github.com/elm-community/Manifesto/issues/69 -- You received this message because you are subscribed to the Google

[elm-discuss] Re: Moving on

Hi folks. I really respect Duane's opinion and right to move on. Anyway since recently I've participated in some kind of dissolving of this community... *original thread: https://groups.google.com/forum/#!topic/elm-dev/iqErmKHnLDY

Re: [elm-discuss] Re: Moving on

On Tuesday, April 25, 2017 at 2:27:49 PM UTC+1, Wojtek Piekutowski wrote: > > The number of similar voices regarding community process and amount of > frequently requested missing features/native libraries (like binary support > and better JS interop) show a problem. No matter how amazing and

Re: [elm-discuss] Re: Moving on

The number of similar voices regarding community process and amount of frequently requested missing features/native libraries (like binary support and better JS interop) show a problem. No matter how amazing and performant Elm will ever be, newcomers will be discouraged by everlasting begging for

Re: [elm-discuss] Re: Moving on

Open an issue here: https://github.com/elm-community/manifesto and we'll discuss On Tue, Apr 25, 2017 at 12:36 PM, 'Rupert Smith' via Elm Discuss wrote: > On Monday, April 24, 2017 at 4:59:43 PM UTC+1, Jakub Hampl wrote: >> >> Typed SVG is a fantastic and much

[elm-discuss] Re: Moving on

On Monday, April 24, 2017 at 4:59:43 PM UTC+1, Jakub Hampl wrote: > > Typed SVG is a fantastic and much needed project so I hope somebody takes > over. I wonder if elm-community would take it over? I'd be happy to review > pull requests and do some other light maintenance work, but unfortunately

[elm-discuss] Re: Moving on

As several have asked, and Peter Damoc kindly reached out off-list, I'll post here what I wrote to him. Please know that I do appreciate what everyone has worked on, but this hasn't worked for me for the reasons I outline. I've started auto-archiving email from elm-discuss, so if you have any

[elm-discuss] Re: Moving on

Duane, I'm curious what the roadblocks were in the 2 of 3 you didn't have success with? This could definitely help others when making their decision. Also, it may provide helpful feedback to more appropriately prioritize future elm platform development. Thanks! On Monday, April 24, 2017 at

Re: [elm-discuss] Re: Moving Color to evancz/graphics

Given this: The Gradient type is opaque, so it’s impossible for anyone but evancz/graphics to use it. How about moving the Gradient type and functions related to it to evancz/elm-graphics? ​ -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To

[elm-discuss] Re: Moving Color to evancz/graphics

elm-style-animation accepts the Color types from core as arguments for color property animations. So does my color mixing library (though who knows how many people use that :) I'm working on another library that utilizes it as well. Having a centralized idea of color seems like a pretty