6 ms·

I'm optimistic about Reason, Facebook's new syntax "skin" on top of OCaml. I find OCaml's syntax to be quite gnarly; of the MLs, F# is probably the cleanest and

I'm optimistic about Reason, Facebook's new syntax "skin" on top of OCaml. I find OCaml's syntax to be quite gnarly; of the MLs, F# is probably the cleanest and most modern-feeling. Something like F# without the .NET stuff could have been amazing.

haskellandchill 10y ago
I find OCaml's syntax simple and clear. I don't get the reason for Reason, but hope it leads to more OCaml adoption.
- emmelaich 10y ago
  I get the reason* for Reason even though it may ostensibly be a superficial one. There was a post by someone on HN saying they started using Reason and ended up using straight Ocaml. * My earliest memories of attempting to use Ocaml was pasting something directly from a beginner's tutorial into ocamli and getting a baffling error message. I think it had to do with use of double semicolons vs single semicolons. Yet that wasn't mentioned in the entire tutorial.
- cies 10y ago
  Reason is more then a "slightly improved syntax to help attract programmers from mainstream languages". It also improves error messages and tooling. It has something akin to JSX built into the lang.
- e12e 10y ago
  OCaml might be simple and clear, but starting from Standard ML - there's a number of differences that feel like warts and needless complications for no discernable gain for the programmer. I do think Reason fix up a few of these ancient and partially crumbled stone walls making the ocaml landscape easier to criss-cross for a new generation of programmers.
  - cies 10y ago
    > there's a number of differences that feel like warts and needless complications for no discernable gain Such as?
    - e12e 10y ago
      It's been a while - but pretty much what Reason address - although I'd prefer filling in SML for js-ish syntax.
rubiquity 10y ago
The good news is that you can have your cake and eat it too! Reason is a front-end to the OCaml compiler and BuckleScript is a back-end. Your Reason programs can be compiled to JS via BuckleScript. Yay!
- lobster_johnson 10y ago
  Nice!
edgyswingset 10y ago
Fable: http://fable.io/ http://fable.io/ It's able to self-host as well. Check it out at http://fable.io/repl http://fable.io/repl F# also runs on .NET Core, which is cross-platform and comes with a good CLI. Documented, too: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/getting-started/getting-started-command-line https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...
- lobster_johnson 10y ago
  Fable looks great, and I might try it out, but I was thinking more along the lines of native, static compilation.
