[elm-discuss] Re: Private state: A contrived example

[Bernardo]

I've been following the thread on elm-dev and the others about components 
and private state and I find this example very useful.
Here is my attempt at creating some sort of component from the counter. My 
aim is to keep the viewCounter and updateCounter without modifications and 
provide a function componetizeCounter that creates the view and update 
functions to be used for creating and updating the counters. This is all 
still a little over my head but in any case was an interesting exercise!

https://gist.github.com/anonymous/508063831274fd1945bb1eba5e751c71

On Friday, 9 September 2016 17:01:50 UTC-3, Mark Hamburg wrote:
>
> Over on Elm dev, there's been a debate over how to handle private state 
> for views that also have public state. Evan's sortable table and his recent 
> updates to the guide with respect to reuse have emphasized how to avoid 
> building much state into a model but that's left a gap for the cases where 
> private state does matter. A real example would deal with things like date 
> pickers or ripples, but implementing those would involve lots of code that 
> had nothing to do with how one handled private state and simply had to do 
> with calendars or ripples. So, I took the counter example from the guide 
> which was used to show how to do models (for similar reasons of limiting 
> distractions) but would really fit better in the view only approach now 
> being advocated and added some private state. Specifically, I introduced 
> counters with a stack of values. The code in this gist actually provides 
> two views onto a shared counter value with each view having its own stack:
>
> https://gist.github.com/markhamburg/dd2b5b1d30db1f03ccee055a4e070677
>
> This implementation isn't quite as minimal as it could be. In particular, 
> I included the notion of updating private state when the public/shared 
> state changes but I don't actually use it. On the other hand, for an 
> example, I wanted to see where it would fit in. In practice, I wouldn't 
> include it if it wasn't needed but I would probably still bottleneck the 
> update to the shared state so that it could be added later if necessary 
> without having to hunt down all of the places where the shared state is 
> changed.
>
> 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] Private state: A contrived example

[Mark Hamburg]

The way to address the problems with having to update too many references
to which private storage I'm using is with a dictionary and identifiers:

https://gist.github.com/markhamburg/e3b9af785d06ed392e4498e569045b25

But it starts to feel like I'm re-inventing elm-parts/elm-mdl and a more
realistic use case wouldn't be able to get away with everything just
referencing model.value.

Again, this particular use case is utterly contrived but I can easily see a
date picker slotting in similarly — just with a lot more logic in the
implementation.

Mark

On Sat, Sep 10, 2016 at 3:00 PM, Mark Hamburg  wrote:

> I reworked my example in terms of passing back new counter values via
> messages (to be more like the auto-complete example):
>
> https://gist.github.com/markhamburg/48f92aaccc419c4b2a93977d09afa4d7
>
> Given the errors that I hit while writing it (and probably the earlier
> versions as well), the biggest problem when it comes to scaling is that
> this is the sort of thing where copy-paste-modify development is really
> natural — I have a new view to add, copy-paste-modify the code from a
> previous view. The problem is that on any of those modifications, I need to
> make sure I hit everything. Otherwise, it's really easy to end up linked to
> the wrong private state and to the extent that one uses the same type of
> view more than once, the type system won't catch this.
>
> Mark
>
>
> On Sat, Sep 10, 2016 at 12:43 PM, Mark Hamburg 
> wrote:
>
>> On Sep 10, 2016, at 8:52 AM, Oliver Searle-Barnes 
>> wrote:
>>
>> Mark, have you considered the approach that Evan took with
>> elm-autocomplete
>> ?
>> Personally, I found this a satisfactory approach to the problem of private
>> state/events, I'd be interested to hear your take on it.
>>
>>
>> I watched the video when it came out but I hadn't looked closely at the
>> code at the time. I just did so and I had a variety of reactions:
>>
>> * There is a similarity between what I did and the auto complete code in
>> that the level above stores both the public state and the private state and
>> provides both to the view and update functions.
>>
>> * The autocomplete code places a lot of burden on the client. For
>> example, key code identification. This may be needed for configurability
>> but I could see it being a problem for consistency across multiple auto
>> completes in a larger project. It could probably benefit from a standard
>> usage path or an example of how to build such a standard usage path as part
>> of the examples.
>>
>> * The communication mechanism back from auto complete is interesting in
>> that it returns messages or rather maybe messages. This is the sort of
>> pattern that deserves more attention. For example, should a fully
>> generalized update function look something like the following?
>>
>> update :
>> Config parentMsg
>> -> StateFromParent
>>  -> LocalMsg
>> -> LocalState
>> -> (LocalState, Cmd LocalMsg, Maybe parentMsg)
>>
>> (Actually, autocomplete splits up the state from the parent into how many
>> to show and the items to show and spreads them out in the update
>> parameters. I don't recall a part of the API design discussion that went
>> into why this particular parameter order. I picked the order I did here in
>> order to make the function look more like a classic TEA update function
>> with extra parameters at the beginning.)
>>
>> * One thing that will be different between the approach I took and this
>> approach is that if any of the local state depends on the global state —
>> e.g., in a date picker, externally setting the date might change the month
>> displayed — then the autocomplete approach which would use a message to set
>> the date at the parent level might have an awkward sequencing problem in
>> that we would do something like the following:
>>
>>   update the date picker in its update function
>>   process the update the date message
>>   update the date picker again because the date changed
>>
>> Basically, routing things back through the update function as a message
>> can interfere with de-bouncing. In contrast, I specifically stored the
>> update to the local state after updating the public state in my counters
>> example. One could do this as well in the deliver messages back approach,
>> but the natural place to handle messages feels like at the end of the
>> update function in essentially a tail recursive call. That said, using
>> messages is definitely a more versatile approach.
>>
>> 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] Private state: A contrived example

[Mark Hamburg]

