9 ms·

Are the new parentheses optional? I love modern JS syntax but the Reason syntax sans parentheses was really growing on me. Also I’m still hoping for an async/a

Are the new parentheses optional? I love modern JS syntax but the Reason syntax sans parentheses was really growing on me. Also I’m still hoping for an async/await équivalent. I’d love to use Reason for Node API stuff but the JS interop with promises isn’t very pretty...

yogthos 9y ago
I simply don't understand why people like C style syntax so much.
- krat0sprakhar 9y ago
  Color me confused as well. I had used C like languages for a long time before trying out OCaml and Clojure. Surprisingly for neither of those I found the lack of parentheses a cause of annoyance. </bikeshedding>
  - caltelt 9y ago
    I think that might be the first time I've ever seen "Clojure" and "lack of parenthesis" in the same sentence. Presumably you meant C-style parens. :D I agree though. Honestly, getting worked up over such fluff as where parens go, which whitespace to use, what line curly braces go on is a minor annoyance of mine. The human brain is capable of parsing some pretty obscure stuff (see: human language) just fine.
    - dualogy 9y ago
      Just gets so visually noisy when reading code though. Maybe depends subjectively on how a given individual tries to re-conceptualize high-level ideas from low-level instructions. I actually have my Sublime/VScode color schemes set up so that all "punctuation" is as grey / half-invisible as the comments and indent-guide --- really helps me scan curly code-bases whether Go, JS or all the others =)
      - dmitriid 9y ago
        It's funny to see people talking about how noisy parentheses/braces are when a regular ReasonML program before adopting a more Javascript-y syntax looked like a combination of random punctuation. Same goes for a lot of Haskell code.
        dualogy 9y ago
        > looked like a combination of random punctuation. Same goes for a lot of Haskell code "A lot", not "all": yeah indeed at least you can tweak the punctuation towards more ergonomic (aka more productive) aesthetics. What you describe is just the unfortunate result of many-perhaps-most (early) Haskellers / the std-lib authors being married to established-but-ugly academic operator symbols instead of boldly redesigning them for green-field programmers of this (then, newly from-scratch) programming language. Once swapping out the built-in `.` for <. and `>>>` for .> and $ for <| and & for |> it all comes a breeze to read (I mean, in comparison), about on par with Elm/F#. Now I've never heard anyone complain that Elm code is unreadable, it's a good example for other MLs to follow. The rest of what you describe is just due to these hackers being heavily into their own combinator libraries, truly if you code all day, just as there shouldn't be a need to elaborately spell out "function" and "return" and so forth all the time in imperative, they feel less need to spell out all the map/filter/reduce English words all the time. At some point, all the names describe "symbolic relations of sorts" and I wouldn't fault anyone for philosophizing: "that which is specific to my program should be named as words, but that which is 'primitive' / generalized / commonly used among all sorts of programs could just as well be just symbols" ;) I mean I hack in Go all days right now and it's fun --- lots of parens & braces don't exactly kill me. Here, tweaking one's colour scheme easily solves this in one fell swoop and takes just under a minute tops. No need to go "ML-ish FP" just for the lack of curlies. =)
        dmitriid 9y ago
        It's basically a struggle between "too much syntax" and "not enough syntax" :)
    - alphaalpha101 9y ago
      Lisps genuinely have fewer brackets than C-like languages. They're just more consistently in the same places.
- chenglou 9y ago
  I made this release, and I also don't understand, and I do mean this _very honestly_. Aside from familiarity that is. But the thing to realize is that this syntax change isn't for folks and you and me. We'll be fine with either.
  - bjz_ 9y ago
    But the syntax adds a layer of obfuscation over the mechanics of currying. I thought we were getting somewhere with Elm, Purescript, and Reason adopting it and making it more widely known, but then we've gone a step backward again. I kind of feel like we need better communication and education rather than just doing a band-aid fix that only helps folks in the short term. :( Did you consider having a 'beginner mode' Reason, then flipping a switch to compare it to compare it to the non-parened version is?
    - chenglou 9y ago
      I'm gonna argue beside the point, but currying has negative semantics and type system impact in a language with uncontrolled side-effects. It also prevents some optimizations and new type features. Don't take my words for it: https://github.com/facebook/reason/pull/1299#issuecomment-309032848 https://github.com/facebook/reason/pull/1299#issuecomment-30... https://realworldocaml.org/v1/en/html/imperative-programming-1.html#side-effects-and-weak-polymorphism https://realworldocaml.org/v1/en/html/imperative-programming... https://drup.github.io/2016/08/02/difflists/ https://drup.github.io/2016/08/02/difflists/ https://bucklescript.github.io/bucklescript/Manual.html#_callback_optimization https://bucklescript.github.io/bucklescript/Manual.html#_cal... I'm jumping into this conversation early on because too often this point is raised and turns into an uncharitable interpretation of our motivations, e.g. "look at these js programmers, not understanding the beauty of currying". Rest assured that we do (and that we're not just js programmers), and that the Merlin and BuckleScript authors know very well what they're doing. Hope this clarifies things a bit.
      - bjz_ 9y ago
        I'm not talking about you not knowing, I'm more worried about language designers talking down to programmers for short term gains, rather than trying to raise them up with tools that will benefit them in the long term. Interesting about argument syntax + effects. I've mainly used currying in pure languages. Is it about accidentally calling an effectful function multiple times? Is the idea here that you are conservatively treating everything as effectful with the uncurried syntax (before algebraic effects land), then will make pure stuff curried in order to attract people to use pure functions where possible?
