5 ms·

Does anybody think ReasonML will become more popular than plain OCaml outside of front end web development?

by badfrog 8y ago

yawaramin 8y ago
Yes.
- badfrog 8y ago
  Just because of FB support, or are there other reasons?
  - yawaramin 8y ago
    I think because of community interest and the need for a good general-purpose, efficient language. Here are some interesting community-developed projects: - A cross-platform native-compiling GUI library with a React-influenced design: https://github.com/revery-ui/revery https://github.com/revery-ui/revery - A lightning-fast Node version manager: https://github.com/Schniz/fnm https://github.com/Schniz/fnm - Erlang-like multicore actors: https://github.com/ostera/reactor https://github.com/ostera/reactor That said, it's early days and the ecosystem has to (and will) mature a lot.
    - badfrog 8y ago
      > the need for a good general-purpose, efficient language Is the implication that plain OCaml is not good?
      - yawaramin 8y ago
        No, but realistically it's not very accessible (general-purpose). If people go for OCaml that's great, it's an amazing language and it's obviously the same language. But the ReasonML focus has been on developer experience and it's showing.
        willtim 8y ago
        Can functional programming really be made more accessible by adding curly brackets? I came from C-style languages and now much prefer the syntax of Haskell and OCaml (although Haskell is my favourite). Learning the syntax was trivial compared to the paradigm and semantics.
        k__ 8y ago
        Have you seen the Reason eco-system lately? The esy package manager alone is a huge improvement over opam and npm.
        v100 8y ago
        Sorry, the developer experience in OCaml is almost unsurpassed. Nearly everything is perfect in that area, the only thing I miss are a couple of features (for example, native compiler support for all stdint.h exact width types).
        yawaramin 8y ago
        Could there perhaps be some things that other mainstream developers need to do that you don't? Maybe, say, quickly scaffold a project with a CLI? With unit tests and a documentation pipeline out of the box? Access online documentation about packages in a centralized location? Easily sandbox library dependencies for multiple projects, while sharing as much as possible? All that said, the OCaml tooling is definitely making strides in the right direction. Dune for one thing is incredible and we are lucky to have it. I'm just saying there is room to make things easier for developers, and Reason is also moving that forward.
- bgorman 8y ago
  It is really puzzling to me, but I think this is true. I saw a comment on Reddit where someone said ReasonML had a pleasant syntax. I suppose if you have always dealt with C-style syntax, ReasonML might seem more familiar. However if you have tried a LISP or even Haskell/another ML family language, the syntax will probably seem like a major impediment to your productivity. However, having witnessed people moving to ReasonML from JavaScript, I have noticed that that initial familiarity makes a difference. Meanwhile LISP flavors languish because of their "alien" syntax.
  - yawaramin 8y ago
    It's not just the familiarity. ReasonML fixes real syntactic issues with OCaml: - Having to learn how to use let ... in - Having to learn how to use semi-colons and where and why - Having to enclose `else` clauses in parentheses or begin/end keywords and learning why they are necessary - Having to use multiple pairs of parentheses to enclose function arguments like `foo (a + b) (c - d)`. With Reason it's `foo(a + b, c - d)`. And another bonus, function application in Reason actually looks like high school math function application - Having to learn to distinguish between tuples and multiple arguments in data constructors Those are just off the top of my head. In addition, ReasonML's refmt tool lets you avoid bikeshedding discussions about code formatting–it's a whole-program formatter. And some additional syntax niceties like single-@-symbol annotations and the upcoming single-line comments (//)–something OCaml will most likely never get.
    - badfrog 8y ago
      I wouldn't consider #1-3 to be issues with OCaml syntax. It took me a while to understand what was going on with them, but once I did, I had a solid understanding of expressions vs statements, which has helped me understand functional programming better in general. IMO blending the syntax for the two will make the earliest stages of learning easier but cause confusion and longer learning curves in the long run.
      - yawaramin 8y ago
        I can't see how. ReasonML syntax has a clear and uniform scope delimiter, curly braces. You are always sure which scope you're in, there's no room for ambiguity. You'll have to provide some more specific ways in which there could be confusion ;-)
