Re: [elm-discuss] Re: Moving on

[John Orford]

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 communicate
better(?)
On Mon 1. May 2017 at 02:33, Mark Hamburg  wrote:

> 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
> specific commitments one would need in order to know that a web component
> with its own state would not get accidentally destroyed and recreated
> rather than preserved. The code that works today just happens to work
> because the virtual DOM implementation just happens to do certain things
> that just happen to work out right. An example of the sort of guarantee
> that would resolve this would be "keyed nodes always preserved keyed child
> identity on updates provided you don't assign the same key to multiple
> children". That comes with caveats about what won't work and you have to
> make sure the path is stable all the way up the DOM and not just at the
> component, but if you obey the rules, it promises that something will work
> and keep working. Html.Keyed makes no such guarantee and as I recall when I
> last looked at the code it didn't look like the implementation would be
> likely to support such a guarantee.
>
> On the broader issue, Elm is free code and it does what it does and being
> free, people have no right to ask for anything more. But similarly people
> need to figure out whether the benefit they are getting is valuable enough
> to stick around v some of the other options that have been bandied about on
> this thread such as moving to other languages or forking Elm (thereby
> essentially creating another language). The talk here does not in general
> seem focused on going elsewhere but rather on what sort of changes in
> process and policy would quell the concerns. Remember that this thread
> started with an engaged community member leaving because using Elm had lead
> him to more failures than successes. People ought to ask "is that likely to
> be the case for me as well" and the community ought to ask "how might we
> fix the things that resulted in those failures?" You are right that this
> code is being made available free by Evan (or by NoRedInk since they are
> funding his work) and as such, it's his call. But similarly, it is a call
> for everyone using Elm as to whether it is still working out or whether
> they would be better off placing their bets elsewhere.
>
> Mark
>
> --
> 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.

Re: [elm-discuss] Re: Moving on

[Mark Hamburg]

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 
specific commitments one would need in order to know that a web component with 
its own state would not get accidentally destroyed and recreated rather than 
preserved. The code that works today just happens to work because the virtual 
DOM implementation just happens to do certain things that just happen to work 
out right. An example of the sort of guarantee that would resolve this would be 
"keyed nodes always preserved keyed child identity on updates provided you 
don't assign the same key to multiple children". That comes with caveats about 
what won't work and you have to make sure the path is stable all the way up the 
DOM and not just at the component, but if you obey the rules, it promises that 
something will work and keep working. Html.Keyed makes no such guarantee and as 
I recall when I last looked at the code it didn't look like the implementation 
would be likely to support such a guarantee.

On the broader issue, Elm is free code and it does what it does and being free, 
people have no right to ask for anything more. But similarly people need to 
figure out whether the benefit they are getting is valuable enough to stick 
around v some of the other options that have been bandied about on this thread 
such as moving to other languages or forking Elm (thereby essentially creating 
another language). The talk here does not in general seem focused on going 
elsewhere but rather on what sort of changes in process and policy would quell 
the concerns. Remember that this thread started with an engaged community 
member leaving because using Elm had lead him to more failures than successes. 
People ought to ask "is that likely to be the case for me as well" and the 
community ought to ask "how might we fix the things that resulted in those 
failures?" You are right that this code is being made available free by Evan 
(or by NoRedInk since they are funding his work) and as such, it's his call. 
But similarly, it is a call for everyone using Elm as to whether it is still 
working out or whether they would be better off placing their bets elsewhere.

Mark

-- 
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.

Re: [elm-discuss] Re: Moving on

[Rehno Lindeque]

>
> 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 part or as a whole. I 
forgot to mention that I highly respect Evan's work (in fact my company 
logo is on the front page of the elm website). This is important to mention 
whenever you offer any criticism, I apologize for not adding this 
counterweight to soften the blow. I forgot to consider how it might be 
taken. I wrote the postscript in a bit of a hurry and should have moderated 
down a bit I think. I generally try very hard to stay on point and fill my 
posts with information-dense arguments so that people will respond to the 
content rather than the tone.


To also add a bit of a positive spin to this, we've been making a push to 
make greater use of Elm at my work, so this is why I've become more 
interested in the health and sustainability of the ecosystem. We currently 
have a couple of internal screens in development that are 100% Elm. The 
experience has been pretty nice so far, though it took a little bit of time 
to aclimate to the Elm way. For a Haskell shop like ours it might have been 
more appropriate to use PureScript as it is better aligned with the skills 
we have in our team. However I think that Elm is a viable candidate and I 
sincerely hope that Evan will succeed in bringing it to the masses (and I 
think he should).


I'm hesitant, but perhaps just one meta-thought. I think that people here 
sometimes misattribute fear or even (misguided?) attempts at being helpful 
as animosity. I think a more moderated, and less reactionary approach to 
responding to people would also contribute to a less inflammatory 
environment and fewer of these meta discussions in general. Perhaps even 
just a friendly reminder quoted from the rules or something if you think it 
is appropriate.


My apologies for further increasing the length of this thread, seems like 
someone will need to start over with a concrete topic.

-- 
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.

Re: [elm-discuss] Re: Moving on

[Erik Lott]