- tomc1985 9y ago
  Because if there aren't enough symbols the language looks too much like Visual Basic
dualogy 9y ago
IMHO "functional scripters" with a penchant for fewer parens, braces etc and a tendency towards ML-style should seriously embrace PureScript, it's such a terrific project, just gets way too little hype. That's not to rain on ReasonML of course here, which I observed for a while as a very cool transpilation project and kudos to the devs! I'd take a reason project over JS/TS/Ecma any day still
- christophilus 9y ago
  I really like PureScript. The one thing that kept me from deep diving into it was that it lacked efficient immutable data structures, unless I'm mistaken. It basically is immutable by doing full copies with variations, no? That seems like a pretty big downside.
  - dualogy 9y ago
    Some truth to this possibly. This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. I mean PS arrays/records map to JS arrays/objects as far as passing/return them, but for those few cases where you really need to mutate inside-a-(no-longer-pure)-func, it's JS-FFI-hackery or (more likely often) a readily-available 3rd-party package offering the persistent or mutable data structure to serve the need at hand. Might not want to write your WebGL 3D game's game loop or a very mathy 2/3/x-dimensional "big array" re-calculation entirely in PS perhaps, sure enough. Depends on what apps you have in mind I guess. Typically in JS what's become more common recently is to map over the structure, extract the small sub-set you actually want to process (reduce/filter) and in the end these copies often turn out small and not so scary. But as always, "it depends". Truly the PureScript/Haskell/Elm family makes mutation harder than all other languages --- with the flip-side that they make immutable purely-functional expression vastly more ergonomic IMHO =)
    - christophilus 9y ago
      I guess I'm thinking more along the lines of Clojure(Script) which has efficient immutable lists, vectors, and maps. It doesn't do a full copy every time you do a cons or assoc. It seems to me that PureScript would really benefit from having something similar baked in.

yogthos 9y ago

I simply don't understand why people like C style syntax so much.

krat0sprakhar 9y ago
Color me confused as well. I had used C like languages for a long time before trying out OCaml and Clojure. Surprisingly for neither of those I found the lack of parentheses a cause of annoyance. </bikeshedding>
- caltelt 9y ago
  I think that might be the first time I've ever seen "Clojure" and "lack of parenthesis" in the same sentence. Presumably you meant C-style parens. :D I agree though. Honestly, getting worked up over such fluff as where parens go, which whitespace to use, what line curly braces go on is a minor annoyance of mine. The human brain is capable of parsing some pretty obscure stuff (see: human language) just fine.
  - dualogy 9y ago
    Just gets so visually noisy when reading code though. Maybe depends subjectively on how a given individual tries to re-conceptualize high-level ideas from low-level instructions. I actually have my Sublime/VScode color schemes set up so that all "punctuation" is as grey / half-invisible as the comments and indent-guide --- really helps me scan curly code-bases whether Go, JS or all the others =)
    - dmitriid 9y ago
      It's funny to see people talking about how noisy parentheses/braces are when a regular ReasonML program before adopting a more Javascript-y syntax looked like a combination of random punctuation. Same goes for a lot of Haskell code.
      - dualogy 9y ago
        > looked like a combination of random punctuation. Same goes for a lot of Haskell code "A lot", not "all": yeah indeed at least you can tweak the punctuation towards more ergonomic (aka more productive) aesthetics. What you describe is just the unfortunate result of many-perhaps-most (early) Haskellers / the std-lib authors being married to established-but-ugly academic operator symbols instead of boldly redesigning them for green-field programmers of this (then, newly from-scratch) programming language. Once swapping out the built-in `.` for <. and `>>>` for .> and $ for <| and & for |> it all comes a breeze to read (I mean, in comparison), about on par with Elm/F#. Now I've never heard anyone complain that Elm code is unreadable, it's a good example for other MLs to follow. The rest of what you describe is just due to these hackers being heavily into their own combinator libraries, truly if you code all day, just as there shouldn't be a need to elaborately spell out "function" and "return" and so forth all the time in imperative, they feel less need to spell out all the map/filter/reduce English words all the time. At some point, all the names describe "symbolic relations of sorts" and I wouldn't fault anyone for philosophizing: "that which is specific to my program should be named as words, but that which is 'primitive' / generalized / commonly used among all sorts of programs could just as well be just symbols" ;) I mean I hack in Go all days right now and it's fun --- lots of parens & braces don't exactly kill me. Here, tweaking one's colour scheme easily solves this in one fell swoop and takes just under a minute tops. No need to go "ML-ish FP" just for the lack of curlies. =)
        dmitriid 9y ago
        It's basically a struggle between "too much syntax" and "not enough syntax" :)
  - alphaalpha101 9y ago
    Lisps genuinely have fewer brackets than C-like languages. They're just more consistently in the same places.
