Re: [elm-discuss] elm-css with type classes (a response to the Elm Town podcast)

[Joey Eremondi]

I might be misunderstanding, but in your use case, you probably want a
tagged Union, what Haskell calls data, instead of type classes. Basically,
they're always preferable when you have a fixed number is variants you
want. Your margin function would then just pattern match.

type Margin = Auto | IntMargin Int

margin: Margin -> Style
margin m = case m of ...

Is there some visual overhead having to have a tag for Int? Yes. Is your
code clearer and simpler? Yes.

Haskell classes are made for abstractions with many instances defined
separately. Things like traversable, Monads, Monoid, etc. There are many
things fitting the pattern, and we want to give people the ability to
implement it for their own types. Most experienced Haskell coders would not
use a type class in your use case.

Classes also have problems if you want to make a list of margins for some
reason. Now you can't without existential types, which are a whole
different kettle of fish. Tagged unions don't have that problem.

On Apr 26, 2017 8:03 PM, "Mitchell Rosen"  wrote:

Hello all! I am a (very) beginner Elm programmer, but I know a fair bit of
Haskell. I listened to the most recent Elm Town podcast and was especially
intrigued by the discussion around a novel use of record types to solve a
real-world problem - embedding a nice CSS DSL directly into Elm. Awesome!

I was further intrigued by Evan's suggestion that type classes were in fact
a poor solution to this problem. I'm well aware that type classes are an
overused abstraction in Haskell that can cause lots of pain in unintended
ways, especially when using them for the sole purpose of reusing nice,
short function names.

This is exactly what a CSS DSL must do, however - we'd like to be able to
say both *"overflow: hidden" *and "border-style: hidden" in our DSL by
reaching for the same intuitive name *hidden* and just have everything
magically work. Sounds like exactly the difficult sort of modeling problem
that type classes seem *superficially* suitable, but are often not in
practice.

However, after looking up the venerable elm-css
 library and peeking around its
internals, I'm not sure I agree. The implementation is, in a word,
abstruse. The types that end-users have to see and interact with are highly
non-intuitive. There's a lot of data being slogged around at runtime to
satisfy the type checker. It's simply not a good abstraction. The DSL that
came out on the other end looks great, but at what cost?

For some context, here's how I'd proceed if I had to implement this in
Haskell with type classes.

Say we want to model the key *margin* which can have a value of *auto* or
some integer (simplifying a bit here). I'd write the following type class:

*  class Margin a where*
*margin :: a -> Style*

Then, I'd write two instances for the type class - one for my made-up type
*auto* and another for *Int*.

*  data Auto = Auto*

*  instance Margin Auto where*



*margin Auto = {- implementation... -}  instance Margin Int where
margin n = {- implementation... -}*

Here's what the final type of the *margin* combinator looks like:

*  margin :: Margin a => a -> Style*

and I could use it like so:

*  margin Auto*
*  margin 5*

Now, I'm not necessarily advocating this approach (DSL design is hard), but
there it is, for reference. I happen to share a lot of the sentiments
expressed in the podcast about type classes, but in this specific case,
they actually don't seem too bad. Compare the above with the machinery in
for margin that exists in elm-css:

  *type alias LengthOrAuto compatible =*


*{ compatible | value : String, lengthOrAuto : Compatible }*
*  margin : LengthOrAuto compatible -> Style*

*  auto :*
*{ lengthOrAuto : Compatible*
*, overflow : Compatible*
*, textRendering : Compatible*
*, flexBasis : Compatible*
*, lengthOrNumberOrAutoOrNoneOrContent : Compatible*
*, alignItemsOrAuto : Compatible*
*, justifyContentOrAuto : Compatible*
*, cursor : Compatible*
*, value : String*
*, lengthOrAutoOrCoverOrContain : Compatible*
*, intOrAuto : Compatible*
*}
*

Compatible, what? Some value field is a String? Keep in mind these type are
all visible to the user - necessarily so - so they can figure out how to
fit the pieces together. However, I don't think it's unreasonable to say
that the only way (or at least the *main *way) to use this library is to
shut your brain off and trust that if you get any compiler error, it's
because you did some illegal CSS thing. It's simultaneously exposes ugly
innards (type aliases) and yet resists when you try to grok what's going on
(Compatible is not exported, though for good reason).