>
>  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 (backed by 
> Google) or React (backed by Facebook). Calling out that you want something 
> done faster or differently, when you are not a financial backer or core 
> contributor (to be fair, there aren't any of those besides Evan), comes off 
> as extremely petulant.


Respectfully, nobody forced Evan to release and promote a programming 
language; the community that's formed around Elm is entirely of his own 
making. If there is a feeling of animosity in the community and Evan wants 
to dedicate resources to improving it, he can choose to... or he can choose 
not to... that's his choice, but the atmosphere of the community will in 
part be a reflection of how he is allocating his time and energy towards 
supporting and maintaining it. 



On Sunday, April 30, 2017 at 11:43:30 AM UTC-4, Max Goldstein wrote:
>
> 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. You should not expect Elm to move at the same pace as Angular (backed 
> by Google) or React (backed by Facebook). Calling out that you want 
> something done faster or differently, when you are not a financial backer 
> or core contributor (to be fair, there aren't any of those besides Evan), 
> comes off as extremely petulant.
>
> Second, as for elm-community hosting the "greylisted" packages. I'm a core 
> member of elm-community, although obviously I don't speak for the group and 
> opinions are subject to change. I think that elm-community is doing a good 
> job of providing high-quality packages, which largely means they are 100% 
> Elm and have the reliability and free distribution that comes from that. 
> Almost all of our packages are in maintenance mode, stewarded for people 
> who left the community but who wrote useful packages that need to keep pace 
> with language version bumps (oh hello original thread topic). With a small 
> number of exceptions, most of our packages aren't actively developed.
>
> Third, regardless of who hosts the greylist, there are other problems. 
> When Evan removed the old graphics library from core and spun it off as a 
> separate package, he inadvertently added or multiple 
>  runtime 
>  errors 
>  (or perhaps the 
> surfaced later). This was a well-used library with native code, meant to 
> not change as it was extracted, by Elm's creator, and runtime errors still 
> happened. It is very easy to break everything that makes Elm nice with 
> native code. Using ports means that you're writing more-or-less normal 
> JavaScript, and it's yours to debug, lint, and fit to your needs, rather 
> than be stuck on a broken library. The open source dream of a project with 
> 100 stars and recent commits is appealing, but what happens during the 
> bring-up when no such project exists? What happens if it never does? What 
> happens if multiple projects look good?
>
> Fourth, web components were briefly mentioned. Richard gave a talk on 
> these  last year and it 
> seems like everything you need already works.
>
> Fifth and finally, to say something positive. (*If you're skimming, 
> please read this part.*) The greylist is built on the idea that the best 
> way to help is by writing code. Instead, let me suggest a collection of 
> markdown documents that research a particular proposed addition and say why 
> it would be useful. This is like doing the lit review before getting to 
> work, and will be helpful to both Evan, anyone pressing ahead with the 
> greylist, any anyone on the list confused as to what a task port is (for 
> example). I think these documents should, for a topic X, define X, say why 
> X is useful, describe the best way(s) to do X in Elm today, describe how 
> other ML-family and JS-ecosystem languages do X, and finally include a 
> brief, "first draft" of an interface or API for X in Elm. I think this will 
> work well for "web platform" things (audio playback, binary data) much 
> better than language features (type classes).
>

-- 
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.

Re: [elm-discuss] Re: Moving on

[Noah Hall]

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 invested in the thread to reply. It's best to keep
things concise and to the point.

-- 
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.

[elm-discuss] Re: Moving on

[Marek Fajkus]

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 
is much more important than commenting everything myself but it's really 
hard to follow everything right now. Anyway I have few points myself. 
*Please understand that these are points that don't define my whole view.*
1. Interop - First of all it was there but now there is white list for just 
few packages. Bringing native code especially on lib level is pretty 
dangerous indeed. On the other hand anyone pulling some hairball (Hickey's 
term ) he/she has to be aware 
of certain risks. This is part of contract defined by all OSS licenses I'm 
aware of. Maybe visible warning + extra confirmation during install would 
be enough.

2. Elm isn't really "web language". It just happened that current target of 
Elm is web and that there are certain architectural decision that reflect 
that. Anyway elm isn't really web technology and in certain ways it's even 
bending web standards. I don't feel there is a need for Elm to really cover 
100% of web standards. Web is very big and loosely defined platform these 
days used for everything from mail logs to mealtime apps. Elm simply 
doesn't fit to everything you can do on web. Personally I still have mixed 
feeling about web component standard. Generally I don't think it's as 
universally as good idea as some people say.

-- 
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.

Re: [elm-discuss] Re: Moving on

[Rehno Lindeque]

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. Allow publishing any package, except prevent publishing packages that 
*depend* on packages that could cause run-time exceptions.
2. Issue a warning when you try to install a package with native code / 
effects.

Censoring packages indirectly based on dependencies sounds like a cop-out 
at first, which is why I think people haven't taken it seriously. But I 
think people haven't considered it as carefully as they should.

Breaking it down based how this affects each of the three concerns:

* Evan and other people with that take the "long-view" want to prevent 
run-time errors from becoming endemic to the ecosystem. No transitive 
dependencies means that run-time errors can be traced to a function call 
you made directly in your app.

* From a marketing perspective we don't want to water down the "no run-time 
errors" argument. Issuing a warning on installation provides some 
justification. Consider that clumsy JS interop negatively affects user 
acquisition and - perhaps more concerning - on user retention.

* Existing users and commercial users want to be productive. Being 
productive in the short term is as important as being productive in the 
long term when you have limited resources.

P.S. What attracted me to Elm was that it was being developed in a similar 
way to how a startup develops a product rather than how an academic might. 
However, I'm increasingly concerned that the current course that is set for 
Elm may be more dogmatic than it is pragmatic.

It worries a great deal that Elm's development methodology is based on 
early Python history. The world moves far more quickly than it did in the 
90's and I think it's dangerously complacent to imagine that we're still 
living in the same era. Consider that SourceForge was launched in 1999, 8 
years after Python first appeared. It's hard to hear but the world just 
doesn't work the same way anymore; people aren't working out of their 
basements in isolation (though they may be working out of their basement in 
a well managed team).

-- 
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.

Re: [elm-discuss] Re: Moving on

[Zachary Kessin]

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 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
>> supervision of that experienced Elm programmers group I mentioned earlier.
>>
>
> If this were the route people decide to take, I get the impression that
> this is the sort of thing elm-community does quite well. Perhaps a
> "greylist" could be simplified to https://github.com/elm-community/*.
>
> Something to keep in mind is that there's likely to be red tape required
> to fork a package on a special list. Not great if you need to fix something
> in a hurry and the author has disappeared. Elm-community provides a little
> bit of peace of mind for people like me who would like to make sure that
> packages they use have at least one active maintainer assigned to it and
> that the code has had some level of peer review.
>
> --
> 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.
>



-- 
Zach Kessin
Teaching Web Developers to test code to find more bugs in less time
Skype: zachkessin
+972 54 234 3956 / +44 203 734 9790 / +1 617 778 7213

-- 
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.

Re: [elm-discuss] Re: Moving on

[Peter Damoc]

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
>> would have to happen after a serious benefits analysis done under the
>> supervision of that experienced Elm programmers group I mentioned earlier.
>>
>
> If this were the route people decide to take, I get the impression that
> this is the sort of thing elm-community does quite well. Perhaps a
> "greylist" could be simplified to https://github.com/elm-community/*.
>

Of course, that would be the optimal course.
I guess this would make the packages a very light shade of grey, closer to
something semi-official than something apocryphal. :)




-- 
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.

Re: [elm-discuss] Re: Moving on

[Rehno Lindeque]

> 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 
> supervision of that experienced Elm programmers group I mentioned earlier. 
>

If this were the route people decide to take, I get the impression that 
this is the sort of thing elm-community does quite well. Perhaps a 
"greylist" could be simplified to https://github.com/elm-community/*. 

Something to keep in mind is that there's likely to be red tape required to 
fork a package on a special list. Not great if you need to fix something in 
a hurry and the author has disappeared. Elm-community provides a little bit 
of peace of mind for people like me who would like to make sure that 
packages they use have at least one active maintainer assigned to it and 
that the code has had some level of peer review.

-- 
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.

Re: [elm-discuss] Re: Moving on

[Peter Damoc]

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 like a grey-list and something similar to
elm-github-install but constrained to this grey-list.
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 supervision
of that experienced Elm programmers group I mentioned earlier.





-- 
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.

[elm-discuss] Re: Moving on

['Rupert Smith' via Elm Discuss]

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 are 
clamouring for features. But it is also a tough job maintaining the vision 
for a language that aims to maintain its functional purity - so every piece 
of design takes time and careful thought and there is only so fast one guy 
can go whilst also holding down a day job.

I do think that support for binary data is something that is constantly 
being asked for and needs to be addressed by the core Elm language though. 
As a community, perhaps the best thing we could do is to discuss the 
options here? What does it look like in code? How is binary data handled in 
ML, OCaml, Haskell etc.

Also Elm aims to cover the whole of the web platform and there is plenty 
outside of the core language. As a community we can get involved by 
identifying area of the platform that the libraries do not cover (well) and 
working on those. I seem to have picked typed-svg for my sins, but it is a 
necessary part of the platform and open to the community to build. We could 
helpfully draw up a list of similar areas requiring work that are outside 
of the kernel and the language itself.

-- 
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.

Re: [elm-discuss] Re: Moving on

[Erik Lott]

>
> 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 Wednesday, April 26, 2017 at 7:08:08 PM UTC-4, Oliver Searle-Barnes 
wrote:
>
> 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.
>
> Currently under development are: Elm the language, Elm the web platform 
> APIs, Elm tooling and effect managers. Evan is an absolute hero for taking 
> on the challenge to reimagine and build all of these different aspects of 
> web development and his success to date has inspired a lot of enthusiasm in 
> this fledgling community. The challenge can not be overstated though, this 
> is a gigantic undertaking, and it currently feels like too much for a 
> single individual. 
>
> It seems clear that the community has many experienced and talented 
> developers within it's ranks. They've all bought into Evan's vision and I 
> believe would be willing to go to great lengths in support of it. While I 
> can understand that Evan wants to retain control over what represents his 
> gold standard there does seem to be an opportunity to help other developers 
> help Evan. At a practical level I see two parts to this:
>
> 1) Better javascript interop to allow the community to provide the missing 
> web APIs and effect managers (task ports have been mooted on several 
> occasions)
>
> 2) A development process that encourages the use of packages from the 
> wider community _before_ they've had sufficient design attention and 
> matured to the point where they may be considered gold standard. The 
> exceptionally high quality of the solutions that Evan puts out is a 
> destination that we all aspire to. Getting there may take a while though, 
> in the mean time people are building apps and having to settle with their 
> own half baked solutions which are difficult to share with the community. 
> This situation is particularly grevious because the time spent building 
> these half baked solutions takes time away from focusing on a single aspect 
> that they could develop to a higher standard and share with the community. 
> As an engineer it's hard to see this process as efficient and optimal. 
>
> I don't want to be too prescriptive here but one suggestion might be to 
> introduce the concept of a quality or status metric for each package e.g. 
> exploratory, draft, candidate, ready (those were chosen purely for 
> illustrative purposes). This would allow the community to benefit from each 
> other's work without requiring any compromise in standards. Versus forcing 
> every team to reimplement the same things with ports this seems like a 
> distinct improvement (IMHO). Potentially packages could even be kept in an 
> entirely different package site until they'd graduated to 
> http://package.elm-lang.org/. (this would allow beginners to be kept in a 
> safer environment until they needed to reach into the community packages)
>
> Hopefully my thoughts will be taken in the postive light that they're 
> intended, I'm a huge fan of Elm and would love to see it go from strength 
> to strength. As the opportunity doesn't often present itself I'd like to 
> extend a huge thankyou to Evan for all the great work you've been putting 
> in!
>
>

-- 
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.

Re: [elm-discuss] Re: Moving on

[Oliver Searle-Barnes]

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.

Currently under development are: Elm the language, Elm the web platform 
APIs, Elm tooling and effect managers. Evan is an absolute hero for taking 
on the challenge to reimagine and build all of these different aspects of 
web development and his success to date has inspired a lot of enthusiasm in 
this fledgling community. The challenge can not be overstated though, this 
is a gigantic undertaking, and it currently feels like too much for a 
single individual. 

It seems clear that the community has many experienced and talented 
developers within it's ranks. They've all bought into Evan's vision and I 
believe would be willing to go to great lengths in support of it. While I 
can understand that Evan wants to retain control over what represents his 
gold standard there does seem to be an opportunity to help other developers 
help Evan. At a practical level I see two parts to this:

1) Better javascript interop to allow the community to provide the missing 
web APIs and effect managers (task ports have been mooted on several 
occasions)

2) A development process that encourages the use of packages from the wider 
community _before_ they've had sufficient design attention and matured to 
the point where they may be considered gold standard. The exceptionally 
high quality of the solutions that Evan puts out is a destination that we 
all aspire to. Getting there may take a while though, in the mean time 
people are building apps and having to settle with their own half baked 
solutions which are difficult to share with the community. This situation 
is particularly grevious because the time spent building these half baked 
solutions takes time away from focusing on a single aspect that they could 
develop to a higher standard and share with the community. As an engineer 
it's hard to see this process as efficient and optimal. 