chenglou 9y ago
I made this release, and I also don't understand, and I do mean this _very honestly_. Aside from familiarity that is. But the thing to realize is that this syntax change isn't for folks and you and me. We'll be fine with either.
- bjz_ 9y ago
  But the syntax adds a layer of obfuscation over the mechanics of currying. I thought we were getting somewhere with Elm, Purescript, and Reason adopting it and making it more widely known, but then we've gone a step backward again. I kind of feel like we need better communication and education rather than just doing a band-aid fix that only helps folks in the short term. :( Did you consider having a 'beginner mode' Reason, then flipping a switch to compare it to compare it to the non-parened version is?
  - chenglou 9y ago
    I'm gonna argue beside the point, but currying has negative semantics and type system impact in a language with uncontrolled side-effects. It also prevents some optimizations and new type features. Don't take my words for it: https://github.com/facebook/reason/pull/1299#issuecomment-309032848 https://github.com/facebook/reason/pull/1299#issuecomment-30... https://realworldocaml.org/v1/en/html/imperative-programming-1.html#side-effects-and-weak-polymorphism https://realworldocaml.org/v1/en/html/imperative-programming... https://drup.github.io/2016/08/02/difflists/ https://drup.github.io/2016/08/02/difflists/ https://bucklescript.github.io/bucklescript/Manual.html#_callback_optimization https://bucklescript.github.io/bucklescript/Manual.html#_cal... I'm jumping into this conversation early on because too often this point is raised and turns into an uncharitable interpretation of our motivations, e.g. "look at these js programmers, not understanding the beauty of currying". Rest assured that we do (and that we're not just js programmers), and that the Merlin and BuckleScript authors know very well what they're doing. Hope this clarifies things a bit.
    - bjz_ 9y ago
      I'm not talking about you not knowing, I'm more worried about language designers talking down to programmers for short term gains, rather than trying to raise them up with tools that will benefit them in the long term. Interesting about argument syntax + effects. I've mainly used currying in pure languages. Is it about accidentally calling an effectful function multiple times? Is the idea here that you are conservatively treating everything as effectful with the uncurried syntax (before algebraic effects land), then will make pure stuff curried in order to attract people to use pure functions where possible?
tomc1985 9y ago
Because if there aren't enough symbols the language looks too much like Visual Basic

dualogy 9y ago

IMHO "functional scripters" with a penchant for fewer parens, braces etc and a tendency towards ML-style should seriously embrace PureScript, it's such a terrific project, just gets way too little hype. That's not to rain on ReasonML of course here, which I observed for a while as a very cool transpilation project and kudos to the devs! I'd take a reason project over JS/TS/Ecma any day still

christophilus 9y ago
I really like PureScript. The one thing that kept me from deep diving into it was that it lacked efficient immutable data structures, unless I'm mistaken. It basically is immutable by doing full copies with variations, no? That seems like a pretty big downside.
- dualogy 9y ago
  Some truth to this possibly. This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. I mean PS arrays/records map to JS arrays/objects as far as passing/return them, but for those few cases where you really need to mutate inside-a-(no-longer-pure)-func, it's JS-FFI-hackery or (more likely often) a readily-available 3rd-party package offering the persistent or mutable data structure to serve the need at hand. Might not want to write your WebGL 3D game's game loop or a very mathy 2/3/x-dimensional "big array" re-calculation entirely in PS perhaps, sure enough. Depends on what apps you have in mind I guess. Typically in JS what's become more common recently is to map over the structure, extract the small sub-set you actually want to process (reduce/filter) and in the end these copies often turn out small and not so scary. But as always, "it depends". Truly the PureScript/Haskell/Elm family makes mutation harder than all other languages --- with the flip-side that they make immutable purely-functional expression vastly more ergonomic IMHO =)
  - christophilus 9y ago
    I guess I'm thinking more along the lines of Clojure(Script) which has efficient immutable lists, vectors, and maps. It doesn't do a full copy every time you do a cons or assoc. It seems to me that PureScript would really benefit from having something similar baked in.