Notice: Please don't take this Issue as offensive or trolling, its a genuine doubt.
So, is there any special reason why Flow is made mostly upon OCaml instead of JavaScript? I'm sure there are definitely some reasons to choose using it (probably performance, if I had to guess), but as I couldn't find anything on Facebook's Dev Blog or Flow's documentation, I felt the need to ask over here.
Are there any special reasons to do so, instead of developing it fully in JavaScript (and enabling its installation via npm on all OSes)?
Great project, and badass work on here thought, keep the good job and thanks for this tool!
kazzkiq
All 6 comments
And what do we use to do static analysis for flow that is implemented in javascript? it's a chicken-egg problem
arypurnomoz
on 2 Apr 2016
Ocaml being a Statically typed functionnal language, is simply a better tool for this kind of job.
sledorze
on 2 Apr 2016
@arypurnomoz, like @kazzkiq, I do not mean to be offensive but isn't bootstrapping common? I know Flow isn't a compiler but I think the same principle applies.
bookercodes
on 2 Apr 2016
@arypurnomoz I can't even start to imagine the quirks both TypeScript and Flow core teams had to deal with when building those tools, and they surely had to face _obscure_ bugs and architecture concerns. But despite that, TypeScript still opted to be made using JavaScript(TypeScript).
So I got genuinely curious as to why Flow decided to go with another approach choosing OCaml instead of JavaScript or Flow's syntax itself.
kazzkiq
on 2 Apr 2016
A lot of people including the Flow team believe that functional programming
languages like OCaml are great for writing compilers. These kinds of
programs make heavy use of abstract data types and pattern matching. Plus,
OCaml's nice interop with C and fast running times make it an ideal
language for systems programming / scaling for perf.
Bootstrapping is cool but we'd still have a compiler to maintain after the
initial coolness fades away.
What's more, OCaml can be compiled to JS so we don't _have_ to give up on
JS interop either.
-Avik.
On Saturday, April 2, 2016, Claudio Holanda [email protected]
wrote:
@arypurnomoz https://github.com/arypurnomoz I cant even start to
imagine the quirks both TypeScript and Flow core teams had to deal with
when building those tools, and they surely had to face _obscure_ bugs and
architecture concerns, but TypeScript is made 100% in ... TypeScript. So if
it managed to use its own language to make a compiler, why Flow didn't
followed the same path? I just ask that because I got curious about Flow
choosing OCaml instead of JavaScript or Flow's syntax itself.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/facebook/flow/issues/1619#issuecomment-204806691
avikchaudhuri
on 4 Apr 2016
@avikchaudhuri Great, thanks!
kazzkiq
on 5 Apr 2016
Related issues
danvk
·
73Comments
opensrcery
·
88Comments
jamesisaac
·
44Comments
TylerEich
·
49Comments
STRML
·
48Comments
Most helpful comment
A lot of people including the Flow team believe that functional programming
languages like OCaml are great for writing compilers. These kinds of
programs make heavy use of abstract data types and pattern matching. Plus,
OCaml's nice interop with C and fast running times make it an ideal
language for systems programming / scaling for perf.
Bootstrapping is cool but we'd still have a compiler to maintain after the
initial coolness fades away.
What's more, OCaml can be compiled to JS so we don't _have_ to give up on
JS interop either.
-Avik.
On Saturday, April 2, 2016, Claudio Holanda [email protected]
wrote: