Hacker News Reader

Comment by vyuh | Hacker News Reader

Elm handicaps my attempts of "making impossible states impossible" because:

- I can't have Sets of arbitrary Types they must be `comparable`. I cannot create a custom comparable type.

- Records, Bool and custom Union Types are not `comparable`

- Bool and Simple Union Types could have been comparable if their comparison worked like they were Enumerated Types. Elm does not have Enumerated types.

Basically https://github.com/elm/compiler/issues/1008 made me look for better alternatives.

View on HN

Elm is a walled garden (as advertised). Agreed this is annoying (for me coming from Haskell). But it does have a great learning experience for those new to FP.

All trade offs.

Can you (or anyone) point me to the files where this `comparable` logic is implemented in elm compiler? I'll try my hand at least making Bool and Record types Comparable. Or maybe implement comparable Enumerated Type in elm which behaves mostly like custom Union Type.

Even if you find the place in the `elmc` code base, fix it and make a PR: it will not be accepted. This is the walled garden aspect of Elm.

Either you accept the walls or you go with PureScript (which could be described as "Elm without the walls"; but then there is a lot more to learn and a whole plethora of frameworks where Elm has the one-to-rule-m-all-FW baked in).

Or create a fork of Elm, which I would support. I'm very happy using Elm for work over the past 3 years, but it's too limiting for advanced usage.

Maybe a good elm-to-purescript transpiler, that couples with the framework this post links to, is all we need :)

I think if someone implements this thing without breaking backward compatibility, then it will be valuable even as a fork of the original elm compiler. I think the License allows this.

Also, Evan has not closed this issue since 2015. Most probably it is about "too much work to get it right" rather than "I'm not convinced that we need it".

I think type classes is how one would want to fix this. Haskell and PureScript have 'm. But them come with a lot, A LOT, of work. Especially to get the std lib to use them!

With comparability you can use the operators (<,>,<=,>=,==,/=,etc.) on various types. This is not how Elm usually works. I.e. the `map` function is different for `List.map`, `Dict.map`, `Maybe.map`, etc.

In Haskell and PS you have type classes. Some types can be mapped, some can be compared, etc. Then the type class defines what functions should be implemented for such type in order to be part of the type class.

You think it's a small change, but it is pretty much what sets Elm and PS apart. Errors can also get a lot more complex with code that leans heavily on type classes.

It simply won't be merged.

FWIW this post is about PureScript, not Elm. The library is an implementation of the Elm Architecture in PureScript. Elm is a language. The framework that goes along with it is called "The Elm Architecture". The Architecture can be implemented in any language. Here's an implementation in TypeScript: https://github.com/gcanti/elm-ts

Also PureScript addresses all of the issues you've complained about above :)

You replied to OP, so I suppose they know.

Did you find better alternatives? I'm currently trying to learn a bit of Elm. So far it's basically the only "Javascript framework" that I've been able to get up and running, while still understanding how things actually work.

This post links to a PureScript project that is probably the easiest PS framework around.

ReScript + rescript-react is a good alternative. Less safe, waaaay more verbose; but backed by Facebook.

This is quite cute (in TypeScript though): https://github.com/cyclejs/cyclejs

And Yew is super cool, it goes the WASM route (in Rust): https://github.com/yewstack/yew

> while still understanding how things actually work

was, methinks, the salient part of his point.

(I emphasize, I too think Elm is coherent enough so you understand how it works, which other Javascript frameworks lack.)

There is a library for Elm style apps in F# called Elmish. Unlike Elm, F# compiled with Fabel can call JS directly (and vice versa).

I am hopeful about using Flame (posted link) along with https://pursuit.purescript.org/packages/purescript-ordered-c....

Looks like purescript development requires node, purescipt compiler, and spago build tool. I have set these up. In future I'll try to learn Flame framework and then adapt my elm code to this.

PureScript's build system is very good (Spago), and the language is too, but it is tougher to learn than Elm veering much nearer Haskell.

I can’t express how useful using Dhall as the configuration format for Spago has been compared to the standard JSON, YAML, or TOML files have been. Having typed configuration with function and can grab environment variables opens a lot of possibilities. One place that has been nice is changing target locale to build with an env var pointing to a different source folder for translations. Overriding packages is just merging two records. Normally this would have to all be handled in a in the build tool or using a non-terminating config language, as a result Spago and PureScript’s package system get to be much simpler.

The fact that Dhall’s aesthetics mirror those of PureScript (including Unicode) is a cherry on top.

I'm also this kind of i-want-to-know-how-things-work person and also never managed to stay at learning React, Vue etc. But a few months ago, I discovered Svelte and I absolutely love it. I recommend you to give a shot to their excellent tutorial which you can finish in < 1 hour https://svelte.dev/tutorial/

Reply on news.ycombinator.com