It concede it's possible I have overlooked some part of the library where
the simple type class approach breaks down. But when attacked top-down (I
want the DSL to come out looking like *this *so I need to use *these
language features*

Re: [elm-discuss] Re: Moving on

[Peter Damoc]

On Thu, Apr 27, 2017 at 2:08 AM, Oliver Searle-Barnes 
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.


-- 
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] elm-css with type classes (a response to the Elm Town podcast)

[Mitchell Rosen]

Hello all! I am a (very) beginner Elm programmer, but I know a fair bit of 
Haskell. I listened to the most recent Elm Town podcast and was especially 
intrigued by the discussion around a novel use of record types to solve a 
real-world problem - embedding a nice CSS DSL directly into Elm. Awesome!

I was further intrigued by Evan's suggestion that type classes were in fact 
a poor solution to this problem. I'm well aware that type classes are an 
overused abstraction in Haskell that can cause lots of pain in unintended 
ways, especially when using them for the sole purpose of reusing nice, 
short function names.

This is exactly what a CSS DSL must do, however - we'd like to be able to 
say both *"overflow: hidden" *and "border-style: hidden" in our DSL by 
reaching for the same intuitive name *hidden* and just have everything 
magically work. Sounds like exactly the difficult sort of modeling problem 
that type classes seem *superficially* suitable, but are often not in 
practice.

However, after looking up the venerable elm-css 
 library and peeking around its 
internals, I'm not sure I agree. The implementation is, in a word, 
abstruse. The types that end-users have to see and interact with are highly 
non-intuitive. There's a lot of data being slogged around at runtime to 
satisfy the type checker. It's simply not a good abstraction. The DSL that 
came out on the other end looks great, but at what cost?

For some context, here's how I'd proceed if I had to implement this in 
Haskell with type classes.

Say we want to model the key *margin* which can have a value of *auto* or 
some integer (simplifying a bit here). I'd write the following type class:

*  class Margin a where*
*margin :: a -> Style*

Then, I'd write two instances for the type class - one for my made-up type 
*auto* and another for *Int*.

*  data Auto = Auto*

*  instance Margin Auto where*



*margin Auto = {- implementation... -}  instance Margin Int where
margin n = {- implementation... -}*

Here's what the final type of the *margin* combinator looks like:

*  margin :: Margin a => a -> Style*

and I could use it like so:

*  margin Auto*
*  margin 5*

Now, I'm not necessarily advocating this approach (DSL design is hard), but 
there it is, for reference. I happen to share a lot of the sentiments 
expressed in the podcast about type classes, but in this specific case, 
they actually don't seem too bad. Compare the above with the machinery in 
for margin that exists in elm-css:

  *type alias LengthOrAuto compatible =*


*{ compatible | value : String, lengthOrAuto : Compatible }*
*  margin : LengthOrAuto compatible -> Style*

*  auto :*
*{ lengthOrAuto : Compatible*
*, overflow : Compatible*
*, textRendering : Compatible*
*, flexBasis : Compatible*
*, lengthOrNumberOrAutoOrNoneOrContent : Compatible*
*, alignItemsOrAuto : Compatible*
*, justifyContentOrAuto : Compatible*
*, cursor : Compatible*
*, value : String*
*, lengthOrAutoOrCoverOrContain : Compatible*
*, intOrAuto : Compatible*
*} 
*

Compatible, what? Some value field is a String? Keep in mind these type are 
all visible to the user - necessarily so - so they can figure out how to 
fit the pieces together. However, I don't think it's unreasonable to say 
that the only way (or at least the *main *way) to use this library is to 
shut your brain off and trust that if you get any compiler error, it's 
because you did some illegal CSS thing. It's simultaneously exposes ugly 
innards (type aliases) and yet resists when you try to grok what's going on 
(Compatible is not exported, though for good reason).

It concede it's possible I have overlooked some part of the library where 
the simple type class approach breaks down. But when attacked top-down (I 
want the DSL to come out looking like *this *so I need to use *these 
language features*), I'm not seeing why one would prefer this row-types 
approach over type classes if both happened to exist in Elm.

Thanks for reading, and if this is the umpteenth post about type classes, I 
apologize. I figured at least the concept of type classes still relevant in 
this community, given they were briefly discussed on Elm Town just today. 
I'd love to hear any seasoned Elm-ers thoughts about row types as an 
abstraction mechanism, type classes or lack thereof, elm-css, or anything 
else that came to mind while reading over this post.

