Re:Elm at Pacific Health Dynamics
by ghayes on Monday April 09, 2018 @07:05PM
(#16797757)
Yeah, we've had a great time writing Elm for a fairly complex single-page Ethereum dApp. It's conceptually a lot simpler than Haskell, which made it easy for the team to pick up. I only wish it had a better system (Tasks) for JavaScript interop instead of ports.
[ Parent
| on HN ]
This is so true. I liked and used Elm when I have the right to make final decision. But it's hard to convince others use Elm when coming to integrate with JS.
That's the reason TypeScript won. It intergrate with existing JavaScript seamlessly.
What's your fairly complex dapp about/for?
ReasonML could be a good middle ground there.
One of the biggest complaints of Elm is the lack of typeclass. I'm not aware of a similar abstraction in OCaml. Does Reason have similar limitations, or are there ways to get around it?
OCaml has parametrized modules, confusingly called functors, a very nice feature along with first class modules that Haskell doesn’t have. It is roughly speaking used wherever one would use a Typeclass in Haskell http://ocamlgraph.lri.fr/index.en.html is one good example.
Noon question: what is a typeclass in the sense of the feature Elm lacks?
Does it mean the equivalent to `class` keyword in the OO sense?
From an OO perspective, Elm lacks interfaces. Typeclasses are probably the best way to handle the idea of interfaces in the functional programming model.
Since functions are first class, you can bodge this with an object that has functions in it, but since those don't serialize they don't play well with a lot of Elm idioms if you put them in your model.
I thought about this, and kinda came to a conclusion, than I would take a language that has generics, and doesn't have interfaces (i.e. Elm) over a language that has interfaces and doesn't have generics (i.e. Go)
typescript has both :D
Well, in my professional life, there is a lot of untyped Python on the horizon :P
And for side-projects I think I prefer PureScript anyway?