3 ms·

Opinionation is often useful but it's best implemented with an escape hatch of some sort for when you run into a sufficiently weird situation there's not actual

by mst 4y ago

Opinionation is often useful but it's best implemented with an escape hatch of some sort for when you run into a sufficiently weird situation there's not actually a sensible way to deal with it. I don't particularly mind if a project holds their opinions sufficiently strongly that they mark the escape match big red letters with "BY USING THIS YOU ARE VOIDING YOUR WARRANTY, IF IT BREAKS YOU GET TO KEEP BOTH HALVES" and then tapping the sign any time somebody asks for support with using it, but it should still -exist-.

hgsgm 4y ago
The escape hatch is Haskell. The only reason Elm exists is to remove escape hatches from Haskell.
mejutoco 4y ago
The escape hatch of elm is the ports system to interface with javascript.
- mst 4y ago
  Ports is explicitly async and therefore only viable for a significantly limited subset of purposes. This has been discussed at length elsewhere in this thread, on elm related discussion boards, and in multiple articles. Ports is the -preferred- way to interface with javascript, certainly, and when its inherent limitations aren't a deal breaker, its being preferred is entirely sensible. It is not, however, an escape hatch in any meaningful way, hence why people were extremely upset when the actual escape hatch was disabled by maintainer fiat.
  - mejutoco 4y ago
    I guess I am less strict with what I consider an escape hatch. It does not need to be optimal or follow my preferred method IMHO. Other than performance I do not see any limitation of the async port system. You can call back from the js side. It is an especial way, I agree, but one that keeps the Elm paradigm intact. It is quite clever. It is "different", but I do not consider that a limitation, but a matter of preference.
jopsen 4y ago
I think it's also fine to just say no when people ask for an escape hatch. Say, no and tell them use another tool. Not every tool, has to solve all problems. But I do think people should spend more time articulating what their tools don't do, rather than what they do :)

by mst 4y ago

hgsgm 4y ago

The escape hatch is Haskell. The only reason Elm exists is to remove escape hatches from Haskell.

mejutoco 4y ago

The escape hatch of elm is the ports system to interface with javascript.

mst 4y ago
Ports is explicitly async and therefore only viable for a significantly limited subset of purposes. This has been discussed at length elsewhere in this thread, on elm related discussion boards, and in multiple articles. Ports is the -preferred- way to interface with javascript, certainly, and when its inherent limitations aren't a deal breaker, its being preferred is entirely sensible. It is not, however, an escape hatch in any meaningful way, hence why people were extremely upset when the actual escape hatch was disabled by maintainer fiat.
- mejutoco 4y ago
  I guess I am less strict with what I consider an escape hatch. It does not need to be optimal or follow my preferred method IMHO. Other than performance I do not see any limitation of the async port system. You can call back from the js side. It is an especial way, I agree, but one that keeps the Elm paradigm intact. It is quite clever. It is "different", but I do not consider that a limitation, but a matter of preference.

jopsen 4y ago

I think it's also fine to just say no when people ask for an escape hatch. Say, no and tell them use another tool. Not every tool, has to solve all problems. But I do think people should spend more time articulating what their tools don't do, rather than what they do :)