Moving on

[Duane Johnson]

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

[Juan Ibiapina]

Good to know I'm not the only one with this feeling!

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Juan

[John Orford]

More info would be nice - just purely out of curiosity. If you have written about this elsewhere, pls pt this out. Thanks.

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.

--

Juan

--

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.

[Zachary Kessin]

Yes, please let us know how you failed so that we can try to improve it!

Zach

ᐧ

On Mon, Apr 24, 2017 at 5:23 PM, John Orford <john....@gmail.com> wrote:

More info would be nice - just purely out of curiosity. If you have written about this elsewhere, pls pt this out. Thanks.

On Mon, 24 Apr 2017 at 15:58 Juan Ibiapina <juanib...@gmail.com> wrote:

Good to know I'm not the only one with this feeling!

On Mon, Apr 24, 2017 at 3:45 PM, Duane Johnson <duane....@gmail.com> 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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Juan

--
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+unsubscribe@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+unsubscribe@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

[Jakub Hampl]

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.

[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!

[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

[Rupert Smith]

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? 

[Noah Hall]

Open an issue here: https://github.com/elm-community/manifesto and we'll discuss

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

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

[Rupert Smith]

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.

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

[Duane Johnson]

On Tue, Apr 25, 2017 at 4:39 AM, Noah Hall <enal...@gmail.com> wrote:

Open an issue here: https://github.com/elm-community/manifesto and we'll discuss

Opened: https://github.com/elm-community/Manifesto/issues/69

[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

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

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

[Eirik Sletteberg]

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.

[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

-- 

Dustin Farris

[Peter Damoc]

On Tue, Apr 25, 2017 at 7:42 PM, Eirik Sletteberg <eiriksl...@gmail.com> 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/

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

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

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

Short of that, it would be great if the features called out on elm-lang.org got more attention. There are only four of them. Semantic versioning is essentially done and while JavaScript performance could probably be better, the benchmarks are doing well. But anytime the implementation can generate a runtime exception — other than stack overflows from halting problem issues — this is a failure of brand promise. And when people are banging their heads against JavaScript interop issues and leaving the ecosystem because of it, that makes the promises in that regard seem particularly hollow.

People are worried and frustrated.

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+unsubscribe@googlegroups.com.

[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

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.

[Peter Damoc]

On Wed, Apr 26, 2017 at 5:17 AM, John Orford <john....@gmail.com> 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. 

[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?

[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!

[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

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...@googlegroups.com.

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

--


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.

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

[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?

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

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@googlegroups.com.

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

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/44OZ-Nd4eYc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss+unsubscribe@googlegroups.com.

[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!

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

[Peter Damoc]

On Thu, Apr 27, 2017 at 2:08 AM, Oliver Searle-Barnes <oli...@opsb.co.uk> wrote:

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.

[...] 

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)

The current elm compiler allows this and if there is enough developer desire, this can be done through tooling without requiring any change to the compiler or the core. 
By going the apocryphal way we could, in theory, even implement the missing SemVer and make the apocryphal Kernel libraries start with a 0 further emphasizing that it is experimental code. 

There is danger in this approach BUT, if a good enough process is put behind it and there are a group of experienced Elm programmers monitoring it, I think that it can provide a lot of value for people who want to move in areas that are currently unsupported by Elm. 

[Rupert Smith]

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.

[Wojciech Piekutowski]

Peter, did you mean https://github.com/gdotdesign/elm-github-install for installing packages with missing Web APIs?

--

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+unsubscribe@googlegroups.com.

[Peter Damoc]

On Thu, Apr 27, 2017 at 12:59 PM, Wojciech Piekutowski <w.piek...@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.

 

 

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

[Peter Damoc]

On Thu, Apr 27, 2017 at 1:48 PM, Rehno Lindeque <rehno.l...@gmail.com> 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. :) 

 

[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 <rehno.l...@gmail.com> wrote:

--

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+unsubscribe@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

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

[Max Goldstein]

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

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

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

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

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

[Mark Hamburg]

On Apr 30, 2017, at 8:43 AM, Max Goldstein <maxgol...@gmail.com> 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

[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(?)

--

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.