I don't want to be too prescriptive here but one suggestion might be to 
introduce the concept of a quality or status metric for each package e.g. 
exploratory, draft, candidate, ready (those were chosen purely for 
illustrative purposes). This would allow the community to benefit from each 
other's work without requiring any compromise in standards. Versus forcing 
every team to reimplement the same things with ports this seems like a 
distinct improvement (IMHO). Potentially packages could even be kept in an 
entirely different package site until they'd graduated to 
http://package.elm-lang.org/. (this would allow beginners to be kept in a 
safer environment until they needed to reach into the community packages)

Hopefully my thoughts will be taken in the postive light that they're 
intended, I'm a huge fan of Elm and would love to see it go from strength 
to strength. As the opportunity doesn't often present itself I'd like to 
extend a huge thankyou to Evan for all the great work you've been putting 
in!

-- 
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.

Re: [elm-discuss] Re: Moving on

[Francesco Orsenigo]

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 disagrees with your assessment
about the npm ecosystem.
We use Elm in production, these errors do not happen and that is of massive
value for us.


It's not that there's one way of doing it, but that once a bad way of doing
> it is widespread


^ This.
Do things once and do them well.

This said, I agree with Mark regarding the presence of too many bugs and
the necessity of a roadmap.



On Thu, Apr 27, 2017 at 5:57 AM, Eirik Sletteberg  wrote:

> 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
> used" wasn't a relevant factor regarding which elements to retain in
> localStorage; there were a few very important keys, and a couple of "less
> important" keys. The Task-based LocalStorage API that is included in
> persistent-cache works very well. It works very well because it mirrors the
> native API. As a developer, I also prefer the freedom to make my own
> technical choices that are right given the circumstances. I need the power
> of the Web API, I just want it with types and without runtime exceptions.
>
> 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. (An exaggeration of course) As far as web APIs are concerned,
> there is only one Correct Way™ we all have to deal with, which is W3C
> standards, as they are implemented in the browsers. Maybe it's possible to
> take WebIDL definitions and convert them to Elm bindings, then one would
> have a type-safe, exception-free interface to the browsers, without all the
> maintenance overhead.
>
> BDFL for both a language and its ecosystem is perfectly fine for a project
> philosophy, but it is intrinsically linked to having a small niche
> community. Then again, broad adoption may not be a significant priority for
> Elm during the next few years, so that might be a good thing. In the case
> of commercial software development, cash is king, and delivering working
> features is the top priority. Nobody cares that your car is shiny and
> polished, if it cannot drive in reverse. The article Choose Boring
> Technology  comes to mind.
>
> Bottom line, there is a huge untapped potential here, people are excited
> about Elm, want to use it in production, but then there are small things
> like missing support for localStorage, file uploads, audio playback, binary
> data, being able to control event.preventDefault(). Many of those are
> problems that people would fix themselves and publish as a package. All it
> takes is to trust the broader community. Even if you end up with 5
> different libraries dealing with cookies, one of them will probably
> prevail, and all 5 of them will learn from each other's advantages and
> drawbacks. I don't buy the argument that opening up the ecosystem will ruin
> Elm's guarantees - I would trust the robustness of a third party cookie
> package with 5000 GitHub stars and 100 merged pull requests just as much as
> (or more than) I trust the Elm core. Just look at what npm did for the
> JavaScript community. Look at the success of React and Redux, which are
> more or less based on TEA. But they have excellent JS interop and an open
> ecosystem. Wouldn't it be great if Elm were just as widespread? And had
> just as many contributors?
>
>
> onsdag 26. april 2017 19.28.59 UTC+2 skrev Wojtek Piekutowski følgende:
>>
>> 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  wrote:
>>
>>> 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 
>>> wrote:
>>>
 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 

Re: [elm-discuss] Re: Moving on

[Mark Hamburg]

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
doesn't mean much — at least not without a roadmap spelling out the
differences between where it is now and 1.0.

On Wed, Apr 26, 2017 at 1:00 PM, Joey Eremondi 
wrote:

> 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 bad way of
> doing it is widespread, it never dies. Once you give people a tool, you can
> never take it back, even if it is a bad tool. The goal is to make Elm solid
> *before* 1.0, so that after 1.0, we won't be plagued by backwards
> compatibility issues.
>
> On Wed, Apr 26, 2017 at 12:57 PM, Eirik Sletteberg <
> eiriksletteb...@gmail.com> wrote:
>
>> 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
>> used" wasn't a relevant factor regarding which elements to retain in
>> localStorage; there were a few very important keys, and a couple of "less
>> important" keys. The Task-based LocalStorage API that is included in
>> persistent-cache works very well. It works very well because it mirrors the
>> native API. As a developer, I also prefer the freedom to make my own
>> technical choices that are right given the circumstances. I need the power
>> of the Web API, I just want it with types and without runtime exceptions.
>>
>> 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. (An exaggeration of course) As far as web APIs are concerned,
>> there is only one Correct Way™ we all have to deal with, which is W3C
>> standards, as they are implemented in the browsers. Maybe it's possible to
>> take WebIDL definitions and convert them to Elm bindings, then one would
>> have a type-safe, exception-free interface to the browsers, without all the
>> maintenance overhead.
>>
>> BDFL for both a language and its ecosystem is perfectly fine for a
>> project philosophy, but it is intrinsically linked to having a small niche
>> community. Then again, broad adoption may not be a significant priority for
>> Elm during the next few years, so that might be a good thing. In the case
>> of commercial software development, cash is king, and delivering working
>> features is the top priority. Nobody cares that your car is shiny and
>> polished, if it cannot drive in reverse. The article Choose Boring
>> Technology  comes to mind.
>>
>> Bottom line, there is a huge untapped potential here, people are excited
>> about Elm, want to use it in production, but then there are small things
>> like missing support for localStorage, file uploads, audio playback, binary
>> data, being able to control event.preventDefault(). Many of those are
>> problems that people would fix themselves and publish as a package. All it
>> takes is to trust the broader community. Even if you end up with 5
>> different libraries dealing with cookies, one of them will probably
>> prevail, and all 5 of them will learn from each other's advantages and
>> drawbacks. I don't buy the argument that opening up the ecosystem will ruin
>> Elm's guarantees - I would trust the robustness of a third party cookie
>> package with 5000 GitHub stars and 100 merged pull requests just as much as
>> (or more than) I trust the Elm core. Just look at what npm did for the
>> JavaScript community. Look at the success of React and Redux, which are
>> more or less based on TEA. But they have excellent JS interop and an open
>> ecosystem. Wouldn't it be great if Elm were just as widespread? And had
>> just as many contributors?
>>
>>
>> onsdag 26. april 2017 19.28.59 UTC+2 skrev Wojtek Piekutowski følgende:
>>>
>>> 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  wrote:
>>>
 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. 

Re: [elm-discuss] Re: Moving on

[Eirik Sletteberg]

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 
so many great things that have been built with Java/C++/insert 
language/technology here. It was certainly a huge step forward from what 
was before, C/C++/insert language/technology here. People thought nulls 
were good it the time they designed Java. Later on, we learned that there 
were better ways to do things. That's the way technology evolves. You 
cannot take tools back, but you can give people new tools. If the bad tools 
aren't widely replaced with the new tools, then maybe the bad tools weren't 
so bad after all, or at least they were good *enough*.

Even Elm will make fundamental design flaws that we aren't aware of, and 
won't be aware of until we learn from them. Nothing lasts forever; even Elm 
will one day be obsolete, which is a good thing, because then we will have 
another, even greater language/technology, based on lessons learnt from 
Elm! Who knows, maybe that new language promises Elm interop, to benefit 
from the large Elm community/ecosystem, just like Elm promises JS interop 
today.

People were discussing Elm 1.0 more than 3 years ago, and it hasn't 
happened yet. I think there's a general fear of release number 1.0 in the 
open source community at large. But even if Elm 1.0 is released, with its 
inevitable design mistakes, that doesn't mean the end of Elm. (nulls 
weren't the end of Java either). It will always be possible to release Elm 
2.0. At least I hope the ecosystem opens up soon, I would be sorry to see a 
great project like Elm suffer from Perfectionist's Dilemma, never accepting 
the risks of an open ecosystem, and never achieve broad adoption.