I reworked my example in terms of passing back new counter values via
messages (to be more like the auto-complete example):

https://gist.github.com/markhamburg/48f92aaccc419c4b2a93977d09afa4d7

Given the errors that I hit while writing it (and probably the earlier
versions as well), the biggest problem when it comes to scaling is that
this is the sort of thing where copy-paste-modify development is really
natural — I have a new view to add, copy-paste-modify the code from a
previous view. The problem is that on any of those modifications, I need to
make sure I hit everything. Otherwise, it's really easy to end up linked to
the wrong private state and to the extent that one uses the same type of
view more than once, the type system won't catch this.

Mark

On Sat, Sep 10, 2016 at 12:43 PM, Mark Hamburg 
wrote:

> On Sep 10, 2016, at 8:52 AM, Oliver Searle-Barnes 
> wrote:
>
> Mark, have you considered the approach that Evan took with
> elm-autocomplete
> ?
> Personally, I found this a satisfactory approach to the problem of private
> state/events, I'd be interested to hear your take on it.
>
>
> I watched the video when it came out but I hadn't looked closely at the
> code at the time. I just did so and I had a variety of reactions:
>
> * There is a similarity between what I did and the auto complete code in
> that the level above stores both the public state and the private state and
> provides both to the view and update functions.
>
> * The autocomplete code places a lot of burden on the client. For example,
> key code identification. This may be needed for configurability but I could
> see it being a problem for consistency across multiple auto completes in a
> larger project. It could probably benefit from a standard usage path or an
> example of how to build such a standard usage path as part of the examples.
>
> * The communication mechanism back from auto complete is interesting in
> that it returns messages or rather maybe messages. This is the sort of
> pattern that deserves more attention. For example, should a fully
> generalized update function look something like the following?
>
> update :
> Config parentMsg
> -> StateFromParent
>  -> LocalMsg
> -> LocalState
> -> (LocalState, Cmd LocalMsg, Maybe parentMsg)
>
> (Actually, autocomplete splits up the state from the parent into how many
> to show and the items to show and spreads them out in the update
> parameters. I don't recall a part of the API design discussion that went
> into why this particular parameter order. I picked the order I did here in
> order to make the function look more like a classic TEA update function
> with extra parameters at the beginning.)
>
> * One thing that will be different between the approach I took and this
> approach is that if any of the local state depends on the global state —
> e.g., in a date picker, externally setting the date might change the month
> displayed — then the autocomplete approach which would use a message to set
> the date at the parent level might have an awkward sequencing problem in
> that we would do something like the following:
>
>   update the date picker in its update function
>   process the update the date message
>   update the date picker again because the date changed
>
> Basically, routing things back through the update function as a message
> can interfere with de-bouncing. In contrast, I specifically stored the
> update to the local state after updating the public state in my counters
> example. One could do this as well in the deliver messages back approach,
> but the natural place to handle messages feels like at the end of the
> update function in essentially a tail recursive call. That said, using
> messages is definitely a more versatile approach.
>
> 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: Sort a list of strings independant of case

[Joey Eremondi]

@Sergey Right, but the List.sortBy examples just sort based on the
toUppercased version, but don't put the toUppercase results in the final
list.

sortBy is different than using List.map

On Sat, Sep 10, 2016 at 1:00 PM, Sergey Zubtsovskiy <
sergey.zubtsovs...@gmail.com> wrote:

> Well, I meant that elements from original list will stay intact. If you
> are first applying List.map toUppercase and then sort, resulting list will
> contain uppercased letters which may be undesirable.
>
> In my solution resulting list will contain same elements as the original
> one sorted in case-insensitive manner.
>
> I see this difference as significant and necessary.
>
> суббота, 10 сентября 2016 г. пользователь Max Goldstein написал:
>
>> not changing original list
>>
>>
>> An an immutable language such as Elm, nothing can change the original
>> list! I think you've more-or-less implemented List.sortBy explicitly, which
>> is instructive, but not really necessary.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/elm-discuss/IwSIlRUoNFw/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Sergey Zubtsovskiy
> sergey.zubtsovs...@gmail.com
> Skype: szubtsovskiy
>
>
> --
> 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: Sort a list of strings independant of case

[Sergey Zubtsovskiy]

Well, I meant that elements from original list will stay intact. If you are
first applying List.map toUppercase and then sort, resulting list will
contain uppercased letters which may be undesirable.

In my solution resulting list will contain same elements as the original
one sorted in case-insensitive manner.

I see this difference as significant and necessary.

суббота, 10 сентября 2016 г. пользователь Max Goldstein написал:

> not changing original list
>
>
> An an immutable language such as Elm, nothing can change the original
> list! I think you've more-or-less implemented List.sortBy explicitly, which
> is instructive, but not really necessary.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/IwSIlRUoNFw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sergey Zubtsovskiy
sergey.zubtsovs...@gmail.com
Skype: szubtsovskiy

-- 
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] Private state: A contrived example

[Mark Hamburg]

On Sep 10, 2016, at 8:52 AM, Oliver Searle-Barnes  wrote:
> 
> Mark, have you considered the approach that Evan took with elm-autocomplete? 
> Personally, I found this a satisfactory approach to the problem of private 
> state/events, I'd be interested to hear your take on it.

I watched the video when it came out but I hadn't looked closely at the code at 
the time. I just did so and I had a variety of reactions:

* There is a similarity between what I did and the auto complete code in that 
the level above stores both the public state and the private state and provides 
both to the view and update functions.

* The autocomplete code places a lot of burden on the client. For example, key 
code identification. This may be needed for configurability but I could see it 
being a problem for consistency across multiple auto completes in a larger 
project. It could probably benefit from a standard usage path or an example of 
how to build such a standard usage path as part of the examples.

