[elm-discuss] Literature review of requested features

[Max Goldstein]

I'm salvaging this idea from the "moving on" thread. Basically, some 
features like audio playback, binary data, task ports, and so on have been 
commonly requested. I'd like to propose that the advocates of these 
features do some of the pre-code legwork. This is more of a literature 
review than a design document. It would serve several purposes: to give 
those clamoring for features something to do (funnel the creative energy), 
to to let them examine the feature in more depth to determine if it really 
solves their problem, and to give some guidance during implementing that 
we're talking about the same thing. It would also provide a common place to 
link when someone asks "what are task ports?".

This project would take the form of a collection of markdown documents, 
each researching a particular proposed addition and say why it would be 
useful. Each document should, for its proposed feature X:

   - Define X
   - Explain of 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, with 
   links
   - Give type signatures or syntax of a *proposed* API for X

This is work that Evan would have to do anyway. (And he might still have to 
do it anyway, since I haven't talked to him about this and he might ignore 
or nix it.)

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[John Orford]

This thread is really good imho.

Uncomfortable? Perhaps. But everyone here has good intentions.

>From my POV Elm ain't your usual throw-things-at-the-wall and see what
sticks open source project, which is what makes it very very special.

And therefore perhaps the community and our BDFL need to communicate
better(?)
On Mon 1. May 2017 at 02:33, Mark Hamburg  wrote:

> On Apr 30, 2017, at 8:43 AM, Max Goldstein 
> wrote:
>
> Fourth, web components were briefly mentioned. Richard gave a talk on
> these  last year and it
> seems like everything you need already works.
>
>
> Specifically, on this, no. The virtual DOM API does not make the sort of
> specific commitments one would need in order to know that a web component
> with its own state would not get accidentally destroyed and recreated
> rather than preserved. The code that works today just happens to work
> because the virtual DOM implementation just happens to do certain things
> that just happen to work out right. An example of the sort of guarantee
> that would resolve this would be "keyed nodes always preserved keyed child
> identity on updates provided you don't assign the same key to multiple
> children". That comes with caveats about what won't work and you have to
> make sure the path is stable all the way up the DOM and not just at the
> component, but if you obey the rules, it promises that something will work
> and keep working. Html.Keyed makes no such guarantee and as I recall when I
> last looked at the code it didn't look like the implementation would be
> likely to support such a guarantee.
>
> On the broader issue, Elm is free code and it does what it does and being
> free, people have no right to ask for anything more. But similarly people
> need to figure out whether the benefit they are getting is valuable enough
> to stick around v some of the other options that have been bandied about on
> this thread such as moving to other languages or forking Elm (thereby
> essentially creating another language). The talk here does not in general
> seem focused on going elsewhere but rather on what sort of changes in
> process and policy would quell the concerns. Remember that this thread
> started with an engaged community member leaving because using Elm had lead
> him to more failures than successes. People ought to ask "is that likely to
> be the case for me as well" and the community ought to ask "how might we
> fix the things that resulted in those failures?" You are right that this
> code is being made available free by Evan (or by NoRedInk since they are
> funding his work) and as such, it's his call. But similarly, it is a call
> for everyone using Elm as to whether it is still working out or whether
> they would be better off placing their bets elsewhere.
>
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Dustin Farris]

Also, have you seen elm-plot?

https://terezka.github.io/elm-plot/

I haven't played with it yet, but it looks pretty neat.  Might help with some 
of your features that used highcharts?

Dustin


Sent from my iPhone

