[elm-discuss] Re: Convincing my team that Elm isn't just going to die like CoffeeScript

[Robin Heggelund Hansen]

I'd say that Elm is such an easy thing to learn that I wouldn't worry about 
hiring Elm devs. If people know React and Redux then they already know the 
principle of how Elm works, and so learning syntax and how functional 
programming works is quite easy. I also think No Red Ink hires people new 
to Elm, and don't have any problems training those people up.

As for longevity, the company where the creator and lead-developer of Elm 
works, No Red Ink, has 55000 lines of Elm in production, and are pretty 
reliant on that technology. I don't see Elm going away any time soon.

So to recap:
1. Elm is simple to learn. It was made for learning. Hiring people that 
don't know Elm shouldn't be a huge problem. (go through the syntax, how 
much is it really compared to ES2016?)
2. The company behind Elm has a huge stake in it's continued development, 
and they're not going anywhere soon.

lørdag 5. november 2016 23.01.42 UTC+1 skrev Zacqary Adam Xeper følgende:
>
> Hey Elmos,
>
> I've finally gotten an opportunity to pitch Elm to my fairly large dev 
> team. I feel like I'm prepared to make the case for it against a lot of 
> objections: i.e. how will we learn yet another programming language, do we 
> really need something that never throws exceptions, etc. etc.
>
> The one thing I'm not really sure I'm prepared to answer is how I can be 
> sure that Elm isn't just another CoffeeScript or Dart, and in 2 or 3 years 
> we'll have an impossible time hiring anyone who knows how to use it because 
> everyone's going to go back to JavaScript.
>
> How do I convince Elm skeptics that this thing is here to stay? I can do a 
> great job of incorporating a small bit of Elm code into our stack to show 
> how great it is, but they won't even let me merge it into prod unless I can 
> make the case for its longevity.
>
>

-- 
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] using a compile-to-js workflow with elm-webpack-starter

[Martin DeMello]

I have my project set up with elm-webpack-starter, which installs a
boilerplate index.html and index.js

https://github.com/moarwick/elm-webpack-starter/tree/master/src/static

I'm now trying to follow the ports guide

http://guide.elm-lang.org/interop/javascript.html

which says to compile elm to javascript instead and include that in my
index.html. I couldn't find any guides towards getting that working with
the starter webpack setup, though, and blindly modifying the index.html
file as shown, and copying the generated elm.js to src/static, didn't work.

martin

-- 
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] Convincing my team that Elm isn't just going to die like CoffeeScript

[Zacqary Adam Xeper]

Hey Elmos,

I've finally gotten an opportunity to pitch Elm to my fairly large dev team. I 
feel like I'm prepared to make the case for it against a lot of objections: 
i.e. how will we learn yet another programming language, do we really need 
something that never throws exceptions, etc. etc.

The one thing I'm not really sure I'm prepared to answer is how I can be sure 
that Elm isn't just another CoffeeScript or Dart, and in 2 or 3 years we'll 
have an impossible time hiring anyone who knows how to use it because 
everyone's going to go back to JavaScript.

How do I convince Elm skeptics that this thing is here to stay? I can do a 
great job of incorporating a small bit of Elm code into our stack to show how 
great it is, but they won't even let me merge it into prod unless I can make 
the case for its longevity.

-- 
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: Support for binary data

[Martin DeMello]

Seconding this one - I need to be able to pass a binary file to my backend,
which requires the ability to both load the file and attach binary data to
a POST request.

martin

On Wed, Oct 19, 2016 at 2:53 AM, Simon  wrote:

