4 ms·
Jordan here (I work on Reason) I've mentioned elsewhere that the primary goal for now was to get the tooling automated as much as possible, so that when we rec
by jordwalke 10y ago
Jordan here (I work on Reason)
I've mentioned elsewhere that the primary goal for now was to get the tooling automated as much as possible, so that when we receive common feedback, we can adapt to that feedback and trivially migrate people's code forward.
I don't think JavaScript's syntax is a selling point and I am someone with a lot of JavaScript experience. I also don't think that OCaml's syntax today is a selling point, and I have a bit of OCaml experience. Both of these syntaxes have evolved over time, working within that limited precious syntactic real estate, trying so very hard to maintain compatibility with decisions made decades ago. Reason's approach is totally different in that it knows we won't get it right on the first shot so it puts into place the tooling for upgrading and beautifying as we learn lessons and take feedback from the community. It places the syntax closer to the user, even if only conceptually.
That being said, the current syntax is not intended to be a JavaScript clone by any means. It actually started in the opposite manner - by taking the top 15 complaints about OCaml's syntax, by experienced OCaml programmers (not JS programmers) and fixing them. There were a couple of things that didn't really matter (such as how you express comments) that were just changed to be more familiar because, well.. simply they don't matter, and even experienced OCaml developers want the largest possible set of people to be able to read their code as long as that comes with little other tradeoffs.
- kangar00 10y ago> I don't think JavaScript's syntax is a selling point Under "Why OCaml?" on the Reason page, it states, "OCaml has a very mature (and still growing) ecosystem for targeting browser and JavaScript environments with a focus on language interoperability and integration with existing JavaScript code," and "Reason‘s non-invasive approach to the OCaml compiler allows Reason code to take advantage of all of the existing OCaml compiler optimizations/backends such as ... and even JavaScript compilation." It seems like what's being said is that one of the main goals for Reason is to integrate with JavaScript, and it would seem to make sense instead of changing between language syntaxes, you'd want more in common between them, so it makes sense why they are similar. I'm confused as to why you seem to be trying to distance Reason and OCaml from JavaScript, when it definitely seems like the similarity with and integration with JavaScript would be a driving factor in Reason's development now, even if maybe it wasn't in the beginning. Reason seems really cool, btw.
- jordwalke 10y agoI personally think that JavaScript is one of the most meaningful and important languages that exists today. This needn't imply that JavaScript's syntax, or its semantics are to be emulated (though we're seeing a bunch of welcome improvements in recent versions of JS). The thing I like most about JavaScript is that it allows anyone, anywhere to easily deploy and share code with anyone anywhere. So I hope this helps explains why many people feel that compiling to JS is important, even if the syntax/semantics of JS are not equally sought after by those same people. At the same time, we can't overlook that JavaScript has become one of the most popular languages today. If that were the case thirty years ago, I'm sure the syntax for the ML family would have taken that into account somehow, at least to convey the parts of the two languages that actually are similar - even if only for things as simple as comments. So at least in this V0.0.1 of Reason, some of the things that just don't matter tend to look like things that are familiar to a larger set of people. I think you've picked up on what looks like an inconsistency in messaging so thanks for pointing it out. I can't speak for everyone else who works on Reason, but I see the two major components (compiling to, and resembling) JavaScript to be largely independent. We can want to compile to JavaScript for totally different reasons than we want some pieces of the grammar to resemble JavaScript and I believe that is the case here. The pieces that currently resemble JavaScript are that way simply because those pieces don't matter too much and why not just be familiar? There are certain syntax features of JS that members of the JS community would tell you were mistakes, and we're not looking to recreate them just for the sake of being like JS.
- rixed 10y agoThe top complain I've heard about syntax is that too many people focus on it ;-p Maybe that's because it's the first and only thing one can see and therefore it's cheap to have an opinion? Or is it because too many professionals are used to languages which are little more than a syntax on top of a toy evaluator? When I first try ocaml long ago, I though overcoming the syntax would be a huge challenge (especially since I was using lisp at the time). Surprisingly, I got used to it after the first night, and even started to like it. Just a single data point of course, but it seems useful to warn new programmers that your first impressions on the syntax of a language are just that. Also, your estimation of the time that would be required to learn a new language based on how easily you can parse the syntax at first sight is completely wrong. It took me longer to understand some error messages that the compiler threw at me long after I though I could "speak ocaml" than to build an initial understanding of the syntax (roughly 2 hours). All of the above, of course, is just a disgruntled and grumpy way to say: despite we all know we don't care about the syntax of any language once we know it, it's still an overly important factor to drive a language adoption (or, in the case of ocaml, disaffection). Therefore, let's hope this new "revised syntax" will help many more programmers discover more sophisticated languages than the industry standards!
- LeonidasXIV 10y agoI am not a fan of introducing curly brackets in a similar way I am not a fan of curly-bracketisms in F#, it makes for a clumsy noise to a relative distraction-free language like OCaml. It feels like trying to get Algol-family programmers on board, whereas OCaml users have been using ( and ) as well as begin/end since a long time. But an advantage I see with the new comment syntax is that there are is that there is no ambiguity what the hell (*) is. At least this.
- smoothdeveloper 10y agoCurious what are the curly-bracketisms in F#?
- kirse 10y agoExpressions of various kinds - Async, seq, query, etc; record type "constructors"... that's all I can think of off the top of my head. F# in general is a beautiful language though, I can't say I've ever thought about the "curly bracketisms" personally because I'm too busy being excited about how much fun it is to write over C#.
- davidpelaez 10y agoIt's great to learn about the process. Sounds amazing. I agree that JS syntax is not a selling point, from what I read the approachability of a wider audience is. However I agree that care should be taken not to fall to easily in stripping away most of the ML interesting things and end up with everything looking the same. Go, Rust, Swift, JS it's all about the same. For different languages their "user interface" is extremely similar. I think that with your proposals you have shown a great suitability to discover the balance between being different and being accesible, I don't think they have to be opposed as many language designers seem to be convinced.