onsdag 26. april 2017 22.00.53 UTC+2 skrev Joey Eremondi følgende:
>
> 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 bad way of 
> doing it is widespread, it never dies. Once you give people a tool, you can 
> never take it back, even if it is a bad tool. The goal is to make Elm solid 
> *before* 1.0, so that after 1.0, we won't be plagued by backwards 
> compatibility issues. 
>
> On Wed, Apr 26, 2017 at 12:57 PM, Eirik Sletteberg  > wrote:
>
>> 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 
>> used" wasn't a relevant factor regarding which elements to retain in 
>> localStorage; there were a few very important keys, and a couple of "less 
>> important" keys. The Task-based LocalStorage API that is included in 
>> persistent-cache works very well. It works very well because it mirrors the 
>> native API. As a developer, I also prefer the freedom to make my own 
>> technical choices that are right given the circumstances. I need the power 
>> of the Web API, I just want it with types and without runtime exceptions.
>>
>> 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. (An exaggeration of course) As far as web APIs are concerned, 
>> there is only one Correct Way™ we all have to deal with, which is W3C 
>> standards, as they are implemented in the browsers. Maybe it's possible to 
>> take WebIDL definitions and convert them to Elm bindings, then one would 
>> have a type-safe, exception-free interface to the browsers, without all the 
>> maintenance overhead.
>>
>> BDFL for both a language and its ecosystem is perfectly fine for a 
>> project philosophy, but it is intrinsically linked to having a small niche 
>> community. Then again, broad adoption may not be a significant priority for 
>> Elm during the next few years, so that might be a good thing. In the case 
>> of commercial software development, cash is king, and delivering working 
>> features is the top priority. Nobody cares that your car is shiny and 
>> polished, if it cannot drive in reverse. The article Choose Boring 
>> Technology  comes to mind.
>>
>> Bottom line, there is a huge untapped potential here, people are excited 
>> about Elm, want to use it in production, but then there are small things 
>> like missing support for localStorage, file uploads, audio playback, binary 
>> data, being able to 

Re: [elm-discuss] Re: Moving on

[Joey Eremondi]

>
> 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 bad way of doing
it is widespread, it never dies. Once you give people a tool, you can never
take it back, even if it is a bad tool. The goal is to make Elm solid
*before* 1.0, so that after 1.0, we won't be plagued by backwards
compatibility issues.

On Wed, Apr 26, 2017 at 12:57 PM, Eirik Sletteberg <
eiriksletteb...@gmail.com> wrote:

> 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
> used" wasn't a relevant factor regarding which elements to retain in
> localStorage; there were a few very important keys, and a couple of "less
> important" keys. The Task-based LocalStorage API that is included in
> persistent-cache works very well. It works very well because it mirrors the
> native API. As a developer, I also prefer the freedom to make my own
> technical choices that are right given the circumstances. I need the power
> of the Web API, I just want it with types and without runtime exceptions.
>
> 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. (An exaggeration of course) As far as web APIs are concerned,
> there is only one Correct Way™ we all have to deal with, which is W3C
> standards, as they are implemented in the browsers. Maybe it's possible to
> take WebIDL definitions and convert them to Elm bindings, then one would
> have a type-safe, exception-free interface to the browsers, without all the
> maintenance overhead.
>
> BDFL for both a language and its ecosystem is perfectly fine for a project
> philosophy, but it is intrinsically linked to having a small niche
> community. Then again, broad adoption may not be a significant priority for
> Elm during the next few years, so that might be a good thing. In the case
> of commercial software development, cash is king, and delivering working
> features is the top priority. Nobody cares that your car is shiny and
> polished, if it cannot drive in reverse. The article Choose Boring
> Technology  comes to mind.
>
> Bottom line, there is a huge untapped potential here, people are excited
> about Elm, want to use it in production, but then there are small things
> like missing support for localStorage, file uploads, audio playback, binary
> data, being able to control event.preventDefault(). Many of those are
> problems that people would fix themselves and publish as a package. All it
> takes is to trust the broader community. Even if you end up with 5
> different libraries dealing with cookies, one of them will probably
> prevail, and all 5 of them will learn from each other's advantages and
> drawbacks. I don't buy the argument that opening up the ecosystem will ruin
> Elm's guarantees - I would trust the robustness of a third party cookie
> package with 5000 GitHub stars and 100 merged pull requests just as much as
> (or more than) I trust the Elm core. Just look at what npm did for the
> JavaScript community. Look at the success of React and Redux, which are
> more or less based on TEA. But they have excellent JS interop and an open
> ecosystem. Wouldn't it be great if Elm were just as widespread? And had
> just as many contributors?
>
>
> onsdag 26. april 2017 19.28.59 UTC+2 skrev Wojtek Piekutowski følgende:
>>
>> 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  wrote:
>>
>>> 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 
>>> wrote:
>>>
 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 

Re: [elm-discuss] Re: Moving on

[Eirik Sletteberg]

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 
used" wasn't a relevant factor regarding which elements to retain in 
localStorage; there were a few very important keys, and a couple of "less 
important" keys. The Task-based LocalStorage API that is included in 
persistent-cache works very well. It works very well because it mirrors the 
native API. As a developer, I also prefer the freedom to make my own 
technical choices that are right given the circumstances. I need the power 
of the Web API, I just want it with types and without runtime exceptions.

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. (An exaggeration of course) As far as web APIs are concerned, there is 
only one Correct Way™ we all have to deal with, which is W3C standards, as 
they are implemented in the browsers. Maybe it's possible to take WebIDL 
definitions and convert them to Elm bindings, then one would have a 
type-safe, exception-free interface to the browsers, without all the 
maintenance overhead.

BDFL for both a language and its ecosystem is perfectly fine for a project 
philosophy, but it is intrinsically linked to having a small niche 
community. Then again, broad adoption may not be a significant priority for 
Elm during the next few years, so that might be a good thing. In the case 
of commercial software development, cash is king, and delivering working 
features is the top priority. Nobody cares that your car is shiny and 
polished, if it cannot drive in reverse. The article Choose Boring 
Technology  comes to mind.

Bottom line, there is a huge untapped potential here, people are excited 
about Elm, want to use it in production, but then there are small things 
like missing support for localStorage, file uploads, audio playback, binary 
data, being able to control event.preventDefault(). Many of those are 
problems that people would fix themselves and publish as a package. All it 
takes is to trust the broader community. Even if you end up with 5 
different libraries dealing with cookies, one of them will probably 
prevail, and all 5 of them will learn from each other's advantages and 
drawbacks. I don't buy the argument that opening up the ecosystem will ruin 
Elm's guarantees - I would trust the robustness of a third party cookie 
package with 5000 GitHub stars and 100 merged pull requests just as much as 
(or more than) I trust the Elm core. Just look at what npm did for the 
JavaScript community. Look at the success of React and Redux, which are 
more or less based on TEA. But they have excellent JS interop and an open 
ecosystem. Wouldn't it be great if Elm were just as widespread? And had 
just as many contributors?


onsdag 26. april 2017 19.28.59 UTC+2 skrev Wojtek Piekutowski følgende:
>
> 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  > wrote:
>
>> 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 > > wrote:
>>
>>> 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 and stop receiving emails from it, send 
>>> an email to elm-discuss...@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...@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, 

Re: [elm-discuss] Re: Moving on

[Wojciech Piekutowski]

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  wrote:

> 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 
> wrote:
>
>> 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 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.
>

-- 
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.

Re: [elm-discuss] Re: Moving on

[Mark Hamburg]

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 
wrote:

> 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 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.

Re: [elm-discuss] Re: Moving on

[Mark Hamburg]

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 Wojciech Piekutowski <
w.piekutow...@gmail.com> wrote:

> 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 stayed at 0.16 because of FRP. It isn't cost effective and could not
> be in fact possible to port to 0.17+. They are frustrated with lack of
> communication (not much info beforehand about the tectonic change between
> 0.16 and 0.17 before it happened). There's no roadmap.
>
> I'm wondering if 0.18 TEA couldn't be just a higher level abstraction over
> FRP. That way we would have simplicity for newcomers and smaller apps, but
> also keep the lower level powerful machinery for advanced cases or people
> who don't want/can't to follow TEA.
>
> Similar approach could apply to things like localStorage. Why not have a
> low-level libs more or less mirroring web APIs, but later community could
> build something higher level, like
> https://github.com/elm-lang/persistent-cache?
>
> On 26 April 2017 at 05:19, Mark Hamburg  wrote:
>
>> 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 speed blog post
>> regarding Elm talks up using Html.Lazy and to do that effectively in some
>> cases you need Html.map. Guess what, use them in the "wrong" way  and you
>> can get type system violations leading to runtime errors.
>>
>> Tight control over the core is something that many language designers
>> have maintained and it leads to clarity. (At the large language end of the
>> spectrum, this has helped C# be a better language than Java despite
>> starting as a Java knock off.) But everything within that tight bound of
>> control then also becomes an area of responsibility or the technical
>> ecosystem suffers.
>>
>> An ecosystem that had looked vibrant and innovative a year ago now looks
>> increasingly buggy and stagnant. We're coming up on the one year
>> anniversary of the Elm 0.17 release in which FRP was removed, effects
>> managers introduced with a plan that they would cover the web APIs, and a
>> new guide to Elm was introduced. The guide long contained promises of
>> material that was coming soon though now it just seems those promises have
>> been deleted rather than fulfilled. The effects manager ecosystem appears
>> to have been abandoned in that nothing new seems to have come to the
>> community in ages. Evan started a manager for local storage but hasn't seen
>> it as worthwhile to finish it leaving people using ports with a range of
>> frustrations (see other threads). Phoenix was cited as an example of where
>> effects managers could be useful but there is no blessed Phoenix effects
>> manager. If you took the velocity of the last nine months and projected it
>> forward, it's hard to make it look promising. People want to help. They
>> want to write and share code to expand what Elm can do, but the evidence
>> suggest that there is a lot of pushback against that right now —
>> particularly when it comes to getting code approved for distribution
>> through the standard package manager.
>>
>> The lack of effects manager build out also reflects a sense that the
>> direction Elm development moves in is capricious. When 0.17 was released,
>> there was a strong message around this being the architecture for the
>> future of Elm and a suggestion that it wasn't going to take that much to
>> get coverage of the standard web API. That appeared to be the plan of
>> record to the extent that there was one. Binary data has been a hot topic
>> for quite a while and the HTTP libraries give nods toward adding support
>> but haven't actually done so. Now, it seems Evan is working on providing
>> ways to download less code or download code incrementally when delivering
>> web apps. That's definitely nice. Smaller is better. But to the extent that
>> there were hints toward a roadmap, this hadn't been on it.
>>
>> This is what leads to people being worried or frustrated. This is what
>> leads to them leaving. There will always be churn. There will always be
>> people who are unhappy because of the strictures of pure functional
>> programming or who are unhappy because Elm isn't Haskell. But this thread
>> started with an active member of the community — as opposed to someone who
>> just came by to kick 

