I've already hit the problems. I'm trying to rebuild the successor to some past systems in Elm and one thing we learned on those systems was that to get good performance it was critical that we prioritize HTTP fetches so that we didn't ask for the low priority items at the same time as the high priority items. From a correctness standpoint, the particular fetches are a local problem and the Elm architecture provides a reasonable way to route those. But the prioritization is a global problem. To go with that, I need cancelation support because that's the other key piece in getting responsiveness and what that means in practice is that if something hasn't left the queue yet, I need a way to cancel it. What are the Elm design patterns to deal with this sort of local v global situation?
What I'm hearing is, "just build a big program and worry about it later". It may be that Elm manages to let things scale further than in the past but that wouldn't really be anything new. Wirth's Pascal had no modularity. But we've learned as an industry that the ability to modularize code helps with reasoning about it — a small module can be subjected to the sort of thorough code review that a large one can't — and helps with keeping programmers out of each others way. Team scale is a problem that I'm also already looking at. While Elm may scale up to monolithic code bases better than some languages, I strongly doubt that it's brought some new magic to the table that makes modularization and separation of concerns irrelevant. So, the question is, what practices should we be keeping in mind so that the codebase doesn't eventually just become so huge that it can't move and adapt? What patterns and architectures should apply to code written now so that it can be modularized down the road? Mark On Fri, Aug 26, 2016 at 12:02 PM, Josh Adams <josh.ruby...@gmail.com> wrote: > Before committing to a new framework like Elm, one would first like to >> know that it can be scaled, how it can be, what will be necessary to >> refactor code to make it scalable and what pitfalls one could have avoided >> in the first place that may become big problems later. I feel more >> comfortable about the start simple approach once I've got that figured out. >> > > So...it's super nice and scalable. Use us as arguments from authority > (not that I'm a huge authority on this or anything, but I've built enough > large systems (billions of dollars in transactions per year, etc) in other > languages and done enough elm that I'm entirely convinced. The problem > stems from people *really* wanting to invent a problem before they've hit > it. I did it too early on in Elm. And I was mad when I got responses like > this. > > Then I breathed a bit and though "huh these people have been doing it for > a while, why don't I just take their advice and see how it goes". And it > was glorious. > > -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. > -- 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.
