Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
If OCaml were a car
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-08-22 (02:50)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] If OCaml were a car
On Tue, 2007-08-21 at 19:57 +0100, Richard Jones wrote:
> On Tue, Aug 21, 2007 at 08:30:28PM +1000, skaller wrote:

> This might come back and bite you in a couple of years you've got 16-
> and 32-core processors and you find your parallel GC / operating
> system really don't scale.

Wrong approach IMHO. There are physical limits on localisation:
the speed of light and Heisenberg's constant. We know from
simple observation of organic systems, that systems clump
at various levels.

This means we need multiple mechanisms of sharing, for example,
to use BOTH shared memory threads and message passing. Indeed,
we use 'fast' message passing to implement 'slow' sharing
right now: isn't that what cache interconnects do already?

It's not an 'either/or' thing. It will not be 'either message
passing or shared memory'. It will always be a mixture of both
with 'layered' levels of granularity/abstraction.

The smart modern CPU programmer can use random access data 
structures but keeps cache locality in mind for performance.
[See Judy Array for an interesting example of this.]
[The smart Erlang programmer probably does the opposite..
funnel messages to local ports where possible]

> One interesting thing I've learned from working with people on the
> GNOME team is that in fact there is no shortage of manpower in the
> free software world (people prepared to do repetitive grunt work,
> reimplement stuff endlessly and so on), but there is a big shortage of
> people who understand anything beyond C and maybe Python.  Python is
> the Visual Basic of the free software world, believe me.

I know. The Felix build system and LP tool is pure Python, the Felix
libraries are C++, and the compiler is Ocaml: the Ocaml part is the
biggest language obstacle to participation ;(

> > > > (2.b) refusal of Inria team to provide a more complete library

> As I've said before, this is a packaging problem.  

Yes indeed. And that's my point.

> Can you not bundle
> private copies of the libraries you need in with felix?

I do. Elkhound, Tre, Judy are all bundled as source code.
[But BSD like licence is mandatory.]

> > > Does Perl have an ISO-standard?
> > 
> > Perl is dead.
> Hum, well.  Perl is far more widely used than OCaml.

But Ocaml is alive, changing, and growing. Perl has been
on the way down for years. Once, every web site offered Perl
as a scripting language. This annoyed Python people :)
But then PHP took over. And now Ruby on Rails is taking over.
Perl is now an arcane language for aging Unix hippies who
fondly remember it is much better than awk and sed.

John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: