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 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.