Mitchell

-- 
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: Scaling Elm

[douglas smith]

Hey all,

Selfishly I would like to see a FUN and ENTERTAINING  instructional 
elm-programming application.

Something that would be useful to the WIDEST range of persons and experience 
possible. 

>From middle-school age kids to experienced 'engineers'. 

It could be built concurrently by different groups of people, but have it all 
integrate together 

into a cohesive FUN and ENTERTAINING kxcd-ish style project. 

A mix of learning material and actual UI elements that teach using the 
technology itself.

A story of sorts that could be refactored over time as the language evolves.  

And of course it needs a repl.  :)


-Doug
>
>

-- 
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 received this message because you are subscribed to the Google
 Groups

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. Until then, please use ports if you want to us

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 control event.preventDefa

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 group and stop receiving emails from it, se

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, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Scaling Elm

[Peter Damoc]

On Wed, Apr 26, 2017 at 7:13 PM, Dwayne Crooks 
wrote:

> How about writing an Elm front-end for https://github.com/
> gothinkster/realworld.
>

This is what I'm actually contemplating right now.
I'll explore it some more next week.



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

[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 the tires — deciding that 

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.

[elm-discuss] Re: Scaling Elm

[Dwayne Crooks]

How about writing an Elm front-end 
for https://github.com/gothinkster/realworld.

On Wednesday, April 19, 2017 at 5:11:05 AM UTC-4, Peter Damoc wrote:
>
> Hello community, 
>
> Scaling Elm apps seams to be a recurring topic. 
>
> I was wondering if maybe we could negotiate a minimal set of 
> functionality, something similar to ToDoMVC, that could be implemented 
> using different approaches to explore what could be the best way to 
> structure the code. 
>
> What should this minimal example cover and what this minimal example 
> should be (topic)?
>
> I'll start the list with some bits of functionality that I would like: 
>
> - multiple pages with common structure (sidebar/navbar)
> - navigation without reloading the app (SPA routing without the hash) 
> - authentication 
> - complex widget reuse (a module/widget that generates side-effects; e.g. 
> a weather widget, some stock ticker, an ad provided by a third party)
> - styling (CSS)
>
> I would also like the example to cover real world concerns of: 
> - using a build manager to integrate with other technologies 
> - development mode - deployment build
> - testing 
>
> As for topic, I was thinking about an interface to the MusicBrainz 
> Database (a simplified interface).
>
> What do you think? 
> What bits of functionality would you like to see exemplified? 
> Are you aware of any other project (in other languages) that exemplifies a 
> minimal set of functionality and could be used as a template?  
>
>
> -- 
> 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] Resources guiding towards shifting to Functional Thinking

[Oliver Searle-Barnes]

I found this talk really useful coming from an OO 
background, https://www.youtube.com/watch?v=E8I19uA-wGY&feature=youtu.be&t=1s. 
The code examples are in F# but it's an ML based language and the talk is 
mainly conceptual rather than code heavy.

On Wednesday, 26 April 2017 12:44:17 UTC+2, Jiggneshh Gohel wrote:
>
> Thanks Wojciech. http://elmprogramming.com/ really looks to be a 
> promising resources for learning Elm.
> Thanks for sharing.
>
>
> On Wed, Apr 26, 2017 at 4:05 PM, Wojciech Piekutowski  > wrote:
>
>> I recommend http://elmprogramming.com/. It isn't solely focused on 
>> functional programming, but has great illustrations of some concepts that 
>> could initially be hard to grasp. For example 
>> http://elmprogramming.com/string.html#filtering-a-string
>>
>> On 26 April 2017 at 12:13, Jiggneshh Gohel > > wrote:
>>
>>> Hello,
>>>
>>> I have started learning programming in Elm and gradually I am moving 
>>> ahead with this following the awesome tutorial at 
>>> https://www.elm-tutorial.org/en/ 
>>> . 
>>>
>>> While I am onto it I got a thought that somebody like me coming from 
>>> purely imperative programming background, when need to shift thinking in a 
>>> functional way then are there any specific classic book resources I should 
>>> refer to? I am kind of person who likes to build a strong foundation and am 
>>> more inclined towards learning on the path instead of targeting just the 
>>> end. So requesting to provide suggestions considering this.
>>>
>>> I did searched on web and found various links related to few books but 
>>> majority of those were either language-specific like Javascript, ML, 
>>> Scheme, Erlang, Elixir, Haskell, Scala, Clojure, F# etc or mostly 
>>> mathematical-notation based.  So I am really confused which ones to 
>>> consider.
>>>
>>> Thanks.
>>>
>>> 
>>>
>>> -- 
>>> 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 a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elm-discuss/9d91xF94cWA/unsubscribe.
>> To unsubscribe from this group and all its topics, 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, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Resources guiding towards shifting to Functional Thinking

