caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Oliver Bandel <oliver@first.in-berlin.de>
Cc: Caml-list List <caml-list@inria.fr>
Subject: Re: [Caml-list] If OCaml were a car
Date: Tue, 21 Aug 2007 20:30:28 +1000	[thread overview]
Message-ID: <1187692228.7354.21.camel@rosella.wigram> (raw)
In-Reply-To: <1187689892.46cab5a45112e@webmail.in-berlin.de>

On Tue, 2007-08-21 at 11:51 +0200, Oliver Bandel wrote:
> Zitat von skaller <skaller@users.sourceforge.net>:

> > (1.a) lack of dynamic loading (of native code)
> >     -- hopefully to be fixed in 3.11
> [...]
> 
> Would be fine, but is not that necessary.
> 

It's absolutely mandatory. Just consider a web browser executing 
compiled client script to see this.

> >
> > (1.b) lack of multi-processing
> 
> You mean parallelization on many processors?

Yes.

> Well, Unix.fork could help, 

No, it can't "help": some applications can be built that way,
with suitable message passing protocols. Others required 
shared data. 

Also note, you can't effectively use both threads and (forked)
processes because Unix is a mess. Quite a few applications use
threads, which precludes forking (completely separate processes
are OK of course).

> or OCamlP3l.

Indeed, but that's not Ocaml.

> > (2.a) interoperability
> >     -- with C libraries
> >     -- with .NET libraries (F# isn't Ocaml)
> 
> What do you mean with interoperability here?

Sharing data and control across language boundaries.

> You have the possibility to marry C and OCaml,
> and it's relatively easy, compared to Perl
> for example (which is very ugly with that XS-stuff).

It's extremely hard, and it's very expensive, compared to
sharing between C and C++, or C++ and Felix, or between
any .NET languages.

Perhaps by easy you mean the effort to handle "two functions".

Now try to wrap a library like GTK with hundreds or even 
thousands of functions!

> > (2.b) refusal of Inria team to provide a more complete library
> 
> I do not really miss a lot in the library.
> Some more functions would be fine, but the missings
> are not so big, IMHO.

Lots of really basic things are missing, for example re-entrant
regular expressions, variable length arrays, doubly linked lists,
sequential hash tables, and a heap of other data structures which
are either basic, or common in other systems.

> Does Perl have an ISO-standard?

Perl is dead.

> Or the ugly Visual Basic, which some big companies
> really are using?

No idea, but most of the new Microsoft offerings have
ECMA standards backing either extant or planned.

> I think an ISO-standard could be fine, but it is not
> the criteria, why companies decide to use a language.

Often it is. Do you know why C++ was standardised? Because
(I think it was Hewlett Packard) wanted to do some 
USA Federal Government contractsusing it, and an ANSI 
Standardised language was a requirement of the contracts.

Many big military contracts mandate Ada. Standards are
vital for big projects.

> IMHO, many (most) things that are used in industry are really bad
> things. And people insist on using bad langauges and bad systems,
> because they are accustomed to it, and some Lobbyists
> sell that stuff.

Many of the industrially used languages are not so good:
it's annoying the designers don't listen to academia.

But then, the academics don't bother to listen to industry
either .. :)


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2007-08-21 10:30 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 [this message]
2007-08-21 18:57               ` Richard Jones
2007-08-22  2:49                 ` skaller
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=1187692228.7354.21.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=oliver@first.in-berlin.de \
    /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).