ReasonML: Strict, powerful and forgiving
harigopal.in
ReasonML: Strict, powerful and forgiving
1–10 of 60 posts
Re: ReasonML: Strict, powerful and forgiving
#2That been said, I love ReasonML and will continue to invest in its ecosystem. Shamelessly plug, I built https://sketch.sh as a quick playground for ReasonML and OCaml, check it out if you're interested in trying ReasonML
Re: ReasonML: Strict, powerful and forgiving
#3I've been using ReasonML for building complex ReasonReact (React.js binding for ReasonML) apps. With the strict type system, I can code for hours without constantly looking at the browser and it just works on first try. I never feel so happy with coding like that before with Javascript. I would recommend ReasonML for all Javascript developers. Those ReasonML has some downsides that need to be addressed: - Bucklescrip…
Re: ReasonML: Strict, powerful and forgiving
#4Re: ReasonML: Strict, powerful and forgiving
#5I've been using ReasonML for building complex ReasonReact (React.js binding for ReasonML) apps. With the strict type system, I can code for hours without constantly looking at the browser and it just works on first try. I never feel so happy with coding like that before with Javascript. I would recommend ReasonML for all Javascript developers. Those ReasonML has some downsides that need to be addressed: - Bucklescrip…
Is lack of ad-hoc polymorphism a real issue for such projects? Everyone who used JS before are accustomed to using overridden methods, or just duck typing, which are form of ad hoc polymorphism too, but Reason/Ocaml lacks it. How does this feel? Or it's easy to code avoiding ad-hoc polymorphism after forming habit for it? Do you use things like function dictionaries to simulate ad-hoc polymorphism?
Re: ReasonML: Strict, powerful and forgiving
#6``` const contract = new web3.eth.Contract(ABI, contractAddress, {from}) ```
in ReasonML easily, despite spending hours on trying to figure it out. At the end I finally reached to a feature request asking to be able to do 'new' on member functions, and it was in 'planning'.
On the other hand Elm's approach to JS interop seemed to be far superior for quirks like these. Javascript code lives on the other side of the border, and Elm code on this. You don't have to create a type for the whole class of the third party library, just the data you want Elm to manage.
Re: ReasonML: Strict, powerful and forgiving
#7Re: ReasonML: Strict, powerful and forgiving
#8I tried using ReasonML for a blockchain project, and I just couldn't get past being able to express this logic of interacting with a third party library: ``` const contract = new web3.eth.Contract(ABI, contractAddress, {from}) ``` in ReasonML easily, despite spending hours on trying to figure it out. At the end I finally reached to a feature request asking to be able to do 'new' on member functions, and it was in 'pl…
For those not familiar with Elm it means you basically have to interact with all JS code through a pub-sub model and can't ever directly call JS code.
Elm's creator has his reasons for why he does this (https://guide.elm-lang.org/interop/ports.html), but it can make calling JS from Elm quite a pain.
Re: ReasonML: Strict, powerful and forgiving
#9The generated JS is readable and well-commented when for instance a record is transformed into an array. Just opening up the generated JS and reading it made for a nice self-check mechanism when I was starting out with the proof of concept.