> My need is to upload PDFs directly to S3. That requires two additional
> things
>
> - the ability to read a file from the hard disk - the sort of native code
> needed is at https://github.com/simonh1000/file-reader/blob/
> master/src/Native/FileReader.js
> - an extra function in Http with signature `blobPart
> 
> : String -> Blob -> Part
> `
>
> Simon
>
>
> On Monday, 11 January 2016 13:55:10 UTC+1, John Watson wrote:
>>
>> Can anyone tell me what the plans are for supporting binary data in elm?
>> I'm thinking of a Byte (and some sort of Byte Array) type and also
>> implementing Blob in HTTP responses.
>>
> --
> 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: Embracing out messages

[Mark Hamburg]

The part that is "more awkward" is in having to write the functions to
apply — or even just translate — the out messages from one layer to the
next. But, of course, the opportunity to do that work is where the pattern
gets its strength, so it's a tradeoff.

Other than that, it could probably benefit from a few more utility
functions and possibly a replacement for List as the way to return
sequences of out messages but I expect those to reveal themselves with
experience.

Mark

On Saturday, November 5, 2016, Eric G  wrote:

> Thanks for writing this up Mark, it seems very clear. It seems like it
> would be especially good for cases where results of effects need to be
> applied further up the state tree from where the effect is triggered. Or
> for cases where you want to examine (and possibly modify) requested effects
> further 'out' before they get converted to commands -- as in your example
> of needing to add credentials further 'out'.
>
> Personally I have only occasionally found a need for this kind of thing,
> but maybe that's for lack of a suitable hammer :)  Those helper functions
> certainly make it look more appealing... But I'm not sure I could evaluate
> it without actually trying it. Have you come across cases where it seems
> more awkward than standard TEA?
>
>
> On Friday, November 4, 2016 at 2:06:10 PM UTC-4, Mark Hamburg wrote:
>>
>> A note on where I'm moving with respect to structuring code (since many
>> have raised similar questions)...
>>
>> We don't have a particularly deep hierarchy but there are some fairly
>> distinct levels around things like app state management — are we logged in?
>> — and then view management while logged in. Even just having a few levels
>> made it worthwhile thinking about how to structure their relationships.
>>
>> I'd been moving toward the inter-module communication pattern supported
>> here:
>>
>> http://package.elm-lang.org/packages/folkertdev/outmessage/latest
>>
>>
>> in which update (and init) functions return not just a model and a
>> command but a model, a command, and out messages in some form. The outer
>> layer then applies the inner out messages to invoke further changes.
>>
>> One thing that didn't seem to be as well supported in this was having the
>> out messages generate out messages to go up to the next layer. Thinking
>> about adding that in and about any implied sequencing guarantees moved me
>> to a pattern in which the update functions have the following signatures:
>>
>> update : Msg -> Model -> ( Model, List OutMsg )
>>
>> (We should arguably change Msg to InMsg for symmetry but prevailing
>> convention uses Msg.)
>>
>> An update to an inner model looks something like the following:
>>
>> update : Msg -> Model -> ( Model, List OutMsg )
>> update msg model =
>>
>> case msg of
>>
>> ToInner innerMsg ->
>>
>> let
>>
>> (newInner, innerOutMsgs) =
>>
>> innerUpdate innerMsg model.inner
>>
>> in
>>
>> ( { model | inner = newInner }, [] )
>>
>> |> applyMessages
>>
>> applyInnerOutMsg
>> innerOutMsgs
>>
>>
>> Where we have support functions:
>>
>> applyInnerOutMsg : Inner.OutMsg -> Model -> ( Model, List OutMsg )
>>
>> applyMessages :
>>
>> ( msg -> model -> ( model, List outMsg ) )
>>
>> -> List msg
>>
>> -> ( model, List outMsg )
>>
>> -> ( model, List outMsg )
>>
>> applyMessages apply msgs state =
>>
>> List.foldl
>>
>> (\msg ( oldM, oldOut ) ->
>>
>> let
>>
>> ( newM, moreOut ) =
>>
>> apply msg m
>>
>> in
>>
>> ( newM, List.append oldOut moreOut )
>>
>> )
>>
>> state
>>
>> msgs
>>
>>
>> The benefits of this approach are that we can decide at each level how to
>> process the out messages from the next level down including both making
>> local changes and passing out messages up to the next level.
>>
>> This approach seems to embrace the "Effects as Data" pattern recommend
>> here:
>>
>> https://www.youtube.com/watch?v=6EdXaWfoslc.
>>
>>
>> In particular, it does so in a way that the standard use of commands
>> seems to thwart since commands aren't particularly designed to be inspected.
>>
>> But still, we have to fit commands in somewhere. At the top level, we
>> can't return a list of out messages and instead must build a command. One
>> way to do this is to make Cmd Msg the out message type for the top level
>> and then as a last step apply a Cmd.batch to the list of out messages.
>> Further down, while potentially less inspectable, we may still want to
>> generate commands without the intervening levels getting involved (though
>> this means that it's harder to put those lower levels in a test harness).
>> We can do that by including a Command (Cmd Msg) in the OutMsg type
>> union. The next layer out then uses Cmd.map to change the message type
>> and rewraps it in its own Command OutMsg. This pattern for handling
>> commands also makes it easy to move existing code over to this out message
>> centric model.
>>
>> I'm still in the process of converting code over, but I'm feeling pretty
>> happy with the results so far and conceptually 

[elm-discuss] Re: Embracing out messages

[Eric G]

Thanks for writing this up Mark, it seems very clear. It seems like it 
would be especially good for cases where results of effects need to be 
applied further up the state tree from where the effect is triggered. Or 
for cases where you want to examine (and possibly modify) requested effects 
further 'out' before they get converted to commands -- as in your example 
of needing to add credentials further 'out'.

Personally I have only occasionally found a need for this kind of thing, 
but maybe that's for lack of a suitable hammer :)  Those helper functions 
certainly make it look more appealing... But I'm not sure I could evaluate 
it without actually trying it. Have you come across cases where it seems 
more awkward than standard TEA?  


On Friday, November 4, 2016 at 2:06:10 PM UTC-4, Mark Hamburg wrote:
>
> A note on where I'm moving with respect to structuring code (since many 
> have raised similar questions)...
>
> We don't have a particularly deep hierarchy but there are some fairly 
> distinct levels around things like app state management — are we logged in? 
> — and then view management while logged in. Even just having a few levels 
> made it worthwhile thinking about how to structure their relationships.
>
> I'd been moving toward the inter-module communication pattern supported 
> here:
>
> http://package.elm-lang.org/packages/folkertdev/outmessage/latest
>
>
> in which update (and init) functions return not just a model and a command 
> but a model, a command, and out messages in some form. The outer layer then 
> applies the inner out messages to invoke further changes.
>
> One thing that didn't seem to be as well supported in this was having the 
> out messages generate out messages to go up to the next layer. Thinking 
> about adding that in and about any implied sequencing guarantees moved me 
> to a pattern in which the update functions have the following signatures:
>
> update : Msg -> Model -> ( Model, List OutMsg )
>
> (We should arguably change Msg to InMsg for symmetry but prevailing 
> convention uses Msg.)
>
> An update to an inner model looks something like the following:
>
> update : Msg -> Model -> ( Model, List OutMsg )
> update msg model =
>
> case msg of
>
> ToInner innerMsg ->
>
> let
>
> (newInner, innerOutMsgs) =
>
> innerUpdate innerMsg model.inner
>
> in
>
> ( { model | inner = newInner }, [] )
>
> |> applyMessages
>
> applyInnerOutMsg
> innerOutMsgs
>
>
> Where we have support functions:
>
> applyInnerOutMsg : Inner.OutMsg -> Model -> ( Model, List OutMsg )
>
> applyMessages :
>
> ( msg -> model -> ( model, List outMsg ) )
>
> -> List msg
>
> -> ( model, List outMsg )
>
> -> ( model, List outMsg )
>
> applyMessages apply msgs state =
>
> List.foldl
>
> (\msg ( oldM, oldOut ) ->
>
> let
>
> ( newM, moreOut ) =
>
> apply msg m
>
> in
>
> ( newM, List.append oldOut moreOut )
>
> )
>
> state
>
> msgs
>
>
> The benefits of this approach are that we can decide at each level how to 
> process the out messages from the next level down including both making 
> local changes and passing out messages up to the next level.
>
> This approach seems to embrace the "Effects as Data" pattern recommend 
> here:
>
> https://www.youtube.com/watch?v=6EdXaWfoslc.
>
>
> In particular, it does so in a way that the standard use of commands seems 
> to thwart since commands aren't particularly designed to be inspected.
>
> But still, we have to fit commands in somewhere. At the top level, we 
> can't return a list of out messages and instead must build a command. One 
> way to do this is to make Cmd Msg the out message type for the top level 
> and then as a last step apply a Cmd.batch to the list of out messages. 
> Further down, while potentially less inspectable, we may still want to 
> generate commands without the intervening levels getting involved (though 
> this means that it's harder to put those lower levels in a test harness). 
> We can do that by including a Command (Cmd Msg) in the OutMsg type union. 
> The next layer out then uses Cmd.map to change the message type and 
> rewraps it in its own Command OutMsg. This pattern for handling commands 
> also makes it easy to move existing code over to this out message centric 
> model.
>
> I'm still in the process of converting code over, but I'm feeling pretty 
> happy with the results so far and conceptually it feels easy to explain: An 
> update function takes a message and a model and produces a new model and a 
> list of out messages to be handled at the next level up. If you need to do 
> something that doesn't fit within an update to your model, generate an out 
> message and let the next level up handle it. If you need information — e.g. 
> credentials — at a lower level to construct a request, don't do the final 
> command construction but rather return an out message describing the 
> request and let the level that has the credentials do the construction.
>
> Mark
>
>

-- 
You received this message because you are subscribed 

[elm-discuss] Re: Interactive maps with Elm 0.17 : recommendation?

[Simon]

You won't find a library because you need access to native code. But I 
wrote a blog using Ports for 
0.16 http://simonh1000.github.io/2015/10/elm-architecture-ports/


On Thursday, 3 November 2016 17:16:08 UTC+1, dedo wrote:
>
> Relatively simple interactive usage to show markers on a map. 
>
> Any suggestions on which map library (google maps, leaflet, other) and 
> which Elm modules are a good starting point? Ideally something known to 
> work with Elm 0.17.
>
> The community packages list on elm-lang did not yield much.
>
> 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] Send a file via an ajax POST request

