Re: [elm-discuss] Best practices for designing models in the Elm Architecture - lean or rich?

[Ray Toal]

Great tip, thanks!

On Tuesday, July 25, 2017 at 12:50:20 AM UTC-7, Christian Charukiewicz 
wrote:
>
> In your expensive function example, you should be able to take advantage 
> of Html.Lazy to prevent the view from re-running the expensive function 
> unless its parameters change.  By storing the derived data in the model 
> rather than letting Elm handling the caching through the Lazy functions, 
> you are effectively doing something similar but at the cost of adding a lot 
> of complexity to your application.
>
> On Tuesday, July 25, 2017 at 2:11:22 AM UTC-5, Peter Damoc wrote:
>>
>> Keep derived data in the model if it makes sense to keep derived data in 
>> the model. 
>>
>> If you have an expensive function that runs and computes a derived value 
>> and you would have to call frequently this function in your view, then by 
>> all means, computer the derived value in update and save it in the model. 
>>
>> If you don't run into a performance problem like the above, keep your 
>> model clean and just extract the computation in a function. for example, 
>> you could have something like 
>>
>> bmiText : Model -> Html msg 
>> bmiText {weight, height} = 
>> weight / height ^ 2 |> toString |> text 
>>
>> this way, everywhere you need that textual representation, you can use 
>> it. 
>>
>>
>>
>>
>> On Tue, Jul 25, 2017 at 4:23 AM, Ray Toal  wrote:
>>
>>> This might be an opinion-based question so I can't ask it on 
>>> StackOverflow. :-)
>>>
>>> I have a trivial beginnerProgram using the Elm Architecture. It has two 
>>> text fields (HTML input elements), one for weight and one for height. The 
>>> onInput attributes of each generate a message. The update function accepts 
>>> the message and produces the new model.
>>>
>>> The question is: Should the model (a) consist of the width and height 
>>> only, or (b) also include the computed BMI (width / height^2)? If the 
>>> former, I compute the BMI in the view function; if the latter, I would 
>>> compute it in the update function.
>>>
>>> Does anyone have a lot of experience with Elm applications that would 
>>> lead them to believe that keeping models as small as possible and computing 
>>> derived data in the view function is better than making rich models? I 
>>> don't have enough experience with Elm to know. I sense that for a problem 
>>> as simple as mine it really doesn't matter (and I in fact got it working 
>>> both ways), but as I start scaling up my apps it would be nice to know if 
>>> there is best practice here (or not).
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> 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: Best practices for designing models in the Elm Architecture - lean or rich?

[Kasey Speakman]

I don't think it matters one way or another. Whatever you end up finding 
easier to maintain.

What I would do is explicitly represent the BMI as its own module, probably 
with an accompanying data type. In the module operations like 
`updateHeight` and `updateWeight`, you could make sure that the calculation 
is getting rerun. Update would call the module instead of directly setting 
individual properties. Then you have this logic encapsulated and 
centralized.

On Monday, July 24, 2017 at 8:23:44 PM UTC-5, Ray Toal wrote:
>
> This might be an opinion-based question so I can't ask it on 
> StackOverflow. :-)
>
> I have a trivial beginnerProgram using the Elm Architecture. It has two 
> text fields (HTML input elements), one for weight and one for height. The 
> onInput attributes of each generate a message. The update function accepts 
> the message and produces the new model.
>
> The question is: Should the model (a) consist of the width and height 
> only, or (b) also include the computed BMI (width / height^2)? If the 
> former, I compute the BMI in the view function; if the latter, I would 
> compute it in the update function.
>
> Does anyone have a lot of experience with Elm applications that would lead 
> them to believe that keeping models as small as possible and computing 
> derived data in the view function is better than making rich models? I 
> don't have enough experience with Elm to know. I sense that for a problem 
> as simple as mine it really doesn't matter (and I in fact got it working 
> both ways), but as I start scaling up my apps it would be nice to know if 
> there is best practice here (or not).
>
>

-- 
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: Systemic problem in Object Oriented languages

[Robin Heggelund Hansen]

First of all, let's agree that both Java and Javascript are successful 
languages in that you can solve most, if not any, given software problems 
in those languages. Does that mean the languages themselves are 
unproblematic? What does it mean to have a problem? Does it mean you cannot 
get anything done? Or could you still write a very successful program 
despite those problems. Cold you, in fact, have a problem without 
considering it one?

What constitutes a problem is highly subjective. It's good to keep in mind 
in this discussion.

So, the line in the docs is not wrong. "this" effectively combines logic 
and data, and Elm does maintain a separation there. The systemic problem 
being referenced, is the comingling of data and logic, not that you can 
write "this".

So why is this is a problem?

We've already defined that it is not a problem which prevents you from 
solving problems, in fact, very few thing in Javascript or Java or any 
other functional language pose such a problem. But there are some downsides 
that is worth considering:

1. What is "this"?
In a single class, "this" is a very easy thing. It refers to this instance 
of a class. But what does "this" mean in a context where the class is a 
child? Does "this" refer to this instance, or a parent instance, or a 
parent parent instance? This might not be conceived as a problem, since we 
got fancy IDE's helping us keep track of things, but I would argue that 
having "this" in any non-trivial piece of code makes it difficult to 
understand such code if you're reading it for the first time. Avoiding 
"this" makes code, IMHO, easier to read.

2. What's the downside of coupling data and logic?
Let's say we have the two following classes:

class Person { public int age; }
class Animal { public int age; }

Why can't we store both of these in an array? They look the same, the carry 
the same information, but they are different. If I write a function which 
operates on the age field, why do I need to write this twice for both 
classes? I can of course write a `Ageable` interface which declares a 
`getAge` function, but why is that necessary? What benefit do we get here 
by combining logic with data?

In Elm, you would define these as type aliases, meaning every function 
would work on one or the other, and you could store them in Lists or what 
not. You can also easily create extendable types if you only care about one 
or more fields.

Another downside: I need a function that works on all integers. Why do I 
have a create a static class for this? Why can't I just have a free 
function for this? What is the benefit of having it this way?

These aren't big things. But for me, combining logic and data makes it 
harder to understand code and to re-use it. There also doesn't seem to be 
any benefit in that combination.

Note: Javascript can avoid all these functions quite easily, but that's 
because javascript really is just as functional as it is object-oriented.

I'd also like to leave this link here, great talk on the 
subject: https://www.youtube.com/watch?v=-6BsiVyC1kM

torsdag 20. juli 2017 09.55.54 UTC+2 skrev Dave Ford følgende:
>
> There is a line from the docs that I am trying to understand: "Elm 
> encourages a strict separation of data and logic, and the ability to say 
> this is primarily used to break this separation. This is a systemic 
> problem in Object Oriented languages that Elm is purposely avoiding."
>
> What is the systemic problem being reference? Is it the [lack of] "separation 
> of data and logic" or "the ability to say this"?
>
> I have been programming in Java (an OO language) for a long time. I can 
> name dozens of systemic problems in the language. But the ability to say 
> "this" is not one of them. Nor is it the commingling of data and logic. 
>
> Please help me to understand what the author is talking about.
>
> Thanks.
>
> Side note: "this" *is* a problem in JavaScript. But not in OO generally.
>

-- 
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: Forms with Floats / Dates

[Vlad GURDIGA]

Hi Simon!

As a newcomer to Elm, I too have this issue fresh in my experience, and my 
approach 

 has 
been similar to what Witold Szczerba’s: I’ve built myself a MyDate type to 
hold all the information I need, and a few helper functions that work with 
values of that type:

type alias MyDate =
{ string : String
, date : Maybe Date
, validationMessage : String
}

I think the essence of the approach is to hold user’s input separate from 
the value that we want to make out of it in the end. 邏


-- 
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] Best practices for designing models in the Elm Architecture - lean or rich?

[Christian Charukiewicz]

In your expensive function example, you should be able to take advantage of 
Html.Lazy to prevent the view from re-running the expensive function unless 
its parameters change.  By storing the derived data in the model rather 
than letting Elm handling the caching through the Lazy functions, you are 
effectively doing something similar but at the cost of adding a lot of 
complexity to your application.

