Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] If OCaml were a car
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