Re: [Caml-list] about OcamIL

[ben kuin <benkuin@gmail.com>]

> So your argument as such says nothing about JVM
jon-bot: yes it does, look at those numbers here: ...
goswin-bot: no it doesn't because: ... startup time ... hotspot ... server
...
jon-bot: moron
goswin-bot: liar

So far the typical java-shootout pattern.

Maybe another approach would be to compare the JVM and the CLR in the
realworld. I think it's interesting that on the ms-windows platform
.net is used for everything with great success:
- desktop apps (mostly .net: windows forms, wpf / c++ is dying)
- web apps (mostly .net: asp.net / asp and com are dead)
- backend services (c++ and .net apis: sharepoint, ... / dcom is dying)

Compared to that I think the jvm is only succesful when it comes to
'backend services', which often play an important role in big and
often technically conservative companies.
 There are (great) desktop and web apps in java but they require much
more expertise then the clr equivalent, they are fewer and often more
expensive. That means on the linux platform we have the following
situation:
- desktop apps (highly fragmented/diversified)
- web apps (highly fragmented/diversified)
- backend services (c++ and jvm)

I think it's safe to say that on the linux platform we have NOTHING
COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't
java doesn't fill this gap? My guess is that:

   For desktop and also web apps startup time, memory usage and ease
of deployment are too important that most developers are happy with
the compromises that the jvm offers. So they do :
- use php, ruby, perl, python even for huge applications (without
typechecking at compiletime)
- write all sorts of extensions in c to speed up: XS, cython, ... (yuck)
- write all sorts of bindings to c libraries: PyGtk, ... (yuck)

With the result of fragile desktop apps and bad scaling web apps and
the consequence that we use a lot of time of hack around those
problems. I think something like the clr would be a huge progress
first and foremost for the linux programmers. Maybe Ocaml could play
an important role of providing a slick api, because of its strength
when it comes to language implementation (compilers), so we would
have:

gil ( gnu intermediate language, a bytecode )
gilrt ( gnu intermediate language runtime, a jit based vm)

- the gilrt written in c or c++
- an Ocaml binding to the gilrt
- different language implementations gPython, gRuby, gC, gJava
(Language to gil compilers written in Ocaml)

Or maybe that's just crazy talk ...
ben



-









On Fri, May 14, 2010 at 5:17 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Jon Harrop <jonathandeanharrop@googlemail.com> writes:
>
>> Xavier Clerc wrote:
>>> Limiting myself to the JVM...
>>> Moreover, at least Scala and Bigloo deliver excellent performances.
>>
>> I have benchmarks where the JVM is well over 10x slower than .NET. So I do
>> not regard any JVM-based language as "high performance".
>>
>> Cheers,
>> Jon.
>
> You can pretty much write a benchmark for any 2 languages that
> specifically targets the weekness of one and the strength of the other
> showing that one is better than the other by a wide margin. You can
> usualy reverse the argument with a different benchmark.
>
> So your argument as such says nothing about JVM, just something about
> your benchmarks.
>
> MfG
>       Goswin
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>