@richiardiandrea Maybe ask them when was the last time they chose C compiler based on the clarity of the output assembly, and ask why do they need readable JS if debuggers can apply source maps?

@richiardiandrea why would you ever need to read the compiled CLJS? thats what source maps are for

@thheller Likely the answer will be "source map tooling is terrible and does not work, and all fancy compilers we tried suck and produce buggy output"

hmm dunno .. I'm fairly certain that CLJS with source maps will be far better even in :advanced over anything that just has "pretty" compiled output but no source maps

@thheller I'm talking about perceptions of people from JS world.

I'd be curious how something like this looks compiled https://facebook.github.io/reason/#diving-deeper-pattern-matching

but really doesn't matter, FWIW I spent quite a bit of time reading CLJS compiled before source maps and still do. It isn't bad.

Yeah the perception of JS folks is that the js needs to be debugged, source maps do the job in other languages, in cljs a bit less and the output of the compiler is difficult to read. Personally I never found this a problem as I never debug cljs. I need to show a bit what Dirac does though, it probably is the closest to what JS devs are used to.

Especially for enterprise and node.js, I am told, it is something that will happen a lot. The output of TypeScript or BuckleScript is closer to what JS devs know how to read (for instance no name mangling). In any case it is an interesting feedback, still for me not enough to choose those languages over cljs. For sure not TypeScript...Maaan, super mutable 😀.

@richiardiandrea you can test some code snippets here: http://bloomberg.github.io/bucklescript/reason-demo

the pattern matching reason code compiles to reasonable js

Yep I saw exactly that

I also like how they use short comments to add some context to generated code

And my colleagues too, we are in the evaluation phase of the main language (node.js) for a project and there are many things that are well done in Reason/Bs

But I am of course pushing for cljs ;)

Would be interesting to see exactly what reason did to ocaml, but with lisp-y frontend instead

maybe cljs-like language compiled to ocaml (so it would be usable with bucklescript as a backend)

not sure how hard it was to do reason, but I assume parsing lisp would be easier, codegen would be probably similar

@darwin I have just PR-ed repl integration for Reason and code parsing is not that hard because everything is scoped so they got rid of many OCaml weirdnesses that way

have to go, will look at reason in more detail soon