On Tuesday, July 25, 2017 at 2:11:22 AM UTC-5, Peter Damoc wrote:
>
> Keep derived data in the model if it makes sense to keep derived data in 
> the model. 
>
> If you have an expensive function that runs and computes a derived value 
> and you would have to call frequently this function in your view, then by 
> all means, computer the derived value in update and save it in the model. 
>
> If you don't run into a performance problem like the above, keep your 
> model clean and just extract the computation in a function. for example, 
> you could have something like 
>
> bmiText : Model -> Html msg 
> bmiText {weight, height} = 
> weight / height ^ 2 |> toString |> text 
>
> this way, everywhere you need that textual representation, you can use it. 
>
>
>
>
> On Tue, Jul 25, 2017 at 4:23 AM, Ray Toal  > wrote:
>
>> This might be an opinion-based question so I can't ask it on 
>> StackOverflow. :-)
>>
>> I have a trivial beginnerProgram using the Elm Architecture. It has two 
>> text fields (HTML input elements), one for weight and one for height. The 
>> onInput attributes of each generate a message. The update function accepts 
>> the message and produces the new model.
>>
>> The question is: Should the model (a) consist of the width and height 
>> only, or (b) also include the computed BMI (width / height^2)? If the 
>> former, I compute the BMI in the view function; if the latter, I would 
>> compute it in the update function.
>>
>> Does anyone have a lot of experience with Elm applications that would 
>> lead them to believe that keeping models as small as possible and computing 
>> derived data in the view function is better than making rich models? I 
>> don't have enough experience with Elm to know. I sense that for a problem 
>> as simple as mine it really doesn't matter (and I in fact got it working 
>> both ways), but as I start scaling up my apps it would be nice to know if 
>> there is best practice here (or not).
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> 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] Best practices for designing models in the Elm Architecture - lean or rich?

[Peter Damoc]

Keep derived data in the model if it makes sense to keep derived data in
the model.

If you have an expensive function that runs and computes a derived value
and you would have to call frequently this function in your view, then by
all means, computer the derived value in update and save it in the model.

If you don't run into a performance problem like the above, keep your model
clean and just extract the computation in a function. for example, you
could have something like

bmiText : Model -> Html msg
bmiText {weight, height} =
weight / height ^ 2 |> toString |> text

this way, everywhere you need that textual representation, you can use it.




On Tue, Jul 25, 2017 at 4:23 AM, Ray Toal  wrote:

> This might be an opinion-based question so I can't ask it on
> StackOverflow. :-)
>
> I have a trivial beginnerProgram using the Elm Architecture. It has two
> text fields (HTML input elements), one for weight and one for height. The
> onInput attributes of each generate a message. The update function accepts
> the message and produces the new model.
>
> The question is: Should the model (a) consist of the width and height
> only, or (b) also include the computed BMI (width / height^2)? If the
> former, I compute the BMI in the view function; if the latter, I would
> compute it in the update function.
>
> Does anyone have a lot of experience with Elm applications that would lead
> them to believe that keeping models as small as possible and computing
> derived data in the view function is better than making rich models? I
> don't have enough experience with Elm to know. I sense that for a problem
> as simple as mine it really doesn't matter (and I in fact got it working
> both ways), but as I start scaling up my apps it would be nice to know if
> there is best practice here (or not).
>
> --
> 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.
>



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

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

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Peter Damoc]

On Tue, Jul 25, 2017 at 3:32 AM, Erik Simmler  wrote:

> That said, what if we flip the question around? Given that we have
> facilities for encapsulation (unexposed types), what would we gain by
> adding a new set of concepts around mixing data/logic and syntactic sugar
> in the form of "this"? What would this enable?
>

We could have better polymorphism.  For example, we could have something
like traits.

trait Stringable =
{ toString : this -> String
}

type Msg implements Stringable  =
{ tags = Increment | Decrement
, toString = \this ->
case this of
Increment ->
"Add One"
Decrement ->
"Subtract One"

}

This would allow one to declare something like List Stringable that would
accept all String and objects that can be turned into a string because they
implement the Stringable trait.

We would not have to keep putting toString all over our code but rather
decide at the type declaration level how the string representation of the
type should look.

The same argument can be made for serialization too.

As far as I can see it, the prime target for this would be to implement
web-components like nodes that would be just implementations of some node
interface. Behind the scenes we would still get a single source of truth
but this single source of truth would be generated based on these
implementations. In my view, this would eliminate at least some of the
boilerplate.



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

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

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Peter Damoc]

On Mon, Jul 24, 2017 at 8:50 PM, Dave Ford  wrote:

> A lot of my early work was centered around UIs which made heavy use of
>> inheritance and mutation.
>>
> I really don't think this is related to the original question. The
> original question was not about inheritance or mutation or even about OO.
> It was about "this" and "combining data with logic". Which were described
> as a "systemic problem".
>
> No one (yet) has convinced me that they are even remotely a problem. No
> one has provided an example. Or any logic to support the claim.
>

I think the added complexity to the language that you mentioned qualifies
as a problem. ;)


>  The fact that "this" has nothing to do with immutability is unrelated to
> my experience.