* The communication mechanism back from auto complete is interesting in that it 
returns messages or rather maybe messages. This is the sort of pattern that 
deserves more attention. For example, should a fully generalized update 
function look something like the following?

update :
Config parentMsg
-> StateFromParent
 -> LocalMsg
-> LocalState
-> (LocalState, Cmd LocalMsg, Maybe parentMsg)

(Actually, autocomplete splits up the state from the parent into how many to 
show and the items to show and spreads them out in the update parameters. I 
don't recall a part of the API design discussion that went into why this 
particular parameter order. I picked the order I did here in order to make the 
function look more like a classic TEA update function with extra parameters at 
the beginning.)

* One thing that will be different between the approach I took and this 
approach is that if any of the local state depends on the global state — e.g., 
in a date picker, externally setting the date might change the month displayed 
— then the autocomplete approach which would use a message to set the date at 
the parent level might have an awkward sequencing problem in that we would do 
something like the following:

  update the date picker in its update function
  process the update the date message
  update the date picker again because the date changed

Basically, routing things back through the update function as a message can 
interfere with de-bouncing. In contrast, I specifically stored the update to 
the local state after updating the public state in my counters example. One 
could do this as well in the deliver messages back approach, but the natural 
place to handle messages feels like at the end of the update function in 
essentially a tail recursive call. That said, using messages is definitely a 
more versatile approach.

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] Private state: A contrived example

[Mark Hamburg]

On Sep 10, 2016, at 10:05 AM, Josh Adams  wrote:
> 
> Would you be willing to paste some example code so we can see the problem you 
> faced and the way you solved it?  If so, maybe we could find that if you'd 
> made one small tweak to your solution then you never would have achieved this 
> level of frustration.

Sadly, I can't put up enough to be interesting without having to get legal 
permission. It's not that there is anything super secret but corporate policies 
would get in the way of just dumping a bunch of code out. So, I could do so, 
but it would probably be a week from now by which point it's a bit late.  I 
could try to summarize them here, but I'm finding this community to be a bit 
hostile at times to such summaries. The code base is also in Elm 0.16, so some 
of the issues are, in fact, improved — specifically, I don't have to watch the 
window size signal and route that information down when the portion that cares 
doesn't make sense to keep at the top level and worse doesn't necessarily exist 
all the time.

To point to something at least similar, consider Slack. You've got a hierarchy 
of boards, channels, and posts (and a bunch of other stuff). The set of 
channels depends on the selected board. The set of posts depends on the 
selected channel (and the selected board). It's natural to just manage them all 
together at the top level but as there get to be more pieces of the model, 
there gets to be more bumping heads as well if multiple people are working on 
it. So, it makes sense to start breaking things up in terms of modules for the 
board list, the channel list, and the message list. But selections in one 
affect the available choices in the other and APIs for talking to the server 
need to know the full information path. The choices then seem to be to 
replicate state — e.g., let the channel list know the ID of the selected board 
so that it can talk to the server about the channels on the board — or pass 
state down with all operations. The latter is better for avoiding things being 
out of sync but we still found ourselves needing messages to say things like 
"the board ID just changed" and if you've got to send those messages or invoke 
those functions, then you are more or less dealing with the sync problem but 
you'll have a harder time debugging sync issues because you won't have the 
values to look at if the sync doesn't happen. I'm not pretending that there is 
some magic way to avoid this. I've worked with observation systems and seen the 
confusion they lead to. But I am looking for best practices to manage this sort 
of coupling.

As for contrivances v real problems, I approach these things like a 
mathematician and look for the core abstraction, the core problem which often 
is intentionally disconnected from the actual problem because much of the real 
problem is a distraction. I've got a new team member looking at elm-mdl and 
wanting to know whether that's a good pattern to follow in implementing a 
fairly elaborate corporate UI standard (not MDL but similarly involved). The 
initial feedback I've had to give is that the approach taken in elm-mdl hasn't 
been embraced by the larger Elm community but when asked as to what one should 
do instead to cover those same sort of problems, I haven't been able to supply 
a good answer. The questions in other threads seemed to boil down to "I'm 
implementing an MDL ripple or a calendar or something else with local/private 
state, how should I handle that?" If every answer is a one-off, then it means 
that Elm is a lot harder for new team members to work with and adopt.

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.

[elm-discuss] Re: Dead code elimination and the future of elm-runtime.js

[Brian Slesinsky]

Delegating to Closure is smart but the combination still needs to be tested to 
really claim code size is solved. Writing code to allow tree shaking isn't an 
entirely natural thing - new dependencies can happen easily unless you have 
testing to tell you that code size has regressed.

-- 
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] Private state: A contrived example

[Josh Adams]

On Saturday, September 10, 2016 at 2:29:10 AM UTC-5, Mark Hamburg wrote:
>
> As for my Elm experience, I've built a moderately large project in Elm 
> working with other developers. We've tried it the giant model way and the 
> codebase became tricky to sustain multiple developers working at once and 
> the ability to reason about it declined. Just relying on the type checker 
> for refactoring was a lot like refactoring in C++ by changing a header file 
> and fixing compiler errors until it built again which was arguably better 
> than the experience in untyped languages but not in and of itself 
> miraculous. We then did more to break the app into pieces and that worked 
> but the plumbing often felt ugly, so the question has been whether 
> there's a better way to decompose and structure large apps and what 
> guidelines should be in place for structuring code when scaling up a team. 
>

So this right here indicated to me a real, concrete example that we could 
all kibitz on.  Can you provide an example of the before/after the 
plumbing?  Maybe the path you took to solve breaking it into pieces was 
ovezealous.  I see a lot of people bring up this problem and I've built a 
lot of elm code and just don't have it, so it always confuses me.

What I often see is what Evan refers to in the reuse section of the guide 
now.  A jump-too-far when running into a particular issue.

