Marek
This reply is only to my part. Did not read other parts.
> Maybe you've noticed that I haven't commented your example with
> reusability. That was on purpose because telling when and on what you
> should use it is completely different topic. For sure it can be used for
> integrating community components. It can be used anytime you're using
> Cmd.map Html.map and Sub.map. That's actually beauty of abstraction that it
> can be applied regardless of your domain. Same way s you can List.map view
> over List of data to turn them into view you can use this to map date
> picker's api to app and anything else. My intention is not telling anyone
> when and on what to use it. It's just super thin helper for doing (a, Cmd
> b) -> (c, Cmd e) with the use of functions.
I'm strongly against this way of thinking.
Telling nothing about who to use, when to use or what to use for is
the *easiest
*way. But does it make anyone happy? As you say, we can use Cmd.map,
Sub.map and Html.map everywhere but we are happy with the fact `view`
function does not return `Cmd msg` so you can say there must be no side
effects in view.
"That's actually beauty of abstraction that it can be applied regardless of
> your domain."
Yes it *can *be, but *should not* be. We (...not every one but at least
many of us including me) found NOT everything is a component. The old TEA
document was doing just like you; "There is a pattern that is sometimes
useful". I thought "oh cool, everywhere in my app should be organized like
this" ...and I regretted it later. Things got needlessly complicated. For
example, some components required many options like { onSelect, onChange,
... } and the parent component just translated to that layer's msg. But
actually that component was used only once. I refactored that component to
have some knowledge about the application and the code got significantly
simpler than before. After that, I've get that better habit to think like
"okay, this is just a view, no need to have state for now".
It's just super thin helper for doing (a, Cmd b) -> (c, Cmd e) with the use
> of functions.
Maybe you need this function? This is thinner.
andThen : (model -> (model, Cmd msg)) -> (model, Cmd msg) -> (model, Cmd
msg)
andThen update (model, cmd) =
let
(newModel, newCmd) =
update model
in
newModel ! [ cmd, newCmd ]
This function enables separating concerns so you can apply many operations
one by one. I'm recently using this and now `update` function is cleaner
than ever. If your core problem is this, this might be the answer, not
components. So I wanted to know what concrete problem you are really want
to solve.
2017-04-20 23:22 GMT+09:00 Marek Fajkus <[email protected]>:
> Richard,
>
> What I'm saying is that *individual functions*, as opposed to *a group of
>> functions and data structures* (model, view, update, msg, etc) is the
>> right unit of composition.
>
>
> I struggle to understand to see where is a difference. Html.program
> constructor is record of functions as well. Sometimes it's just nicer to
> have arguments named. Also as docs and code clearly says it's just
> composing functions, nothing more. init with init, update with update... I
> think saying that pure function inside record is by any mean different than
> pure function living in module's namespace is really misleading. For
> instance this using elm-decode-pipeline
> <http://package.elm-lang.org/packages/NoRedInk/elm-decode-pipeline/3.0.0/Json-Decode-Pipeline#required>
> you're lifting (operation called pure in Json.Decode it's succeed)
> function (usually type constructor) to `Decoder` context. And it's fine
> because this is how functional programming work.
>
> You have mention experience with teaching beginners on many occasions.
> That's fair point I don't have that much experience teaching beginners
> however I have quite a lot experience with folks doing side project in elm
> being scared of complex apps.
> For instance our HR have contacted Tomas <https://twitter.com/tomaslatal> just
> few days ago. Since he knows me from elm community meetups he DM. We're
> both czech (and was speaking czech) so I have to translate it (adding
> original and translation:
>
> czech:
>
>> No na to zatím nemám :) jsem Funkcionalni lama :)
>
>
> english:
>
>> I can't do this :) I'm not that skilled in functional programming
>
>
> Than I spend 2 hours trying to convince him that there is nothing to be
> afraid of.
>
> Just on this Tuesday he wrote me again without previous warning (this is
> before interview which he will have next week):
>
> cze:
>
>> Třeba se to vyřeší samo a nevezmete mě. Alespoň pak naboucham nějaké
>> zkušenosti do zásoby na příští kolo ;)
>
>
> eng:
>
>> Maybe it will resolve itself and will not hire me. At least I will have
>> time to gain more experience on next round.
>
>
> *THIS IS COMPLETELY CRAZY!*
>
> We've already lost one talented guy because he was afraid that he won't be
> able to do anything on such scale! From my experience it's easier to hire
> js developer and teach him elm than to hire folks from community because
> they are so afraid when we show them js implementation we're porting.
>
> Yosuke,
>
> So Marek's library is for organizing entire app, not about using external
>> library.
>
>
> Maybe you've noticed that I haven't commented your example with
> reusability. That was on purpose because telling when and on what you
> should use it is completely different topic. For sure it can be used for
> integrating community components. It can be used anytime you're using
> Cmd.map Html.map and Sub.map. That's actually beauty of abstraction that it
> can be applied regardless of your domain. Same way s you can List.map view
> over List of data to turn them into view you can use this to map date
> picker's api to app and anything else. My intention is not telling anyone
> when and on what to use it. It's just super thin helper for doing (a, Cmd
> b) -> (c, Cmd e) with the use of functions.
>
> What I think...
>
> Richard
> is building software for learning kids (which is actually ethically super
> important mission in my opinion) where initial idea, first prototype and
> final feature might looks really really different. I can imagine this might
> be a lot about exploration and validating and reevaluating ideas. I also
> think you did mention this in one of your talks but I can't remember which
> one it was. Logically there you see value of system that is easy to reshape
> and many language features helps you there. Honestly this is really
> building ball of mud but the point sometimes there is nothing wrong with
> that.. Mud can be reshaped in few minutes. The really crazy idea in your
> field would be to do DDD since that domain is so loosely specified.
>
> Mark
> on the other hand values design patterns and architectural thinking. He
> has experiences with identifying critical concerns up front by
> analyzing obviously pretty deterministic domain. In his view of
> development there're is really not time involved. His problem didn't change
> over night he is analyzing problem which is observably same each time you
> look at it. I also think he might be into DDD (Domain Driven Design).
> Personally I'm most of the time pretty skeptical about DDD and has many
> arguments with our CTO who is also fan of DDD.
>
> Me
> For me the important thing is separation of concerns. This is actually why
> we're reimplementing that app in first place. The biggest cost in our case
> is when any new feature breaks anything existing. By that cost I mean we
> will rather send for times that much on new feature rather then being able
> to break existing one. This is due to the fact we're working with data
> where slight bug in sorting in case of some weird state in analytics tool
> <https://knowledge.globalwebindex.net/hc/en-us/articles/115001735345-How-To-Chart-Builder>
> can resolve with switched order in exported data which is then big issue
> for many other people like data scientists which are using that data for
> testing machine learning modeling and have unpredictable results (that
> actually happened in past). I would go even further and intentionally make
> it hard to reshape system any any way that might lead to some
> unexpected side-effects. Anyway I don't think this is real point. Real
> point is that there is value of separating concerns.
>
> I don't know what's the point of Richards way of argumentation. I have a
> feeling that he is trying to convince me about something he's not able to
> explain.
>
> Claim composing function is good, composing init/update/view is bad is odd
> because:
>
> - obviously using functions is good there's no even need to say that
> - init/update/view are functions too
> - right from beginning I made it 100x clear that this is tiny
> abstraction you can use to simplify composition of update and init. That's
> assuming you want to do it in first place.
>
> I don't see any real value about continuing in this direction. Anyone is
> trying to convince me about something he can't even name. Also I want to
> point out that I've found usage of term agile quite to be quite odd
> <https://www.youtube.com/watch?v=a-BOSpxYJ9M>. I really don't see point
> in bringing that to this conversation.
>
> With that I really apologize if this sounds mean in any way but I'm not
> willing to comment anything in this thread anymore. But head ups everyone.
> I hope we can still tolerate and respect each other and rather focus on
> what we can do for community beside flaming.
>
>
> --
> 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/Lo6bG96zotI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