[Jiggneshh Gohel]

Thanks Wojciech. http://elmprogramming.com/ really looks to be a promising
resources for learning Elm.
Thanks for sharing.


On Wed, Apr 26, 2017 at 4:05 PM, Wojciech Piekutowski <
w.piekutow...@gmail.com> wrote:

> I recommend http://elmprogramming.com/. It isn't solely focused on
> functional programming, but has great illustrations of some concepts that
> could initially be hard to grasp. For example http://elmprogramming.
> com/string.html#filtering-a-string
>
> On 26 April 2017 at 12:13, Jiggneshh Gohel 
> wrote:
>
>> Hello,
>>
>> I have started learning programming in Elm and gradually I am moving
>> ahead with this following the awesome tutorial at
>> https://www.elm-tutorial.org/en/ . 
>>
>> While I am onto it I got a thought that somebody like me coming from
>> purely imperative programming background, when need to shift thinking in a
>> functional way then are there any specific classic book resources I should
>> refer to? I am kind of person who likes to build a strong foundation and am
>> more inclined towards learning on the path instead of targeting just the
>> end. So requesting to provide suggestions considering this.
>>
>> I did searched on web and found various links related to few books but
>> majority of those were either language-specific like Javascript, ML,
>> Scheme, Erlang, Elixir, Haskell, Scala, Clojure, F# etc or mostly
>> mathematical-notation based.  So I am really confused which ones to
>> consider.
>>
>> Thanks.
>>
>> 
>>
>> --
>> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/9d91xF94cWA/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Resources guiding towards shifting to Functional Thinking

[Wojciech Piekutowski]

I recommend http://elmprogramming.com/. It isn't solely focused on
functional programming, but has great illustrations of some concepts that
could initially be hard to grasp. For example
http://elmprogramming.com/string.html#filtering-a-string

On 26 April 2017 at 12:13, Jiggneshh Gohel  wrote:

> Hello,
>
> I have started learning programming in Elm and gradually I am moving ahead
> with this following the awesome tutorial at https://www.elm-tutorial.org/en/
> . 
>
> While I am onto it I got a thought that somebody like me coming from
> purely imperative programming background, when need to shift thinking in a
> functional way then are there any specific classic book resources I should
> refer to? I am kind of person who likes to build a strong foundation and am
> more inclined towards learning on the path instead of targeting just the
> end. So requesting to provide suggestions considering this.
>
> I did searched on web and found various links related to few books but
> majority of those were either language-specific like Javascript, ML,
> Scheme, Erlang, Elixir, Haskell, Scala, Clojure, F# etc or mostly
> mathematical-notation based.  So I am really confused which ones to
> consider.
>
> Thanks.
>
> 
>
> --
> 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] Resources guiding towards shifting to Functional Thinking

[Jiggneshh Gohel]

Hello,

I have started learning programming in Elm and gradually I am moving ahead 
with this following the awesome tutorial at https://www.elm-tutorial.org/en/ 
. 

While I am onto it I got a thought that somebody like me coming from purely 
imperative programming background, when need to shift thinking in a 
functional way then are there any specific classic book resources I should 
refer to? I am kind of person who likes to build a strong foundation and am 
more inclined towards learning on the path instead of targeting just the 
end. So requesting to provide suggestions considering this.

I did searched on web and found various links related to few books but 
majority of those were either language-specific like Javascript, ML, 
Scheme, Erlang, Elixir, Haskell, Scala, Clojure, F# etc or mostly 
mathematical-notation based.  So I am really confused which ones to 
consider.

Thanks.



-- 
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 fear. When people talk about