For instance, I've seen people introduce a ton of state and independent 
updates when all I would have done in that situation is break out a new 
module to handle the complexity of a given view.  You had a giant flat 
model (I think this is wise as a starting point in Elm) and then you wanted 
to tweak it.  There are typically a few reasons for this:

   1. The views are becoming confusing because they are forced to drill 
   into nested portions of the model.  I've seen people do crazy things here 
   where they could have just passed in a particular field to that view or 
   destructured in the function head (the former is better but sometimes you 
   aren't well-factored and you need more than just the piece of the model you 
   should really care about).
   2. The update is becoming overwhelmingly complicated.  When this comes 
   up I've seen people do what I (again) consider to be crazy, when really 
   they could just tag a portion of their model in the top level Msg, 
   introduce a UserMsg' or something similar, and break out all the 
   user-related pieces into an `updateUser` function they call from the top 
   level model.  This isn't bad at all either.  Html.App.map, Cmd.map, and 
   Sub.map are perfect for this exact use case.
  1. If you are in a situation where you can't easily just 
  "Html.App.map" a subset, just use function composition.  I have a 
top-level 
  Msg that's "NavigateTo Route.Location" and I want to be able to send that 
  out from any of my children, so I can either Html.App.map the 
  'sub-view-functions' inside those child views or I can just compose the 
  taggers in-place and refactor it whenever I feel it's gotten too 
bothersome.
   
You don't really have to go whole-hog to solve those problems.  Most of the 
times I've dug into someone's problems of this nature, once we had a 
concrete discussion of their concerns and actual code, we were able to find 
a solution for them.  I dislike contrived examples specifically because 
they ask for a general solution where I just think you likely shouldn't. 
 There are 5 or 6 patterns to solve different levels of this 'problem'.  In 
my opinion the proper way to learn Elm is to gradually improve the dumb/bad 
code until it's amazing.  I've *literally only seen this issue come up* when 
people wanted to "solve all the future issues at once" rather than just 
incrementally making a codebase better.

Would you be willing to paste some example code so we can see the problem 
you faced and the way you solved it?  If so, maybe we could find that if 
you'd made one small tweak to your solution then you never would have 
achieved this level of frustration.

The point
My core point - every time we've had a discussion about concrete code that 
wasn't a contrived example, I've seen good things happen.  For contrived 
examples, there's too much "I want to take as an axiom that I should do 
something that seems unreasonable to people that have built large things in 
Elm successfully - now let's talk about how to make that unreasonable thing 
nicer."

Sidebar
The elm-mdl/elm-parts issue is in my opinion entirely coincidental (though 
related) to this discussion.  I'd love to have a discussion about it but I 
think this thread isn't the place.  I think it'd be fun to have some people 
try their hand at using the non-elm-parts style of elm-mdl and see how 
usable they can make it / get a list of what those solutions look like.  If 
someone's interested in talking about elm-mdl/elm-parts, does starting a 
thread with that explicit goal seem 

[elm-discuss] Re: Pairing Session Video: Josh Adams and Luke Westby pairing on server-side-validations

[Josh Adams]

On Saturday, September 10, 2016 at 2:07:37 AM UTC-5, Maxwell Gurewitz wrote:
>
> I think the video link is broken.
>

You're right.  It seems to have acquired a non-printing character in the 
above link.

The url 
is https://www.dailydrip.com/topics/elm/drips/server-side-validations - 
that's what it looks like you get when you click that original link but 
there appears to be an additional "%E2%80%8B" floating at the end somehow 
in the original :(

-- 
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: Sort a list of strings independant of case

[Max Goldstein]

>
> not changing original list


An an immutable language such as Elm, nothing can change the original list! 
I think you've more-or-less implemented List.sortBy explicitly, which is 
instructive, but not really necessary. 

-- 
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] What languages do you write your back-ends in?

[Jim Freeze]

It depends on your goals for the backend.

If you want distributed and fault tolerant systems, Elixir/Erlang is proven
in that space for the last 30 years - as they both run on the BEAM. (I'm
livin' the dream. I have the BEAM).

There are others that can explain this much better than myself, but the
most fault tolerant systems don't come from a family of typed languages.
Erlang with it's dynamic typing, pattern matching and OTP has been
providing 99.9% uptime for over 20 years. And, if you understand the
trend in hardware CPU's with more cores and lower clock speeds, you
certainly want to explore the BEAM as a tool to utilize those cores in an
efficient and simple manner.

Jim


On Sat, Sep 10, 2016 at 11:09 AM, Dave Rapin  wrote:

> Elixir is compiled to bytecode similar to how a JVM language like Closure
> or Scala is. So not quite like C but similar to Elm.
>
> Also I assume you're taking about dynamic types which it has unlike Elm's
> type system. I've heard however that Elixir's safer than your usual dynamic
> language due to pattern matching.
>
> Depending on your use case I would alsoseriously consider a DBAAS option
> like Firebase if your not much for devops or simply don't feel like
> managing infrastructure. Combined with something like AWS lambda or
> Google's cloud functions for a microsrrvice architecture (only when you
> need it) it's pretty close to feature parity with a Phoenix type setup with
> less effort.
>
> --
> 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.
>



-- 
Dr. Jim Freeze, Ph.D.
(m) 512 949 9683

-- 
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: Sort a list of strings independant of case

[Sergey Zubtsovskiy]

This is a solution not changing original list:

import Html exposing (text)
import String exposing (toUpper)

main =
  text (toString sortedList)
  
sortedList : List String
sortedList =
  [ "c", "B" , "a" ] |> List.sortWith compareIgnoreCase
  
compareIgnoreCase : String -> String -> Order
compareIgnoreCase a b =
  case compare (toUpper a) (toUpper b) of