> On Apr 30, 2017, at 8:10 PM, Dwayne Crooks  wrote:
> 
> I posted here as the other thread seems to be closed off from replies.
> 
> For this particular app I'm writing/porting the SPA from scratch to Elm and 
> the formatting issue was the first small hiccup I ran into. As suggested in 
> the other thread I went ahead and wrote the code I needed in Elm.
> 
> Here it is in case anyone else is interested:
> 
>> module Format exposing (asMoney)
>> 
>> asMoney : Float -> String
>> asMoney value =
>> let
>> totalCents = round (value * 100)
>> dollars = totalCents // 100
>> cents = totalCents % 100
>> in
>> "$" ++ (groupBy 3 ',' dollars) ++ "." ++ (zeroPad 2 cents)
>> 
>> groupBy : Int -> Char -> Int -> String
>> groupBy per sep n =
>> let
>> pow10 = 10 ^ per
>> in
>> if n < pow10 then
>> toString n
>> else
>> zeroPad 3 (n % pow10)
>> |> String.cons sep
>> |> String.append (groupBy per sep <| n // pow10)
>> 
>> zeroPad : Int -> Int -> String
>> zeroPad k n = String.padLeft k '0' (toString n)
> 
> P.S. Dustin, I decided to write one for myself. But thanks.
> 
> My next task is to draw some charts using Highcharts. I expect ports would be 
> the approach here so I'm crossing my fingers and hoping it all works out. I 
> certainly won't want to be re-writing parts of Highcharts at this point.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] Ports seem contrived when trying to format a value as money

[Dustin Farris]

Ah, your version is way better！Love the groupBy function.   Cheers! 

Dustin

Sent from my iPhone

> On Apr 30, 2017, at 8:10 PM, Dwayne Crooks  wrote:
> 
> I posted here as the other thread seems to be closed off from replies.
> 
> For this particular app I'm writing/porting the SPA from scratch to Elm and 
> the formatting issue was the first small hiccup I ran into. As suggested in 
> the other thread I went ahead and wrote the code I needed in Elm.
> 
> Here it is in case anyone else is interested:
> 
>> module Format exposing (asMoney)
>> 
>> asMoney : Float -> String
>> asMoney value =
>> let
>> totalCents = round (value * 100)
>> dollars = totalCents // 100
>> cents = totalCents % 100
>> in
>> "$" ++ (groupBy 3 ',' dollars) ++ "." ++ (zeroPad 2 cents)
>> 
>> groupBy : Int -> Char -> Int -> String
>> groupBy per sep n =
>> let
>> pow10 = 10 ^ per
>> in
>> if n < pow10 then
>> toString n
>> else
>> zeroPad 3 (n % pow10)
>> |> String.cons sep
>> |> String.append (groupBy per sep <| n // pow10)
>> 
>> zeroPad : Int -> Int -> String
>> zeroPad k n = String.padLeft k '0' (toString n)
> 
> P.S. Dustin, I decided to write one for myself. But thanks.
> 
> My next task is to draw some charts using Highcharts. I expect ports would be 
> the approach here so I'm crossing my fingers and hoping it all works out. I 
> certainly won't want to be re-writing parts of Highcharts at this point.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] Ports seem contrived when trying to format a value as money

[Dwayne Crooks]

I posted here as the other thread seems to be closed off from replies.

For this particular app I'm writing/porting the SPA from scratch to Elm and 
the formatting issue was the first small hiccup I ran into. As suggested in 
the other thread I went ahead and wrote the code I needed in Elm.

Here it is in case anyone else is interested:

module Format exposing (asMoney)
>
> asMoney : Float -> String
> asMoney value =
> let
> totalCents = round (value * 100)
> dollars = totalCents // 100
> cents = totalCents % 100
> in
> "$" ++ (groupBy 3 ',' dollars) ++ "." ++ (zeroPad 2 cents)
>
> groupBy : Int -> Char -> Int -> String
> groupBy per sep n =
> let
> pow10 = 10 ^ per
> in
> if n < pow10 then
> toString n
> else
> zeroPad 3 (n % pow10)
> |> String.cons sep
> |> String.append (groupBy per sep <| n // pow10)
>
> zeroPad : Int -> Int -> String
> zeroPad k n = String.padLeft k '0' (toString n)


*P.S.* *Dustin, I decided to write one for myself. But thanks.*

My next task is to draw some charts using Highcharts. I expect ports would 
be the approach here so I'm crossing my fingers and hoping it all works 
out. I certainly won't want to be re-writing parts of Highcharts at this 
point.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Witold Szczerba]

Noah, just re-read the Dwayne's original post. He has some app in React and
he's trying Elm to replace it. One of his first bump was the little,
(trivial maybe) issue with formatting. He's used to use that very library
for it and the question was how should the integration look like.

Using ports and subscriptions is an obvious overkill. Dewayne has tried it
and, of course, it's just a crazy idea.

If all you have to say is "just reimplement the damn formatting yourself"
then I would not be surprised if he would try this and run away from Elm
next time he needs some interop with JS, because next time it can be
something 100x more complicated than just the currency formatting.

I'm not saying the native bindings are a recipe for everything, but this is
just the (potential) case for them: no effects, pure function, prefect
match. Elm-lang/core is full of it and it works good. I'm sure half of out
could be reimplementend in terms of the other half in Elm, but what for?

01.05.2017 1:18 AM "Noah Hall"  napisał(a):

> Witold, that's a ridiculous response. Please re-read my reply. Without
> fully knowing the context of the problem, you suggested using Native.
> This is not something we encourage in the Elm community. There are
> valid reasons as to why not. When recommending it, is it best to know
> _everything_ about the situtation. Like I said, it should _never_ be
> the first thing you reach for. I emphasised this in both my replies.
> Please re-read them.
>
> Dwayne, please come get help on Slack. People are helpful there, and
> we will help drill down into the best possible solution for your
> problem. :)
>
> On Mon, May 1, 2017 at 1:12 AM, Witold Szczerba 
> wrote:
> > Noah is always right. He's just a Elm Rock Star, he knows the best. is
> that
> > realy what be said to me or did I miss the point? I have no idea what I
> was
> > thinking when I dreaded to "lecture" him.
> >
> > Oh, by the way, Dwayne's attempt to follow those golden rules failed. He
> > must have missed something obvious, like reimplementing the formatting in
> > Elm by his own.
> >
> > Dustin is right here. If it's trivial then just go for it, Dwayne,
> really.
> > If it's not simple then... suffer, or do what I did and get the job done,
> > just do follow all the FP rules and don't feel "bad" about it all.
> >
> > 01.05.2017 12:15 AM "Erik Lott"  napisał(a):
> >>
> >> Noah is right. You don't want to reach for Native for this type of
> >> integration. If this can't be smoothly integrated with ports (we've all
> felt
> >> that pain), the next best option is to write the elements of the plug-in
> >> that you need in elm.
> >>
> >> On Sunday, April 30, 2017 at 1:37:04 PM UTC-4, Noah Hall wrote:
> >>>
> >>> Witold, with all due respect, I am one of the people who has written
> >>> the _most_ Native code. I know a thing or two about it. You do not
> >>> need to lecture me, and my warning should be heeded.
> >>>
> >>> Like I said, there are _some_ cases where a Native binding makes
> >>> sense. They are few and far between.  These problems are best
> >>> discussed on Slack, where we can drill down into the exact use case.
> >>> For example, is it only one currency format? If it is, re-writing in
> >>> Elm should be trivial.
> >>>
> >>> On Sun, Apr 30, 2017 at 7:30 PM, Witold Szczerba 
> >>> wrote:
> >>> > Noah, this is exactly the kind of problem to be solved by native
> >>> > binding.
> >>> > Dwayne wants to use his formatting library. This is a classic example
> >>> > of
> >>> > pure function. Nothing is going to crash if you wrap exception in
> >>> > Result and
> >>> > check types.
> >>> >
> >>> > Good advices of self reimplementig everything from scratch in Elm or
> >>> > using
> >>> > subscriptions for pure functions is nothing but making Elm people
> >>> > suffer
> >>> > instead of getting things done.
> >>> >
> >>> > Native bindings are not bad per se. Just use it wisely, be pragmatic
> or
> >>> > we
> >>> > will read another "Moving on", by Dwayne Crooks" this time.
> >>> >
> >>> > 30.04.2017 7:07 PM "Noah Hall"  napisał(a):
> >>> >>
> >>> >> Witold, this it not the advice that we give to people exploring such
> >>> >> problems in Elm. There are many reasons why Native bindings are
> bad. A
> >>> >> single error in your JS will cause the _entire_ application to crash
> >>> >> unrecoverably. Wrapping things as a result will not help you catch
> >>> >> those errors. Writing carefully thought out and tested code will.
> >>> >> While there are cases where a Native function helps out a lot, it
> >>> >> should _never_ be the first thing to reach for.
> >>> >>
> >>> >>
> >>> >> Dwayne, I suggest discussing things on the Elm Slack. It will be
> >>> >> easier to get to the exact use case you have for your formatting
> >>> >> issue.
> >>> >>
> >>> >>
> >>> >> On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba <
> witold...@gmail.com>
> >>> 

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Noah Hall]