[Marcus Roberts]

(but I don't think that will work until we get binary support as Simon says)

On Sat, Nov 5, 2016 at 11:30 AM, Marcus Roberts 
wrote:

> You can pass a string to a POST request, by setting the body:
>
> body = Http.string someStringValue
>
> So if you could convert the binary data into a base64 encoded string you
> could then pass it as the body of the request.
>
>
>
> On Sat, Nov 5, 2016 at 9:27 AM, Martin DeMello 
> wrote:
>
>> Thanks, I took a look at that, but it loads the file data into elm, where
>> we still have the problem that we cannot attach a binary blob to a POST
>> request.
>>
>> I'm not fully sure, but I think the flow needs to be:
>> 1. Get filename from the input button, in elm.
>> 2. Pass filename to javascript
>> 3. Upload the file and attach it to an ajax post request in javascript
>> 4. Pass the return value of the ajax call back to elm
>>
>> martin
>>
>> --
>> 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] Send a file via an ajax POST request

[Marcus Roberts]

You can pass a string to a POST request, by setting the body:

body = Http.string someStringValue

So if you could convert the binary data into a base64 encoded string you
could then pass it as the body of the request.



On Sat, Nov 5, 2016 at 9:27 AM, Martin DeMello 
wrote:

> Thanks, I took a look at that, but it loads the file data into elm, where
> we still have the problem that we cannot attach a binary blob to a POST
> request.
>
> I'm not fully sure, but I think the flow needs to be:
> 1. Get filename from the input button, in elm.
> 2. Pass filename to javascript
> 3. Upload the file and attach it to an ajax post request in javascript
> 4. Pass the return value of the ajax call back to elm
>
> martin
>
> --
> 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] Send a file via an ajax POST request

