On Thursday, 5 January 2017 21:46:26 UTC+7, Bob Zhang wrote:
>
> Indeed, in OCaml native backend, `for loop` still dominates the
> performance critical code since most optimizations does not work across
> function boundaries.
> There is still a long way for optimizing compiler to catch up with
> carefully tuned code, but BuckleScript does not get in your way, you can
> still write low level code with type safe guarantee in it when performance
> matters
>
To anyone that might try to get something useful out of this thread, after
a week of trying BuckleScript, PureScript, and Fable (I couldn't get GHCJS
to install on my machine), I have the following observations:
1. As Hongbo asserts, BuckleScript is the fastest of the ones I tried,
both as to run speed and compilation speed. It also doesn't get (much) in
the way of writing imperative code for the very fastest output, nor does it
(much) obstruct the forced generation of pretty much any JavaScript special
functions one might want to call from BuckleScript or Elm. My main
objections to it is that it gets very wordy and obscure when one has to
force it to generate uncurried calls to special JavaScript functions, and I
have grown to hate OCaml syntax even more than I ever did as feeling very
archaic compared to more modern feeling functional languages as F#,
Haskell, and Elm: not a white space language, no operator overloading
other than through modules/"Functors" which have a run-time cost - quite
usable but that doesn't mean I like it.
2. Fable is a great concept using F# (one of my favourite languages) as
the front end and outputting JavaScript through using Babel; however, it
isn't (at least yet) mature enough to consider: it is slow to compile
(likely due to adding passes in compiling to F# AST, then converting to
Babel AST, then finally compiling to JavaScript) and in many cases to run,
this last much due to poor emulations of F# libraries but also generally
poor code generation. It doesn't have tail call optimizations at all
although there is a plug-in that looks that it would do the job and as for
BuckleScript/OCaml, one can use imperative code if one must. One can
output (emit) any JavaScript one might desire for calling from Elm or
Fable, and such code can have type signatures attached for (some) type
safety. Other than speed, my main problem with it is difficulty in
controlling when functions are curried or not, which is a problem for
temporary functions used functional style. This pretty much invalidates
writing functional code when one has to drop to imperative code frequently
in order to get performance. If only one could decorate functions to show
whether they are to be called non-curried as one can in BuckleScript
("[@bs]").
3. PureScript in a very powerful language comparable to Haskell, but
being Haskell-like, there is no provision for writing imperative code at
all, meaning that one would need to write Javascript in order to accomplish
this. That pretty much precludes PureScript's use for me, as the things I
need it for involve speed and its more work writing JavaScript modules in
some other language and then calling them from PureScript (which is quite
easy) that I may as well do it more simply from Elm. There also that
PureScript depends on many library functions do be able to have its
Haskell-like complexity, so anything done in the language idiom is going to
be quite bulky; also, calling those features have a run-time cost so are
slow.
4. Although I could not try it, I suspect that GHCJS will also depend on
many library calls in order to emulate what GHC/Haskell can do. I did not
investigate whether one can emit JavaScript directly from the language and
how easy it is to call JavaScript from the language, nor do I knkow how
compilation speed compares.
BuckleScript can do basic transformation of tail calls inside (some)
functions into loops, but not in all cases; however, within about a year
that capability won't be vary important as all mainline browsers and nodejs
will do this themselves once the ECMAScript specification is formalized
(currently in flux) Other optimizations such as not making unnecessary
function calls (which lack of in Elm started this thread) or creating too
many objects will become the more important optimizations.
My general conclusion is that while one could use BuckleScript for the
purpose of generating the fast JavaScript that Elm currently cannot, one
has to be pretty committed to its use and is going to have to some
imperative code in a language where writing imperative code what it was
designed to do. For some uses, one could do the same in Fable but it
generally is very slow at anything functional (I measured up to about six
times slower than BuckleScript due to overuse of JavaScript objects. I am
starting to think that one may as well write in TypeScript in order to
avoid having to know JavaScript too well (using TypeScript classes and
interfaces is an option but not compulsory and have a slight run time
cost), which was my first thought. However, I do admit that BuckleScript
can do the job if one is willing to live with OCaml syntax and typing.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