Witold, that's a ridiculous response. Please re-read my reply. Without
fully knowing the context of the problem, you suggested using Native.
This is not something we encourage in the Elm community. There are
valid reasons as to why not. When recommending it, is it best to know
_everything_ about the situtation. Like I said, it should _never_ be
the first thing you reach for. I emphasised this in both my replies.
Please re-read them.

Dwayne, please come get help on Slack. People are helpful there, and
we will help drill down into the best possible solution for your
problem. :)

On Mon, May 1, 2017 at 1:12 AM, Witold Szczerba  wrote:
> Noah is always right. He's just a Elm Rock Star, he knows the best. is that
> realy what be said to me or did I miss the point? I have no idea what I was
> thinking when I dreaded to "lecture" him.
>
> Oh, by the way, Dwayne's attempt to follow those golden rules failed. He
> must have missed something obvious, like reimplementing the formatting in
> Elm by his own.
>
> Dustin is right here. If it's trivial then just go for it, Dwayne, really.
> If it's not simple then... suffer, or do what I did and get the job done,
> just do follow all the FP rules and don't feel "bad" about it all.
>
> 01.05.2017 12:15 AM "Erik Lott"  napisał(a):
>>
>> Noah is right. You don't want to reach for Native for this type of
>> integration. If this can't be smoothly integrated with ports (we've all felt
>> that pain), the next best option is to write the elements of the plug-in
>> that you need in elm.
>>
>> On Sunday, April 30, 2017 at 1:37:04 PM UTC-4, Noah Hall wrote:
>>>
>>> Witold, with all due respect, I am one of the people who has written
>>> the _most_ Native code. I know a thing or two about it. You do not
>>> need to lecture me, and my warning should be heeded.
>>>
>>> Like I said, there are _some_ cases where a Native binding makes
>>> sense. They are few and far between.  These problems are best
>>> discussed on Slack, where we can drill down into the exact use case.
>>> For example, is it only one currency format? If it is, re-writing in
>>> Elm should be trivial.
>>>
>>> On Sun, Apr 30, 2017 at 7:30 PM, Witold Szczerba 
>>> wrote:
>>> > Noah, this is exactly the kind of problem to be solved by native
>>> > binding.
>>> > Dwayne wants to use his formatting library. This is a classic example
>>> > of
>>> > pure function. Nothing is going to crash if you wrap exception in
>>> > Result and
>>> > check types.
>>> >
>>> > Good advices of self reimplementig everything from scratch in Elm or
>>> > using
>>> > subscriptions for pure functions is nothing but making Elm people
>>> > suffer
>>> > instead of getting things done.
>>> >
>>> > Native bindings are not bad per se. Just use it wisely, be pragmatic or
>>> > we
>>> > will read another "Moving on", by Dwayne Crooks" this time.
>>> >
>>> > 30.04.2017 7:07 PM "Noah Hall"  napisał(a):
>>> >>
>>> >> Witold, this it not the advice that we give to people exploring such
>>> >> problems in Elm. There are many reasons why Native bindings are bad. A
>>> >> single error in your JS will cause the _entire_ application to crash
>>> >> unrecoverably. Wrapping things as a result will not help you catch
>>> >> those errors. Writing carefully thought out and tested code will.
>>> >> While there are cases where a Native function helps out a lot, it
>>> >> should _never_ be the first thing to reach for.
>>> >>
>>> >>
>>> >> Dwayne, I suggest discussing things on the Elm Slack. It will be
>>> >> easier to get to the exact use case you have for your formatting
>>> >> issue.
>>> >>
>>> >>
>>> >> On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba 
>>> >> wrote:
>>> >> > Ports and subscriptions are for executing actions with effects, in
>>> >> > my
>>> >> > opinion. Native bindings for pure functions are nothing bad. Just
>>> >> > keep
>>> >> > away
>>> >> > from exceptions, use Result in case of possible troubles.
>>> >> >
>>> >> > 30.04.2017 4:00 PM "Dwayne Crooks"  napisał(a):
>>> >> >>
>>> >> >> Thanks guys.
>>> >> >>
>>> >> >> I explored Noah's approach to see how the solution would turn out.
>>> >> >> But
>>> >> >> I
>>> >> >> didn't like it. The code change required to format a list of floats
>>> >> >> as
>>> >> >> money
>>> >> >> is ridiculous. Here's what I started with
>>> >> >>
>>> >> >>
>>> >> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm.
>>> >> >> And here's what I ended up with
>>> >> >>
>>> >> >>
>>> >> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1a-useports-elm,
>>> >> >>
>>> >> >>
>>> >> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1b-useports-html.
>>> >> >>
>>> >> >> P.S. The solution still doesn't quite work because all money
>>> >> >> receives
>>> >> >> the
>>> >> >> first incoming subscription message causing them to 

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Witold Szczerba]

Noah is always right. He's just a Elm Rock Star, he knows the best. is that
realy what be said to me or did I miss the point? I have no idea what I was
thinking when I dreaded to "lecture" him.

Oh, by the way, Dwayne's attempt to follow those golden rules failed. He
must have missed something obvious, like reimplementing the formatting in
Elm by his own.

Dustin is right here. If it's trivial then just go for it, Dwayne, really.
If it's not simple then... suffer, or do what I did and get the job done,
 just do follow all the FP rules and don't feel "bad" about it all.

01.05.2017 12:15 AM "Erik Lott"  napisał(a):

