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

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.

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 =)

> This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone.

The JS world has this in Immutable.js, which provides a set of persistent data structures that are excellent by any measure. However, since it's not the default data structures provided by the language, practically no third party library actually consumes/emits them as input/output directly.

What this means in practice is that most of the performance benefits of structural sharing through Immutable.js ends up being outright negated many-times fold by the necessity to recursively convert to and from JS native collections at the edges of your system that inevitably needs to call out to/consume data from third party libraries. Not to mention that the developer ergonomics of working with Immutable.js pales in comparison with that of native JS collections, since you're limited to the traversal and manipulation APIs provided by the library, and have to forgo excellent functional utility libraries like Ramda [1], and handy language features like destructuring and spread.

This is why even in systems that embrace immutability like Redux, the prospect of using Immutable.js comes with a huge list of caveats that are well documented [2], driving most developers to end up choosing JS native collections and doing naive copy-on-write without structural sharing across the board.

[1] http://ramdajs.com/

[2] http://redux.js.org/docs/recipes/UsingImmutableJS.html

In contrast, in the ClojureScript ecosystem, everything uses the default persistent collections, and so this is never a problem.

I thought that Reason implicitly used Immutable-Re and Bucklescript implicity used Immutable, similar to how Clojurescript implicitly uses its own library from these structures. That is, if you write wholly within the language, you get the benefits of these structures without thinking about it. Is that not true?

GP was talking about PureScript, not Reason. To be honest, I have very little experience with either, but I just wanted to chime in re: the persistent data structures as a library topic with an anecdote from the JS side.

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.

It does have efficient maps (purescript-maps) and listss (purescript-lists). Couldn't find any package which provides a Vector type that is not optimised specifically for math operations which always operate on the whole vector (multiply, add, dot product etc).

Ah. Right. My impression was that most PureScript code just uses plain JS objects / arrays, though. Is that not correct? If the ecosystem isn't built around the efficient immutable data types, much of the advantage disappears.

When is Purescript going to get rid of the need for Bower? That's a pretty significant turn-off for most folks :(

As others have mentioned, psc-package can be used so there is no "need" for Bower.

"Why the PureScript community uses Bower" explains why Bower was chosen: http://harry.garrood.me/blog/purescript-why-bower/

I don't understand why Bower is such a sticking point for people. It works perfectly fine for PureScript and (as the article explains) was the right tool for the job.

You can use psc-package instead of Bower.

Oh, this is great: https://github.com/purescript/psc-package

Any word of when this will be supported/promoted officially? Just got this response from one of my former JS colleagues: https://twitter.com/keirasaid/status/924169973878046721 - it's pretty hard to convince JS developers to use something that is still recommends using Bower for package management. :/

"Officially" isn't really a thing here, I feel. I mean the `purs` (formerly `psc`) compiler just gets given a list of .purs files from your build setup (pulp, custom make files, a little custom program, whatever) and recompiles what changed to the given output paths. I think they just converged on bower by accident (whatever it professes to offer, the sub-set of features required here for PS apparenty just-worked sufficiently well) but really anyone can manage their packages however they like.

psc-package does* very much look like it's going to be the "sanctioned/endorses/semi-official" tooling for pkg-mgmt one way or the other.

This popped up just now in my feed reader: https://qiita.com/kimagure/items/0d9354900d7a7dbd3864

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

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.

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?

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-30... https://realworldocaml.org/v1/en/html/imperative-programming... https://drup.github.io/2016/08/02/difflists/ 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.

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?

There's a distinction between syntax and semantics though. E.g. Go pushes bad semantics (null values, bad error handling, no generics) in the name of beginner ease, with no transition path to better semantics. Reason pushes 'bad' (JavaScript) syntax but good OCaml semantics in the name of attracting JavaScript devs, with a clear transition path to OCaml syntax should they want to.

Good points. Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term.

I still can't get my head around why it would be an optimization problem too, seeing as it would be most using the same underlying AST. Unless they actually translate the pseudo-parameter lists into actual tuples in the parser, forbidding raw, single argument passing. :/

Yes, as far as I know Reason is the first project to try to have auto-currying semantics with tupled syntax. It's definitely a bit of an experiment.

Not sure what optimisation problem you're referring to, Reason and OCaml underlying AST are exactly the same. There are no actual tuples unless the programmer is creating actual tuples.

I was referring to chenglou's comment[1] where he said "It also prevents some optimizations and new type features."

[1]: https://news.ycombinator.com/item?id=15573956

I think what @chenglou was referring to are issues like the "value restriction" [1] and the need to wrap "uncurried" FFI functions with a function that "adapts" it to curried form, thereby adding a layer of indirection.

Reason does not solve these, they're problems inherent to the underlying language and the choices made. I think the point being made was just that currying isn't a clear step forward, but causes some problems as well.

[1]: http://mlton.org/ValueRestriction

Yeah, definitely agree that there are trade-offs with currying when mapping it to a compilation target like JS, and I am consistently impressed by Bucklescipt's ability to convert the curried versions of functions to regular JS calls. That said, I do still think that it's worth the trouble!

> Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term

_This_, I do think, is a fair argument. It's indeed an accidental drawback of the syntax revamp. Though there are very realistic way to prevent the confusion: https://github.com/reasonml-community/error-message-improvem...

Regarding optimization: see the BuckleScript link on explicit uncurrying. The impact is very visible: the compiler analysis for specializing for uncurrying best-effort, and when it bails, it looks like this: https://reasonml.github.io/try/?reason=PQKgBA5g9lAmYGMCGBnAp... which calls https://github.com/BuckleScript/bucklescript/blob/2a66960b5a.... How many function calls did your curried call just turn into, in the second case?

Unless you introspect the output (which is actually viable to do in a compiler with clean output, such as BuckleScript), you wouldn't know that your higher-order function accidentally became pretty much 4+ calls instead of one. Now imagine quadrupling every high-order function calls or so. BucklesScript (and native OCaml) do a crazy good job of avoiding this when possible, more so than most, as shown in the snippet's first scenario; the manual even shows guaranteed uncurry if you put the right annotation. But if you want to take advantage of _that_ (and please do), there are other tradeoffs as well, but I digress. In general, the compiled code's speed is as good as you can get for JS output.

The perf point alone is not a pedantic argument as you can see. And you might start wondering about other languages' output for currying. Regarding your other comment: yes, from a typing perspective, currying indeed works out wonderfully for pure languages like Elm and PureScript. But OCaml's not a pure language; we've made other tradeoffs; and context matters.

Not sure about your comment about the AST, but I think you're saying that the situation doesn't get better/worse in the new syntax: this is true, since the syntax revamp is really just that: a syntax change. Which is why I said earlier that I was arguing beside the point. But currying seems to attract so much unbalanced attention in this context that I felt I should address it so that it doesn't overwhelm the rest of the syntax change's purpose. Looking at the rest of the threads, it still did, but I'm glad your reaction has been doubt rather than unreasoned negativity, so thanks for that.

> currying has negative semantics and type system impact in a language with uncontrolled side-effects.

Can you explain this? Currying and side-effects seem orthogonal to me.

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>

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.

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 =)

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.

> 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. =)

It's basically a struggle between "too much syntax" and "not enough syntax" :)

Because if there aren't enough symbols the language looks too much like Visual Basic