Jon Harrop jonathandeanhar...@googlemail.com a écrit :
(...)
I don't think this is heated at all. We were talking about high
performance languages and you cited a bunch of languages that get whipped
by Python on this benchmark:
Xavier Clerc wrote:
Jon Harrop jonathandeanhar...@googlemail.com a écrit :
I don't think this is heated at all. We were talking about high
performance languages and you cited a bunch of languages that get
whipped
by Python on this benchmark:
Xavier Clerc wrote:
Jon Harrop jonathandeanhar...@googlemail.com a écrit :
Xavier Clerc:
Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
Xavier Clerc wrote:
Limiting myself to the JVM...
Moreover, at least Scala and Bigloo deliver excellent
performances.
I have benchmarks where
Jon Harrop jonathandeanhar...@googlemail.com a écrit :
Xavier Clerc:
Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
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
On Sun, May 16, 2010 at 5:04 AM, Jon Harrop
jonathandeanhar...@googlemail.com wrote:
Erik wrote:
Jon Harrop wrote:
Not really. Windows supports a far wider variety of hardware than
Linux and
Oh really?
Yes, really.
Well, this does sound a little funny considering that Linux is free
Erik wrote:
Jon Harrop wrote:
Not really. Windows supports a far wider variety of hardware than
Linux and
Well, this does sound a little funny considering that Linux is free
software and has been ported to almost every odd hardware platform,
and how many platforms does Windows run on?
I
Xavier Clerc:
Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
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
hi erik,
I highly appreciate your blog, so it hurts me a little but - I disagree:
The only evidence to support this is the widespead usage of
Java and C#, but I think that is a language choice rather than
a conscious decision to use a language that runs on a VM.
People chose Java and C#
--- On Sat, 5/15/10, ben kuin benk...@gmail.com wrote:
What if ocamlopt would be dropped for a faster
ocaml vm?
Why? Even if the Ocaml was able to target a faster VM,
there
are still many people who would chose to generate
native
binaries.
I'd call that a questionable decision. As
Le 15 mai 10 à 11:45, ben kuin a écrit :
What if ocamlopt would be dropped for a faster ocaml vm?
Why? Even if the Ocaml was able to target a faster VM, there
are still many people who would chose to generate native
binaries.
I'd call that a questionable decision. As far as I know, using
If yes it seems this has not been a big showstopper to Windows apps
err what?? On what planet do you live? It must be a nice place :-)
COM components ( to encapsulate the abi )
DLL hell ( never heard of that? com registration)
STL ( taming the abi)
CORBA ( to talk between incompatible
ben kuin benk...@gmail.com writes:
hi erik,
I highly appreciate your blog, so it hurts me a little but - I disagree:
The only evidence to support this is the widespead usage of
Java and C#, but I think that is a language choice rather than
a conscious decision to use a language that runs on
Goswin wrote:
Hardly any business today has an inhomogene environment. And if the
environment is homogene then the vm gives you 0 advantage. It just
costs you overhead to emulate.
A Common Language Runtime (CLR) is an obvious counter example = the shared
VM gives you safe and high-level
Raoul Duke wrote:
On Fri, May 14, 2010 at 11:59 AM, ben kuin benk...@gmail.com wrote:
but that would be the big benefit of a clr like vm: It doesn't matter
how messed up, chaotic or just heterogen the environment is as long
as you can count on a regular execution of your portable bytecode.
ben kuin wrote:
English is not my first language, maybe I misunderstand, but what
you're are saying here sound like a complete contradiction to me:
Like you say C and C++ are considered as 'unsafe' languages.
Yes. One can't really program in those languages without using
pointers and manually
Jon Harrop wrote:
Not really. Windows supports a far wider variety of hardware than Linux and
Oh really?
I have a three machine here:
a) A Dual PowerPC G5 Apple Mac.
b) A SUN ultra-sparc X1.
c) One of the early Cobalt Qube machines with a MIPS CPU.
All of these run Debian. Can windows
Microsoft was your saviour because Microsoft caused all your problems
in the first place.
Ok, the topic here is personal and office computing. I mean cubical
drones who are not allowed to used right mouse button? Consultants and
their 20 MB powerpoints? Middle management assholes with the
Jon Harrop jonathandeanhar...@googlemail.com writes:
Goswin wrote:
Hardly any business today has an inhomogene environment. And if the
environment is homogene then the vm gives you 0 advantage. It just
costs you overhead to emulate.
A Common Language Runtime (CLR) is an obvious counter
Jon Harrop jonathandeanhar...@googlemail.com writes:
Erik wrote:
Jon Harrop wrote:
Not really. Windows supports a far wider variety of hardware than
Linux and
Oh really?
Yes, really.
I have a three machine here:
a) A Dual PowerPC G5 Apple Mac.
b) A SUN ultra-sparc X1.
c)
Erik de Castro Lopo mle+oc...@mega-nerd.com writes:
ben kuin wrote:
If you really want to torture a developer, these is the best toolset
you get.
You have to be kidding me. I personally think the Microsoft development
tools are completely horrible.
That is what he said. That toolset is the
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.
On Fri, May 14, 2010 at 1:40 PM, Jon Harrop
jonathandeanhar...@googlemail.com wrote:
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
Le 14 mai 2010 à 12:40, Jon Harrop a écrit :
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
--- On Fri, 5/14/10, Jon Harrop jonathandeanhar...@googlemail.com wrote:
From: Jon Harrop jonathandeanhar...@googlemail.com
Subject: RE: [Caml-list] about OcamIL
To: caml-list@yquem.inria.fr
Date: Friday, May 14, 2010, 6:40 AM
Xavier Clerc wrote:
Limiting myself to the JVM...
Moreover
Jon Harrop jonathandeanhar...@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
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
Le 14 mai 10 à 18:26, ben kuin a écrit :
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
On Fri, May 14, 2010 at 9:26 AM, ben kuin benk...@gmail.com wrote:
realworld. I think it's interesting that on the ms-windows platform
.net is used for everything with great success:
Compared to that I think the jvm is only succesful when it comes to
'backend services', which often play an
but that would be the big benefit of a clr like vm: It doesn't matter
how messed up, chaotic or just heterogen the environment is as long as
you can count on a regular execution of your portable bytecode.
On Fri, May 14, 2010 at 8:11 PM, Raoul Duke rao...@gmail.com wrote:
On Fri, May 14, 2010 at
Isn't this precisely the aim of Jon's hlvm
(www.ffconsultancy.com/ocaml/hlvm/)?
that's an interesting question, Here are a few thoughts:
technical:
- in .NET everything is easy (from the surface): you have your source
file (hello.cs) you take your compiler (cs.exe) and compile it to a
msil
-- Forwarded message --
From: Raoul Duke rao...@gmail.com
Date: Fri, May 14, 2010 at 2:42 PM
Subject: Re: [Caml-list] about OcamIL
To: ben kuin benk...@gmail.com
On Fri, May 14, 2010 at 11:59 AM, ben kuin benk...@gmail.com wrote:
but that would be the big benefit of a clr like
Le 14 mai 10 à 23:42, Raoul Duke a écrit :
-- Forwarded message --
From: Raoul Duke rao...@gmail.com
Date: Fri, May 14, 2010 at 2:42 PM
Subject: Re: [Caml-list] about OcamIL
To: ben kuin benk...@gmail.com
On Fri, May 14, 2010 at 11:59 AM, ben kuin benk...@gmail.com wrote
Please. You're not talking about the same thing. Ben talks about the
benefits such a vm would have once it would be done, you talk about how hard
it would be to do it.
i think several things are being intertwined here, i don't agree with
you evaluation of the discussion.
sincerely.
Please. You're not talking about the same thing. Ben talks about the
benefits such a vm would have once it would be done, you talk about how hard
it would be to do it.
Exactly, thanks.
I assume it's save to say that most today (business) critical
applications have to be written in a vm
ben kuin wrote:
I assume it's save to say that most today (business) critical
applications have to be written in a vm supported language.
Why do you assume that?
The only evidence to support this is the widespead usage of
Java and C#, but I think that is a language choice rather than
a
Ben Kuin wrote:
technical:
- in .NET everything is easy (from the surface): you have your source
file (hello.cs) you take your compiler (cs.exe) and compile it to a
msil bytecode file (hello.dll). You can run reflection tools to
hello.dll or link it to a exe or generate back to source. This
Erik de Castro Lopo mle+oc...@mega-nerd.com writes:
ben kuin wrote:
I assume it's save to say that most today (business) critical
applications have to be written in a vm supported language.
Hardly any business today has an inhomogene environment. And if the
environment is homogene then the
Ben Kuin wrote:
A little off topic, but how is Mono/Unix these days?
Still leaks memory,
you refer to your examinations?
(http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-
memory.html?showComment=1233522107493#c7872630239059031867)
where you say yes and the mono devs are say
Jon Harrop jonathandeanhar...@googlemail.com a écrit :
Ben Kuin wrote:
I've introduced the post with some license related concerns, maybe I
should take a step back and think about what I want:
1. - programming in a ML like language ( especially the caml family
since I really like those
A little off topic, but how is Mono/Unix these days?
Still leaks memory,
you refer to your examinations?
(http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-memory.html?showComment=1233522107493#c7872630239059031867)
where you say yes and the mono devs are say no to memory leaking?
On Tue, May 11, 2010 at 9:39 AM, Peng Zang peng.z...@gmail.com wrote:
And of course as you pointed out you can always compile OCaml code to native
machine code which has always had good performance.
i was under the impression the main complaint is lack of top-notch
support for concurrency?
1. - programming in a ML like language ( especially the caml family
since I really like those lightweigt type definitions and the pattern
matching that can be applied on those)
2. - high performance runtime, preferably a jit based vm, no problems with TCO
3. - a true open source license
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ah, I guess I think of ocamlrun as just an interpreter. But you're right,
that's also a vm.
Peng
On Tuesday 11 May 2010 07:47:25 pm ben kuin wrote:
OCaml doesn't have a vm like the jvm.
ocamlc compiles to bytecode
ocamlrun interprets the
A little off topic, but how is Mono/Unix these days? Last I checked
(2 years ago) it implemented the basic libraries and runtimes but had
terrible
performance. Is it now on par with Windows?
Still leaks memory, has broken TCO and runs like a dog. Mono has also fallen
even farther behind now
On Thursday 06 May 2010 06:43:21 am Dmitry Bely wrote:
Ironically it's also not entirely true. F# works well under Mono/Unix.
A little off topic, but how is Mono/Unix these days? Last I checked (2 years
ago) it implemented the basic libraries and runtimes but had terrible
performance. Is
On Wed, May 5, 2010 at 11:16 PM, Ed Keith e_...@yahoo.com wrote:
It bothers me that the Ocaml community seems to consider Windows developers
as second class citizens. Until this changes
Ocaml will never be a main stream language.
I think it's not really that bad. Ocaml developers support
for instance abstracting over
x11/win32(horrors!) windowing systems first
you're an optimist :-)
On Wed, May 5, 2010 at 7:13 PM, Eray Ozkural examach...@gmail.com wrote:
On Thu, May 6, 2010 at 1:36 AM, ben kuin benk...@gmail.com wrote:
I think the main problem is the lack of cross
1. [...] it would still require some time to rewrite a few parts.
Release early, release often. Maybe you put it under your name on
sourceforge, if you are afraid to put potentially non-buildable code
under the flags of lexifi.
2. Similarly, we rely on our extended standard library (a
--- On Wed, 5/5/10, ben kuin benk...@gmail.com wrote:
From: ben kuin benk...@gmail.com
Subject: Re: [Caml-list] about OcamIL
To: Ed Keith e_...@yahoo.com, caml-list@yquem.inria.fr
Date: Wednesday, May 5, 2010, 6:18 PM
keith, a few thoughts, ... before
I've worked with linux I was a
windows
lablGTK2 on linux is not fragile! Its robust, well designed, and
produces nice guis!
(at least on debian. props to the packagers and developers, if you're
listening)
On Wed, May 5, 2010 at 6:36 PM, ben kuin benk...@gmail.com wrote:
I think the main problem is the lack of cross platform gui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 06 May 2010 06:43:21 am Dmitry Bely wrote:
Ironically it's also not entirely true. F# works well under Mono/Unix.
- Dmitry Bely
A little off topic, but how is Mono/Unix these days? Last I checked (2 years
ago) it implemented the
hi
I'm waiting for the day that microsoft release f# under a official
open source license. It has been promised several times, but its still
only available under the Microsoft Research Shared Source license
agreement and
meanwhile I'm not sure if it ever really happens.
So I've stumbled over
On 05/05/2010 02:06 PM, ben kuin wrote:
I'm waiting for the day that microsoft release f# under a official
open source license. It has been promised several times, but its still
only available under the Microsoft Research Shared Source license
agreement and
meanwhile I'm not sure if it ever
Or use the real ocaml on a real OS (^_^)
--
Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives:
--- On Wed, 5/5/10, Eray Ozkural examach...@gmail.com wrote:
Or use the real ocaml on a real OS
(^_^)
I do not understand UNIX bigotry.
Yes, Unix is technically superior to Windows. But Plan 9 is technically
superior to Unix. But I doubt Eray is running Plan 9.
More computers run Windows
http://caml.inria.fr/download.en.html
Well, it is actually available on Windows. And mind you, there is some
popular windows software written in ocaml. We were taking a look at
haxe the other day. The F# makes use of the (pretty good designed)
.net CLR. Which isn't a bad thing at all, but it's
Or use the real ocaml on a real OS (^_^)
my vision is a unix centric clr based vm:
- no non-ecma parts
- maybe a complete different base class library (like OcamIL)
- the target is not to enable windows apps on unix, but the other way around
- the vm is crossplattform, the bytecode is compatible
Le 5 mai 10 à 21:16, Ed Keith a écrit :
--- On Wed, 5/5/10, Eray Ozkural examach...@gmail.com wrote:
Or use the real ocaml on a real OS
(^_^)
I do not understand UNIX bigotry.
Yes, Unix is technically superior to Windows. But Plan 9 is
technically superior to Unix. But I doubt Eray is
keith, a few thoughts, ... before I've worked with linux I was a
windows guy. I remember the day (forgot the context though) when I
installed the ocaml package on my dell/windows-xp/laptop (yuk) . Since
the workflow on windows is very gui centric, you can't help to get
very sensible how a
I think the main problem is the lack of cross platform gui that looks
good on windows.
LablTk: ok only for simple gui
LablGtk:fragile on linux, bad on windows
qt: I once tried to create bindings for a newer qt release (
4.2), I didn't finished it, but I think it would be doable. The big
On Thu, May 6, 2010 at 1:36 AM, ben kuin benk...@gmail.com wrote:
I think the main problem is the lack of cross platform gui that looks
good on windows.
LablTk: ok only for simple gui
LablGtk: fragile on linux, bad on windows
qt: I once tried to create bindings for a newer qt release
61 matches
Mail list logo
