From my reading of Hong Bo’s comments about it, it sounds like the “let-op” feature may be supported in the future – probably not soon because of the dependency of that on moving to a newer version of the upstream OCaml compiler code – but because of my own lack of knowledge I don’t believe I understand the idea behind Cheng Lou’s comment that “we’re not very interested in anything functors/applicative/monads beyond letting them exist.”
I wouldn’t call myself a functional programmer – I’ve done some limited Haskell and have been dabbling with ReasonML for the past few months, and I gather let-op syntax would somehow fill the role of do-syntax in Haskell – but I don’t know enough to understand what Cheng Lou is referring to with that “beyond”? A big chunk of my interest in ReScript is tied up with functional programming. So I’d like to understand better, as an outsider, what I’d be getting and not getting by personally investing more in the language.
Can anybody help me understand this better? Maybe: What are some examples of things “beyond letting them exist” that might be out of scope?
I’ve not felt so much that a language hit all three of practicality, of being somehow a significant step forwards, and having an ecosystem I wanted to deal with since adopting Python in 2000 or so – and I’m looking for reasons to hold on to that.
By the way, I meant to add I think I’ve already benefitted from hanging around a bit, having @yawaramin seemingly answer every question I have, and reading around in the general area of this community, so thanks.
Yes, whenever ReScript is being updated with newer OCaml versions, you may be able to use newer syntactic features as well.
So the reason why he said that is because we needed to draw a line somewhere to be able to align the ReScript community on a JS friendly mindset, that is also compatible with future ReScript features. The major selling point of ReScript shouldn’t be that it is a functional programming language (that’s just an implementation detail). The goal is to have a language that allows you to quickly build products and well performing user interfaces. We don’t necessarily care too much about the paradigm, but more about cherry picking the features that help us reach our goal.
The let-op operator specifically is tricky, because it’s too abstract for our liking. Ppl got excited about that feature because they finally had a potential solution to handle async processes (aka async / await) or boxed values (nullables, options) in a cleaner way. We think it’s worth having dedicated syntax for those very common cases, instead of allowing a highly generic operator. It’s a better way to align users to one way of doing things, while having an even cleaner looking, easier to use syntax.
(Especially for the async / await thing, there are also plans to introduce a small coroutine based layer on top, which would make JS async programming even nicer)
Besides that we saw a lot of (sometimes code-golfy) patterns, where users tried to express everything as a monad, including highly impure entities like the DOM, which unfortunately will never be easy nor safe to express no matter how many indirections you add in between. These constructs also appear to be hard to optimize for the JS use-case.
I am not entirely sure what you mean by that, but maybe let’s frame it in a different question: What is your goal of learning ReScript? Do you want to use ReScript because you want to do “real functional programming”, or do you want to use ReScript because you believe you will have an easier time building and maintaining JS / Node applications?
In case you are looking for a language that relies on mathematical terminology and rather builds on abstract constructs, then you might be better off in more traditional functional programming communities, such as pure OCaml, Haskell, PureScript, or in a light version even Elm.
In case you want to use a language that leverages a subset of functional concepts (with a simpler, more concrete terminology) that compiles to very idiomatic JS with a nice interop story to integrate in your existing (React) JS / Node apps, with concrete syntax to tackle specific JS problems, then ReScript is definitely worth your time.
Please be aware that we don’t say that any of the concepts mentioned above, or the letop operator specifically, is bad, and we don’t try to discredit, nor forbid them. Different platforms have different needs, and we try to give at least some directions for our average users to make them as productive as possible. Also you will still be able to do your typical FP stuff if you want to, but we don’t want everyone to think that they are now forced to be a Haskell developer just to be able to use the language.
I’m not 100% clear whether this philosophy – which on a technical level makes a lot of sense to me – is likely to translate into “special support for common cases + let-op” or “special support for common cases + no let-op”? From what Hong Bo said, sounded likely the former eventually, but my impression is that Cheng Lou isn’t so warm towards that. And if the former, whether that may likely mean particular compromises that might make some more general uses less of a good choice in ReScript than they might be in OCaml for example?
Perhaps the reason for that is simply that is as yet undecided
I assume this was strictly a rhetorical question to help explain. But for what it’s worth, here’s my datapoint anyway (abbreviating):
I’m unashamed to say: those were not the only reasons to get interested, but definitely both, if I interpret “real functional programming” to mean learning more about functional programming, and using what I learn, on my own terms.
One reason I’m here is that I see ReScript as a way to learn about functional programming without losing all productivity for a long time. That doesn’t mean I see my destination as Agda for the FP bragging rights (nor even Haskell or Elm: certainly there are things I don’t like there), nor that I don’t see ReScript as a tool I want to use to write applications – but seeing significant room for learning would certainly be a major plus point in my eyes. I guess I’d be surprised if I was alone in that.
You’re definitely not alone in that. Coming into ReasonML a while back, I definitely saw it as a gateway drug to hardcore OCaml programming That’s still an option: even if (at some indefinite point in the future) ReScript will totally lose compatibility with OCaml, I think I’ll still have learnt way more about OCaml types, modules, etc than using, say, TypeScript.
But I also recognize than exploring new programming techniques and paradigms can be a very different goal to being productive. I mean, I’m very interested in trying Lisp or Haskell (or C, or Ruby, or Forth), but I probably wouldn’t choose any of those languages for any significant project. But I’d probably pick ReScript for any reasonably long-term project any day, even with the current state of its tooling. Whereas using some promising FP feature in a long-term project and after a year discovering it doesn’t make your code very readable would be a rather expensive mistake. So I very much see where the ReScript team is coming from.
Also, it does seem like a little feature like let-op will do no harm, but any feature, however small, might have serious repercussions, and I totally wouldn’t want ReScript to turn into a huge-ass, feature-creepy behemoth like Scala or C++