> Noah is right. You don't want to reach for Native for this type of
> integration. If this can't be smoothly integrated with ports (we've all
> felt that pain), the next best option is to write the elements of the
> plug-in that you need in elm.
>
> On Sunday, April 30, 2017 at 1:37:04 PM UTC-4, Noah Hall wrote:
>>
>> Witold, with all due respect, I am one of the people who has written
>> the _most_ Native code. I know a thing or two about it. You do not
>> need to lecture me, and my warning should be heeded.
>>
>> Like I said, there are _some_ cases where a Native binding makes
>> sense. They are few and far between.  These problems are best
>> discussed on Slack, where we can drill down into the exact use case.
>> For example, is it only one currency format? If it is, re-writing in
>> Elm should be trivial.
>>
>> On Sun, Apr 30, 2017 at 7:30 PM, Witold Szczerba 
>> wrote:
>> > Noah, this is exactly the kind of problem to be solved by native
>> binding.
>> > Dwayne wants to use his formatting library. This is a classic example
>> of
>> > pure function. Nothing is going to crash if you wrap exception in
>> Result and
>> > check types.
>> >
>> > Good advices of self reimplementig everything from scratch in Elm or
>> using
>> > subscriptions for pure functions is nothing but making Elm people
>> suffer
>> > instead of getting things done.
>> >
>> > Native bindings are not bad per se. Just use it wisely, be pragmatic or
>> we
>> > will read another "Moving on", by Dwayne Crooks" this time.
>> >
>> > 30.04.2017 7:07 PM "Noah Hall"  napisał(a):
>> >>
>> >> Witold, this it not the advice that we give to people exploring such
>> >> problems in Elm. There are many reasons why Native bindings are bad. A
>> >> single error in your JS will cause the _entire_ application to crash
>> >> unrecoverably. Wrapping things as a result will not help you catch
>> >> those errors. Writing carefully thought out and tested code will.
>> >> While there are cases where a Native function helps out a lot, it
>> >> should _never_ be the first thing to reach for.
>> >>
>> >>
>> >> Dwayne, I suggest discussing things on the Elm Slack. It will be
>> >> easier to get to the exact use case you have for your formatting
>> >> issue.
>> >>
>> >>
>> >> On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba 
>>
>> >> wrote:
>> >> > Ports and subscriptions are for executing actions with effects, in
>> my
>> >> > opinion. Native bindings for pure functions are nothing bad. Just
>> keep
>> >> > away
>> >> > from exceptions, use Result in case of possible troubles.
>> >> >
>> >> > 30.04.2017 4:00 PM "Dwayne Crooks" 
>> napisał(a):
>> >> >>
>> >> >> Thanks guys.
>> >> >>
>> >> >> I explored Noah's approach to see how the solution would turn out.
>> But
>> >> >> I
>> >> >> didn't like it. The code change required to format a list of floats
>> as
>> >> >> money
>> >> >> is ridiculous. Here's what I started with
>> >> >>
>> >> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d338
>> 73d#file-0-start-elm.
>> >> >> And here's what I ended up with
>> >> >>
>> >> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d338
>> 73d#file-1a-useports-elm,
>> >> >>
>> >> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d338
>> 73d#file-1b-useports-html.
>> >> >>
>> >> >> P.S. The solution still doesn't quite work because all money
>> receives
>> >> >> the
>> >> >> first incoming subscription message causing them to display the
>> same
>> >> >> formatted value. I didn't bother to fix it because the solution is
>> bad
>> >> >> enough.
>> >> >>
>> >> >> I think we can safely rule out ports. Noah, do you have any
>> thoughts on
>> >> >> the code? Did I miss anything?
>> >> >>
>> >> >> That leaves us with:
>> >> >>
>> >> >> Using a Native module. (Looks like the best compromise for my needs
>> in
>> >> >> the
>> >> >> short-term.)
>> >> >> Rewrite in pure Elm. (Looks like the best long-term solution.)
>> >> >>
>> >> >> Next step: I will write up a Native solution and see how that goes.
>> >> >>
>> >> >> --
>> >> >> 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 

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Erik Lott]

Noah is right. You don't want to reach for Native for this type of 
integration. If this can't be smoothly integrated with ports (we've all 
felt that pain), the next best option is to write the elements of the 
plug-in that you need in elm.

On Sunday, April 30, 2017 at 1:37:04 PM UTC-4, Noah Hall wrote:
>
> Witold, with all due respect, I am one of the people who has written 
> the _most_ Native code. I know a thing or two about it. You do not 
> need to lecture me, and my warning should be heeded. 
>
> Like I said, there are _some_ cases where a Native binding makes 
> sense. They are few and far between.  These problems are best 
> discussed on Slack, where we can drill down into the exact use case. 
> For example, is it only one currency format? If it is, re-writing in 
> Elm should be trivial. 
>
> On Sun, Apr 30, 2017 at 7:30 PM, Witold Szczerba  > wrote: 
> > Noah, this is exactly the kind of problem to be solved by native 
> binding. 
> > Dwayne wants to use his formatting library. This is a classic example of 
> > pure function. Nothing is going to crash if you wrap exception in Result 
> and 
> > check types. 
> > 
> > Good advices of self reimplementig everything from scratch in Elm or 
> using 
> > subscriptions for pure functions is nothing but making Elm people suffer 
> > instead of getting things done. 
> > 
> > Native bindings are not bad per se. Just use it wisely, be pragmatic or 
> we 
> > will read another "Moving on", by Dwayne Crooks" this time. 
> > 
> > 30.04.2017 7:07 PM "Noah Hall"  
> napisał(a): 
> >> 
> >> Witold, this it not the advice that we give to people exploring such 
> >> problems in Elm. There are many reasons why Native bindings are bad. A 
> >> single error in your JS will cause the _entire_ application to crash 
> >> unrecoverably. Wrapping things as a result will not help you catch 
> >> those errors. Writing carefully thought out and tested code will. 
> >> While there are cases where a Native function helps out a lot, it 
> >> should _never_ be the first thing to reach for. 
> >> 
> >> 
> >> Dwayne, I suggest discussing things on the Elm Slack. It will be 
> >> easier to get to the exact use case you have for your formatting 
> >> issue. 
> >> 
> >> 
> >> On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba  > 
> >> wrote: 
> >> > Ports and subscriptions are for executing actions with effects, in my 
> >> > opinion. Native bindings for pure functions are nothing bad. Just 
> keep 
> >> > away 
> >> > from exceptions, use Result in case of possible troubles. 
> >> > 
> >> > 30.04.2017 4:00 PM "Dwayne Crooks"  
> napisał(a): 
> >> >> 
> >> >> Thanks guys. 
> >> >> 
> >> >> I explored Noah's approach to see how the solution would turn out. 
> But 
> >> >> I 
> >> >> didn't like it. The code change required to format a list of floats 
> as 
> >> >> money 
> >> >> is ridiculous. Here's what I started with 
> >> >> 
> >> >> 
> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm.
>  
>
> >> >> And here's what I ended up with 
> >> >> 
> >> >> 
> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1a-useports-elm,
>  
>
> >> >> 
> >> >> 
> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1b-useports-html.
>  
>
> >> >> 
> >> >> P.S. The solution still doesn't quite work because all money 
> receives 
> >> >> the 
> >> >> first incoming subscription message causing them to display the same 
> >> >> formatted value. I didn't bother to fix it because the solution is 
> bad 
> >> >> enough. 
> >> >> 
> >> >> I think we can safely rule out ports. Noah, do you have any thoughts 
> on 
> >> >> the code? Did I miss anything? 
> >> >> 
> >> >> That leaves us with: 
> >> >> 
> >> >> Using a Native module. (Looks like the best compromise for my needs 
> in 
> >> >> the 
> >> >> short-term.) 
> >> >> Rewrite in pure Elm. (Looks like the best long-term solution.) 
> >> >> 
> >> >> Next step: I will write up a Native solution and see how that goes. 
> >> >> 
> >> >> -- 
> >> >> 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 

