5 ms·

I think there’s a very weird mismatch between the way the core language people are pushing for the adoption of the language, and then at the same time they will

by Tehnix 8y ago

I think there’s a very weird mismatch between the way the core language people are pushing for the adoption of the language, and then at the same time they will turn around and say “we’ll, it’s not even 1.0, yet, so what’d you expect”. The way Elm is developed is fit for a language that has little to no users, and can take going so long between updates, that remove escape hatches needed to fill out the immaturity of the language. It really saddens me to see it go like this, because I once had high hopes for Elm. Nowadays I see it purely as a stepping-stone into more advanced languages like PureScript and Haskell. Elm is there to hold your hand, but it seems it has no intention of ever taking you further than the basics.

dsiegel2275 8y ago
> remove escape hatches needed to fill out the immaturity of the language I think you mean "immaturity of the platform". Also, native modules weren't the only "escape hatch". An Elm application can communicate with JS through ports.
- k__ 8y ago
  Complicated interop with JS also broke Darts back.
  - pjmlp 8y ago
    Politics broke Dart's back.
    - k__ 8y ago
      Sure, the bad JS interop had to come from somewhere.
- AlexCoventry 8y ago
  What was the capability of native modules which enabled the dev.to essayist to use them, where ports would have been unreasonable ("there is no other reasonable way to do what I need")?
  - always_good 8y ago
    Ports are an asynchronous interop boundary. You basically subscribe to a port from Javascript and attach a callback to handle data as it passes from Elm -> JS. Javascript errors then are relegated outside of Elm or they fail at the boundary (like serialization errors when passing data from JS to an Elm port). They're kept outside of Elm. Native modules, on the other hand, let you create Elm functions that synchronously call Javascript. That means that what look like regular Elm functions can now synchronously blow up at callsite inside Elm. The first native modules I saw in the wild as a beginner were people making shortcut functions for things like `Math.random()` instead of the proper way of threading a random seed into the entry point and keeping it in the model which has various benefits. Same with quick access to "Date.now()". From this perspective, you can see why native module access was removed, and especially why you needed permission to publish a native module Elm's package repo. Native modules are tempting because they are easy, but widespread use eliminates one of the major upsides of Elm: no runtime errors inside Elm, or rather the ability to boundary them. However, some forms of JS interop are hard or impossible without synchronous FFI, 1:1 JS library wrapping being the most obvious example. Having to use asynchronous ports for that is like wrapping a Javascript library's sync functions with an EventEmitter. You emit an event and then listen for the resulting event. Maybe you even decide to pass in a messageId echo for request/response reconciliation (I've seen people build this abstraction around Elm's ports!). On one hand, a lot of people have the idea that because they are using Elm, they shouldn't have to write any Javascript at all. After all, this is what many compile-to-JS languages give you. And on the other hand, no more synchronous FFI means that some Elm apps that exist today cannot move ahead, and some people think the approach is too heavy-handed or they disagree with the direction. In my experience, Elm is best seen as a way to build a functional core that you wire up to an external world of Javascript. For example, a game simulation that emits game states over a port, and you write Javascript to render those updates with a JS library like Pixi.js, resisting the temptation to wrap Pixi.js in Elm and calling it from Elm.
    - heavenlyhash 8y ago
      > you needed permission to publish a native module Elm's package repo. See, this, to me, sounds quite reasonable. A feature is potentially dangerous to the rest of the ecosystem if encountered unexpectedly: therefore, we put some extra friction on sharing code which uses those features, and made it an obvious and opt-in process if you wished to take that potential danger into your project. Great! Given that... why on earth would it be necessary to remove the feature from the language entirely?
erokar 8y ago
What you term the "immaturity of the language" is imo a well thought put focus on simplicity. It was never Elm's intention to reach the complexity of Haskell or indeed PureScript. I think that was a sound decision.
- iodiniemetra 8y ago
  That's not the takeaway that you should have - simplicity doesn't matter if minor language versions make breaks.
  - knewter 8y ago
    it was a rewrite of the compiler in a pre-1.0 language trying to find its preferred API. you shouldn't be surprised it broke stuff, especially when literally every thing about native explained it was a private unsupported API. calling this a minor release is idiotic and you're just mad because they took away a thing they promised to take away and said you shouldn't use.
    - alluro2 8y ago
      While I agree about it being ok to break things at this stage, some of the words in your reply were a bit confusing - what do you mean a "private unsupported API" in an open source project? Kind of supports the notion that this is a private group project and others can use it, but are not welcome to participate. Also, if calling this a minor release is idiotic, why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes.
      - Zyst 8y ago
        In semver versions before 1.0 are prerelease versions.
      - uryga 8y ago
        GP probably meant something like "an internal API that's exposed in case you need it but gives no guarantees about stability because it's still evolving"
