On Thursday, 29 December 2016 02:02:10 UTC+7, Josh Adams wrote: > > I don't love the idea of furthering this thread, but felt I'd take a swing > at something I think is kind of core to the Elm community (and has been > communicated as such): > > - There is a limited amount of time that can be spent on Elm (this is > true of all things) > - To maximize the benefit/time ratio of work being done, it is best to > have a motivating use case to identify actual use cases that are > problematic. > - Once one has been identified, writing up a short (because there's > limited time, again) explanation of the real world problem that you are > experiencing, coupled with an SSCCE <http://sscce.org/>, is the best > way to communicate the problem you're having - both the motivating use > case > and the initial work that's gone into identifying the core problem. > > *Inside of this framework*, I've seen extremely meaningful discussions > occur. *Outside of this framework*, I've witnessed a lot of threads that > serve to rile people up but don't meaningfully benefit the language. > > I would love a do-over of this thread. If you have a real-world problem > that you can share with us, we can all work on seeing what we can do to > help. If you don't, we'll talk about micro-optimizations. > > As one example, Noah mentioned that there was a real-world problem related > to this, and by modeling the data in a slightly different way they were > able to solve it. If we had a similar situation perhaps a similar result > could ensue. > > My $0.02. (given the number of words, it seems my opinions are *cheap*) >
Joshie, your words are good, but I actually got out of the thread what I wanted: 1. I have a real world problem of performance of Elm doing specific types of problems involving intense math. 2. I submitted here an small example showing that for any kind of tight loop that Elm produced code that can be five to ten times slower than JavaScript. 3. I suggested that the compiler might be able to produce better code with not too extensive changes. 4. The answer from several knowledgeable contributors is that, yes, the compiler can be improved, but that it is a huge project and not likely to happen soon. 5. From there, several have suggested that in the interim, the only solution is to call more efficient code written in JavaScript (or of course it could be written in TypeScript or Kotlin with the JavaScript backend). 6. Problems in doing that were raised, primarily with the difficulty in calling ports and getting results through subscriptions. 7. A solution was suggested that shows it isn't that hard if it works. 8. Further details on his problem were provided by Mark, with the general idea that there needs to be provided better documentation and libraries supporting farming out asynchronous work to Task's, which standardization isn't probably ready yet due to the state of the Process definition. His further refinements to Elm are unlikely to be implemented soon. 9. For my purpose and the reason I opened the thread, I have the best answer available right now if it works: farm out the computational intensive work to JavaScript with the discussed method. 10. I will test that capability and report back. Even if this method works, the interim method means I have to produce JavaScript code which I understood that the purpose of Elm was to avoid. If one still has to write large parts of the code in JavaScript for this particular application, one then starts to ask why not use TypeScript directly (c#'ish syntax) or Kotlin with the JavaScript back end (more concise, can be very functional in use, quite a bit more advanced stage of development than Elm). For me, these are the implied questions this thread raises. -- 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.
