@evancz and others helped me realize saying that “x is less expressive than y” makes little sense.
When I first used the word in my thread (“Is it fair to say abstraction and expressiveness are Elm’s weak points?”) it wasn’t much focused on its particular meaning in that context, and I got a little arrogant and stubborn when someone contradicted me.
At this point though I’m left wondering how exactly one could express the concept I had in mind.
I was thinking about 2 things:
- The problem that this guy faces while trying to implement a select widget.
Basically, he wants to show a select box with n values and change the view when the selection is changed. He creates a union type with the n values to be chosen from, and he gets stuck.
The problem is the select widget only allows for the onSelect event, which embeds the selected String in a message and calls the update function. He is left juggling to and from between his value types and the corresponding strings to be displayed, losing the advantages of exhaustive pattern matching.
I also found someone else trying to implement a (Elm) code generation tool to make sure to have enum types and a corresponding list in sync.
- The fact that you can’t have user defined types as dict keys, since the comparable property is embedded in the compiler.
If I needed to do either of those, I’d have to find ways to work around my problem (like a code generation tool, or a function mapping my types to other data). Regardless of whether I should do it, it’s something I can’t achieve neatly in Elm. “(lack of) Expressiveness” is not the right term, so how would you call this?
As a side note, sorry if I’m spamming; Evan himself said to create a new thread if there were any follow up questions though, so I felt allowed to continued inquiring.