Re: [elm-discuss] Re: Moving on

[Rex van der Spuy]

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 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.

Re: [elm-discuss] Re: Moving on

[Wojciech Piekutowski]

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 stayed at 0.16 because of FRP. It isn't cost effective and could not
be in fact possible to port to 0.17+. They are frustrated with lack of
communication (not much info beforehand about the tectonic change between
0.16 and 0.17 before it happened). There's no roadmap.

I'm wondering if 0.18 TEA couldn't be just a higher level abstraction over
FRP. That way we would have simplicity for newcomers and smaller apps, but
also keep the lower level powerful machinery for advanced cases or people
who don't want/can't to follow TEA.

Similar approach could apply to things like localStorage. Why not have a
low-level libs more or less mirroring web APIs, but later community could
build something higher level, like
https://github.com/elm-lang/persistent-cache?

On 26 April 2017 at 05:19, Mark Hamburg  wrote:

> 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 speed blog post
> regarding Elm talks up using Html.Lazy and to do that effectively in some
> cases you need Html.map. Guess what, use them in the "wrong" way  and you
> can get type system violations leading to runtime errors.
>
> Tight control over the core is something that many language designers have
> maintained and it leads to clarity. (At the large language end of the
> spectrum, this has helped C# be a better language than Java despite
> starting as a Java knock off.) But everything within that tight bound of
> control then also becomes an area of responsibility or the technical
> ecosystem suffers.
>
> An ecosystem that had looked vibrant and innovative a year ago now looks
> increasingly buggy and stagnant. We're coming up on the one year
> anniversary of the Elm 0.17 release in which FRP was removed, effects
> managers introduced with a plan that they would cover the web APIs, and a
> new guide to Elm was introduced. The guide long contained promises of
> material that was coming soon though now it just seems those promises have
> been deleted rather than fulfilled. The effects manager ecosystem appears
> to have been abandoned in that nothing new seems to have come to the
> community in ages. Evan started a manager for local storage but hasn't seen
> it as worthwhile to finish it leaving people using ports with a range of
> frustrations (see other threads). Phoenix was cited as an example of where
> effects managers could be useful but there is no blessed Phoenix effects
> manager. If you took the velocity of the last nine months and projected it
> forward, it's hard to make it look promising. People want to help. They
> want to write and share code to expand what Elm can do, but the evidence
> suggest that there is a lot of pushback against that right now —
> particularly when it comes to getting code approved for distribution
> through the standard package manager.
>
> The lack of effects manager build out also reflects a sense that the
> direction Elm development moves in is capricious. When 0.17 was released,
> there was a strong message around this being the architecture for the
> future of Elm and a suggestion that it wasn't going to take that much to
> get coverage of the standard web API. That appeared to be the plan of
> record to the extent that there was one. Binary data has been a hot topic
> for quite a while and the HTTP libraries give nods toward adding support
> but haven't actually done so. Now, it seems Evan is working on providing
> ways to download less code or download code incrementally when delivering
> web apps. That's definitely nice. Smaller is better. But to the extent that
> there were hints toward a roadmap, this hadn't been on it.
>
> This is what leads to people being worried or frustrated. This is what
> leads to them leaving. There will always be churn. There will always be
> people who are unhappy because of the strictures of pure functional
> programming or who are unhappy because Elm isn't Haskell. But this thread
> started with an active member of the community — as opposed to someone who
> just came by to kick the tires — deciding that the ecosystem just wasn't
> viable as a place to invest anymore. Maybe this is just a one off. But
> maybe it's symptomatic. As web technologies — of which Elm clearly
> positions itself as one — demonstrate it doesn't take much  to tilt from
> being the hot new thing to being the thing that everyone has heard that
> people have gotten burned by and one best stay away.
>
> What you are hearing is frustration and 

Re: [elm-discuss] Re: Moving on

[Peter Damoc]

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 haven't been finalised
> yet.
>

V1 has been accepted and assumed by the major browser providers for some
time and we will probably see official support in the evergreens this
summer but this is beside the point.

The idea of custom elements could have been implemented in Elm without
browser support if this would have been desired.

Unfortunately, this idea comes packaged together with the idea of localized
state and this seams to be rejected on philosophical grounds.
I seriously doubt we'll ever see web-components support without a proper
dialog around this subject.

I've seen the idea of "mutation-as-service" being put forth as the main
drawback of web-components and I would love to see a proof-of-concept for
this just so that I can accept that this is a bad idea. Heck, I even tried
to implement such a proof-of-concept and failed.

Anyway... I used to feel worse about this topic but I realized that there
are still a lot of things that I can do and haven't done yet so... I have
options.


-- 
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.

Re: [elm-discuss] Re: Moving on

[John Orford]

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) Vapourware. Par for the course

4) Eco system. 1.0 cannot come quick enough
On Wed 26. Apr 2017 at 11:19, Mark Hamburg  wrote:

> 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 speed blog post
> regarding Elm talks up using Html.Lazy and to do that effectively in some
> cases you need Html.map. Guess what, use them in the "wrong" way  and you
> can get type system violations leading to runtime errors.
>
> Tight control over the core is something that many language designers have
> maintained and it leads to clarity. (At the large language end of the
> spectrum, this has helped C# be a better language than Java despite
> starting as a Java knock off.) But everything within that tight bound of
> control then also becomes an area of responsibility or the technical
> ecosystem suffers.
>
> An ecosystem that had looked vibrant and innovative a year ago now looks
> increasingly buggy and stagnant. We're coming up on the one year
> anniversary of the Elm 0.17 release in which FRP was removed, effects
> managers introduced with a plan that they would cover the web APIs, and a
> new guide to Elm was introduced. The guide long contained promises of
> material that was coming soon though now it just seems those promises have
> been deleted rather than fulfilled. The effects manager ecosystem appears
> to have been abandoned in that nothing new seems to have come to the
> community in ages. Evan started a manager for local storage but hasn't seen
> it as worthwhile to finish it leaving people using ports with a range of
> frustrations (see other threads). Phoenix was cited as an example of where
> effects managers could be useful but there is no blessed Phoenix effects
> manager. If you took the velocity of the last nine months and projected it
> forward, it's hard to make it look promising. People want to help. They
> want to write and share code to expand what Elm can do, but the evidence
> suggest that there is a lot of pushback against that right now —
> particularly when it comes to getting code approved for distribution
> through the standard package manager.
>
> The lack of effects manager build out also reflects a sense that the
> direction Elm development moves in is capricious. When 0.17 was released,
> there was a strong message around this being the architecture for the
> future of Elm and a suggestion that it wasn't going to take that much to
> get coverage of the standard web API. That appeared to be the plan of
> record to the extent that there was one. Binary data has been a hot topic
> for quite a while and the HTTP libraries give nods toward adding support
> but haven't actually done so. Now, it seems Evan is working on providing
> ways to download less code or download code incrementally when delivering
> web apps. That's definitely nice. Smaller is better. But to the extent that
> there were hints toward a roadmap, this hadn't been on it.
>
> This is what leads to people being worried or frustrated. This is what
> leads to them leaving. There will always be churn. There will always be
> people who are unhappy because of the strictures of pure functional
> programming or who are unhappy because Elm isn't Haskell. But this thread
> started with an active member of the community — as opposed to someone who
> just came by to kick the tires — deciding that the ecosystem just wasn't
> viable as a place to invest anymore. Maybe this is just a one off. But
> maybe it's symptomatic. As web technologies — of which Elm clearly
> positions itself as one — demonstrate it doesn't take much  to tilt from
> being the hot new thing to being the thing that everyone has heard that
> people have gotten burned by and one best stay away.
>
> What you are hearing is frustration and fear. When people talk about
> forks, I doubt that it is because they really want to fork Elm. Most of us
> recognize that language development is hard. But people are trying to
> figure out a backup plan.
>
> As I've said, some people want very specific extensions to the language
> and those just don't seem likely to happen. As a language, Elm seems to be
> focused on being a strongly-typed, pure functional language that avoids the
> complexities of Haskell. That's laudable. (I'm the sort of caveman that
> prefers C to C++.) But for the ecosystem, if I look at other successful
> languages, it feels like Evan needs to make clear where the boundary lies
> for what he wants absolute 