jarcane 8y ago
I hope not. It is hideous and unnecessary.
- purity_resigns 8y ago
  I think the ReasonML parser and formatter have numerous issues that'll keep it from being adopted more widely. Especially with nested expressions, the inability to find mismatched parens and braces ultimately turned my team's experiment with it sour. The base language's grammar is said to have inconsistencies, but I think Reason's 1:1 matching while keeping older constructs makes translating very difficult. There is a tool to do so, but it's lossy. That said, I use Reason React for a small front end project at work and sort of wish that the ppx for JSX wasn't tied to Reason, so that vanilla OCaml could be used instead. An example of lossy translation from Reason -> OCaml: https://reasonml.github.io/en/try?rrjsx=true&reason=DYUwLgBAlgdgDgV0gXggbwD4CgIQDwAWYAtsAHw674EgCGAJhVVXmFGKGQIIQDKUxOKAgAJACoBZADIQAIgHsAxgmIgYYPAHo2HEExaaaDfbjwAjefQCeJlnDJiCUAM7RXtCADcQAJysRnASEQUUkZeiUVNQ1Ne0pmPHsASUh5GGB-AlpXMAB3eQg4Wh9aAHMSuAJnLTiEzQtrfS0iUgoMAF8AbiwsUEgfEGcEYBQIAClnADpeMB9YUsniWjBFAgAKAG0AUgH0DE1EsjXJgCoAfgBKPAAdWLJNUqgOgF0AGmh4JAvurGdc9lWEDWAyGIwu6CwGD48lUwMGwzA4OQZHGUy4PhKVkmADN5D4AKK0VZrCaTYDyUrvEEIi6QiAAOTSIWRqLJFLWACIYAUlisaM4ObSukA https://reasonml.github.io/en/try?rrjsx=true&reason=DYUwLgBA...
  - k__ 8y ago
    You mean using ReasonReact without JSX in OCaml is a pain? Doesn't it allow to quickly code something like HyperScript-Helpers?
  - yawaramin 8y ago
    I don't understand, what is being lost here?
    - purity_resigns 8y ago
      `| ((Some (result))[@explicit_arity ]) -> Js.Array.forEach Js.log result` the explicit_arity being added in. I can't think of other examples at the moment.
deleted 8y ago
[deleted]

Does anybody think ReasonML will become more popular than plain OCaml outside of front end web development?

yawaramin 8y ago

Yes.

badfrog 8y ago
Just because of FB support, or are there other reasons?
- yawaramin 8y ago
  I think because of community interest and the need for a good general-purpose, efficient language. Here are some interesting community-developed projects: - A cross-platform native-compiling GUI library with a React-influenced design: https://github.com/revery-ui/revery https://github.com/revery-ui/revery - A lightning-fast Node version manager: https://github.com/Schniz/fnm https://github.com/Schniz/fnm - Erlang-like multicore actors: https://github.com/ostera/reactor https://github.com/ostera/reactor That said, it's early days and the ecosystem has to (and will) mature a lot.
  - badfrog 8y ago
    > the need for a good general-purpose, efficient language Is the implication that plain OCaml is not good?
    - yawaramin 8y ago
      No, but realistically it's not very accessible (general-purpose). If people go for OCaml that's great, it's an amazing language and it's obviously the same language. But the ReasonML focus has been on developer experience and it's showing.
      - willtim 8y ago
        Can functional programming really be made more accessible by adding curly brackets? I came from C-style languages and now much prefer the syntax of Haskell and OCaml (although Haskell is my favourite). Learning the syntax was trivial compared to the paradigm and semantics.
        k__ 8y ago
        Have you seen the Reason eco-system lately? The esy package manager alone is a huge improvement over opam and npm.
      - v100 8y ago
        Sorry, the developer experience in OCaml is almost unsurpassed. Nearly everything is perfect in that area, the only thing I miss are a couple of features (for example, native compiler support for all stdint.h exact width types).
        yawaramin 8y ago
        Could there perhaps be some things that other mainstream developers need to do that you don't? Maybe, say, quickly scaffold a project with a CLI? With unit tests and a documentation pipeline out of the box? Access online documentation about packages in a centralized location? Easily sandbox library dependencies for multiple projects, while sharing as much as possible? All that said, the OCaml tooling is definitely making strides in the right direction. Dune for one thing is incredible and we are lucky to have it. I'm just saying there is room to make things easier for developers, and Reason is also moving that forward.
