Hi Gorden, Thanks for your lengthy reply. I didn't try to convince you that OCaml is better than Haskell, they are different styles : ). It just feel a little weird that "when you want performance, you should switch from a statically typed language(elm here) into a dynamically typed language(js)", a decent compiler should produce much more efficient js output than hand written js, note that I have been working on BuckleScript compiler for only one year, there are still many low hanging fruits there and you can expect even better performance in the near future. Some minor corrections to your comment - I am quite familiar with Haskell, OCaml, and F# (did 3 years research in PL, I learned F# first, Haskell later and OCaml as the last one), the expressivity of type system in my opinion follow as below: Haskell ~ OCaml > F# >> Elm (OCaml has a fairly advanced object system with structural typing and row polymorphism which is incredibly useful to build FFI to JS objects) - If syntax matters a lot, you may be interested in ReasonML, Facebook are working on a new syntax for OCaml and it works seamlessly with BuckleScript, some core ReactJS developers are also working on high quality ReactJS bindings Happy New York and enjoy your favorite language!
On Sun, Jan 1, 2017 at 11:04 PM, GordonBGood <gordonbg...@gmail.com> wrote: > On Sunday, 1 January 2017 22:27:40 UTC+7, Bob Zhang wrote: >> >> Note that a high quality optimizing compiler like BuckleScript >> outperforms native JS significantly > Elm. >> (See the benchmark here: http://bloomberg.github. >> io/bucklescript/slides/preview/bb-reveal-example-presentation.html#/5/1) >> >> >> The only reason that I suggest these things is that I agree with Evan >>> that JavaScript would ideally only be used as necessary in libraries, with >>> the majority of applications never having to deal with it; however, with >>> the current version there seems to be various applications where Elm code >>> is not performant enough. >>> >> > Bob/Hongbo, I don't argue with you (and you have clearly demonstrated) > that BuckleScript (and the OCaml front end) are fast. The reasons I don't > care for OCaml particularly for general use is the paucity of primitive > data types (as discussed) and limitations of its type system in general as > compared to more modern ML type languages such as F# (which syntax and use > I quite like) and Haskell, and the feeling I get using the OCaml syntax > that it is a prototype of a modern language but not quite there. With > clearly long familiarity, you are used to overcoming OCaml's "warts", but > for others these are real obstructions to the common acceptance of the > language. > > You have replied that for BuckleScript's use with JavaScript as output > also having limited types, the limitations of primitive types has been > overcome, and I can see how it could as long as one is using a 64-bit OCaml > compiler so that Int's are large enough to fully express a 32-bit range > (remember those OCaml tag bits). For this limited use of output to > Javascript, many of Ocaml's "warts" aren't a problem. > > My latter complaint is more apt I believe: > > 1. Come now, tag bits like a dynamically typed Lisp-type language for > a statically typed language? This really harks back to List-type > dynamicall typed languages. > 2. Requirement for semicolons as an end of block (or even dual > semicolons such as global imports?) at certain key places, although granted > those are mostly for imperative forms of code with `do` thatwe would > prefer not to use (while/for)? > 3. In spite of being white space delimited, also requiring that sub > blocks be delimited by begin..end or brackets? > 4. I'm sure there are others as in the definition of the type system... > > However, your implementation is most usable and valuable as for this use > you seem to have overcome most of the limitations of OCaml, and for many > small uses your provision of a the online compiler in the "try in browser" > page is so useful that one doesn't have to go to the work of downloading a > good IDE (OCaml-Top or Visual Studio Code plus plugin) plus the node > bucketscript plugin. Thank you very much for bringing it up, as it appears > that your implementation is ahead of the alternate JavaScript Transpilers > as to stability and immediate usability, perhaps partially due to the > stability of OCaml. It is impresive that a fairly young project produces > such incredibly efficient JavaScript code! It seems that your project is > also well supported by a corporation, so it isn't going to disappear as so > many other one-horse-pony's do over the course of time. > > As developer of the program, you can be most proud. Your project is both > practical and eminently usable. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/elm-discuss/Um7WIBTq9xU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Regards -- Hongbo Zhang -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
