I am not trying to draw up a list of things that I think Evan should fix, nor do I have any expectation that he would, or would appreciate being given such a list. The things that interest me most, are the things that we can try and solve independantly.
I am working on my private package server, but have written a spec for it that describes the full extent of what it will be in its first incarnation. I want to understand more fully the problem that Elm has in interfacing into the world of professional work more widely and see if that informs my thinking around what direction I can push in towards that end. Also, the results may help inform others thinking around what they can do.
I find the N+1 conversation about this, where people pitch in with their ideas but nothing comes of it a little pointless, a distraction at best. Hence the reason for the risk based approach, which is analytical, and not just based on feelings, opinions or sounding off. Gather information - Analyze - Act.
My guess is this will confirm that some of the hardest issues to solve will remain unresolved - are they the most important issues though? And at the levels below that, there is some interesting stuff, that is fixable.
I personally look forward to many years of working with Elm and to its future evolution. It has certainly changed my programming life for the better and enabled me to be far more productive.
I got started in software development with Angular and Ruby, and learned a lot with them. But among the positive lessons was another one: how difficult it can be to grow and maintain a large codebase: hours or days spent tracing runtime bugs back to the source, then fixing the source without breaking something else, etc. In Elm, runtime errors basically don’t exist, and the type system and compiler make refactoring it a pleasure, not an anxiety-producing ordeal.
I believe that the economic benefit of making easy code changes and refactoring in Elm is underappreciated. These tasks take time, and for business, time is money.
I think a very good response to compiler closed, can’t call JavaScript directly, is that nobody has forked the compiler and created an alternative. It feels that won’t be much work (16 hours??) and can be used as plugin, and probably fairly easily maintained when incorporating new features.
Given that this hasn’t happened, it seems to me this indicates these features are not pressingly needed in the community. It’s more the it would be nice scenario.
Well, you can’t call synchronous JS directly. Sending a message to JS and back is possible. For myself, I use code like my SimpleJS or someone else had a similar idea before, elm-eval. For small code I am thinking of creating a string with JS-code on Elm, send it trough port, use eval() on JS, and send the result back.
I really wish to have all “pure” JS-functions (without side-effects) available in Elm, especially for internationalization, but I have no idea, how to match JS-Objects to Elm without a type for it, like Json.Encode.Value, but with the guarantee, that functions keep intact, when stored in Elm.