[Simon]

Hi guys, I'm the author for FileReader and the shortcoming you note is well 
known and currently unavoidable.  Please add you needs to this 
thread 
https://groups.google.com/forum/#!searchin/elm-discuss/blob|sort:relevance/elm-discuss/spr621OlUeo/UQq0rk0dBQAJ
 
 as we need to get WebApi implementations prioritised.


Simon


On Saturday, 5 November 2016 10:27:30 UTC+1, Martin DeMello wrote:
>
> Thanks, I took a look at that, but it loads the file data into elm, where 
> we still have the problem that we cannot attach a binary blob to a POST 
> request.
>
> I'm not fully sure, but I think the flow needs to be:
> 1. Get filename from the input button, in elm.
> 2. Pass filename to javascript
> 3. Upload the file and attach it to an ajax post request in javascript
> 4. Pass the return value of the ajax call back to elm
>
> martin
>

-- 
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] Send a file via an ajax POST request

[Martin DeMello]

Thanks, I took a look at that, but it loads the file data into elm, where
we still have the problem that we cannot attach a binary blob to a POST
request.

I'm not fully sure, but I think the flow needs to be:
1. Get filename from the input button, in elm.
2. Pass filename to javascript
3. Upload the file and attach it to an ajax post request in javascript
4. Pass the return value of the ajax call back to elm

