ReasonML: Strict, powerful and forgiving • Hacker News Board

Re: ReasonML: Strict, powerful and forgiving

#41

Post by AlexCoventry » Sun, Nov 11, 2018, 4:27 AM UTC

int_19h wrote: post #38

jarcane wrote: post #16

So ReasonML is actually a Javascript-like syntax for OCaml, and its tool-chain converts Reason code to OCaml, which then uses a tool called Bucklescript to convert that OCaml to Javascript. All because some people just have to have their curly braces. I will never stop being angry that this exists. There is no reason for it other than pedantic bikeshedding and Facebook’s mission to proprietize web tech. It does nothi…

It's not just about the curly braces - there are many warts about OCaml's syntax, and some of them go beyond mere niceties, and into the territory of making it too easy to unintentionally write code that doesn't do what the author intended. In Reason, it looks like they specifically went after those, e.g.: https://reasonml.github.io/docs/en/comparison-to-ocaml#patte...

In practice, your editor's indentation will alert you to the compiler's interpretation of the pattern match.

Re: ReasonML: Strict, powerful and forgiving

#42

Post by AlexCoventry » Sun, Nov 11, 2018, 4:37 AM UTC

splintercell wrote: post #33

scns wrote: post #13

Earlier quoted context omitted.

You can embed raw js in reason/BS easily with [%raw ] iirc. Check the bucklescript documentaton, where the interop docs are located.

But then I don't get the benefit of ReasonML/BS. I can do that, but then I keep having to do that everywhere I interact with that library (which is essentially the core part of my app). I do the same thing in Elm, but all that code is living in a JS file, and it can be in Typescript/whatever.

The usual solution to that kind of interop issue is to use wrapper modules and functions.

Re: ReasonML: Strict, powerful and forgiving

#43

Post by h1d » Sun, Nov 11, 2018, 4:46 AM UTC

skosch wrote: post #22

chrisweekly wrote: post #11

In the context of developing React webapps, what advantages obtain from ReasonML over TypeScript?

I've worked with both. Typescript is (and feels) bolted-on, and can fail in dozens of ways. ReasonML's type checker is 100% airtight. It also has pattern matching and piping, to help make your code more concise. Typescript is easy: it's just ES6. ReasonML is (and feels) very much unpolished. Conflicts and overlaps between ReasonML's and Bucklescript's and JS's standard libraries, poor documentation, very flexible but…

What could be the fastest way to recompile TypeScript that also monitors for file addition and deletion?

So far I'm having a decent experience with pm2 monitoring for any changes or additions of files to restart a ts-node instance but it does make you wait a few seconds or else nginx throws a 502 when the ts-node is still restarting.

Re: ReasonML: Strict, powerful and forgiving

#44

Post by thetophs » Sun, Nov 11, 2018, 6:10 AM UTC

smnplk wrote: post #35

Does anyone have experience with Clojurescript and ReasonML?

I used both a fair amount. I liked both languages quite a bit, but I always found the tooling around Clojurescript difficult to use. ReasonML was a much better experience for me. After using both I think I personally prefer the experience of using a typed language over a dynamic language. This was from the perspective of making UIs with React.

Re: ReasonML: Strict, powerful and forgiving

#45

Post by jarcane » Sun, Nov 11, 2018, 6:32 AM UTC

int_19h wrote: post #38

jarcane wrote: post #16

So ReasonML is actually a Javascript-like syntax for OCaml, and its tool-chain converts Reason code to OCaml, which then uses a tool called Bucklescript to convert that OCaml to Javascript. All because some people just have to have their curly braces. I will never stop being angry that this exists. There is no reason for it other than pedantic bikeshedding and Facebook’s mission to proprietize web tech. It does nothi…

It's not just about the curly braces - there are many warts about OCaml's syntax, and some of them go beyond mere niceties, and into the territory of making it too easy to unintentionally write code that doesn't do what the author intended. In Reason, it looks like they specifically went after those, e.g.: https://reasonml.github.io/docs/en/comparison-to-ocaml#patte...

If Reason uses == to represent OCaml's =, and uses === to represent OCaml's ==, then how would Reason represent OCaml's === symbol (if it were defined)? Reason provides a way! "Escape" the triple equals symbol!

Yes, such a massive improvement to clarity.

Seriously there is nothing here I hadn't internalized within a day of working with F# or Python. Certainly nothing that justifies forking an entire alternate syntax.

Re: ReasonML: Strict, powerful and forgiving

#46

Post by int_19h » Sun, Nov 11, 2018, 7:13 AM UTC

jarcane wrote: post #45

int_19h wrote: post #38

Earlier quoted context omitted.

It's not just about the curly braces - there are many warts about OCaml's syntax, and some of them go beyond mere niceties, and into the territory of making it too easy to unintentionally write code that doesn't do what the author intended. In Reason, it looks like they specifically went after those, e.g.: https://reasonml.github.io/docs/en/comparison-to-ocaml#patte...