[elm-discuss] Re: Discovery: Model /= Database

[Oliver Searle-Barnes]

The pattern we use is to have our Page.update functions return

(model, cmd, storeCmd)

the main update then applies the storeCmd to the Store. (the actual code 
supports a few other things but that's the basic gist of it). Hit me up on 
slack if you want to chat about it.



On Sunday, 30 April 2017 08:45:49 UTC+2, Dustin Farris wrote:
>
> I think I've just had an aha moment with this post.
>
> I am in the process of refactoring my monolith MUV into separate modules 
> with their own MUV for each "page" of my SPA.  Up to this point, I have had 
> a separate Store module with its own Model and Msg types and an update 
> function (no view, obviously).  This has worked well up until now, but 
> after splitting off the pages of my app, it is getting more cumbersome to 
> update the Store in a way that looks nice.
>
> e.g. in my Main.elm I'm ending up with something like
>
> update msg model =
> case msg of
> UserProfilePageMsg msg_ ->
> let
> ( userProfilePageModel, userProfilePageCmd ) =
> UserProfilePage.update msg_ model.userProfilePage
> in
> case msg_ of
> UserProfilePage.StoreMsg msg__ ->
> let
> ( storeModel, storeCmd ) =
> Store.update msg__ model.store
> in
> { model
> | userProfilePage = userProfilePageModel
> , store = storeModel
> }
> ! [ Cmd.map UserProfilePageMsg 
> userProfilePageCmd
>   , Cmd.map StoreMsg storeCmd
>   ]
> _ ->
> { model | userProfilePage = userProfilePageModel }
> ! [ Cmd.map UserProfilePageMsg 
> userProfilePageCmd ]
>
>
> and so on for every page that invokes Store.Msg—which is most pages.
>
> I am thinking that there is a better way, and perhaps Kasey's suggestion 
> of forgoing an in-memory Store on the Model might be it.  I'm still not 
> sure—I do like the snappy feel of a page loading instantly if the data is 
> in memory—even if it might change after a brief consultation with the 
> server.
>
> Dustin
>
>
> On Wednesday, April 19, 2017 at 7:28:06 PM UTC-4, Kasey Speakman wrote:
>>
>> I'm probably slow, but in recent months I've discovered that trying to 
>> use Elm's Model like a database or cache (as I have previously seen 
>> suggested) has turned out to be pretty painful for me. An example 
>> database-minded model where a section could display *either* a list of 
>> employees *or* a list of courses.
>>
>> type alias Model =
>> { employees : List Employee
>> , courses : List Course
>> , loadingError : Maybe Http.Error
>> , route : MyRoute -- employee or course
>> }
>>
>> The problem this runs into is having to worry about state management. I 
>> have to remember to "reset" or "turn off" things when they are not active. 
>> As my application grew, I had a lot of problems that boiled down to tedious 
>> state management details. My cached data didn't turn out to be all that 
>> useful because I usually had to reload it anyway, in case something changed.
>>
>> Instead, I have been moving toward the model only representing the 
>> current state of my UI. The big difference here is the model representing 
>> the current *visual* elements and their data. This leads more to using 
>> union types to represent parts of the UI. When you switch to a different 
>> case of the union type, the data from the previous case is *dropped on 
>> the floor*. This leaves nothing to remember to "reset". RemoteData is a 
>> good micro-example of this. If there was an error fetching the data, when 
>> the user requests the data again, you switch back to Loading, the error 
>> message is dropped on the floor. No forgetting to hide it.
>>
>> type RemoteData e a
>> = NotAsked
>> | Loading
>> | Failure e
>> | Success a
>>
>> If it is really important to cache the data, I prefer to keep that as a 
>> persistence concern, not on Model. It can be part of the process for 
>> retrieving the data to first check my chosen cache before making a request 
>> for fresh data. For instance, first check local storage before making an 
>> HTTP call. (Currently, this scenario is easier with Native modules for lack 
>> of Local Storage API or being able to wait on port subscriptions. But it's 
>> still doable.)
>>
>> So working towards a Model reflecting the visuals on the page has been an 
>> interesting challenge. I'm not claiming it's easier, but so far I've found 
>> it avoids a class of problems, and has led to some interesting discoveries 
>> in my own apps. One small example: I realized that my LoggedIn and 
>> NotLoggedIn routes should actually be separate "apps". 

Re: [elm-discuss] Re: Moving on

[Mark Hamburg]