tpetricek 10y ago
I can confirm that the story of F# on the JS ecosystem is already quite good and is getting better every day. As already mentioned, Fable (http://fable.io http://fable.io) is the way to go today. I did two things that involve "writing compilers" using F# that target the web and did not have any notable issuues. - My coeffects page (http://tomasp.net/coeffects http://tomasp.net/coeffects) is an implementation of a simple ML-like language with coeffect type system. It was written using FunScript, which is a precursor of Fable - Fable improved many things, but this was over a year ago when it was not around yet. - The Gamma (https://thegamma.net https://thegamma.net) is a web-based language for doing simple data science work and the compiler for that is written all in Fable. It works perfectly and integrates neatly with things like virtual-dom (source code is on GitHub https://github.com/the-gamma/thegamma-script https://github.com/the-gamma/thegamma-script)
- hongbo_zhang 10y ago
  Indeed, fable is a very neat project, but to be honest, it is not as mature as BuckleScript at this time. For example, it takes around 20~80ms to compile a single file for BuckleScript, while Fable would talk 10x more to compile. Its generated code is pretty but its performance is not very good, see this issue (https://github.com/fable-compiler/Fable/issues/646 https://github.com/fable-compiler/Fable/issues/646) "this can make a difference in speed of up to about six or seven times for tight loop code using tuples, records, lists, unions, etc.(compared with BuckleScript)" But Fable is a nice project, JavaScript platform is large enough to have both :-)
  - tpetricek 10y ago
    I absolutely agree that the JS platform is large enough to have both! That said, I think doing a fair comparison is going to be difficult. Although OCaml and F# share the same background, I think the OCaml and F# communities care about quite different things - and this can be seen in the difference between BuckleScript and Fable. OCaml compiler is very fast and produces efficient code and so it feels reasonable to expect the same for BuckleScript. F# is often slower, but people tend to care a lot about making interop nice. You can see this with the React bindings and Elmish tooling. Those different goals are exactly the reason why there is room for both. I think Fable vs. BuckleScript mirror the philosophy of F# vs. OCaml with respect to .NET and native.
ernst_klim 10y ago
>I find OCaml's syntax to be quite gnarly What's wrong with the OCaml syntax? It's much more clean than say scala's one, it's indentation insensitive, and a' list feels more relevant than the list<'T>
- ufo 10y ago
  One problem is that it is full of shift-reduce conflicts, due to a lack of an "end" token in most expressions. The one that bugs me the most is nested match expressions, which often need to be wrapped in parenthesis.
  - cyrus_ 10y ago
    In OCaml's expression syntax, "begin" is a synonym for left parenthesis, and "end" is a synonym for right parenthesis. So I've taken to just using "begin match e with ... end" in every situation to avoid this problem.
- lobster_johnson 10y ago
  It's a lot of little random things. For example, the ~keyword: syntax, the need to paranthesize where other languages don't (e.g.: "foo -1" doesn't work, you have to do "foo (-1)"). The way argumentless functions must be declared with "function". The expression termination issue (";;") is a lot less elegant than, say, Haskell's whitespace awareness. Operators not being overloaded is annoying, although there's a valid argument for explicitness. Overall, it's not a terrible syntax, but it feels a lot like someone just invented things along the way as they needed them, without a cohesive plan. Lots of pragmatic but visually ugly choices. I also take issue with the tooling; things like error messages, or just the antiquated feel of the CLI tools. For example, having a REPL without built-in readline support (rlwrap to the rescue) in this day and age is not acceptable.
  - ernst_klim 10y ago
    >The way argumentless functions must be declared with "function". Could you show an example, I don't get it? >The expression termination issue (";;") Strange, I've never used ";;" in my code, only in repl. >Operators not being overloaded is annoying, although there's a valid argument for explicitness. Overloading is harmful. It's definitely the wrong way to do ad-hoc polymorphism, and OCaml have a polymorphic comparison operators, which brought so much headache. Type classes or modular implicits are the right way to do ad-hoc. Looking forward to see modular implicits in OCaml [1]. >For example, having a REPL without built-in readline support (rlwrap to the rescue) What do you mean by "readline" support? [1] http://ocamllabs.io/doc/implicits.html http://ocamllabs.io/doc/implicits.html
eru 10y ago
F# has lots of .net warts. Haskell is probably the cleanest ML syntax-wise in somewhat widespread use.

haskellandchill 10y ago

I find OCaml's syntax simple and clear. I don't get the reason for Reason, but hope it leads to more OCaml adoption.

emmelaich 10y ago
I get the reason* for Reason even though it may ostensibly be a superficial one. There was a post by someone on HN saying they started using Reason and ended up using straight Ocaml. * My earliest memories of attempting to use Ocaml was pasting something directly from a beginner's tutorial into ocamli and getting a baffling error message. I think it had to do with use of double semicolons vs single semicolons. Yet that wasn't mentioned in the entire tutorial.
cies 10y ago
Reason is more then a "slightly improved syntax to help attract programmers from mainstream languages". It also improves error messages and tooling. It has something akin to JSX built into the lang.
e12e 10y ago
OCaml might be simple and clear, but starting from Standard ML - there's a number of differences that feel like warts and needless complications for no discernable gain for the programmer. I do think Reason fix up a few of these ancient and partially crumbled stone walls making the ocaml landscape easier to criss-cross for a new generation of programmers.
- cies 10y ago
  > there's a number of differences that feel like warts and needless complications for no discernable gain Such as?
  - e12e 10y ago
    It's been a while - but pretty much what Reason address - although I'd prefer filling in SML for js-ish syntax.

rubiquity 10y ago

The good news is that you can have your cake and eat it too! Reason is a front-end to the OCaml compiler and BuckleScript is a back-end. Your Reason programs can be compiled to JS via BuckleScript. Yay!

lobster_johnson 10y ago
Nice!

edgyswingset 10y ago

Fable: http://fable.io/ http://fable.io/ It's able to self-host as well. Check it out at http://fable.io/repl http://fable.io/repl F# also runs on .NET Core, which is cross-platform and comes with a good CLI. Documented, too: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/getting-started/getting-started-command-line https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...

lobster_johnson 10y ago
Fable looks great, and I might try it out, but I was thinking more along the lines of native, static compilation.

tpetricek 10y ago

I can confirm that the story of F# on the JS ecosystem is already quite good and is getting better every day. As already mentioned, Fable (http://fable.io http://fable.io) is the way to go today. I did two things that involve "writing compilers" using F# that target the web and did not have any notable issuues. - My coeffects page (http://tomasp.net/coeffects http://tomasp.net/coeffects) is an implementation of a simple ML-like language with coeffect type system. It was written using FunScript, which is a precursor of Fable - Fable improved many things, but this was over a year ago when it was not around yet. - The Gamma (https://thegamma.net https://thegamma.net) is a web-based language for doing simple data science work and the compiler for that is written all in Fable. It works perfectly and integrates neatly with things like virtual-dom (source code is on GitHub https://github.com/the-gamma/thegamma-script https://github.com/the-gamma/thegamma-script)

hongbo_zhang 10y ago
Indeed, fable is a very neat project, but to be honest, it is not as mature as BuckleScript at this time. For example, it takes around 20~80ms to compile a single file for BuckleScript, while Fable would talk 10x more to compile. Its generated code is pretty but its performance is not very good, see this issue (https://github.com/fable-compiler/Fable/issues/646 https://github.com/fable-compiler/Fable/issues/646) "this can make a difference in speed of up to about six or seven times for tight loop code using tuples, records, lists, unions, etc.(compared with BuckleScript)" But Fable is a nice project, JavaScript platform is large enough to have both :-)
- tpetricek 10y ago
  I absolutely agree that the JS platform is large enough to have both! That said, I think doing a fair comparison is going to be difficult. Although OCaml and F# share the same background, I think the OCaml and F# communities care about quite different things - and this can be seen in the difference between BuckleScript and Fable. OCaml compiler is very fast and produces efficient code and so it feels reasonable to expect the same for BuckleScript. F# is often slower, but people tend to care a lot about making interop nice. You can see this with the React bindings and Elmish tooling. Those different goals are exactly the reason why there is room for both. I think Fable vs. BuckleScript mirror the philosophy of F# vs. OCaml with respect to .NET and native.

ernst_klim 10y ago

>I find OCaml's syntax to be quite gnarly What's wrong with the OCaml syntax? It's much more clean than say scala's one, it's indentation insensitive, and a' list feels more relevant than the list<'T>

ufo 10y ago
One problem is that it is full of shift-reduce conflicts, due to a lack of an "end" token in most expressions. The one that bugs me the most is nested match expressions, which often need to be wrapped in parenthesis.
- cyrus_ 10y ago
  In OCaml's expression syntax, "begin" is a synonym for left parenthesis, and "end" is a synonym for right parenthesis. So I've taken to just using "begin match e with ... end" in every situation to avoid this problem.
lobster_johnson 10y ago
It's a lot of little random things. For example, the ~keyword: syntax, the need to paranthesize where other languages don't (e.g.: "foo -1" doesn't work, you have to do "foo (-1)"). The way argumentless functions must be declared with "function". The expression termination issue (";;") is a lot less elegant than, say, Haskell's whitespace awareness. Operators not being overloaded is annoying, although there's a valid argument for explicitness. Overall, it's not a terrible syntax, but it feels a lot like someone just invented things along the way as they needed them, without a cohesive plan. Lots of pragmatic but visually ugly choices. I also take issue with the tooling; things like error messages, or just the antiquated feel of the CLI tools. For example, having a REPL without built-in readline support (rlwrap to the rescue) in this day and age is not acceptable.
- ernst_klim 10y ago
  >The way argumentless functions must be declared with "function". Could you show an example, I don't get it? >The expression termination issue (";;") Strange, I've never used ";;" in my code, only in repl. >Operators not being overloaded is annoying, although there's a valid argument for explicitness. Overloading is harmful. It's definitely the wrong way to do ad-hoc polymorphism, and OCaml have a polymorphic comparison operators, which brought so much headache. Type classes or modular implicits are the right way to do ad-hoc. Looking forward to see modular implicits in OCaml [1]. >For example, having a REPL without built-in readline support (rlwrap to the rescue) What do you mean by "readline" support? [1] http://ocamllabs.io/doc/implicits.html http://ocamllabs.io/doc/implicits.html

eru 10y ago

F# has lots of .net warts. Haskell is probably the cleanest ML syntax-wise in somewhat widespread use.