Most programming languages that have a "this" construct allow mutation.
This is what you have to take into account when discussing this. The very
idea of OOP is that you have independent objects that communicate through
messages. This means that you send an object a message and it mutates its
state (if need be). This mutation is achieved through the use of this/self
or a similar concept.

You cannot simply ignore this historical reality.

Sure, we can have a fully immutable object system but this is not commonly
encountered. If Kotlin has something like this it is an exception not part
of the rule.

Once we acknowledge the issue of mutability we can move the discussion
forward and analyze the benefits of having data and behavior together in
the context of immutability.

I too would love to see an argument against having the data and logic
together in the context of immutability.


-- 
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] Immutable data design problem

[Aaron VonderHaar]

Ah yes, a nice complicated system :)   If you're still looking for more
abstract suggestions, here's how I would approach the problem:

It sounds like you're trying to construct intermediate data structures that
directly map to certain domain concepts, and then you later have to
transform that data into a structure that you ultimately need.  I suspect
you may be able to clean it up a bit by focusing on what you need, and not
on what you think you ought to have.

At the boundaries of the system, you have structured input data (perhaps
being decoded from JSON?), possibly structured output data (perhaps being
sent out as JSON?), and the UI view.  In my opinion, those are the most
important types in your system.  Rather than trying to devise a data
structure that's somewhere in the middle of the input and output, I'd focus
on modeling the input and the output data structures in isolation, and then
try to figure out the shortest/most modular route for transforming the data
from one to the other.  If you work in this way, I think you'll tend to end
up with more modular functions (which will also benefit you later, as you
mentioned anticipating having to handle realtime updates to the data).

In what you're describing, the following things stuck out to me:

> AssessmentEvents must in turn have been created by calling
createAssessmentEvent, which takes the independent fields of an
AssessmentEvent and creates the full record with the derived fields

This sounds like it might be premature optimization.  If you didn't already
try this, I'd suggest passing around the original raw fields instead and
exposing the functions that can compute the derived fields.  Furthermore,
try having those functions take only the things that are needed for that
exact calculation, rather than taking the entire AssessmentEvent record as
an input parameter.  Doing this will help expose the actual dependencies in
your data and avoid unnecessary coupling with the "AssessmentEvent" concept.

> when outside code needed to get the delta value, it couldn't just have an
AssessmentEvent. It would have to have an AssessmentStore (or Parcel) and
an EventID

I would work backwards here and start with what data structure makes sense
in the view, and then write the code to generate that from the raw data,
and then see if there are logical groupings that make sense to refactor out
as data types/modules (as opposed to starting with the domain concepts you
think you are supposed to have and trying to write your view to work with
those).

Does your view just want a list of things to iterate through and display?
If so, it sounds like you want to give it a list of records that have all
the necessary data assembled so you can just iterate through it.  Or do you
have some kind of master-detail view where one view is showing the details
of a thing that is chosen in another view?  In that case you might want to
have the selector view produce an Id that's stored in the model and used to
later request a specific item to be calculated for the detail view.  Or
maybe different parts of the view show different pieces of information,
each of which is hard to compute?

In either case, I'd try writing your view the way you want it, then write
the function to transform the data how you need it, and then decide whether
that function (or parts of it) make the most sense in the view module or in
one of the data structure modules.


Overall, my suspicion is that you might be trying to specific domain
concepts that you are expecting to have but are possibly unnecessary for
what you need to do.  So it might be useful to try to cleanly model the
input data and the data you want to display, then write the functions to
map between then, and only then figure out how those functions map to your
business domain as you refactor.  Based on what you described, it sounds
like Parcel, AssessmentEvent, and Property are all getting quite
interconnected.  If you instead try to focus on transforming from input to
output as directly as possible, I think you'll end up with a system that's
easier to modify or reconfigure later.  (The downside is that it may seem
unnatural to people who are used to thinking in terms of the standard
business domain concepts.)

I'll note that the suggestions here match the way I personally like to
approach problems, which is to focus on iteratively discovering the
interfaces.  If that style doesn't match the way your team works, you
should disregard :)

Also, would be happy to look at some type annotations if you want to talk
more concretely.

On Mon, Jul 24, 2017 at 4:02 PM, Lyle Kopnicky  wrote:

> Hi Aaron,
>
> Thanks for your thoughtful reply.
>
> The domain model is pretty complex, so it's hard to distill down to a few
> issues. There's a higher-level structure called a Parcel. That already
> contains, among other things, the list of AssessmentEvents. I have a
> function called createParcel that takes a record with a parcel number,
>