[Ur] Strategy - UrWeb Backend

[Gian Perrone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/8/10 12:56 PM, Marc Weber wrote:
> Excerpts from Adam Chlipala's message of Wed Dec 08 00:40:43 +0100 2010:
>> Which benefits do you see from server-side JavaScript?  I'll be really 
>> surprised if any such system can get over the inherent costs of the 
>> JavaScript language, to match the performance and security of Ur/Web.
> 
> Performance does no longer matter much (unless you're Amazon - or
> google) - because servers are so cheap compared to development time -
> and they will be even cheaper tomorrow.

I don't know that this is really true.  Environments such as a LAMP
stack often introduce an unacceptable page load time that simply cannot
be reduced without some shift in the underlying technologies (which
often involves bolting on memcache).  I think that the approach such
that I write some code and it runs in an acceptable amount of time
without any extra work from me is very worthwhile.

> Benefits of JS target:
>  - never think about memory

As a developer-user of Ur/Web, I definitely don't have to think about
memory, and as an end-user there appears to be even less need to think
about it.  In what situations is it necessary to think about memory?

I think Adam already covered the other points.

A word about LLVM, though.  I've recently been working on a compiler for
a functional language which uses an LLVM backend.  In the space of an
evening I also wrote a working C backend for testing purposes.  The
performance is comparable, and the extra effort to go directly to LLVM
yields almost no benefits for a language like SML or Ur/Web, because
there simply isn't the correspondence with these low-level features,
whereas there is definitely an easy mapping to C features that compile
into native code in predictable ways.

I would personally not bother with LLVM unless there were some serious
benefits to be had, such as JIT compilation to enable some specific
goal.  The earlier assertion made seems to have been that performance
doesn't matter, so "performance" can't really be seen as a valid reason
for employing LLVM.  Other than that I see no benefits to it for this
kind of project.

- --Gian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJM/tAYAAoJEDd5xfOXfbYMMEIIANL+McSW6UDSe7MxU6KnyoKX
A10Io9ZmCuh4bLqeaM/OMxvODLZLlHYpbGAIKNmpLqOryHIoC4Do+lkx6dkXDJjg
Gev8bdq7r2QMIApmViG1RmnFJCngOu3DlD+Vmf37W6Dqzw3rksKDtzx+HwEhVzVp
qMLTswHKFUGGYnmhMCeJOnhP+Ld55UlC+ZgbmyJYkmwH1cZ/d9UMOtglbBGq2vNu
kc7dFCY0QhpY7I+B9pbDy19bgE7IoN04c0sDj2U1PHyamcHsg2mlo6wKLofRnKaJ
RHBsVX/jHiIzyxpKoYuAmOMorNMa1Kl2deId2W/CZlQUE8abQBlK3x8FYzsVACk=
=75OI
-----END PGP SIGNATURE-----