LT -> LT
EQ -> EQ
GT -> GT

Efficiency can be improved by keeping a cache of already upper cased 
letters.


On Friday, September 9, 2016 at 5:45:01 PM UTC+2, Rudolf Bargholz wrote:
>
> Hi,
>
> Failing here dismally, so I hope someone here is kind enough to help out.
>
> *Problem*: I have a list of strings and want to sort the list independant 
> of the case of the chars in the string
>
> What I have so far:
>
> > import List
> > import String
> > unorderedList = [ "c", "B" , "a"]
> ["c","B","a"] : List String
> > orderedList = List.sort unorderedList
> ["B","a","c"] : List String
> > orderedList2 = unorderedList |> List.map String.toUpper |> List.sort
> ["A","B","C"] : List String
>
>
> What I am trying to acheive is the following result:
>
> ["a","B","c"] : List String
>
> I must be overlooking something easy. 
>
> Could anyone point me in the right direction how I can accomplish this?
> Is there any resource that has numerous Elm examples on how to use 
> *List.sort*, *List.sortBy* and *List.sortWith*?
>
> Regards
>
> Rudolf Bargholz
>

-- 
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] What languages do you write your back-ends in?

[Dave Rapin]

Elixir is compiled to bytecode similar to how a JVM language like Closure or 
Scala is. So not quite like C but similar to Elm.

Also I assume you're taking about dynamic types which it has unlike Elm's type 
system. I've heard however that Elixir's safer than your usual dynamic language 
due to pattern matching.

Depending on your use case I would alsoseriously consider a DBAAS option like 
Firebase if your not much for devops or simply don't feel like managing 
infrastructure. Combined with something like AWS lambda or Google's cloud 
functions for a microsrrvice architecture (only when you need it) it's pretty 
close to feature parity with a Phoenix type setup with less effort.

-- 
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] What languages do you write your back-ends in?

[Joey Eremondi]

I used Haskell, but it's been a while since I've had a chance to work on an
app with a backend...

On Sep 10, 2016 8:57 AM, "Mario Sangiorgio" 
wrote:

> Being compiled doesn't really mean that the compiler helps the programmer.
> There is the need for a good type system and from what I see here
> 
> Elixir is a bit lacking on this regards:
>
> Elixir is a dynamically typed language, so all types in Elixir are
> inferred by the runtime. Nonetheless, Elixir comes with typespecs, which
> are a notation used for:
>
>
>- declaring custom data types;
>- declaring typed function signatures (specifications).
>
> The problem is that typespecs are not required nor enforced by the
> compiler itself but by Dialyzer, a static analysis tool. And they type
> system itself is less powerful than Elm's.
> On Sat, 10 Sep 2016 14:25 Jim Freeze,  wrote:
>
>> Elixir is a compiled language.
>>
>> If you need performance your best option to fully utilize your hardware
>> is the BEAM and OTP.
>>
>> Sent from my iPhone
>>
>> On Sep 10, 2016, at 2:41 AM, Mario Sangiorgio 
>> wrote:
>>
>> Hello,
>>
>> I was wondering what programming language you use to implement the
>> back-end for your Elm single page web app.
>>
>> Reading around I see that the Elm/Elixir combo is popular but for how
>> much I think BEAM is an awesome VM I'm a bit sceptical due to Elixir being
>> a dynamic language. How much do you miss the compiler when you write Elixir
>> code?
>>
>> If you're not using Elixir, to what do you use? I played a bit with F#
>> (using Suave.io ) and I think it's quite nice.
>>
>> Now I'm in the mood of learning something new so I'd like to know what
>> you use and maybe get an idea of what to look at next.
>>
>> Mario
>>
>> --
>> 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.

Re: [elm-discuss] What languages do you write your back-ends in?

[Mario Sangiorgio]

Being compiled doesn't really mean that the compiler helps the programmer.
There is the need for a good type system and from what I see here

Elixir is a bit lacking on this regards:

Elixir is a dynamically typed language, so all types in Elixir are inferred
by the runtime. Nonetheless, Elixir comes with typespecs, which are a
notation used for:


   - declaring custom data types;
   - declaring typed function signatures (specifications).

The problem is that typespecs are not required nor enforced by the compiler
itself but by Dialyzer, a static analysis tool. And they type system itself
is less powerful than Elm's.
On Sat, 10 Sep 2016 14:25 Jim Freeze,  wrote:

> Elixir is a compiled language.
>
> If you need performance your best option to fully utilize your hardware is
> the BEAM and OTP.
>
> Sent from my iPhone
>
> On Sep 10, 2016, at 2:41 AM, Mario Sangiorgio 
> wrote:
>
> Hello,
>
> I was wondering what programming language you use to implement the
> back-end for your Elm single page web app.
>
> Reading around I see that the Elm/Elixir combo is popular but for how much
> I think BEAM is an awesome VM I'm a bit sceptical due to Elixir being a
> dynamic language. How much do you miss the compiler when you write Elixir
> code?
>
> If you're not using Elixir, to what do you use? I played a bit with F#
> (using Suave.io ) and I think it's quite nice.
>
> Now I'm in the mood of learning something new so I'd like to know what you
> use and maybe get an idea of what to look at next.
>
> Mario
>
> --
> 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] Private state: A contrived example

[Oliver Searle-Barnes]

Mark, have you considered the approach that Evan took with elm-autocomplete 
?
 
Personally, I found this a satisfactory approach to the problem of private 
state/events, I'd be interested to hear your take on it.

> From my view, the issue here is with how you scale a page when it is full 
of such "components". 

This is definitely the issue that feels the least resolved for me. The 
elm-parts approach hasn't been endorsed, but I'm not aware of any other 
approach being put forward.


