caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Richard Jones <rich@annexia.org>
Cc: Oliver Bandel <oliver@first.in-berlin.de>,
	Caml-list List <caml-list@inria.fr>
Subject: Re: [Caml-list] If OCaml were a car
Date: Wed, 22 Aug 2007 12:49:35 +1000	[thread overview]
Message-ID: <1187750976.9072.39.camel@rosella.wigram> (raw)
In-Reply-To: <20070821185720.GC32626@furbychan.cocan.org>

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++: http://felix.sf.net


  reply	other threads:[~2007-08-22  2:50 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-18 19:21 Richard Jones
2007-08-18 20:24 ` [Caml-list] " Jeff Meister
2007-08-18 21:32   ` Michael Vanier
2007-08-19 11:50     ` Daniel Bünzli
2007-08-19 11:59       ` Erik de Castro Lopo
2007-08-22  5:50         ` Luca de Alfaro
2007-08-22  8:13           ` Jon Harrop
2007-08-22  9:20             ` Jacques Garrigue
2007-08-24  2:54           ` Nathaniel Gray
2007-08-25 19:45             ` Oliver Bandel
2007-08-19 14:43       ` John Carr
2007-08-19 16:22         ` brogoff
2007-08-19 17:07         ` Richard Jones
2007-08-19 17:19           ` Stefano Zacchiroli
2007-08-22  6:04             ` Luca de Alfaro
2007-08-19 20:51           ` Vincent Hanquez
2007-08-21  8:05           ` David Allsopp
2007-08-21 18:33             ` Richard Jones
2007-08-19 20:30         ` Tom
2007-08-19 21:45           ` skaller
2007-08-20  3:37             ` Jon Harrop
2007-08-20  6:26               ` skaller
2007-08-20 10:00                 ` Joerg van den Hoff
2007-08-21 12:03                   ` Florian Hars
2007-08-20  6:54               ` skaller
2007-08-20 19:54       ` Oliver Bandel
2007-08-20 20:27         ` David Allsopp
2007-08-20 20:50           ` Ulf Wiger (TN/EAB)
2007-08-21 10:56             ` Joerg van den Hoff
2007-08-20 21:13           ` Oliver Bandel
2007-08-21  0:47         ` skaller
2007-08-21  9:51           ` Oliver Bandel
2007-08-21 10:30             ` skaller
2007-08-21 18:57               ` Richard Jones
2007-08-22  2:49                 ` skaller [this message]
2007-08-22 11:33                   ` Thomas Fischbacher
2007-08-21 14:46             ` Business Adoption of Ocaml [was Re: [Caml-list] If OCaml were a car] Robert Fischer
2007-08-21 15:09               ` Brian Hurt
2007-08-21 15:48           ` [Caml-list] If OCaml were a car brogoff
2007-08-19 18:15 [caml-list] " Mike Lin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1187750976.9072.39.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=oliver@first.in-berlin.de \
    --cc=rich@annexia.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).