Re: [elm-discuss] Re: Moving on

[Mark Hamburg]

>
> 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 speed blog post
regarding Elm talks up using Html.Lazy and to do that effectively in some
cases you need Html.map. Guess what, use them in the "wrong" way  and you
can get type system violations leading to runtime errors.

Tight control over the core is something that many language designers have
maintained and it leads to clarity. (At the large language end of the
spectrum, this has helped C# be a better language than Java despite
starting as a Java knock off.) But everything within that tight bound of
control then also becomes an area of responsibility or the technical
ecosystem suffers.

An ecosystem that had looked vibrant and innovative a year ago now looks
increasingly buggy and stagnant. We're coming up on the one year
anniversary of the Elm 0.17 release in which FRP was removed, effects
managers introduced with a plan that they would cover the web APIs, and a
new guide to Elm was introduced. The guide long contained promises of
material that was coming soon though now it just seems those promises have
been deleted rather than fulfilled. The effects manager ecosystem appears
to have been abandoned in that nothing new seems to have come to the
community in ages. Evan started a manager for local storage but hasn't seen
it as worthwhile to finish it leaving people using ports with a range of
frustrations (see other threads). Phoenix was cited as an example of where
effects managers could be useful but there is no blessed Phoenix effects
manager. If you took the velocity of the last nine months and projected it
forward, it's hard to make it look promising. People want to help. They
want to write and share code to expand what Elm can do, but the evidence
suggest that there is a lot of pushback against that right now —
particularly when it comes to getting code approved for distribution
through the standard package manager.

The lack of effects manager build out also reflects a sense that the
direction Elm development moves in is capricious. When 0.17 was released,
there was a strong message around this being the architecture for the
future of Elm and a suggestion that it wasn't going to take that much to
get coverage of the standard web API. That appeared to be the plan of
record to the extent that there was one. Binary data has been a hot topic
for quite a while and the HTTP libraries give nods toward adding support
but haven't actually done so. Now, it seems Evan is working on providing
ways to download less code or download code incrementally when delivering
web apps. That's definitely nice. Smaller is better. But to the extent that
there were hints toward a roadmap, this hadn't been on it.

This is what leads to people being worried or frustrated. This is what
leads to them leaving. There will always be churn. There will always be
people who are unhappy because of the strictures of pure functional
programming or who are unhappy because Elm isn't Haskell. But this thread
started with an active member of the community — as opposed to someone who
just came by to kick the tires — deciding that the ecosystem just wasn't
viable as a place to invest anymore. Maybe this is just a one off. But
maybe it's symptomatic. As web technologies — of which Elm clearly
positions itself as one — demonstrate it doesn't take much  to tilt from
being the hot new thing to being the thing that everyone has heard that
people have gotten burned by and one best stay away.

What you are hearing is frustration and fear. When people talk about forks,
I doubt that it is because they really want to fork Elm. Most of us
recognize that language development is hard. But people are trying to
figure out a backup plan.

As I've said, some people want very specific extensions to the language and
those just don't seem likely to happen. As a language, Elm seems to be
focused on being a strongly-typed, pure functional language that avoids the
complexities of Haskell. That's laudable. (I'm the sort of caveman that
prefers C to C++.) But for the ecosystem, if I look at other successful
languages, it feels like Evan needs to make clear where the boundary lies
for what he wants absolute control over, needs to make a commitment to
making the material inside that boundary as strong as possible, and needs
to figure out how to be supportive of active development outside of that
boundary. Those actions would allow people to make decisions based on facts
rather than hopes and/or fears. It would allow more people to decide up
front whether the Elm ecosystem is where they want to be and if it results
in some people not coming in then it also results in fewer people leaving
noisily or throwing around talk of forks to address issues that don't seem
to be being 

Re: [elm-discuss] Re: Moving on

[John Orford]

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 own
implementations are fine, but you get bitten when they have breaking
updates (Ng 1 -> 2 etc...).

Best to stick with the W3C when it appears.

2) Community / priority setting / BDFL

Elm is unique, it doesn't try to do everything well. Evan obviously has his
priorities and other things go by the way side. This is a strategy, and
this is how Elm will be effective.

It's right there on the home page:

> A delightful language for reliable webapps

>From my POV, Elm is almost success already, in that it has a goal, clearly
advertises it and is almost there. Roll on 1.0!

3) JS interop

This will evolve, but see above, the constraint is that Elm remains
reliable...

-- 
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.

[elm-discuss] Re: Moving on

[Francesco Orsenigo]

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, the elm devs are taking a very conservative, very careful 
approach: do things once and do them right.

I've come to really appreciate this, even if it clashes with my instinct of 
wanting all and wanting it now.
I do wish there were more people working on bugs tho.



On Monday, April 24, 2017 at 11:45:57 PM UTC+10, Duane Johnson wrote:
>
> Hi all,
>
> I've decided to move on from Elm. I've only been successful in 1 of 3 
> projects. I'm now in a role where I need to make an important decision 
> regarding the transition of a codebase from Angular to something else, and 
> I don't feel like I can responsibly recommend Elm as the replacement. So I 
> need to focus my time and effort elsewhere.
>
> If someone could please remove me as a moderator of elm-discuss it would 
> be appreciated.
>
> If anyone is interested in taking the `canadaduane/typed-svg` project 
> over, I'd be happy to help transition it to willing hands.
>
> Thanks,
> Duane Johnson
> aka canadaduane
>
>

-- 
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.

Re: [elm-discuss] Re: Moving on

[Peter Damoc]

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 main language seams like
a gigantic waste of energy. :)



-- 
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.

Re: [elm-discuss] Re: Moving on

[Dustin Farris]

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 language/framework—I have full 
confidence that the issues raised here and elsewhere will be put to rest 
eventually.  Regardless, Elm works great for me as it is now.

Dustin