martin

-- 
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] Send a file via an ajax POST request

[Marcus Roberts]

I've not used it yet, but there's a module for doing that here:

https://github.com/simonh1000/file-reader

Note you have to enable native modules in your config, and you can't just
install it as a package as Elm packages don't allow native code.

On Sat, Nov 5, 2016 at 8:27 AM, Martin DeMello 
wrote:

> I'm a bit lost trying to put the pieces together for this. I have a web
> service that does file format conversion, and I want to use the
> binary->json converter to import a binary file into an elm frontend.
>
> Here's some code to illustrate what I want to achieve. I can call my
> webapp via
>
> $ curl --form "filedata=@filename.bin" --form "from=binary" --form
> "to=json" http://localhost:1234/json
>
> and in my view I have
>
>   form [class "pure-form", id "convert-form"]
>   [ fieldset []
>   [ input [ type' "file" , class "pure-button"] []
>   , a [class "pure-button", onClick UploadFile] [text "Load"]
>   ]
>   ]
>
> From what I can tell, I'll need to go through the ports system both to
> upload the file and to attach the binary data to a POST request, but I'm
> not too familiar with javascript either, and I'm hoping this is something
> someone has already figured out for their own app.
>
> martin
>
> --
> 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] Send a file via an ajax POST request

[Martin DeMello]

I'm a bit lost trying to put the pieces together for this. I have a web
service that does file format conversion, and I want to use the
binary->json converter to import a binary file into an elm frontend.

Here's some code to illustrate what I want to achieve. I can call my webapp
via

$ curl --form "filedata=@filename.bin" --form "from=binary" --form
"to=json" http://localhost:1234/json

and in my view I have

  form [class "pure-form", id "convert-form"]
  [ fieldset []
  [ input [ type' "file" , class "pure-button"] []
  , a [class "pure-button", onClick UploadFile] [text "Load"]
  ]
  ]

>From what I can tell, I'll need to go through the ports system both to
upload the file and to attach the binary data to a POST request, but I'm
not too familiar with javascript either, and I'm hoping this is something
someone has already figured out for their own app.

martin

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