On Saturday, 10 September 2016 16:39:53 UTC+2, Mark Hamburg wrote:
>
> > On Sep 10, 2016, at 1:22 AM, Peter Damoc  
> wrote: 
> > 
> > Charlie was right, an accordion is a better example. 
>
> I'm sure it is. As is a date picker. As with lists of counters as models 
> in the Elm Architecture documents, my example is entirely contrived — 
> hence, my subject line — with the intent that in being so contrived and yet 
> so simple, attention could instead focus on the proposed pattern for 
> handling a combination of public/shared state and private/local state. I 
> figured that these discussions had come around enough that that context 
> would be as clear as the context for why a list of counters is interesting. 
> I seem to have been wrong in that regard. 
>
> > From my view, the issue here is with how you scale a page when it is 
> full of such "components". 
>
> I rather hoped that if the approach I took could be endorsed as being 
> closer to what some would argue is the right way to write Elm code that the 
> scalability issue could be the next discussion point. But to get there we 
> need something that's being scaled and we can't even seem to get to that 
> point. 
>
> 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.

[elm-discuss] Re: Pairing Session Video: Josh Adams and Luke Westby pairing on server-side-validations

[Eric G]

Haven't watched the video but wanted to say just reading through your 
"annotated diffs" I could mostly follow along, thanks! (I'm working on 
something similar now -- not using elm-simple-form or elm-mdl, but it was 
still extremely helpful to see how you did it.)

On Friday, September 9, 2016 at 10:33:36 AM UTC-4, Josh Adams wrote:
>
> Yesterday, I got the chance to spend nearly 2 hours pairing with Luke 
> Westby.  We did this: 
> https://www.dailydrip.com/topics/elm/drips/server-side-validations​
>
> *tl;dw*
>
>- I showed him where http://github.com/knewter/time-tracker had gotten 
>this week with live validation merging elm-simple-form and elm-mdl.
>- Then we added a server-side validation to the API that the 
>client-side validators couldn't help with (unique field constraint in 
>database table).
>- Finally, we merged the server-side validations in nicely with the 
>client-side validations and made sure the UX was pleasant. 
>
> 
>   - I *hate it* when UX people don't fix these simple things.
>
>
> Anyway, I hope you enjoy watching it!  *I know there's tons to refactor* 
> but I was (trying to stay) focused on just getting the ugly dirty thing out 
> the door.
>
> :heart:
>
> -Josh
>

-- 
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] Private state: A contrived example

[Mark Hamburg]

> On Sep 10, 2016, at 1:22 AM, Peter Damoc  wrote:
> 
> Charlie was right, an accordion is a better example. 

I'm sure it is. As is a date picker. As with lists of counters as models in the 
Elm Architecture documents, my example is entirely contrived — hence, my 
subject line — with the intent that in being so contrived and yet so simple, 
attention could instead focus on the proposed pattern for handling a 
combination of public/shared state and private/local state. I figured that 
these discussions had come around enough that that context would be as clear as 
the context for why a list of counters is interesting. I seem to have been 
wrong in that regard.

> From my view, the issue here is with how you scale a page when it is full of 
> such "components". 

I rather hoped that if the approach I took could be endorsed as being closer to 
what some would argue is the right way to write Elm code that the scalability 
issue could be the next discussion point. But to get there we need something 
that's being scaled and we can't even seem to get to that point.

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] What languages do you write your back-ends in?

[Jim Freeze]

Elixir is a compiled language. 

If you need performance your best option to fully utilize your hardware is the 
BEAM and OTP. 

Sent from my iPhone

> On Sep 10, 2016, at 2:41 AM, Mario Sangiorgio  
> wrote:
> 
> Hello,
> 
> I was wondering what programming language you use to implement the back-end 
> for your Elm single page web app.
> 
> Reading around I see that the Elm/Elixir combo is popular but for how much I 
> think BEAM is an awesome VM I'm a bit sceptical due to Elixir being a dynamic 
> language. How much do you miss the compiler when you write Elixir code?
> 
> If you're not using Elixir, to what do you use? I played a bit with F# (using 
> Suave.io) and I think it's quite nice.
> 
> Now I'm in the mood of learning something new so I'd like to know what you 
> use and maybe get an idea of what to look at next.
> 
> Mario
> -- 
> 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: Private state: A contrived example

[Charles-Edouard Cady]

I have the feeling that some people think if you can't do it simply without 
a local state then use a ready-made external component. Maybe that's the 
answer after all - I don't know.
I was once told that design patterns exist to address the shortcomings of a 
language & I think it's quite true: the local state problem isn't one in 
other languages with private states (e.g.. object-oriented).
Not having the choice between hiding or showing state in Elm is a mixed 
blessing: it makes the code very easy to reason about & provides strong 
safety guarantees & eases debugging & testing, but on the other hand it 
hurts encapsulation a great deal.
I once thought extensible records might be an answer as each component 
would simply add the states it needs, but it raises the issue of name 
collision (& was removed from the language because, hey, who could possibly 
need such a feature).

I'm starting to think that maybe you should simply use stuff like Polymer, 
knowing that it will probably blow up the quantity of code by fifty.

On Saturday, September 10, 2016 at 10:24:49 AM UTC+2, Peter Damoc wrote:
>
> Do you have an example on how to define a web component in Elm without 
> native code? Or you wanted to say that Elm could be used to define web 
> components internals? 
> If it's the second case, then yes, that would be awesome! 
>  
>
> On Sat, Sep 10, 2016 at 1:02 AM, John Mayer  > wrote:
>
>> Has anyone explored using web components (the browser standard)? 
>>
>> Elm can be used to define web component internals, the "build process" 
>> registers the components with the browser, and Elm can also consume web 
>> components as normal HTML as the top-level application. 
>>
>> Might be a worthwhile spike before we commit to developing another coding 
>> pattern.
>>
>  
>
>
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

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