bgorman 8y ago
It is really puzzling to me, but I think this is true. I saw a comment on Reddit where someone said ReasonML had a pleasant syntax. I suppose if you have always dealt with C-style syntax, ReasonML might seem more familiar. However if you have tried a LISP or even Haskell/another ML family language, the syntax will probably seem like a major impediment to your productivity. However, having witnessed people moving to ReasonML from JavaScript, I have noticed that that initial familiarity makes a difference. Meanwhile LISP flavors languish because of their "alien" syntax.
- yawaramin 8y ago
  It's not just the familiarity. ReasonML fixes real syntactic issues with OCaml: - Having to learn how to use let ... in - Having to learn how to use semi-colons and where and why - Having to enclose `else` clauses in parentheses or begin/end keywords and learning why they are necessary - Having to use multiple pairs of parentheses to enclose function arguments like `foo (a + b) (c - d)`. With Reason it's `foo(a + b, c - d)`. And another bonus, function application in Reason actually looks like high school math function application - Having to learn to distinguish between tuples and multiple arguments in data constructors Those are just off the top of my head. In addition, ReasonML's refmt tool lets you avoid bikeshedding discussions about code formatting–it's a whole-program formatter. And some additional syntax niceties like single-@-symbol annotations and the upcoming single-line comments (//)–something OCaml will most likely never get.
  - badfrog 8y ago
    I wouldn't consider #1-3 to be issues with OCaml syntax. It took me a while to understand what was going on with them, but once I did, I had a solid understanding of expressions vs statements, which has helped me understand functional programming better in general. IMO blending the syntax for the two will make the earliest stages of learning easier but cause confusion and longer learning curves in the long run.
    - yawaramin 8y ago
      I can't see how. ReasonML syntax has a clear and uniform scope delimiter, curly braces. You are always sure which scope you're in, there's no room for ambiguity. You'll have to provide some more specific ways in which there could be confusion ;-)

jarcane 8y ago

I hope not. It is hideous and unnecessary.

purity_resigns 8y ago
I think the ReasonML parser and formatter have numerous issues that'll keep it from being adopted more widely. Especially with nested expressions, the inability to find mismatched parens and braces ultimately turned my team's experiment with it sour. The base language's grammar is said to have inconsistencies, but I think Reason's 1:1 matching while keeping older constructs makes translating very difficult. There is a tool to do so, but it's lossy. That said, I use Reason React for a small front end project at work and sort of wish that the ppx for JSX wasn't tied to Reason, so that vanilla OCaml could be used instead. An example of lossy translation from Reason -> OCaml: https://reasonml.github.io/en/try?rrjsx=true&reason=DYUwLgBAlgdgDgV0gXggbwD4CgIQDwAWYAtsAHw674EgCGAJhVVXmFGKGQIIQDKUxOKAgAJACoBZADIQAIgHsAxgmIgYYPAHo2HEExaaaDfbjwAjefQCeJlnDJiCUAM7RXtCADcQAJysRnASEQUUkZeiUVNQ1Ne0pmPHsASUh5GGB-AlpXMAB3eQg4Wh9aAHMSuAJnLTiEzQtrfS0iUgoMAF8AbiwsUEgfEGcEYBQIAClnADpeMB9YUsniWjBFAgAKAG0AUgH0DE1EsjXJgCoAfgBKPAAdWLJNUqgOgF0AGmh4JAvurGdc9lWEDWAyGIwu6CwGD48lUwMGwzA4OQZHGUy4PhKVkmADN5D4AKK0VZrCaTYDyUrvEEIi6QiAAOTSIWRqLJFLWACIYAUlisaM4ObSukA https://reasonml.github.io/en/try?rrjsx=true&reason=DYUwLgBA...
- k__ 8y ago
  You mean using ReasonReact without JSX in OCaml is a pain? Doesn't it allow to quickly code something like HyperScript-Helpers?
- yawaramin 8y ago
  I don't understand, what is being lost here?
  - purity_resigns 8y ago
    `| ((Some (result))[@explicit_arity ]) -> Js.Array.forEach Js.log result` the explicit_arity being added in. I can't think of other examples at the moment.

deleted 8y ago

[deleted]