Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reason: A new interface to OCaml

facebook.github.io

Post reply on HN
Print view View original

281–290 of 294 posts

Re: Reason: A new interface to OCaml

#281

Post by eru »

tom_mellior wrote: post #224
weberc2 wrote: post #11

Earlier quoted context omitted.

This definitely makes me feel more warmly toward OCaml. Syntax has kept me away in the past. It's silly, but it's really hard to evaluate a language if you can't read the examples.

> It's silly, but it's really hard to evaluate a language if you can't read the examples. No, this is not a silly notion. But I don't think the difference Reason makes is as big as you think. I mean, I don't really believe that you can read this: let foo = if (cond) { x } else { y }; foo + 1 but not this: let foo = if cond then x else y in foo + 1

Hmm, the new if syntax really feels like a step backwards. (But I can see why they chose it: the C-like syntax here isn't too much of a burden, and is familiar to a lot of programmers already.)

Re: Reason: A new interface to OCaml

#282

Post by eru »

MichaelGG wrote: post #271
ngrilly wrote: post #267

Earlier quoted context omitted.

You're right about auto-formatting being possible with significant whitespaces... but: When you copy-paste a block of code in another block of code, with significant whitespace you have to correctly reindenting everything very carefully, while with explicit blocks you can let an automatic formatter do the work. When you copy-paste a block of code in chat/email/comment, it is sometimes difficult to preserve significan…

Without examples it's hard to say. Python isn't static, and it's type system isn't as capable as MLs. I'm entirely unconcerned about random formatting systems destroying whitespace. Some eat angle brackets. Maybe I'm not copy+pasting enough. I find "for beginners" to not be useful as a measure of anything - anything can be said to be confusing for beginners. But I can see how people might come to a different opinion.

Haskell doesn't nearly has as much of a problem with copy-and-pasting from websites as Python have. (But in Haskell the significant indentation is much more optional.)

Re: Reason: A new interface to OCaml

#283

Post by eru »

LeonidasXIV wrote: post #229
oblio wrote: post #109

Has anyone here built something say, over 10k lines in Ocaml? How is the development experience? IDEs, debuggers, linters, deployment, etc.

I was working on a 30kloc compiler written in OCaml: - No IDE, I was happily using Vim but many of my coworkers were using Emacs. What helped a lot was Merlin, so I could print the types of the identifiers. This was much more useful than any REPL or IDE I have ever used. - Debuggers: didn't use much, ocamldebug was an okay experience at best - Linters: did not use. Most of the LOC were simple enough to just be obviou…

> - Linters: did not use. Most of the LOC were simple enough to just be obvious.

I imagine an hlint like linter might be useful, and could give you information about common programming patterns. (Ie hlint tells you when you could be using foldr instead of an explicit recursion.)

Re: Reason: A new interface to OCaml

#284

Post by eru »

ngrilly wrote: post #240
runT1ME wrote: post #215

Earlier quoted context omitted.

OCaml is a much more modern language than Go.

Yes and no, depending on which aspect of the language you consider: - Type system -> OCaml is more modern (despite being designed before Go) - Concurrency, parallelism, garbage collector, tooling -> Go is more modern (Reason is improving the tooling with refmt for example; work is ongoing on parallelism)

Interesting. What's fancy about the Go garbage collector?

Re: Reason: A new interface to OCaml

#285

Post by eru »

jordwalke wrote: post #196
wtetzner wrote: post #185

Earlier quoted context omitted.

Yeah, I kinda feel like this whole project is pointless. As many warts as OCaml's syntax has, for the most part I actually like it. It seems like Reason is solving a non-problem. When I first went to the webpage, and saw "Build Systems Rapidly", I thought maybe it was a new build system for OCaml. I was hoping it would be a Cargo-style build system/package manager for OCaml.

"As many warts as OCaml's syntax has, for the most part I actually like it." This is for those people who do not like OCaml because of those warts. If you are one who is already sold on OCaml, it's very easy to forget how many there really are. Regarding "Build Systems Rapidly": Please hang in there and stay tuned. The syntax is there to help people learn ML rapidly. The Merlin integration and syntax formatting tooli…

I'm looking forward to having an OCaml version that looks more like Haskell. :)

Re: Reason: A new interface to OCaml

#287

Post by eru »

evincarofautumn wrote: post #126
stuartaxelowen wrote: post #104

Earlier quoted context omitted.

Indeed, but leaving out the parens makes more work for humans. What does `a b c` mean? `a(b)(c)`? `a(b(c))`? If the only thing that is gained by leaving out the parens is brevity, I don't think its worth it.

It’s no different than having to know the associativity of an operator. Does “a - b - c” mean “(a - b) - c” or “a - (b - c)”? The former, for no reason other than a long history of convention. Same goes for function application. And you could make the same argument about languages that require parentheses for function calls: what does “a(b)(c)” mean? “(a(b))(c)” or “a((b)(c))”? What’s gained is that the syntax mirror…

You get right-associative function application (in Haskell) by putting $ in between your functions.

(And if you are using composition instead, it associates in both directions.)

Re: Reason: A new interface to OCaml

#288

Post by eru »

stuartaxelowen wrote: post #110
jordwalke wrote: post #98

Earlier quoted context omitted.

Please take a look at the FAQ which describes the best way to move forward with evolving the syntax. It helps to know your personal technical background and where you're coming from, as well. I do like your idea, but you can currently use parens - it's just that they aren't required by the parser when the argument is clearly one item (like an integer constant etc). Then at that point, it's just a matter of configurin…

My background is in Python, Scala, Java, C, and Ruby. My reaction is based on the monstrous DSLs I've seen in Scala and Ruby (because the language lets them), where the clever syntax actually hid the important features of the interface. Every time you get to "wait what is this actually doing" and you have to learn another tiny language instead of just writing functions that return a `Future[HttpResponse]` and be done…

That's a valid complaint for new untested syntax that people came up with yesterday.

The paren-less function invocation has been around and tried for ages in the ML-family.

(The main downside is that variadic functions are hard to express this way. For fixed arity this is a clear win, also makes partial application nicer to read.)

Re: Reason: A new interface to OCaml

#289

Post by jordwalke »

eru wrote: post #285
jordwalke wrote: post #196

Earlier quoted context omitted.

"As many warts as OCaml's syntax has, for the most part I actually like it." This is for those people who do not like OCaml because of those warts. If you are one who is already sold on OCaml, it's very easy to forget how many there really are. Regarding "Build Systems Rapidly": Please hang in there and stay tuned. The syntax is there to help people learn ML rapidly. The Merlin integration and syntax formatting tooli…

I'm looking forward to having an OCaml version that looks more like Haskell. :)

To start, we have "fixed" type parameter application syntax. (Most people see this as a win and now matches Haskell IIRC). Some have requested ability for type annotation ayntax to be above the value it annotates.

Re: Reason: A new interface to OCaml

#290

Post by eru »

jordwalke wrote: post #289
eru wrote: post #285

Earlier quoted context omitted.

I'm looking forward to having an OCaml version that looks more like Haskell. :)

To start, we have "fixed" type parameter application syntax. (Most people see this as a win and now matches Haskell IIRC). Some have requested ability for type annotation ayntax to be above the value it annotates.

By the way, do you even need to work towards _one_ better syntax? Seems like you should be able to support mostly whatever syntax the user wants? (Within reason.)
Post reply on HN