[elm-discuss] Re: Dead code elimination and the future of elm-runtime.js

[Robin Heggelund Hansen]

First of all, I agree with all your main points. The size and scope of the 
runtime should not be dictated by the number of bytes it takes up. Also, 
the compiler does have more flexibility if it was all in JS.

However. As long as the target language is JS, I don't think DCE should be 
a priority, as we already have minifiers that provide this service for us. 
This also means that there is no reason to include a 'prod' or 'dev' mode 
to the compiler (at least not for this) as a 'prod' mode is simply adding a 
minifier step to your build configuration.

The elm compiler already outputs JS in a way that makes it very simple to 
remove dead code, and to minify well. The only 'problem' with the current 
way of things, is that the elm-runtime is written by hand, and thus not 
written in such a way that makes it easy to minify well and remove dead 
code. Re-writing more of the elm-runtime in elm should mitigate this 
further. In fact, I believe Elm already beats other languages like 
ClojureScript quite well in size, even though CLJS uses google closure for 
minification. The main advantage cljs has over Elm, is that cljs' runtime 
is written in cljs.

I also don't believe that elm-html should be a part of the standard 
library. While it might makes sense today, it makes less sense in the 
distant feature when someone has come up with a new, revolutionary and 
soon-to-become de-facto HTML library. It also wouldn't make sense if Elm 
ever becomes a backend or scripting language. It should be noted however, 
that my interpretation of what a standard library is, is a library that 
provides functions you would likely use in any app, and which are unlikely 
to do better any other way. The current standard library is, IMHO, fine the 
way it is when it comes to scope, while there are certain functions I would 
love to add to certain modules (like List.find). You're interpretation may 
be different. In any case, there is no reason to discuss the size and scope 
of the standard library here, I just thought I would voice my opinion that 
just because we have DCE, that doesn't mean should be uncritical with what 
we put in the standard library.

I would also like to point out that while optimizing for Google Closure is 
a good thing (tm), it should not come at the cost of hampering other 
minifiers like UglifyJS. UglifyJS already removes all dead code (except 
dead code in native code) quite well in my applications, and I would love 
for that to still be a thing in the future without swapping out Uglify with 
a Java application.

So yeah, my 2 cents essentially boils down to:
1) Move more runtime code from native to pure elm.
2) Explore a way to make native code as easy to minify/DCE as compiled Elm 
code.
3) Should the Elm compiler ever support another target in the future, spend 
resources on DCE.

torsdag 16. oktober 2014 16.12.46 UTC+2 skrev Laszlo Pandy følgende:
>
> Currently elm-runtime.js works like any JavaScript library: you include it 
> with your page and your generated Elm code use the exposed functions. In 
> fact you could even use it from hand-written JS code. But a language 
> runtime is not the same thing as a JS library.
>
> Recently many people have brought up two issues:
> - should elm-html be in the standard library?
> - why is elm-runtime.js so big?
>
> And here are two stories which indicate which direction Elm should be 
> heading in:
> 1. Since Haxe started, they were always concerned about compiled JS size. 
> They believed that JS devs wouldn't switch to Haxe if a hello world was 10K 
> of JS. So they kept the standard modules small. There was a class String 
> with a few functions, and StringTools[1] with many more. StringTools would 
> not be included if you didn't import it.
>
> Later on, Haxe implemented function-level dead code elimination. After 
> that it didn't matter how big String was. All the parts you didn't use 
> would be deleted from your output. Now StringTools is just API baggage that 
> shouldn't exist.
>
> [1] http://api.haxe.org/StringTools.html
>
> 2. Just like Elm's runtime is written in JS, Go's runtime is written in C. 
> But how there is a big project rewrite much of it in Go[2] to take 
> advantage of the compiler's stack layouts. But even if we are talking about 
> Elm and JS, there would be many advantages to having most of the runtime 
> written in Elm:
> - inlining, and other optimizations
> - function-level dead code elimination
> - less code maintenance (ie. if Elm changes its data structures)
>
> [2] 
> http://dave.cheney.net/2014/09/01/gos-runtime-c-to-go-rewrite-by-the-numbers
>
> What we see is:
> - dead code elimination decouples the runtime size from the API design. 
> This is a good thing
> - the runtime should be a collection of functions, not a self-contained 
> library to enable dead code elimination
> - the compiler has more flexibility if more functions are in Elm instead 
> of JS
>
> The direction Elm should be heading in is to have no separate 

Re: [elm-discuss] Re: Private state: A contrived example

[Peter Damoc]

Do you have an example on how to define a web component in Elm without
native code? Or you wanted to say that Elm could be used to define web
components internals?
If it's the second case, then yes, that would be awesome!


On Sat, Sep 10, 2016 at 1:02 AM, John Mayer  wrote:

> Has anyone explored using web components (the browser standard)?
>
> Elm can be used to define web component internals, the "build process"
> registers the components with the browser, and Elm can also consume web
> components as normal HTML as the top-level application.
>
> Might be a worthwhile spike before we commit to developing another coding
> pattern.
>




-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

Re: [elm-discuss] Private state: A contrived example

[Peter Damoc]

Personally, I think that "local state" or "accidental state" is a better
name for this issue.

It is the state that has no business logic value. You can change it and
nothing of consequence happens in the stuff that you do save in a database.
It has everything to do with the interaction with the user. It supports
that interaction in some way.
Charlie was right, an accordion is a better example.
You have a little bit of state that the developer doesn't have to handle.
The developer could set some kind of shape of that state by using options
or config of the accordion or it can just leave the accordion in its
default state.
The user can interact with the accordion and this could or could now be of
importance to the developer. It can leave the events (open some section)
just do the default behavior OR the developer could want to be informed
when they happen in order to maybe log them from analysis purposes.