If Reason uses == to represent OCaml's =, and uses === to represent OCaml's ==, then how would Reason represent OCaml's === symbol (if it were defined)? Reason provides a way! "Escape" the triple equals symbol! Yes, such a massive improvement to clarity. Seriously there is nothing here I hadn't internalized within a day of working with F# or Python. Certainly nothing that justifies forking an entire alternate syntax.

> Yes, such a massive improvement to clarity.

Given that === is not a standard operator in OCaml, I fail to see the problem with clarity.

> Certainly nothing that justifies forking an entire alternate syntax.

You do realize that this is very much a subjective judgment, do you? Syntax does matter. You can argue that it doesn't matter enough to bother, but that's down to personal taste. Given the popularity that Reason seems to be enjoying, clearly, syntax is a sore point for enough people.

In any case, I fail to see the problem in general. Reason doesn't fragment the OCaml ecosystem, really, since it's just a different syntax for the same core language, and libraries etc remain. It's not any different than all the macro libraries for Lisps. Nobody is forcing you to use them, and you can still use a library written in Reason from OCaml, and vice versa. There's no real fragmentation.

And if Reason ever dies, all code that's written in it could just be converted to OCaml using the last version of their transpiler, and maintained as such thereafter.

So, what's the problem?

Re: ReasonML: Strict, powerful and forgiving

#47

Post by jarcane » Sun, Nov 11, 2018, 8:48 AM UTC

thatswrong0 wrote: post #17

jarcane wrote: post #16

So ReasonML is actually a Javascript-like syntax for OCaml, and its tool-chain converts Reason code to OCaml, which then uses a tool called Bucklescript to convert that OCaml to Javascript. All because some people just have to have their curly braces. I will never stop being angry that this exists. There is no reason for it other than pedantic bikeshedding and Facebook’s mission to proprietize web tech. It does nothi…

Making a language feel more familiar to the developers that would likely be using it will probably speed up its adoption and decrease the learning curve for new developers. I don't understand what is so enraging about that.

No one did this for Python.

People still complain about it, but somehow, it became one of the most popular languages on the planet.

And how is it welcoming to newcomers to essentially be upfront asking them "right, now which syntax will you use?"

Unless the answer of course is just to nudge them all in the direction of the one owned by a massive corporation with more money than some countries ...

Re: ReasonML: Strict, powerful and forgiving

#48

Post by jarcane » Sun, Nov 11, 2018, 8:50 AM UTC

int_19h wrote: post #46

jarcane wrote: post #45

Earlier quoted context omitted.

If Reason uses == to represent OCaml's =, and uses === to represent OCaml's ==, then how would Reason represent OCaml's === symbol (if it were defined)? Reason provides a way! "Escape" the triple equals symbol! Yes, such a massive improvement to clarity. Seriously there is nothing here I hadn't internalized within a day of working with F# or Python. Certainly nothing that justifies forking an entire alternate syntax.

> Yes, such a massive improvement to clarity. Given that === is not a standard operator in OCaml, I fail to see the problem with clarity. > Certainly nothing that justifies forking an entire alternate syntax. You do realize that this is very much a subjective judgment, do you? Syntax does matter. You can argue that it doesn't matter enough to bother, but that's down to personal taste. Given the popularity that Reason…

Nobody is forcing you to use them, and you can still use a library written in Reason from OCaml, and vice versa.

You really should go read up about this, because the actual answer is far more complicated than advertised. Hell, the Ocaml interop section in the official docs isn't even finished yet.

Re: ReasonML: Strict, powerful and forgiving

#49

Post by bobbby » Sun, Nov 11, 2018, 10:03 AM UTC

jarcane wrote: post #47

thatswrong0 wrote: post #17

Earlier quoted context omitted.

Making a language feel more familiar to the developers that would likely be using it will probably speed up its adoption and decrease the learning curve for new developers. I don't understand what is so enraging about that.

No one did this for Python. People still complain about it, but somehow, it became one of the most popular languages on the planet. And how is it welcoming to newcomers to essentially be upfront asking them "right, now which syntax will you use?" Unless the answer of course is just to nudge them all in the direction of the one owned by a massive corporation with more money than some countries ...

How's the uptake for ocaml going? Its had 20 years maybe next year will be its year?

Re: ReasonML: Strict, powerful and forgiving

#50

Post by kitten_mittens_ » Sun, Nov 11, 2018, 2:49 PM UTC

jordwalke wrote: post #27

kitten_mittens_ wrote: post #19

Avoiding reason-cli and just using bs-platform and reason-vscode together is the way to go in this ecosystem. The problem with reason-cli is that it can get out of sync with the bs-platform version and fail in unclear ways. There was quite a bit of pushback against reason at my shop due to the interop between these two packages and trying to do things like have autocompletion fail because of them. It’d be nice if the…

Hi, I work on Reason full time and have been managing the reason-cli releases, and I'm happy to say that we're pretty close to not needing reason-cli anymore because the much better alternative is to _avoid_ global installs and instead model IDE support and as devDependencies of your project. We only have been releasing a global install (reason-cli) because: 1) Until recently we didn't have better alternatives for Bu…

Thanks for the reply! The Discord channel has been very helpful, but I must have missed this sort of thing there.