deleted 8y ago
[deleted]
vmchale 8y ago
At this point it's barely a stepping stone. I'd recommend just diving in to Haskell or the like head-first so you learn the tools you'll actually use. When you update this quickly (and for no reason), the learning resources go out of date too.

by Tehnix 8y ago

dsiegel2275 8y ago

> remove escape hatches needed to fill out the immaturity of the language I think you mean "immaturity of the platform". Also, native modules weren't the only "escape hatch". An Elm application can communicate with JS through ports.

k__ 8y ago
Complicated interop with JS also broke Darts back.
- pjmlp 8y ago
  Politics broke Dart's back.
  - k__ 8y ago
    Sure, the bad JS interop had to come from somewhere.
AlexCoventry 8y ago
What was the capability of native modules which enabled the dev.to essayist to use them, where ports would have been unreasonable ("there is no other reasonable way to do what I need")?
- always_good 8y ago
  Ports are an asynchronous interop boundary. You basically subscribe to a port from Javascript and attach a callback to handle data as it passes from Elm -> JS. Javascript errors then are relegated outside of Elm or they fail at the boundary (like serialization errors when passing data from JS to an Elm port). They're kept outside of Elm. Native modules, on the other hand, let you create Elm functions that synchronously call Javascript. That means that what look like regular Elm functions can now synchronously blow up at callsite inside Elm. The first native modules I saw in the wild as a beginner were people making shortcut functions for things like `Math.random()` instead of the proper way of threading a random seed into the entry point and keeping it in the model which has various benefits. Same with quick access to "Date.now()". From this perspective, you can see why native module access was removed, and especially why you needed permission to publish a native module Elm's package repo. Native modules are tempting because they are easy, but widespread use eliminates one of the major upsides of Elm: no runtime errors inside Elm, or rather the ability to boundary them. However, some forms of JS interop are hard or impossible without synchronous FFI, 1:1 JS library wrapping being the most obvious example. Having to use asynchronous ports for that is like wrapping a Javascript library's sync functions with an EventEmitter. You emit an event and then listen for the resulting event. Maybe you even decide to pass in a messageId echo for request/response reconciliation (I've seen people build this abstraction around Elm's ports!). On one hand, a lot of people have the idea that because they are using Elm, they shouldn't have to write any Javascript at all. After all, this is what many compile-to-JS languages give you. And on the other hand, no more synchronous FFI means that some Elm apps that exist today cannot move ahead, and some people think the approach is too heavy-handed or they disagree with the direction. In my experience, Elm is best seen as a way to build a functional core that you wire up to an external world of Javascript. For example, a game simulation that emits game states over a port, and you write Javascript to render those updates with a JS library like Pixi.js, resisting the temptation to wrap Pixi.js in Elm and calling it from Elm.
  - heavenlyhash 8y ago
    > you needed permission to publish a native module Elm's package repo. See, this, to me, sounds quite reasonable. A feature is potentially dangerous to the rest of the ecosystem if encountered unexpectedly: therefore, we put some extra friction on sharing code which uses those features, and made it an obvious and opt-in process if you wished to take that potential danger into your project. Great! Given that... why on earth would it be necessary to remove the feature from the language entirely?

erokar 8y ago

What you term the "immaturity of the language" is imo a well thought put focus on simplicity. It was never Elm's intention to reach the complexity of Haskell or indeed PureScript. I think that was a sound decision.

iodiniemetra 8y ago
That's not the takeaway that you should have - simplicity doesn't matter if minor language versions make breaks.
- knewter 8y ago
  it was a rewrite of the compiler in a pre-1.0 language trying to find its preferred API. you shouldn't be surprised it broke stuff, especially when literally every thing about native explained it was a private unsupported API. calling this a minor release is idiotic and you're just mad because they took away a thing they promised to take away and said you shouldn't use.
  - alluro2 8y ago
    While I agree about it being ok to break things at this stage, some of the words in your reply were a bit confusing - what do you mean a "private unsupported API" in an open source project? Kind of supports the notion that this is a private group project and others can use it, but are not welcome to participate. Also, if calling this a minor release is idiotic, why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes.
    - Zyst 8y ago
      In semver versions before 1.0 are prerelease versions.
    - uryga 8y ago
      GP probably meant something like "an internal API that's exposed in case you need it but gives no guarantees about stability because it's still evolving"

deleted 8y ago

[deleted]

vmchale 8y ago

At this point it's barely a stepping stone. I'd recommend just diving in to Haskell or the like head-first so you learn the tools you'll actually use. When you update this quickly (and for no reason), the learning resources go out of date too.