It is very very easy to think about this accordion as being "a component".
It is very very easy to think about using something different in it's place
like a dumb component that's just a bunch of paragraphs.

HOWEVER, the problem is not with the accordion as the implementation. That
can be done easy.
>From my view, the issue here is with how you scale a page when it is full
of such "components".

And here is the disconnect.
If you focus on the specific accordion, you focus on how to create a
pleasant API for the accordion (elm-sortable-table and autocomplete is an
example of solving this kind of a problem) .
If you focus on the general widget that the accordion is, you need to solve
a completely different kind of API problem (elm-parts is such an attempt to
solve this problem).

Both of these focuses are valid but they solve different problems.
I tried to ask for a solution to the second problem and I have been accused
of steering the conversation away from the specifics and being
disrespectful of everyone's time.

I still think this is a very important problem and a very specific one.
It is the kind of problem that might not have a solution without some kind
of OO facilities because, from where I look it seams to be about "treating
a bunch of stuff that are different types like the same thing".
A GUI toolkit is the perfect example of a use-case for this problem.

Just look at what GUI toolkits one has in functional language. Either they
have bindings to GTK/QT (which are stateful) OR they have purely functional
attempts that are used only by a minority (one has to wonder why is that
?).



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

[elm-discuss] What languages do you write your back-ends in?

[Mario Sangiorgio]

Hello,

I was wondering what programming language you use to implement the back-end
for your Elm single page web app.

Reading around I see that the Elm/Elixir combo is popular but for how much
I think BEAM is an awesome VM I'm a bit sceptical due to Elixir being a
dynamic language. How much do you miss the compiler when you write Elixir
code?

If you're not using Elixir, to what do you use? I played a bit with F#
(using Suave.io) and I think it's quite nice.

Now I'm in the mood of learning something new so I'd like to know what you
use and maybe get an idea of what to look at next.

Mario

-- 
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] Private state: A contrived example

[Mark Hamburg]

elm-mdl is loaded with private state support in order to support various 
Material Design Language elements. I'll let those who built it go into those 
details. I was responding to the argument that the elaborate apparatus that 
elm-mdl uses is "not the right way to do this in Elm" but those arguments 
haven't been accompanied by examples of how one should build support for MDL. 
Evan's sortable table provides a demonstration of storing data separately from 
the view state but requires little behavior from the table element and doesn't 
edit the table data. Other examples beyond MDL that people have raised include 
date pickers that need to store information about whether they are displayed, 
what month is displayed, etc and none of this has to do with the public/shared 
state that is the actual chosen date. Again, we haven't had a demonstration of 
how to handle this. Last I knew, for example, NoRedInk was bridging to a 
JavaScript component for date picking and meanwhile Evan has argued that 
greater reliance on existing JavaScript code is a bad thing because Elm is 
supposed to be better than JavaScript.

So, in that context, I tried to see what code patterns would support a UI 
element with both public and private state and that had element specific 
behavior without the special state store that elm-mdl built. What I linked to 
shows that while you do have to explicitly store the private state for the view 
somewhere, it doesn't seem overly onerous to do so nor to build or work with a 
UI element that has such a split between shared and private state.

As for my Elm experience, I've built a moderately large project in Elm working 
with other developers. We've tried it the giant model way and the codebase 
became tricky to sustain multiple developers working at once and the ability to 
reason about it declined. Just relying on the type checker for refactoring was 
a lot like refactoring in C++ by changing a header file and fixing compiler 
errors until it built again which was arguably better than the experience in 
untyped languages but not in and of itself miraculous. We then did more to 
break the app into pieces and that worked but the plumbing often felt ugly, so 
the question has been whether there's a better way to decompose and structure 
large apps and what guidelines should be in place for structuring code when 
scaling up a team.

Mark

> On Sep 9, 2016, at 7:25 PM, Leroy Campbell  wrote:
> 
> Mark,
> 
> I don't understand why so much concern about private state. The reason 
> components (in JS frameworks) need private state is to protect them from 
> accidental mutation by callers. With immutable data, I don't see a need to 
> hide data.
> 
> I've had to maintain several 10K+ JavaScript codebases. The number one 
> problem I've had is mutable state spread throughout those apps. Unit tests 
> don't help here; sure components work fine in isolation, but no amount of 
> disciple saves you from bugs where a reference is leaked from a nested data 
> structure then mutated in a closure somewhere else.
> 
> Do you have a real case for components in the way you propose? To me, it 
> doesn't seem like you've tried to build anything substantial with Elm to 
> understand Evan and Richard's point of view on the matter.
> 
> -- 
> 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: Pairing Session Video: Josh Adams and Luke Westby pairing on server-side-validations

[Maxwell Gurewitz]

I think the video link is broken.

On Friday, September 9, 2016 at 7:33:36 AM UTC-7, Josh Adams wrote:
>
> Yesterday, I got the chance to spend nearly 2 hours pairing with Luke 
> Westby.  We did this: 
> https://www.dailydrip.com/topics/elm/drips/server-side-validations​
>
> *tl;dw*
>
>- I showed him where http://github.com/knewter/time-tracker had gotten 
>this week with live validation merging elm-simple-form and elm-mdl.
>- Then we added a server-side validation to the API that the 
>client-side validators couldn't help with (unique field constraint in 
>database table).
>- Finally, we merged the server-side validations in nicely with the 
>client-side validations and made sure the UX was pleasant. 
>
> 
>   - I *hate it* when UX people don't fix these simple things.
>
>
> Anyway, I hope you enjoy watching it!  *I know there's tons to refactor* 
> but I was (trying to stay) focused on just getting the ugly dirty thing out 
> the door.
>
> :heart:
>
> -Josh
>

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