> On Apr 25, 2017, at 12:42 PM, Eirik Sletteberg  
> wrote:
> 
> Since you mention pitch forks...
> Maybe there's a potential for an Elm fork. Something like io.js was for 
> node.js, until they re-merged. A fork which encourages community involvement 
> in the form of code patches/pull requests, even to the compiler and the core 
> library (maybe even adding new syntax to the language), and an open ecosystem 
> where anybody can publish packages. (Maybe build a package ecosystem 
> piggybacked on top of npm, instead of elm's own package manager). It could 
> support task ports, which many people think would provide much better interop 
> between Elm and JS. A fork governed and maintained by multiple people. 
> Features from the fork could be merged back into Elm upstream if they 
> succeed, or they could be discarded.
> 
> 
> tirsdag 25. april 2017 17.23.20 UTC+2 skrev Erik Lott følgende:
> 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 share packages with each other, 
> without the language creators being involved in that loop.
> 
> Unfortunately, the only solutions to the current holes and under-developed 
> areas of the web api are either to use ports or native modules (hack), 
> neither of which are acceptable solutions for developing blessed community 
> packages. So we're blocked...
> 
> The foundation of the language isn't quite ready for explosive community 
> growth yet, so expect to see a lot of pitch forks and torches until it is.
> 
> 
> 
> 
> 
> On Tuesday, April 25, 2017 at 9:27:49 AM UTC-4, 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 performant 
> Elm will ever be, newcomers will be discouraged by everlasting begging for 
> native APIs support.
> 
> Does anybody has an idea how other languages/platforms manage to get 
> community involved? I think it could be beneficial to learn from, for example 
> Elixir community, and borrow some good practices that could work for Elm too.
> 
> On Tue, 25 Apr 2017 at 05:22, Duane Johnson > wrote:
> 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 questions, 
> please reach out to me off-list. Thanks.
> 
> Hi Peter, that's kind of you to follow up off-list.
> 
> I've had several pain points. I'll go over the technical ones first and the 
> community ones second.
> 
> In the two (and a half) projects that failed, they failed for different 
> reasons but in general, because of JS interop issues. In the first project, I 
> was unable to access binary data in order to represent compiled hex blobs as 
> visual SVG (see https://github.com/canadaduane/elm-hccb/tree/master 
> ). I made a use case 
> post here 
> https://groups.google.com/d/msg/elm-discuss/spr621OlUeo/awhuqzpzBgAJ 
> .
> 
> In the second case, I was trying to create custom elements that could be 
> embedded inside the QuillJS rich text editor--in other words, it wasn't 
> enough just to treat Javascript as an external API, I needed to embed elm 
> "things" inside a JS component inside elm.
> 
> I made a third attempt to convert an AngularJS app to Elm, but didn't get 
> very far in and gave up, in part because of the attitude I've felt from the 
> Elm community that components are bad and have no place here (when everything 
> I'm seeing in Angular is trying to be more like a component, and interact 
> with the world like a component).
> 
> The community aspect that has weighed heavily on me is the feeling that I'm 
> not a participant in the decision-making or priority-setting. I feel more 
> like a distant user, or maybe an interesting use case, from which data is 
> gathered and decisions are made (by someone else, somewhere else).
> 
> I hope that helps!
> 
> Thanks 

[elm-discuss] Re: Moving on

[Marek Fajkus]

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 
obvious that making nontrivial layouts with complicated shapes based on 
dynamic data 

 
can be quite complicated and side-effectful thing to do we just simply used 
d3 (with TypeScript) for charting library (it's stand alone, works with 
server render in export service and will be used in embedable library as 
well). This means we can still make all data transformations in elm with 
immutability and types and then just encode this data and send them to d3 
to do all the dirty work in render. I wouldn't use FFI for something like 
this even if that option was there.

Anyway I agree that FFI is important for community based extensions over 
things provided by core. Even though I understand concerns of allowing 
packages with native extensions I would say some risks are part of a deal 
in OSS and that everyone using any library not only should but has to be 
aware of that . 
Nevertheless making this the reason not to use elm seems to be a bit 
overstated to me.

Anyway I'm really sorry to see Duane saying:

I made a third attempt to convert an AngularJS app to Elm, but didn't get 
> very far in and gave up, in part because of the attitude I've felt from the 
> Elm community that components are bad and have no place here (when 
> everything I'm seeing in Angular is trying to be more like a component, and 
> interact with the world like a component).
>
> The community aspect that has weighed heavily on me is the feeling that 
> I'm not a participant in the decision-making or priority-setting. I feel 
> more like a distant user, or maybe an interesting use case, from which data 
> is gathered and decisions are made (by someone else, somewhere else).
>

since I know exactly what is talking about (similar use case, similar 
experience) and can't say nothing more than that I hope this can be and 
will be improved.

-- 
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.

Re: [elm-discuss] Re: Moving on

[Erik Lott]

>
> 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 share packages with each other, 
without the language creators being involved in that loop.

Unfortunately, the only solutions to the current holes and under-developed 
areas of the web api are either to use ports or native modules (hack), 
neither of which are acceptable solutions for developing blessed community 
packages. So we're blocked...

The foundation of the language isn't quite ready for explosive community 
growth yet, so expect to see a lot of pitch forks and torches until it is.





On Tuesday, April 25, 2017 at 9:27:49 AM UTC-4, 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 performant 
> Elm will ever be, newcomers will be discouraged by everlasting begging for 
> native APIs support.
>
> Does anybody has an idea how other languages/platforms manage to get 
> community involved? I think it could be beneficial to learn from, for 
> example Elixir community, and borrow some good practices that could work 
> for Elm too.
>
> On Tue, 25 Apr 2017 at 05:22, Duane Johnson  > wrote:
>
>> 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 questions, please reach out to me off-list. Thanks.
>>
>> Hi Peter, that's kind of you to follow up off-list.
>>
>> I've had several pain points. I'll go over the technical ones first and 
>> the community ones second.
>>
>> In the two (and a half) projects that failed, they failed for different 
>> reasons but in general, because of JS interop issues. In the first project, 
>> I was unable to access binary data in order to represent compiled hex blobs 
>> as visual SVG (see https://github.com/canadaduane/elm-hccb/tree/master). 
>> I made a use case post here 
>> https://groups.google.com/d/msg/elm-discuss/spr621OlUeo/awhuqzpzBgAJ.
>>
>> In the second case, I was trying to create custom elements that could be 
>> embedded inside the QuillJS rich text editor--in other words, it wasn't 
>> enough just to treat Javascript as an external API, I needed to embed elm 
>> "things" inside a JS component inside elm.
>>
>> I made a third attempt to convert an AngularJS app to Elm, but didn't get 
>> very far in and gave up, in part because of the attitude I've felt from the 
>> Elm community that components are bad and have no place here (when 
>> everything I'm seeing in Angular is trying to be more like a component, and 
>> interact with the world like a component).
>>
>> The community aspect that has weighed heavily on me is the feeling that 
>> I'm not a participant in the decision-making or priority-setting. I feel 
>> more like a distant user, or maybe an interesting use case, from which data 
>> is gathered and decisions are made (by someone else, somewhere else).
>>
>> I hope that helps!
>>
>> Thanks again for your reaching out. I really look up to you and eeue56.
>>
>> Take care,
>> Duane
>>
>>
>> On Monday, April 24, 2017 at 4:31:08 PM UTC-6, Joe Andaverde wrote:
>>>
>>> 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 8:45:57 AM UTC-5, Duane Johnson wrote:

 Hi all,

 I've decided to move on from Elm. I've only been successful in 1 of 3 
 projects. I'm now in a role where I need to make an important decision 
 regarding the transition of a codebase from Angular to something else, and 
 I don't feel like I can responsibly recommend Elm as the replacement. So I 
 need to focus my time and effort elsewhere.

 If someone could please remove me as a moderator of elm-discuss it 
 would be appreciated.

 If anyone is interested in taking the `canadaduane/typed-svg` project 
 over, I'd be happy to help transition it to willing hands.

 Thanks,
 Duane Johnson
 aka canadaduane

 -- 
>> 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...@googlegroups.com .
>> For more options, visit 

Re: [elm-discuss] Re: Moving on

[Mark Hamburg]

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
implementation all being the work of one person. They clearly listen to the
mailing list, but they make decisions themselves about what the language is
going to be and how the implementation is going to work.

But having asserted that control over the core, the Lua team takes bug
fixes very seriously and are aggressive about fixing bugs in releases while
preserving the specification. Elm does not fare as well here with multiple
runtime crash inducing bugs sitting for months at a time.

Furthermore, Lua invested in a strong API for interoperation with native
code and welcomed people writing libraries to extend it. The Lua community
has struggled to have anything like the package repositories of Python or
Perl — it's notorious as a batteries not included language — but there was
express support as opposed to discouragement for rolling up your sleeves
and extending it as you needed. (One result of Lua's friendliness to
extension is that Lua is now at the core of some of the most important
machine learning libraries.) Contrast this with the thin official
documentation around ports and the significant limitations on how those can
be used to access and work with external functionality. It feels like an
"if you must but we'd really rather you didn't" situation.

I don't know how the process on Python worked, but I suspect given the
range of extensions to Python it was similar.

Own and control the core. Be dedicated to making it as high quality as
possible. Make it easy and encouraged for people to provide extensions
beyond the core. Elm certainly practices the first. There are signs of
trouble with respect to the second. Significant issues with regard to the
third are driving people away.

Mark

On Tue, Apr 25, 2017 at 6:27 AM Wojciech Piekutowski <
w.piekutow...@gmail.com> 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 performant
> Elm will ever be, newcomers will be discouraged by everlasting begging for
> native APIs support.
>
> Does anybody has an idea how other languages/platforms manage to get
> community involved? I think it could be beneficial to learn from, for
> example Elixir community, and borrow some good practices that could work
> for Elm too.
>
> On Tue, 25 Apr 2017 at 05:22, Duane Johnson 
> wrote:
>
>> 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 questions, please reach out to me off-list. Thanks.
>>
>> Hi Peter, that's kind of you to follow up off-list.
>>
>> I've had several pain points. I'll go over the technical ones first and
>> the community ones second.
>>
>> In the two (and a half) projects that failed, they failed for different
>> reasons but in general, because of JS interop issues. In the first project,
>> I was unable to access binary data in order to represent compiled hex blobs
>> as visual SVG (see https://github.com/canadaduane/elm-hccb/tree/master).
>> I made a use case post here
>> https://groups.google.com/d/msg/elm-discuss/spr621OlUeo/awhuqzpzBgAJ.
>>
>> In the second case, I was trying to create custom elements that could be
>> embedded inside the QuillJS rich text editor--in other words, it wasn't
>> enough just to treat Javascript as an external API, I needed to embed elm
>> "things" inside a JS component inside elm.
>>
>> I made a third attempt to convert an AngularJS app to Elm, but didn't get
>> very far in and gave up, in part because of the attitude I've felt from the
>> Elm community that components are bad and have no place here (when
>> everything I'm seeing in Angular is trying to be more like a component, and
>> interact with the world like a component).
>>
>> The community aspect that has weighed heavily on me is the feeling that
>> I'm not a participant in the decision-making or priority-setting. I feel
>> more like a distant user, or maybe an interesting use case, from which data
>> is gathered and decisions are made (by someone else, somewhere else).
>>
>> I hope that helps!
>>
>> Thanks again for your reaching out. I really look up to you and eeue56.
>>
>> Take care,
>> Duane
>>
>>
>> On Monday, April 24, 2017 at 4:31:08 PM UTC-6, Joe Andaverde wrote:
>>>
>>> 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.

Re: [elm-discuss] Re: Moving on

[Duane Johnson]

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 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.

[elm-discuss] Re: Moving on

[Marek Fajkus]

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 
further 
discussion: https://groups.google.com/forum/#!topic/elm-discuss/Lo6bG96zotI 
*

I feel I *need* to comment on this topic from slightly different side.

Even though I don't feel like current situation within community is 100% 
alrigh not just because of the thing mentioned above but also many more 
discussions here I was watching quietly *I still strongly believe that Elm 
is valuable option even for SPAs. Not will but is right now.* Sure there 
are some kind of challenges on a way but also many benefits of choosing Elm 
over Angular, React (with what ever), Ember and similar but also 
ClojureScript, PureScript, ghc.js you name it.

I deeply believe in Duane's right to make his own decisions based on both 
technical and social issues. Anyway I would be very disappointed to see his 
leading to any panic within community. More importantly I would be really 
sad to see that someone has misinterpreted some of my (possibly badly 
chosen) words.

-- 
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.

Re: [elm-discuss] Re: Moving on

['Rupert Smith' via Elm Discuss]

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 performant 
> Elm will ever be, newcomers will be discouraged by everlasting begging for 
> native APIs support.
>
> Does anybody has an idea how other languages/platforms manage to get 
> community involved? I think it could be beneficial to learn from, for 
> example Elixir community, and borrow some good practices that could work 
> for Elm too.
>

ZeroMQ was hugely successful. I worked on Apache Qpid AMQP in corporate 
sponsored context but sadly I only joined shortly after Hintjens left the 
project, in part due to a distasteful interaction with one of the other 
project sponsors that was very proprietary in its nature. This probably 
influenced his attitude to community in ZeroMQ.

http://hintjens.com/blog:95

Worth a read and the other blog posts by him around the community process - 
I'm not saying this is perfect for Elm, just worth reading.

-- 
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.

Re: [elm-discuss] Re: Moving on

[Wojciech Piekutowski]

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
native APIs support.

Does anybody has an idea how other languages/platforms manage to get
community involved? I think it could be beneficial to learn from, for
example Elixir community, and borrow some good practices that could work
for Elm too.

On Tue, 25 Apr 2017 at 05:22, Duane Johnson  wrote:

> 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 questions, please reach out to me off-list. Thanks.
>
> Hi Peter, that's kind of you to follow up off-list.
>
> I've had several pain points. I'll go over the technical ones first and
> the community ones second.
>
> In the two (and a half) projects that failed, they failed for different
> reasons but in general, because of JS interop issues. In the first project,
> I was unable to access binary data in order to represent compiled hex blobs
> as visual SVG (see https://github.com/canadaduane/elm-hccb/tree/master).
> I made a use case post here
> https://groups.google.com/d/msg/elm-discuss/spr621OlUeo/awhuqzpzBgAJ.
>
> In the second case, I was trying to create custom elements that could be
> embedded inside the QuillJS rich text editor--in other words, it wasn't
> enough just to treat Javascript as an external API, I needed to embed elm
> "things" inside a JS component inside elm.
>
> I made a third attempt to convert an AngularJS app to Elm, but didn't get
> very far in and gave up, in part because of the attitude I've felt from the
> Elm community that components are bad and have no place here (when
> everything I'm seeing in Angular is trying to be more like a component, and
> interact with the world like a component).
>
> The community aspect that has weighed heavily on me is the feeling that
> I'm not a participant in the decision-making or priority-setting. I feel
> more like a distant user, or maybe an interesting use case, from which data
> is gathered and decisions are made (by someone else, somewhere else).
>
> I hope that helps!
>
> Thanks again for your reaching out. I really look up to you and eeue56.
>
> Take care,
> Duane
>
>
> On Monday, April 24, 2017 at 4:31:08 PM UTC-6, Joe Andaverde wrote:
>>
>> 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 8:45:57 AM UTC-5, Duane Johnson wrote:
>>>
>>> Hi all,
>>>
>>> I've decided to move on from Elm. I've only been successful in 1 of 3
>>> projects. I'm now in a role where I need to make an important decision
>>> regarding the transition of a codebase from Angular to something else, and
>>> I don't feel like I can responsibly recommend Elm as the replacement. So I
>>> need to focus my time and effort elsewhere.
>>>
>>> If someone could please remove me as a moderator of elm-discuss it would
>>> be appreciated.
>>>
>>> If anyone is interested in taking the `canadaduane/typed-svg` project
>>> over, I'd be happy to help transition it to willing hands.
>>>
>>> Thanks,
>>> Duane Johnson
>>> aka canadaduane
>>>
>>> --
> 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.

Re: [elm-discuss] Re: Moving on

[Noah Hall]

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 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
>> can't commit any real time to continue development.
>
>
> Exactly what I was thinking - can it be moved to elm-community and work
> continued on it there?
>
> --
> 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.

[elm-discuss] Re: Moving on

['Rupert Smith' via Elm Discuss]

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 
> can't commit any real time to continue development.
>

Exactly what I was thinking - can it be moved to elm-community and work 
continued on it there? 

-- 
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.

[elm-discuss] Re: Moving on

[Duane Johnson]

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 questions, please reach out to me off-list. Thanks.

Hi Peter, that's kind of you to follow up off-list.

I've had several pain points. I'll go over the technical ones first and the 
community ones second.

In the two (and a half) projects that failed, they failed for different 
reasons but in general, because of JS interop issues. In the first project, 
I was unable to access binary data in order to represent compiled hex blobs 
as visual SVG (see https://github.com/canadaduane/elm-hccb/tree/master). I 
made a use case post here 
https://groups.google.com/d/msg/elm-discuss/spr621OlUeo/awhuqzpzBgAJ.

In the second case, I was trying to create custom elements that could be 
embedded inside the QuillJS rich text editor--in other words, it wasn't 
enough just to treat Javascript as an external API, I needed to embed elm 
"things" inside a JS component inside elm.

I made a third attempt to convert an AngularJS app to Elm, but didn't get 
very far in and gave up, in part because of the attitude I've felt from the 
Elm community that components are bad and have no place here (when 
everything I'm seeing in Angular is trying to be more like a component, and 
interact with the world like a component).

The community aspect that has weighed heavily on me is the feeling that I'm 
not a participant in the decision-making or priority-setting. I feel more 
like a distant user, or maybe an interesting use case, from which data is 
gathered and decisions are made (by someone else, somewhere else).

I hope that helps!

Thanks again for your reaching out. I really look up to you and eeue56.

Take care,
Duane


On Monday, April 24, 2017 at 4:31:08 PM UTC-6, Joe Andaverde wrote:
>
> 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 8:45:57 AM UTC-5, Duane Johnson wrote:
>>
>> Hi all,
>>
>> I've decided to move on from Elm. I've only been successful in 1 of 3 
>> projects. I'm now in a role where I need to make an important decision 
>> regarding the transition of a codebase from Angular to something else, and 
>> I don't feel like I can responsibly recommend Elm as the replacement. So I 
>> need to focus my time and effort elsewhere.
>>
>> If someone could please remove me as a moderator of elm-discuss it would 
>> be appreciated.
>>
>> If anyone is interested in taking the `canadaduane/typed-svg` project 
>> over, I'd be happy to help transition it to willing hands.
>>
>> Thanks,
>> Duane Johnson
>> aka canadaduane
>>
>>

-- 
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.

[elm-discuss] Re: Moving on

[Joe Andaverde]

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 8:45:57 AM UTC-5, Duane Johnson wrote:
>
> Hi all,
>
> I've decided to move on from Elm. I've only been successful in 1 of 3 
> projects. I'm now in a role where I need to make an important decision 
> regarding the transition of a codebase from Angular to something else, and 
> I don't feel like I can responsibly recommend Elm as the replacement. So I 
> need to focus my time and effort elsewhere.
>
> If someone could please remove me as a moderator of elm-discuss it would 
> be appreciated.
>
> If anyone is interested in taking the `canadaduane/typed-svg` project 
> over, I'd be happy to help transition it to willing hands.
>
> Thanks,
> Duane Johnson
> aka canadaduane
>
>

-- 
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.

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

[Janis Voigtländer]

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 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.

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

[Matthew Griffith]

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 basic and useful 
thing to me, even if two prominent libraries don't use it directly.  Moving 
it to evancz/graphics means I have to either make my users depend on 
evancz/graphics(which doesn't make a ton of sense as they're probably using 
the html/svg libraries), or it means that every library that wants to work 
with color has to export their own type, which seems a bit much as well.

So, I guess I'm happy where it is:)

-Matt










On Thursday, September 29, 2016 at 4:17:38 PM UTC-4, Nick H wrote:
>
> P.S. If this sounds like a good idea, I am happy to do the work.
>
> On Thu, Sep 29, 2016 at 1:16 PM, Nick H  > wrote:
>
>> Hi everybody,
>>
>> Since 0.18 is going to involve some module juggling in core, I thought 
>> this would be a good time to bring this up.
>>
>> This is a follow-up to an elm-discuss thread from last month. Robin 
>> argued that the Color module should not be in elm-lang/core. I agreed and 
>> suggested that it be moved to evancz/graphics.
>>
>> For me the strongest indicator that Color doesn't belong in core is to 
>> look at who depends on it. Neither of the UI-related elm-lang packages 
>> (html, svg) use it. elm-css and elm-mdl both define their own color types.
>>
>> The only library that operates well with Color is evancz/graphics. 
>> Furthermore, it is the only one that can use the entire thing. The Gradient 
>> type is opaque, so it's impossible for anyone but evancz/graphics to use it.
>>
>> I hate to suggest "one more thing" to add to the release, but it feels 
>> like low-hanging fruit. I'm sure there is a reason Color stayed behind when 
>> Graphics was extracted. One way or the other, it should be easy to decide. 
>> And if it makes sense to move it, the lack of dependencies means the change 
>> would be easy to implement.
>>
>> Thanks for humoring me,
>>
>> ~Nick
>>
>
>

-- 
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.