I think we have two general trains of thought regarding development here. One is YAGNI. Let things grow organically. Refactor when it gets messy.
The other is Build for Success. Over engineer because you will probably end up shipping the prototype and once you do it will be too late to go back and do major restructuring. Each has its place. Each builds for particular outcomes. Each can succeed or fail in spectacular and unique ways. With great effort, each can emulate the advantages of the other — ignoring the fact that the advantages are often in terms of not needing as much effort. To the extent that we live in a world where we all say "you're free to develop software however you see fit", we can often take the attitude. "That's interesting. It wouldn't work for me but I see why you are making those choices." Where this turns ugly is when it ceases to be about approaches we individually find valuable but about how everyone should work. Let's look at this thread. It was instigated by Marek's "components" package which got some discussion on elm-dev and which I moved over here to elm-discuss. The structure camp was essentially looking at this and trying to judge whether it would help with their own structural work. The YAGNI camp joined in and said in bold text: "*a Model-View-Update triplet is the wrong unit of composition for Elm applications."* Not, "I (or we) haven't found it useful" but "it is wrong". So, now we're off to the races. The structure camp says (in many more words) "I've seen your alternative and it isn't a real alternative. It's a pathway that decades of software industry experience indicates leads to creating big balls of mud." The YAGNI camp can argue that its statements are strongly worded in the interest of keeping beginners away from excessive complexity. The structure camp can argue that it needs to be vocal so that beginners understand the mess that they may get themselves into on a refactor only as needed path. Mark On Wed, Apr 19, 2017 at 2:30 PM, Yosuke Torii <[email protected]> wrote: > Richard, > > >> Can you think of a way to use this overloaded word in a way where the >> people in the discussion are not confused by it, even though they think it >> means different things? > > > I don't know. I just answered the question why I received your message as > "DIY every time". I'm not looking for the alternative for "component" . > > I covered how to grow Elm application code bases >> <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbuu0m4/>, >> and Evan covered reuse <https://guide.elm-lang.org/reuse/>. >> What is the remaining problem? :) > > > Again I agree to how to break the monolith and when to do it. But is any > of those reusable things non-TEA? I find UI libraries at > packages.elm-lang.com but they are often written in TEA manner. If it is > not simple, how can they be instead? > > Sorry if you have already explained enough. Honestly it is hard to read > whole of messages, as Noah said. > > > Peter, > > The problem is that this approach makes it impossible (as far as I could >> see) to implement the components that need side effects (like the old >> RandomGif list) > > > Yeah, I know. But at least, some of the UI widgets that does not have > side-effects can be solved. As far as I can see, the discussion here is > not on this stage yet. > > I think something like `mapWithCmd : (a -> Cmd msg) -> Html a -> Html msg` > would solve it. The problem is that it allows any kind of side effects > including HTTP. But I don't find good explanation of why HTTP via view is > bad while random (or time stamp too?) is OK. > > > 2017-04-20 5:40 GMT+09:00 Peter Damoc <[email protected]>: > >> >> >> On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii <[email protected]> >> wrote: >> >>> I'm curious what makes it sound that way, since as you noted, that is >>>> not the point I'm making. >>>> >>> >>> I don't know if others feels like me or not. But at least for me, "no >>> components" sounds a bit confusing (it is in official guide too). >>> >> >> I view it as destructive so, you're not alone in seeing something not OK >> with that. >> >> >>> Also, "no components, no nesting TEA" does not answer the problem >>> discussed here. So how can we do instead? Maybe introducing sortable-table >>> pattern is more constructive for this discussion. I think it is a variant >>> of TEA, managing its own state, but still keeping the form of "reusable >>> *view*". So great! >>> >> >> the sortable table is a clever component that pushed the external call to >> update inside the view. >> You still need what used to be the ChildMsg tag but now instead of >> calling the Child.update and saving the state it receives the updated >> state and just saves it. >> >> Other than the update trick, it's more or less the same thing as the old >> MUV triplets. >> You can even use the pattern to do nesting. >> >> The problem is that this approach makes it impossible (as far as I could >> see) to implement the components that need side effects (like the old >> RandomGif list) >> >> >> >> >> >> >> -- >> There is NO FATE, we are the creators. >> blog: http://damoc.ro/ >> >> -- >> 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/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. > -- 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.