On Apr 30, 2017, at 8:43 AM, Max Goldstein  wrote:
> 
> Fourth, web components were briefly mentioned. Richard gave a talk on these 
> last year and it seems like everything you need already works.

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

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

Mark

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[Rehno Lindeque]

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

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


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


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


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

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[Erik Lott]

>
>  I'm going to call out the air of ungratefulness and animosity in this 
> thread. Evan is giving you software for free, and it's software that's good 
> enough that you invest your time into writing it and commenting about it. 
> You should not expect Elm to move at the same pace as Angular (backed by 
> Google) or React (backed by Facebook). Calling out that you want something 
> done faster or differently, when you are not a financial backer or core 
> contributor (to be fair, there aren't any of those besides Evan), comes off 
> as extremely petulant.


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



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

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[Noah Hall]

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

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Noah Hall]

Witold, with all due respect, I am one of the people who has written
the _most_ Native code. I know a thing or two about it. You do not
need to lecture me, and my warning should be heeded.

Like I said, there are _some_ cases where a Native binding makes
sense. They are few and far between.  These problems are best
discussed on Slack, where we can drill down into the exact use case.
For example, is it only one currency format? If it is, re-writing in
Elm should be trivial.

On Sun, Apr 30, 2017 at 7:30 PM, Witold Szczerba  wrote:
> Noah, this is exactly the kind of problem to be solved by native binding.
> Dwayne wants to use his formatting library. This is a classic example of
> pure function. Nothing is going to crash if you wrap exception in Result and
> check types.
>
> Good advices of self reimplementig everything from scratch in Elm or using
> subscriptions for pure functions is nothing but making Elm people suffer
> instead of getting things done.
>
> Native bindings are not bad per se. Just use it wisely, be pragmatic or we
> will read another "Moving on", by Dwayne Crooks" this time.
>
> 30.04.2017 7:07 PM "Noah Hall"  napisał(a):
>>
>> Witold, this it not the advice that we give to people exploring such
>> problems in Elm. There are many reasons why Native bindings are bad. A
>> single error in your JS will cause the _entire_ application to crash
>> unrecoverably. Wrapping things as a result will not help you catch
>> those errors. Writing carefully thought out and tested code will.
>> While there are cases where a Native function helps out a lot, it
>> should _never_ be the first thing to reach for.
>>
>>
>> Dwayne, I suggest discussing things on the Elm Slack. It will be
>> easier to get to the exact use case you have for your formatting
>> issue.
>>
>>
>> On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba 
>> wrote:
>> > Ports and subscriptions are for executing actions with effects, in my
>> > opinion. Native bindings for pure functions are nothing bad. Just keep
>> > away
>> > from exceptions, use Result in case of possible troubles.
>> >
>> > 30.04.2017 4:00 PM "Dwayne Crooks"  napisał(a):
>> >>
>> >> Thanks guys.
>> >>
>> >> I explored Noah's approach to see how the solution would turn out. But
>> >> I
>> >> didn't like it. The code change required to format a list of floats as
>> >> money
>> >> is ridiculous. Here's what I started with
>> >>
>> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm.
>> >> And here's what I ended up with
>> >>
>> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1a-useports-elm,
>> >>
>> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1b-useports-html.
>> >>
>> >> P.S. The solution still doesn't quite work because all money receives
>> >> the
>> >> first incoming subscription message causing them to display the same
>> >> formatted value. I didn't bother to fix it because the solution is bad
>> >> enough.
>> >>
>> >> I think we can safely rule out ports. Noah, do you have any thoughts on
>> >> the code? Did I miss anything?
>> >>
>> >> That leaves us with:
>> >>
>> >> Using a Native module. (Looks like the best compromise for my needs in
>> >> the
>> >> short-term.)
>> >> Rewrite in pure Elm. (Looks like the best long-term solution.)
>> >>
>> >> Next step: I will write up a Native solution and see how that goes.
>> >>
>> >> --
>> >> 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.
>
> --
> 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 

[elm-discuss] Re: Ports seem contrived when trying to format a value as money

[Dustin Farris]

Hi Dwayne,

I'm not sure how complex your currency formatting needs are.  But I think 
you should be able to do a lot of this yourself in Elm—especially if all 
you're looking for is commas and dollar signs.

I threw together an Ellie app to get you started.

https://ellie-app.com/34vgDLqvmd6a1/1

Would something like that help you?

Dustin

On Saturday, April 29, 2017 at 8:26:05 AM UTC-4, Dwayne Crooks wrote:
>
> I'm porting an application from React/Redux to Elm and I'm having trouble 
> figuring out how to format a value as money. In the original application we 
> used http://openexchangerates.github.io/accounting.js/. So naturally I 
> wanted to make use of that same library when writing the Elm version. Based 
> on my reading ports seem to be the solution however when I think through 
> the implications it doesn't seem natural to write my code in that way when 
> formatting is a presentation concern.
>
> Here's what I came up with:
>
> 1. I created a port module called Format.
>
> port module Format exposing (..)
>>
>> port asMoney : Float -> Cmd msg
>> port moneyFormats : (String -> msg) -> Sub msg
>
>
> 2. I originally envisioned writing the view as follows:
>
> viewSales : Float -> Html Msg
>> viewSales amount =
>> viewWidget "Gross Sales (All Time)" (Format.asMoney amount)
>
>
> But obviously, that's out the window since Format.asMoney returns a 
> command.
>
> 3. It means I now have to format in my update function and store the 
> formatted data in my model so that my view can access it. I find that very 
> inconvenient and I don't want presentation concerns in neither my update 
> function nor my model.
>
> Am I thinking through this correctly?
>
> How do I proceed?
>
> Should I consider writing an external library with a Native module like 
> for e.g. https://github.com/NoRedInk/elm-moment or 
> https://github.com/evancz/elm-graphics?
>
> Any help would be greatly appreciated.
>

-- 
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] Ports seem contrived when trying to format a value as money

[Witold Szczerba]

Noah, this is exactly the kind of problem to be solved by native binding.
Dwayne wants to use his formatting library. This is a classic example of
pure function. Nothing is going to crash if you wrap exception in Result
and check types.

Good advices of self reimplementig everything from scratch in Elm or using
subscriptions for pure functions is nothing but making Elm people suffer
instead of getting things done.

