>
> But compared to other compile-to-js languages, Elm is seemingly the one
> that puts the most the hurdles ahead of easily using the libraries
> available in the world's most popular language.
You are correct. Elm is harder to interop than most other compile-to-js
platforms. That's because Elm tries to guarantee that all user code is pure
(as in pure functions). This makes Elm apps continue to be evolvable and
refactorable despite adding new features. Using native code throws away
Elm's guarantees, so it is discouraged. Using ports (the blessed way to
interop) maintains the guarantees at the border, but it has trade-offs as
you've noted in the original post.
Unfortunately, interop is a hard problem to solve while keeping Elm's
benefits intact. WIP.
On Sunday, March 26, 2017 at 2:57:11 PM UTC-5, Simon wrote:
>
> Ok, I hope that this is just a naming change, but spent too much time in
> politics not to fixate on choice of language issues!
> But compared to other compile-to-js languages, Elm is seemingly the one
> that puts the most the hurdles ahead of easily using the libraries
> available in the world's most popular language.
>
>
>
> On Saturday, 25 March 2017 02:52:20 UTC+1, Kasey Speakman wrote:
>>
>> Yeah, I regretted posting that 2nd half. I don't use any native modules
>> myself except the one to return decoders out of ports. And I was getting by
>> without it via ports, although somewhat less optimally. Maybe some people
>> really need native stuff, though. I haven't. (And I'm willing to monkey
>> patch what I use native for now if need be.)
>>
>> On Friday, March 24, 2017 at 1:48:01 PM UTC-5, Kasey Speakman wrote:
>>>
>>> Indeed, the post mentions renaming Native to Elm.Kernel and ending the
>>> native module whitelist (sortof). Expectation management.
>>>
>>> User native module blocking was not mentioned. In our current Javascript
>>> ecosystem such a thing would make Elm non-viable.
>>>
>>> Well, except that repo-forking and monkey-patching exist.
>>>
>>> On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:
>>>>
>>>> On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>>>>>
>>>>> It's pretty clear that these practices are frowned upon, but the shift
>>>>> to 'kernel' sounds like a plan to squeeze the pragmatic programmer's
>>>>> options further. I hope that's not the case.
>>>>>
>>>>
>>>> I think all that is happening is that Native is being renamed to Kernel
>>>> to reduce confusion. At the moment when we say 'Elm' and 'native' in the
>>>> same sentence we could mean an Elm Native module used to implement its
>>>> kernel, or native javascript code through ports.
>>>>
>>>> I can't be certain of the details but I think your function would just
>>>> be re-written as:
>>>>
>>>> var _user$project$Kernel_Msgpack = function() { ... }
>>>>
>>>> But you won't be able to publish it officially and will have to use
>>>> elm-github-install.
>>>>
>>>> It makes sense to me anyway, the 'kernel' needs to be carefully managed
>>>> as the language takes shape.
>>>>
>>>>
--
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.
