I also feel like Evan is misrepresenting the implications of business pressure on the language a bit. His fear seems bound to how a “bad” business might manage a language, which is definitely realistic of course. But I’ve personally only been fortunate enough to work for “good” employers, who I think would tackle it differently. For example, if there is business pressure to achieve some goal, then a good business wouldn’t necessarily care about whether something is a feature of the language or not. You just need to be able to explain why the decision to not change the language is still the right move, both short term and long term.
Additionally, if a business were to apply pressure towards getting e.g. web socket support in Elm, then a good business wouldn’t necessarily say “it must be integrated directly in the language”, but could say “we need the tools to be able to create a library for this”. Which is something everyone would benefit from, without bloating the language. Similarly, there might be business pressure to add better protocol buffers support in Elm, but that could also just as easily mean better libraries or better tools (or both).
Heck, there are probably still some business out there who would like to pay just to make sure some some bugs fixed and other maintenance work gets done.
So generally I don’t consider business pressure bad, it just depends on how that pressure is managed. And actually, I think having no pressure at all to make changes is only possible if nobody uses a language or nobody cares about it.
Have to say that the pseudo-economics felt a bit pompous. The Elm community has offered to provide a lot more input to the core elm language and generally been rebuffed, or just ignored.
Unfortunately this doesn’t help put food on the table, and takes time away from Evan doing other language work. So not sure how this helps the points he makes.
I think it’s clear that Evan has been thinking about the client/server relationship and data interchange for a while and has wanted to provide something “delightful and reliable” (i.e. better than JSON + decoders).
Yes, its one thing to use JSON to communicate between Elm and Javascript, where it makes the most sense. I tend to think of Decoders over Value as opposed to over a String as windows into the javascript side - since they don’t actually really do anything other than runtime type checking what you are bringing over.
Talking to the server side using JSON on the other hand - you can see how that came about since before JSON was popular there were XML based web services standards evolving mostly out of the Java space (ugh!). So much easier to read and debug JSON. I do like JSON for development and debugging purposes due to its simplicity.
But of course once you have all the details correct switching over to a compact binary format just makes a lot more sense for conserving bandwidth. And with good data modelling, code gen and debug tooling skipping out JSON and going straight to the binary formats could be made to be just as simple as using JSON.
Perhaps Elm might be improved by allowing us to be more agnostic about the actual encoding used, whether its JSON, String, binary or whatever. That is, can some of the same code be used to implement encoders/decoders to multiple formats. I have not had the time to really investigate it, but I think that is what the elm-morph 3.0.1 from @lue-bird is aiming at? Code gen is another approach.
I was reading a post about ubuntu’s community and remembered this thread. Below is my understanding of the post overall structure related to the Elm community:
community wisdom
collective ownership
modular problem-solving
incremental success
empowering future leaders
scalability and growth
work-life balance
I’m not sure whether this is off-topic or not, but I saw these characteristics in my exposure to Elm during past 32 month.
community wisdom
empowering future leaders
work-life balance