Native bindings are not bad per se. Just use it wisely, be pragmatic or we
will read another "Moving on", by Dwayne Crooks" this time.

30.04.2017 7:07 PM "Noah Hall"  napisał(a):

> Witold, this it not the advice that we give to people exploring such
> problems in Elm. There are many reasons why Native bindings are bad. A
> single error in your JS will cause the _entire_ application to crash
> unrecoverably. Wrapping things as a result will not help you catch
> those errors. Writing carefully thought out and tested code will.
> While there are cases where a Native function helps out a lot, it
> should _never_ be the first thing to reach for.
>
>
> Dwayne, I suggest discussing things on the Elm Slack. It will be
> easier to get to the exact use case you have for your formatting
> issue.
>
>
> On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba 
> wrote:
> > Ports and subscriptions are for executing actions with effects, in my
> > opinion. Native bindings for pure functions are nothing bad. Just keep
> away
> > from exceptions, use Result in case of possible troubles.
> >
> > 30.04.2017 4:00 PM "Dwayne Crooks"  napisał(a):
> >>
> >> Thanks guys.
> >>
> >> I explored Noah's approach to see how the solution would turn out. But I
> >> didn't like it. The code change required to format a list of floats as
> money
> >> is ridiculous. Here's what I started with
> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d3387
> 3d#file-0-start-elm.
> >> And here's what I ended up with
> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d3387
> 3d#file-1a-useports-elm,
> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d3387
> 3d#file-1b-useports-html.
> >>
> >> P.S. The solution still doesn't quite work because all money receives
> the
> >> first incoming subscription message causing them to display the same
> >> formatted value. I didn't bother to fix it because the solution is bad
> >> enough.
> >>
> >> I think we can safely rule out ports. Noah, do you have any thoughts on
> >> the code? Did I miss anything?
> >>
> >> That leaves us with:
> >>
> >> Using a Native module. (Looks like the best compromise for my needs in
> the
> >> short-term.)
> >> Rewrite in pure Elm. (Looks like the best long-term solution.)
> >>
> >> Next step: I will write up a Native solution and see how that goes.
> >>
> >> --
> >> 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.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Moving on

[Marek Fajkus]

Folks. I feel this thread is maybe not the best place to discuss certain 
details of topics that raised in discussion. I feel there are too much 
topic being actively discuss right now and it starts to be pretty hard to 
follow everything. I feel that understanding what others are talking about 
is much more important than commenting everything myself but it's really 
hard to follow everything right now. Anyway I have few points myself. 
*Please understand that these are points that don't define my whole view.*
1. Interop - First of all it was there but now there is white list for just 
few packages. Bringing native code especially on lib level is pretty 
dangerous indeed. On the other hand anyone pulling some hairball (Hickey's 
term ) he/she has to be aware 
of certain risks. This is part of contract defined by all OSS licenses I'm 
aware of. Maybe visible warning + extra confirmation during install would 
be enough.

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

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Noah Hall]

Witold, this it not the advice that we give to people exploring such
problems in Elm. There are many reasons why Native bindings are bad. A
single error in your JS will cause the _entire_ application to crash
unrecoverably. Wrapping things as a result will not help you catch
those errors. Writing carefully thought out and tested code will.
While there are cases where a Native function helps out a lot, it
should _never_ be the first thing to reach for.


Dwayne, I suggest discussing things on the Elm Slack. It will be
easier to get to the exact use case you have for your formatting
issue.


On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba  wrote:
> Ports and subscriptions are for executing actions with effects, in my
> opinion. Native bindings for pure functions are nothing bad. Just keep away
> from exceptions, use Result in case of possible troubles.
>
> 30.04.2017 4:00 PM "Dwayne Crooks"  napisał(a):
>>
>> Thanks guys.
>>
>> I explored Noah's approach to see how the solution would turn out. But I
>> didn't like it. The code change required to format a list of floats as money
>> is ridiculous. Here's what I started with
>> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm.
>> And here's what I ended up with
>> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1a-useports-elm,
>> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1b-useports-html.
>>
>> P.S. The solution still doesn't quite work because all money receives the
>> first incoming subscription message causing them to display the same
>> formatted value. I didn't bother to fix it because the solution is bad
>> enough.
>>
>> I think we can safely rule out ports. Noah, do you have any thoughts on
>> the code? Did I miss anything?
>>
>> That leaves us with:
>>
>> Using a Native module. (Looks like the best compromise for my needs in the
>> short-term.)
>> Rewrite in pure Elm. (Looks like the best long-term solution.)
>>
>> Next step: I will write up a Native solution and see how that goes.
>>
>> --
>> 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] Ports seem contrived when trying to format a value as money

[Witold Szczerba]

Ports and subscriptions are for executing actions with effects, in my
opinion. Native bindings for pure functions are nothing bad. Just keep away
from exceptions, use Result in case of possible troubles.

30.04.2017 4:00 PM "Dwayne Crooks"  napisał(a):

> Thanks guys.
>
> I explored Noah's approach to see how the solution would turn out. But I
> didn't like it. The code change required to format a list of floats as
> money is ridiculous. Here's what I started with https://gist.github.com/
> dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm. And here's what
> I ended up with https://gist.github.com/dwayne/
> 550341a5b27ba3c03ce7eba92d33873d#file-1a-useports-elm, https
> ://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d3387
> 3d#file-1b-useports-html.
>
> *P.S.* *The solution still doesn't quite work because all money receives
> the first incoming subscription message causing them to display the same
> formatted value. I didn't bother to fix it because the solution is bad
> enough*.
>
> I think we can safely rule out ports. Noah, do you have any thoughts on
> the code? Did I miss anything?
>
> That leaves us with:
>
>1. Using a Native module. (Looks like the best compromise for my needs
>in the short-term.)
>2. Rewrite in pure Elm. (Looks like the best long-term solution.)
>
> Next step: I will write up a Native solution and see how that goes.
>
> --
> 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

[Rehno Lindeque]

Just to play devil's advocate for a moment; Despite my suggestion, and as 
much as I'm an advocate for package curation I don't think that it's the 
right first step towards solving the problem.

In my opinion the realistic solution is one that may already have been 
discussed in the past: 

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

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

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

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

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

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

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

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

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Dwayne Crooks]

Thanks guys.

I explored Noah's approach to see how the solution would turn out. But I 
didn't like it. The code change required to format a list of floats as 
money is ridiculous. Here's what I started 
with 
https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm.
 
And here's what I ended up 
with 
https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1a-useports-elm,
 
https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1b-useports-html.

*P.S.* *The solution still doesn't quite work because all money receives 
the first incoming subscription message causing them to display the same 
formatted value. I didn't bother to fix it because the solution is bad 
enough*.

I think we can safely rule out ports. Noah, do you have any thoughts on the 
code? Did I miss anything?

That leaves us with:

   1. Using a Native module. (Looks like the best compromise for my needs 
   in the short-term.)
   2. Rewrite in pure Elm. (Looks like the best long-term solution.)

Next step: I will write up a Native solution and see how that goes.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[Zachary Kessin]

I think if we are working on the basis of a blessed set of modules one of
the requirements should be having several people who can merge a pull
request etc.

Zach
ᐧ

On Thu, Apr 27, 2017 at 1:48 PM, Rehno Lindeque 
wrote:

>
> This grey list would be backed by a clear process of getting things on the
>> list that would include a checklist of mandatory things.
>> This checklist would be like a rule list and breaking any of the rule
>> would have to happen after a serious benefits analysis done under the
>> supervision of that experienced Elm programmers group I mentioned earlier.
>>
>
> If this were the route people decide to take, I get the impression that
> this is the sort of thing elm-community does quite well. Perhaps a
> "greylist" could be simplified to https://github.com/elm-community/*.
>
> Something to keep in mind is that there's likely to be red tape required
> to fork a package on a special list. Not great if you need to fix something
> in a hurry and the author has disappeared. Elm-community provides a little
> bit of peace of mind for people like me who would like to make sure that
> packages they use have at least one active maintainer assigned to it and
> that the code has had some level of peer review.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Discovery: Model /= Database

[Dustin Farris]

I think I've just had an aha moment with this post.

I am in the process of refactoring my monolith MUV into separate modules 
with their own MUV for each "page" of my SPA.  Up to this point, I have had 
a separate Store module with its own Model and Msg types and an update 
function (no view, obviously).  This has worked well up until now, but 
after splitting off the pages of my app, it is getting more cumbersome to 
update the Store in a way that looks nice.

e.g. in my Main.elm I'm ending up with something like

update msg model =
case msg of
UserProfilePageMsg msg_ ->
let
( userProfilePageModel, userProfilePageCmd ) =
UserProfilePage.update msg_ model.userProfilePage
in
case msg_ of
UserProfilePage.StoreMsg msg__ ->
let
( storeModel, storeCmd ) =
Store.update msg__ model.store
in
{ model
| userProfilePage = userProfilePageModel
, store = storeModel
}
! [ Cmd.map UserProfilePageMsg 
userProfilePageCmd
  , Cmd.map StoreMsg storeCmd
  ]
_ ->
{ model | userProfilePage = userProfilePageModel }
! [ Cmd.map UserProfilePageMsg 
userProfilePageCmd ]


and so on for every page that invokes Store.Msg—which is most pages.

I am thinking that there is a better way, and perhaps Kasey's suggestion of 
forgoing an in-memory Store on the Model might be it.  I'm still not sure—I 
do like the snappy feel of a page loading instantly if the data is in 
memory—even if it might change after a brief consultation with the server.

Dustin


On Wednesday, April 19, 2017 at 7:28:06 PM UTC-4, Kasey Speakman wrote:
>
> I'm probably slow, but in recent months I've discovered that trying to use 
> Elm's Model like a database or cache (as I have previously seen suggested) 
> has turned out to be pretty painful for me. An example database-minded 
> model where a section could display *either* a list of employees *or* a 
> list of courses.
>
> type alias Model =
> { employees : List Employee
> , courses : List Course
> , loadingError : Maybe Http.Error
> , route : MyRoute -- employee or course
> }
>
> The problem this runs into is having to worry about state management. I 
> have to remember to "reset" or "turn off" things when they are not active. 
> As my application grew, I had a lot of problems that boiled down to tedious 
> state management details. My cached data didn't turn out to be all that 
> useful because I usually had to reload it anyway, in case something changed.
>
> Instead, I have been moving toward the model only representing the current 
> state of my UI. The big difference here is the model representing the 
> current *visual* elements and their data. This leads more to using union 
> types to represent parts of the UI. When you switch to a different case of 
> the union type, the data from the previous case is *dropped on the floor*. 
> This leaves nothing to remember to "reset". RemoteData is a good 
> micro-example of this. If there was an error fetching the data, when the 
> user requests the data again, you switch back to Loading, the error message 
> is dropped on the floor. No forgetting to hide it.
>
> type RemoteData e a
> = NotAsked
> | Loading
> | Failure e
> | Success a
>
> If it is really important to cache the data, I prefer to keep that as a 
> persistence concern, not on Model. It can be part of the process for 
> retrieving the data to first check my chosen cache before making a request 
> for fresh data. For instance, first check local storage before making an 
> HTTP call. (Currently, this scenario is easier with Native modules for lack 
> of Local Storage API or being able to wait on port subscriptions. But it's 
> still doable.)
>
> So working towards a Model reflecting the visuals on the page has been an 
> interesting challenge. I'm not claiming it's easier, but so far I've found 
> it avoids a class of problems, and has led to some interesting discoveries 
> in my own apps. One small example: I realized that my LoggedIn and 
> NotLoggedIn routes should actually be separate "apps". Attempts to model 
> this in a SPA fashion with the LoggedIn and NotLoggedIn routes as siblings 
> always came up with the conundrum: how do I make it a compiler error for 
> the model to be in LoggedIn mode but I receive a NotLoggedIn message, or 
> vice versa? Even using TEA, I could not avoid this situation. Then I 
> realized the only way to do that would be as separate apps. And that it was 
> entirely possible to separate them. My "login page" turned out to be an 
>