Re: [Caml-list] Haskell vs OCaml

Re: [Caml-list] Haskell vs OCaml

[adrian.alexander.may]

On Wednesday, 13 August 2008 20:49:17 UTC+8, circ ular  wrote:
> What are the advantages/disadvantages when comparing OCaml to Haskell?

case you of
  man   -> haskell
  mouse -> ocaml

Re: [Caml-list] Haskell vs OCaml

[Malcolm Matalka]

The biggest advantage for me is Ocaml is simpler than Haskell IMO.

adrian.alexander.may@gmail.com writes:

> On Wednesday, 13 August 2008 20:49:17 UTC+8, circ ular  wrote:
>> What are the advantages/disadvantages when comparing OCaml to Haskell?
>
> case you of
>   man   -> haskell
>   mouse -> ocaml

Re: [Caml-list] Haskell vs OCaml

[Gabriel Scherer]

I see no point in keeping this thread going on, given the mediocre way
it started.

The original question was about feedback on OCaml being used to teach
programming, and I think it is good that is answered in detail if it
can help in making informed curriculum decisions. Don't hesitate to
keep providing data if you think it helps.

On the other side, there is no "competition" going on here -- and it's
indeed an excellent thing that Haskell, being a beautiful language, is
also taught at university (same for SML)! If only there were less Java
courses...

I'm sure there are interesting things to be said about "Haskell and
OCaml" (rather than "vs."), but this is not the way to start it.

"Keep Caml and Curry On"!

On Mon, Mar 18, 2013 at 10:48 AM, Malcolm Matalka <mmatalka@gmail.com> wrote:
> The biggest advantage for me is Ocaml is simpler than Haskell IMO.
>
> adrian.alexander.may@gmail.com writes:
>
>> On Wednesday, 13 August 2008 20:49:17 UTC+8, circ ular  wrote:
>>> What are the advantages/disadvantages when comparing OCaml to Haskell?
>>
>> case you of
>>   man   -> haskell
>>   mouse -> ocaml
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Haskell vs OCaml

[Adrian May]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

Actually I was making a serious point, namely, that Haskell forces you to
learn the whole FP deal even to write Hello World, whereas Ocaml lets you
chicken out into imperative programming at the first hurdle. Which is
better? Well I'd say the former because the latter risks building up a code
base that doesn't rhyme with itself and a population of programmers who
react to one half or the other of the code with either derision or
confusion.



On 18 March 2013 17:59, Gabriel Scherer <gabriel.scherer@gmail.com> wrote:

> I see no point in keeping this thread going on, given the mediocre way
> it started.
>
> The original question was about feedback on OCaml being used to teach
> programming, and I think it is good that is answered in detail if it
> can help in making informed curriculum decisions. Don't hesitate to
> keep providing data if you think it helps.
>
> On the other side, there is no "competition" going on here -- and it's
> indeed an excellent thing that Haskell, being a beautiful language, is
> also taught at university (same for SML)! If only there were less Java
> courses...
>
> I'm sure there are interesting things to be said about "Haskell and
> OCaml" (rather than "vs."), but this is not the way to start it.
>
> "Keep Caml and Curry On"!
>
> On Mon, Mar 18, 2013 at 10:48 AM, Malcolm Matalka <mmatalka@gmail.com>
> wrote:
> > The biggest advantage for me is Ocaml is simpler than Haskell IMO.
> >
> > adrian.alexander.may@gmail.com writes:
> >
> >> On Wednesday, 13 August 2008 20:49:17 UTC+8, circ ular  wrote:
> >>> What are the advantages/disadvantages when comparing OCaml to Haskell?
> >>
> >> case you of
> >>   man   -> haskell
> >>   mouse -> ocaml
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2867 bytes --]

Re: [Caml-list] Haskell vs OCaml

[Kakadu]

Please, don't feed the troll

On Mon, Mar 18, 2013 at 1:48 PM, Malcolm Matalka <mmatalka@gmail.com> wrote:
> The biggest advantage for me is Ocaml is simpler than Haskell IMO.
>
> adrian.alexander.may@gmail.com writes:
>
>> On Wednesday, 13 August 2008 20:49:17 UTC+8, circ ular  wrote:
>>> What are the advantages/disadvantages when comparing OCaml to Haskell?
>>
>> case you of
>>   man   -> haskell
>>   mouse -> ocaml
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

[Caml-list] Re: Haskell vs OCaml

[Chet Murthy]

Geez, I don't want to fan the flames of any sort of war, but .... as
long as this subject came up, I'd really like to find out if anybody
has done decent-sized-system comparisons of ocaml and haskell for
performance and footprint.

I'm a long-time Caml (and before that SML) hacker, and (hopefully)
fully appreciate the FP Nature, so it's not like I'm looking for an
argument about which language is better, etc, etc.

And I'm not looking for microbenchmarks, either.  I'm looking for
-significant- systems that have been implemented in both, and
information about footprint and performance of those systems.

Why am I looking?  Because if you're a bigot about your favorite
language, and -never- look for countervailing facts about the
competition, you might miss out.

Heck, that's how I became an Ocaml bigot lo' these many years.

So .... anybody got anything?
--chet--

RE: [Caml-list] Re: Haskell vs OCaml

[Jon Harrop]

FWIW, I'd say that the differences between OCaml and Haskell are of academic
interest (first-class modules vs type classes). The important thing is the
shortcomings that both OCaml and Haskell share (high barrier to entry, poor
interop, performance limitations, limited libraries, commerce unfriendly,
ageing foundations).
 
Cheers,
Jon.

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On
Behalf Of Chet Murthy
Sent: 18 March 2013 18:05
To: caml-list@inria.fr
Subject: [Caml-list] Re: Haskell vs OCaml


Geez, I don't want to fan the flames of any sort of war, but .... as long as
this subject came up, I'd really like to find out if anybody has done
decent-sized-system comparisons of ocaml and haskell for performance and
footprint.

I'm a long-time Caml (and before that SML) hacker, and (hopefully) fully
appreciate the FP Nature, so it's not like I'm looking for an argument about
which language is better, etc, etc.

And I'm not looking for microbenchmarks, either.  I'm looking for
-significant- systems that have been implemented in both, and information
about footprint and performance of those systems.

Why am I looking?  Because if you're a bigot about your favorite language,
and -never- look for countervailing facts about the competition, you might
miss out.

Heck, that's how I became an Ocaml bigot lo' these many years.

So .... anybody got anything?
--chet--


--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Re: Haskell vs OCaml

[Yaron Minsky]

On Wed, Mar 20, 2013 at 4:44 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> FWIW, I'd say that the differences between OCaml and Haskell are of academic
> interest (first-class modules vs type classes). The important thing is the
> shortcomings that both OCaml and Haskell share (high barrier to entry, poor
> interop, performance limitations, limited libraries, commerce unfriendly,
> ageing foundations).

While I agree that first-class modules vs type-classes is not the most
burning issue, I broadly disagree with your dismal estimate of the
state of the language.

I don't think OCaml is unfriendly to commercial users.  Certainly Jane
Street has had a great relationship with the OCaml maintainers and the
larger community.  And while there are performance limitations,
OCaml's overall performance is quite good and quite predictable.  That
performance is also rapidly improving as more and more people start
working on improving the foundations.

It's true that the selection of libraries is limited (less true for
Haskell, FWIW).  But with the recent arrival of OPAM, the ease of
using OCaml has gone way up, and we're already seeing improvements to
the set of available libraries.  The rest of the toolchain, from
performance monitoring tools to document generation to support for
IDE-like features, are all actively being worked on.

All told, between the work being done at INRIA, OCamlPro, OCaml Labs,
and the broader community there's an amazing amount of energy being
poured into the language.

And one shouldn't lose sight of the most important facts about the
language: OCaml is highly productive, and it greatly simplifies the
task of building efficient, reliable and above all correct code.

y

> Cheers,
> Jon.
>
> -----Original Message-----
> From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On
> Behalf Of Chet Murthy
> Sent: 18 March 2013 18:05
> To: caml-list@inria.fr
> Subject: [Caml-list] Re: Haskell vs OCaml
>
>
> Geez, I don't want to fan the flames of any sort of war, but .... as long as
> this subject came up, I'd really like to find out if anybody has done
> decent-sized-system comparisons of ocaml and haskell for performance and
> footprint.
>
> I'm a long-time Caml (and before that SML) hacker, and (hopefully) fully
> appreciate the FP Nature, so it's not like I'm looking for an argument about
> which language is better, etc, etc.
>
> And I'm not looking for microbenchmarks, either.  I'm looking for
> -significant- systems that have been implemented in both, and information
> about footprint and performance of those systems.
>
> Why am I looking?  Because if you're a bigot about your favorite language,
> and -never- look for countervailing facts about the competition, you might
> miss out.
>
> Heck, that's how I became an Ocaml bigot lo' these many years.
>
> So .... anybody got anything?
> --chet--
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Re: Haskell vs OCaml

[Jon Harrop]

Yaron wrote:
> I don't think OCaml is unfriendly to commercial users

I meant that few people buy or sell commercial OCaml code compared to .NET,
particularly when the target market is OCaml programmers themselves. We
tried with products like Smoke and Presenta but hit problems that don't
exist on alternatives like .NET. Smoke was made difficult by a combinatorial
explosion with brittle bindings that required us to recompile and re-release
for every minor version increment of either OCaml itself or LablGL. In
essence, OCaml bytecode was not designed to be redistributable. We were
forced to drop Presenta when we found that around 80% of beta testers
experienced segmentation faults even though it was 100% pure OCaml code. In
contrast, the same code ported to F# has hundreds of commercial users and
we've never had a single report of unreliability.

> OCaml is highly productive, and it greatly simplifies the task of building
efficient, reliable and above all correct code

Although I often found that to be true there were several important kinds of
applications where OCaml fell short on some of those metrics for me.

One obvious one is GUI programming where I found OCaml+LablGTK to be
anything but highly productive. F# is much more productive and reliable when
it comes to GUIs (although performance is a problem with WPF).

OCaml is very efficient for most symbolic code but there are lots of
examples where there is significant room for improvement (polymorphism,
recursive lambdas, that weird +. 0.0 thing, static optimization of % by a
constant, unboxing types like complex numbers, hash tables, deep recursion,
large arrays of reference types, CSE). Some of those will be fixed, as you
say, but many of the core ones will not.

Presenta is obviously a counter-example for reliability. 100% OCaml code
isn't supposed to be able to segfault...

Cheers,
Jon.

-----Original Message-----
From: Yaron Minsky [mailto:yminsky@janestreet.com] 
Sent: 20 March 2013 21:10
To: jon@ffconsultancy.com
Cc: Chet Murthy; caml-list@inria.fr
Subject: Re: [Caml-list] Re: Haskell vs OCaml

On Wed, Mar 20, 2013 at 4:44 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> FWIW, I'd say that the differences between OCaml and Haskell are of 
> academic interest (first-class modules vs type classes). The important 
> thing is the shortcomings that both OCaml and Haskell share (high 
> barrier to entry, poor interop, performance limitations, limited 
> libraries, commerce unfriendly, ageing foundations).

While I agree that first-class modules vs type-classes is not the most
burning issue, I broadly disagree with your dismal estimate of the state of
the language.

I don't think OCaml is unfriendly to commercial users.  Certainly Jane
Street has had a great relationship with the OCaml maintainers and the
larger community.  And while there are performance limitations, OCaml's
overall performance is quite good and quite predictable.  That performance
is also rapidly improving as more and more people start working on improving
the foundations.

It's true that the selection of libraries is limited (less true for Haskell,
FWIW).  But with the recent arrival of OPAM, the ease of using OCaml has
gone way up, and we're already seeing improvements to the set of available
libraries.  The rest of the toolchain, from performance monitoring tools to
document generation to support for IDE-like features, are all actively being
worked on.

All told, between the work being done at INRIA, OCamlPro, OCaml Labs, and
the broader community there's an amazing amount of energy being poured into
the language.

And one shouldn't lose sight of the most important facts about the
language: OCaml is highly productive, and it greatly simplifies the task of
building efficient, reliable and above all correct code.

y

> Cheers,
> Jon.
>
> -----Original Message-----
> From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] 
> On Behalf Of Chet Murthy
> Sent: 18 March 2013 18:05
> To: caml-list@inria.fr
> Subject: [Caml-list] Re: Haskell vs OCaml
>
>
> Geez, I don't want to fan the flames of any sort of war, but .... as 
> long as this subject came up, I'd really like to find out if anybody 
> has done decent-sized-system comparisons of ocaml and haskell for 
> performance and footprint.
>
> I'm a long-time Caml (and before that SML) hacker, and (hopefully) 
> fully appreciate the FP Nature, so it's not like I'm looking for an 
> argument about which language is better, etc, etc.
>
> And I'm not looking for microbenchmarks, either.  I'm looking for
> -significant- systems that have been implemented in both, and 
> information about footprint and performance of those systems.
>
> Why am I looking?  Because if you're a bigot about your favorite 
> language, and -never- look for countervailing facts about the 
> competition, you might miss out.
>
> Heck, that's how I became an Ocaml bigot lo' these many years.
>
> So .... anybody got anything?
> --chet--
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Re: Haskell vs OCaml

[Yaron Minsky]

On Wed, Mar 20, 2013 at 8:26 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> Yaron wrote:
>> I don't think OCaml is unfriendly to commercial users
>
> I meant that few people buy or sell commercial OCaml code compared to .NET,
> particularly when the target market is OCaml programmers themselves.

I agree, I would not recommend basing a business on selling OCaml code
to programmers.

> We tried with products like Smoke and Presenta but hit problems that
> don't exist on alternatives like .NET. Smoke was made difficult by a
> combinatorial explosion with brittle bindings that required us to
> recompile and re-release for every minor version increment of either
> OCaml itself or LablGL. In essence, OCaml bytecode was not designed
> to be redistributable. We were forced to drop Presenta when we found
> that around 80% of beta testers experienced segmentation faults even
> though it was 100% pure OCaml code. In contrast, the same code
> ported to F# has hundreds of commercial users and we've never had a
> single report of unreliability.
>
>> OCaml is highly productive, and it greatly simplifies the task of
>> building efficient, reliable and above all correct code
>
> Although I often found that to be true there were several important
> kinds of applications where OCaml fell short on some of those
> metrics for me.
>
> One obvious one is GUI programming where I found OCaml+LablGTK to be
> anything but highly productive. F# is much more productive and
> reliable when it comes to GUIs (although performance is a problem
> with WPF).
>
> OCaml is very efficient for most symbolic code but there are lots of
> examples where there is significant room for improvement
> (polymorphism, recursive lambdas, that weird +. 0.0 thing, static
> optimization of % by a constant, unboxing types like complex
> numbers, hash tables, deep recursion, large arrays of reference
> types, CSE). Some of those will be fixed, as you say, but many of
> the core ones will not.

As I said, OCaml's performance is already excellent for our purposes,
and getting better.  The CLR and JVM also have their performance
warts, for sure.

I'd be careful about pointing at any single limitation and saying
"that won't get fixed".  There's an energetic and talented crew
attacking all sorts of problems, and I expect they'll go far.

> Presenta is obviously a counter-example for reliability. 100% OCaml
> code isn't supposed to be able to segfault...

Re: [Caml-list] Re: Haskell vs OCaml

[Richard W.M. Jones]

On Thu, Mar 21, 2013 at 04:58:32PM -0400, Yaron Minsky wrote:
> On Wed, Mar 20, 2013 at 8:26 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> > Yaron wrote:
> >> I don't think OCaml is unfriendly to commercial users
> >
> > I meant that few people buy or sell commercial OCaml code compared to .NET,
> > particularly when the target market is OCaml programmers themselves.
> 
> I agree, I would not recommend basing a business on selling OCaml code
> to programmers.

Or *selling* any code to programmers.  Just release the source.
Developers don't want to deal with licensing and binary blobs.

On Wed, Mar 20, 2013 at 8:26 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> One obvious one is GUI programming where I found OCaml+LablGTK to be
> anything but highly productive.

Gtk sucks from every language I've tried.

Rich.

Re: [Caml-list] Re: Haskell vs OCaml

[Török Edwin]

On 03/21/2013 02:26 AM, Jon Harrop wrote:

> Presenta is obviously a counter-example for reliability. 100% OCaml code
> isn't supposed to be able to segfault...

Were you able to track down the cause?
I'm aware of at least one problem before OCaml 4.00.0 (segfault instead of stack overflow,
possible even with pure OCaml code, because even that would eventually call the C functions in the stdlib), but I'm sure there
can be other reasons.

On a related note perhaps it would be useful to have a tool that checks whether OCaml code (and its dependencies!) uses "unsafe" features,
or lacks tail calls, etc.

Best regards,
--Edwin

RE: [Caml-list] Re: Haskell vs OCaml

[Jon Harrop]

Edwin wrote:
> Were you able to track down the cause?

No but I suspect it was related to OpenGL and I doubt it would affect
standalone OCaml applications.

Cheers,
Jon.

Re: [Caml-list] Re: Haskell vs OCaml

[Daniel Bünzli]

Le vendredi, 22 mars 2013 à 18:51, Jon Harrop a écrit :
> No but I suspect it was related to OpenGL and I doubt it would affect
> standalone OCaml applications.


This seems to contradict :

Le jeudi, 21 mars 2013 à 01:26, Jon Harrop a écrit :
> We were forced to drop Presenta when we found that around 80% of beta testers
> experienced segmentation faults even though it was 100% pure OCaml code.

  


Daniel

RE: [Caml-list] Re: Haskell vs OCaml

[Jon Harrop]

In what sense?

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Daniel Bünzli
Sent: 22 March 2013 18:47
To: caml-list@inria.fr
Subject: Re: [Caml-list] Re: Haskell vs OCaml

Le vendredi, 22 mars 2013 à 18:51, Jon Harrop a écrit :
> No but I suspect it was related to OpenGL and I doubt it would affect 
> standalone OCaml applications.


This seems to contradict :

Le jeudi, 21 mars 2013 à 01:26, Jon Harrop a écrit :
> We were forced to drop Presenta when we found that around 80% of beta 
> testers experienced segmentation faults even though it was 100% pure OCaml code.

  


Daniel



--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs=

Re: [Caml-list] Re: Haskell vs OCaml

[Daniel Bünzli]

Le vendredi, 22 mars 2013 à 20:53, Jon Harrop a écrit :
> In what sense?

Since it was using OpenGL it wasn't "100% pure OCaml code". And apparently your bindings to OpenGL were somehow broken. Unless as Edwin suggested you maybe had stack overflows but that would also be a programming error on your part. One other track could be that the OpenGL drivers of your users were buggy, which is really not uncommon.  

To sum up, your comment made it seem like the thing to blame for your own failures was OCaml itself, I doubt this is the right culprit in that case.

Daniel

RE: [Caml-list] Re: Haskell vs OCaml

[Jon Harrop]

> Since it was using OpenGL it wasn't "100% pure OCaml code".

How so?

> And apparently your bindings to OpenGL were somehow broken.

Why do you assume that I wrote my own OpenGL bindings? I used the pre-existing LablGL bindings that were not only the defacto-standard for OCaml+OpenGL at the time (i.e. OCaml's most widely tested OpenGL bindings) but had been written by Jacques Garrigue, one of the authors of OCaml itself.

> One other track could be that the OpenGL drivers of your users
> were buggy, which is really not uncommon.  

Why do "buggy drivers" affect 80% of our users when we write our software in 100% OCaml and 0% of our customers when we write our software in 100% F#?

> To sum up, your comment made it seem like the thing to blame
> for your own failures was OCaml itself, I doubt this is the right
> culprit in that case.

So the stuff all around OCaml that we used only because we were using OCaml was to blame and not OCaml itself?

Cheers,
Jon.

Re: [Caml-list] Re: Haskell vs OCaml

[Daniel Bünzli]

Le vendredi, 22 mars 2013 à 23:13, Jon Harrop a écrit :
> > Since it was using OpenGL it wasn't "100% pure OCaml code".
>  
> How so?


Unless I'm mistaken, here around when we say 100% pure OCaml code, it means code that uses the standard library, 100% pure OCaml modules and no C bindings or unsafe features like Obj.  

But maybe you are new around here...

> Why do you assume that I wrote my own OpenGL bindings? I used the pre-existing LablGL bindings that were not only the defacto-standard for OCaml+OpenGL at the time (i.e. OCaml's most widely tested OpenGL bindings) but had been written by Jacques Garrigue, one of the authors of OCaml itself.

AFAIK labgl is not part of the OCaml system. If that software layer was key to your product you should have ensured that you had some understanding/control of it -- even if that meant writing your own. More than that you should have realized that while lablgl is fine for hobby opengl programming, it has obvious shortcomings that makes it ill suited to develop products on top of it.

> Why do "buggy drivers" affect 80% of our users when we write our software in 100% OCaml and 0% of our customers when we write our software in 100% F#?

You know it's called hypotheses, I don't know what you did, we will never know since you are never able to provide any details. I'm aware that's the way you like to discuss, by boasting unverifiable claims, but it became very boring after all these years.  

It seems you did something wrong in building your product, don't blame the system because you are making the wrong choices (it seems a pattern with you btw [1]). There's more than one OCaml industrial user out there, if the OCaml system had random segfaults, I'm pretty sure we would be aware of it.

Anyway, believe me I'm very glad you are successful in programming in F#, keep going.

Best,

Daniel

[1] http://caml.inria.fr/pub/ml-archives/caml-list/2009/06/7f2abbd136332881dff65ab4fa0fd673.en.html

Re: [Caml-list] Re: Haskell vs OCaml

[Chet Murthy]

> > Why do "buggy drivers" affect 80% of our users when we write our software
> > in 100% OCaml and 0% of our customers when we write our software in 100%
> > F#?

[short answer: because each time that a paying customer is affected by
a buggy driver, the vendor of the CLR or JVM spends -serious- money
finding and shooting that bug.  They spend -serious- money building
internal tooling to help them do this.  It's expensive and
time-consuming, and furthermore consumes -extremely-skilled- people.
No OSS language runtime can afford that.]

Maybe I can help here.  I've spent a lot of my life with ocaml, and
even more with the JVM and Java (feh).  The JVM's not so different
from the CLR in the sense that it gets used with a -ton- of C drivers.
Especially in the early days, lots and lots of C drivers.

Here's the thing, though: Java "comes with" a decent number of C
libraries for things like graphics and such.  And -vendors- write
database drivers (like the old ORCL OCI JDBC drivers).  When those
drivers segfault (or trample on JVM memory), believe it, it's a
nightmare for JVM maintainers and support people.  Of course, the
vendors themsleves work -very- hard to find and remove bugs in these
drivers, but some always remain.

To the point where, one common diagnosis step is to try to eliminate
that C driver and get repro.

It is common that JVM developers will also develop in-house support
tools that can analyze core-dumps at a -ridiculously- detailed level,
in order to figure out what got trampled, and try to work out why.

This is hard, expensive, and will never happen for a language runtime
maintained by an open-source community.

So .... why should you use ocaml instead of a CLR-based language (like
F#)?  Well, as Daniel Bunzli said, maybe you shouldn't.  But I would
note that your experience would be no different if you were using
Python, Perl, Ruby, or PHP.  All those language-runtimes lack support
of the sort you get from the JVM or CLR.  And there are reasons why
people prefer these languages/runtimes over the commercial ones.

--chet--

Re: [Caml-list] Re: Haskell vs OCaml

[Daniel Bünzli]

Le samedi, 23 mars 2013 à 00:47, Chet Murthy a écrit :

> [short answer: because each time that a paying customer is affected by
> a buggy driver, the vendor of the CLR or JVM spends -serious- money
> finding and shooting that bug. They spend -serious- money building
> internal tooling to help them do this. It's expensive and
> time-consuming, and furthermore consumes -extremely-skilled- people.
> No OSS language runtime can afford that.]

I can't speak for what happens with CLR or JVM, but if you bind to OpenGL from OCaml you are basically programming with OpenGL's C interface. There's no direct interaction between the OpenGL drivers and OCaml's language runtime. So I don't think your remark makes sense in that context.  

Best,

Daniel

Re: [Caml-list] Re: Haskell vs OCaml

[Chet Murthy]

On Saturday, March 23, 2013 01:02:51 AM Daniel Bünzli wrote:
> Le samedi, 23 mars 2013 à 00:47, Chet Murthy a écrit :
> > [short answer: because each time that a paying customer is affected by
> > a buggy driver, the vendor of the CLR or JVM spends -serious- money
> > finding and shooting that bug. They spend -serious- money building
> > internal tooling to help them do this. It's expensive and
> > time-consuming, and furthermore consumes -extremely-skilled- people.
> > No OSS language runtime can afford that.]
> 
> I can't speak for what happens with CLR or JVM, but if you bind to OpenGL
> from OCaml you are basically programming with OpenGL's C interface. There's
> no direct interaction between the OpenGL drivers and OCaml's language
> runtime. So I don't think your remark makes sense in that context.

For most C drivers I've seen, the same is true in the JVM.  The
"direct interaction" consists in manipulating/allocating some
heap-objects, and .... stray pointers.  Obv. it's the latter that
cause all the problem.

For example, long ago a (POSIX-threaded) JVM used signals to stop
threads in order to do mark-and-sweep GC.  Unfortunately, there were a
number of C drivers that were not "signal-safe" (didn't restart their
syscalls properly), and so you'd get "interesting" segfaults at GC
time.  The solution involved some hacking to avoid sending signals to
threads in C driver code, but still stopping them when they emerged
(or called code in the JVM, e.g. to allocate heap-memory).

--chet--

RE: [Caml-list] Re: Haskell vs OCaml

[Jon Harrop]

Chet Murthy wrote:
> No OSS language runtime can afford that.
> ...
> This is hard, expensive, and will never happen for a language runtime
maintained by an open-source community.

That amount of effort might not be expected for such a language but I would
not neglect some opportunities that OCaml does have to improve this. For
example, LLVM and Clang could be used to help autogenerate bindings to C
libraries. That would be a big step up from where OCaml is today and would
yield dividends across the board.

> So .... why should you use ocaml instead of a CLR-based language (like
F#)?
> Well, as Daniel Bunzli said, maybe you shouldn't.

Exactly. Yaron's assertions that OCaml is highly productive, efficient and
reliably are not universally applicable. Which raises the question of when
they are applicable?

The OCaml distribution itself is certainly very reliable but is also very
limited in capability so I see no merit in restricting consideration to just
that. Indeed, LablGL was always reliable provided the code was compiled on
the machine it was run on and not distributed as a binary.

> But I would note that your experience would be no different if you were
> using Python, Perl, Ruby, or PHP.

I'm not convinced. I think part of the problem may have been linking between
statically-compiled OCaml code and libraries like OpenGL. With Python, the
OpenGL bindings would have been compiled for a specific binary distro which
might affect reliability.

Cheers,
Jon.

Re: [Caml-list] Re: Haskell vs OCaml

[oliver]

On Sat, Mar 23, 2013 at 01:17:33AM -0000, Jon Harrop wrote:
[...]
> Exactly. Yaron's assertions that OCaml is highly productive, efficient and
> reliably are not universally applicable. Which raises the question of when
> they are applicable?
[...]

When using it on unixoid systems. :P


Ciao,
   Oliver

RE: [Caml-list] Re: Haskell vs OCaml

[Jon Harrop]

Daniel Bunzli wrote:
> Unless I'm mistaken, here around when we say 100% pure OCaml code,
> it means code that uses the standard library, 100% pure OCaml modules
> and no C bindings or unsafe features like Obj.
> AFAIK labgl is not part of the OCaml system. If that software layer was
> key to your product you should have ensured that you had some
> understanding/control of it -- even if that meant writing your own.

How do you reconcile having to reinvent the wheel by writing my own OpenGL bindings with Yaron's assertion that OCaml is "highly productive"?

> More than that you should have realized that while lablgl is fine for
> hobby opengl programming, it has obvious shortcomings that makes
> it ill suited to develop products on top of it.

What shortcomings?

> It seems you did something wrong in building your product...

Only when I was building my product using OCaml. When I was building my product using F# instead I apparently didn't do anything wrong.

Cheers,
Jon.

Re: [Caml-list] Re: Haskell vs OCaml

[Daniel Bünzli]

Le samedi, 23 mars 2013 à 02:15, Jon Harrop a écrit :
> How do you reconcile having to reinvent the wheel by writing my own OpenGL bindings with Yaron's assertion that OCaml is "highly productive"?


I don't have to reconcile anything, these are not my words.  

I care about quality software, "highly productive" caries no qualitative assessment, a lot of people are "highly productive" but produce only shit.  

Sometimes you have to invest to ground yourself on good foundations.

> What shortcomings?
Lots of so called "modern" opengl functionality needed for high performance graphics has been missing for a long time (e.g. buffer objects). Lack of bigarray support. Lack of shader support (no longer true but was for a long time). Basically a design rooted in the "old" OpenGL of the late nineties, OpenGL has been moving.  

Daniel

Re: [Caml-list] Re: Haskell vs OCaml

[Francois Berenger]

On 03/23/2013 10:15 AM, Jon Harrop wrote:
> Daniel Bunzli wrote:
>> Unless I'm mistaken, here around when we say 100% pure OCaml code,
>> it means code that uses the standard library, 100% pure OCaml modules
>> and no C bindings or unsafe features like Obj.
>> AFAIK labgl is not part of the OCaml system. If that software layer was
>> key to your product you should have ensured that you had some
>> understanding/control of it -- even if that meant writing your own.
>
> How do you reconcile having to reinvent the wheel by writing my own OpenGL bindings with Yaron's assertion that OCaml is "highly productive"?

It's highly productive for their use case.
They do mostly back-end programming in OCaml, not GUIs or websites.

And it looks the same for the part of Citrix products using OCaml 
(back-end/system programming), cf. some ICFP papers.

>> More than that you should have realized that while lablgl is fine for
>> hobby opengl programming, it has obvious shortcomings that makes
>> it ill suited to develop products on top of it.
>
> What shortcomings?
>
>> It seems you did something wrong in building your product...
>
> Only when I was building my product using OCaml. When I was building my product using F# instead I apparently didn't do anything wrong.
>
> Cheers,
> Jon.

Re: [Caml-list] Re: Haskell vs OCaml

[oliver]

On Thu, Mar 21, 2013 at 12:26:56AM -0000, Jon Harrop wrote:
> Yaron wrote:
> > I don't think OCaml is unfriendly to commercial users
> 
> I meant that few people buy or sell commercial OCaml code compared to .NET,
> particularly when the target market is OCaml programmers themselves. We
> tried with products like Smoke and Presenta but hit problems that don't
> exist on alternatives like .NET. Smoke was made difficult by a combinatorial
> explosion with brittle bindings that required us to recompile and re-release
> for every minor version increment of either OCaml itself or LablGL. In
> essence, OCaml bytecode was not designed to be redistributable. We were
> forced to drop Presenta when we found that around 80% of beta testers
> experienced segmentation faults even though it was 100% pure OCaml code.
[...]
> Presenta is obviously a counter-example for reliability. 100% OCaml code
> isn't supposed to be able to segfault...
[...]

"OCaml bytecode was not designed to be redistributable", so you used native code
 instead of bytecode?

Mem-eating code (e.g. non-tailrec stuff) gives Stack_overflow-exception for bytecode,
but Segfault for native code.

Maybe that was the reason?

Ciao,
   Oliver

Re: [Caml-list] Haskell vs OCaml

[Francois Berenger]

On 03/18/2013 08:26 PM, Kakadu wrote:
> Please, don't feed the troll
>
> On Mon, Mar 18, 2013 at 1:48 PM, Malcolm Matalka <mmatalka@gmail.com> wrote:
>> The biggest advantage for me is Ocaml is simpler than Haskell IMO.
>>
>> adrian.alexander.may@gmail.com writes:
>>
>>> On Wednesday, 13 August 2008 20:49:17 UTC+8, circ ular  wrote:
>>>> What are the advantages/disadvantages when comparing OCaml to Haskell?
>>>
>>> case you of
>>>    man   -> haskell
>>>    mouse -> ocaml

Last time I used it, the Haskell "ecosystem" around the language
(tools and libraries) was quite advanced (they had an OPAM-like
long time ago for example).

Also, the population of Haskell programmers might be bigger
(bigger open-source community, easier to find programmers to hire).

F.

Re: [Caml-list] Haskell vs OCaml

[Nicolas Braud-Santoni]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On 19/03/2013 02:23, Francois Berenger wrote:
> On 03/18/2013 08:26 PM, Kakadu wrote:
>> Please, don't feed the troll
>>
>> On Mon, Mar 18, 2013 at 1:48 PM, Malcolm Matalka <mmatalka@gmail.com>
>> wrote:
>>> The biggest advantage for me is Ocaml is simpler than Haskell IMO.
>>>
>>> adrian.alexander.may@gmail.com writes:
>>>
>>>> On Wednesday, 13 August 2008 20:49:17 UTC+8, circ ular  wrote:
>>>>> What are the advantages/disadvantages when comparing OCaml to
>>>>> Haskell?
>>>>
>>>> case you of
>>>>    man   -> haskell
>>>>    mouse -> ocaml
>
> Last time I used it, the Haskell "ecosystem" around the language
> (tools and libraries) was quite advanced (they had an OPAM-like
> long time ago for example).

As a Haskell programmer, I can tell you that Cabal (Haskell's OPAM-like)
is somewhat quirky, and can become very painful to work around when
hitting some corner-cases.

For now, I have had no such experience with OPAM ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Caml-list] Haskell vs OCaml

[Kristopher Micinski]

One other potentially unmentioned point is basically that Haskell is
call by need and OCaml is call by value.  This causes a bit of a
headache sometimes (lazy io, etc, etc...), but birthed some cool
constructs (such as iteratees).

I personally find Haskell *harder* to understand because of all the
hoops you have to jump through to be purely functional (but maybe
that's just me).

Although I haven't personally used it, Camlp4 is nice (and used by
research) for implementing language extensions.  I'm not sure that GHC
is quite as hackable / extensible, but maybe that's just because I'm
uninformed about Haskell :-)..

Kris

On Mon, Mar 18, 2013 at 5:08 AM,  <adrian.alexander.may@gmail.com> wrote:
> On Wednesday, 13 August 2008 20:49:17 UTC+8, circ ular  wrote:
>> What are the advantages/disadvantages when comparing OCaml to Haskell?
>
> case you of
>   man   -> haskell
>   mouse -> ocaml
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Haskell vs OCaml

[Erik de Castro Lopo]

Kristopher Micinski wrote:

> Although I haven't personally used it, Camlp4 is nice (and used by
> research) for implementing language extensions.  I'm not sure that GHC
> is quite as hackable / extensible, but maybe that's just because I'm
> uninformed about Haskell :-)..

I suspect that Template Haskell is probably very near to Camlp4 in
terms of capabilities. Its also relatively widely used, for instance
in the Yesod web framework.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Re: [Caml-list] Haskell vs OCaml

[Kristopher Micinski]

I agree, but I've found templates in TH to be a bit sticky since they
lack a lot of semantic support.  Maybe it's just an aversion to
quasiquoters from examples I've seen.  Although I do understand that
within Yesod TH does have quite a bit of success.  I guess my only
real point was extrapolating from examples of people I know that use
camlp4 for language extensions (within a research context) and not TH.
I haven't ruminated as to whether TH would suffice for individual
instances (probably so, and the people I know simply prefer OCaml..).

In any case the newer versions of OCaml actually export the compiler,
which makes some other language analysis-y things slightly easier from
an API standpoint.

Kris

On Mon, Mar 25, 2013 at 10:37 PM, Erik de Castro Lopo
<mle+ocaml@mega-nerd.com> wrote:
> Kristopher Micinski wrote:
>
>> Although I haven't personally used it, Camlp4 is nice (and used by
>> research) for implementing language extensions.  I'm not sure that GHC
>> is quite as hackable / extensible, but maybe that's just because I'm
>> uninformed about Haskell :-)..
>
> I suspect that Template Haskell is probably very near to Camlp4 in
> terms of capabilities. Its also relatively widely used, for instance
> in the Yesod web framework.
>
> Erik
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Haskell vs OCaml

[Damien Guichard]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]


Well said Brian.

Any tutorial is good enough at underlining respective language features.
Haskell has lazy evaluation, Caml has strict evaluation, don't pretend it's a secret and don't ask whether good or bad. 
Be responsible, try it yourself if needed, then choose yourself.

- damien






> circ ular wrote:
>
> > What are the advantages/disadvantages when comparing OCaml to Haskell?
> 
>
> The biggest disadvantage of comparing Ocaml to Haskell would have to be 
> causing a long, pointless flamewar. Offhand, I can't think of an upside.
>
> Brian

[-- Attachment #2: Type: text/html, Size: 1350 bytes --]

Haskell vs OCaml

[circ ular]

What are the advantages/disadvantages when comparing OCaml to Haskell?

Re: [Caml-list] Haskell vs OCaml

[Brian Hurt]

circ ular wrote:

>What are the advantages/disadvantages when comparing OCaml to Haskell?
>
>  
>

The biggest disadvantage of comparing Ocaml to Haskell would have to be 
causing a long, pointless flamewar.  Offhand, I can't think of an upside.

Brian

Re: [Caml-list] Haskell vs OCaml

[Jon Harrop]

On Wednesday 13 August 2008 13:48:45 circ ular wrote:
> What are the advantages/disadvantages when comparing OCaml to Haskell?

Techically, predictable performance, high performance on x64, tools like 
camlp4 and language features including records, functors, polymorphic 
variants and structurally-typed objects are probably the main advantages of 
OCaml over Haskell.

Non-technically, OCaml has more well-tested libraries, more practical books 
(e.g. my own), more high-profile open source projects (e.g. FFTW has millions 
of users):

http://ocamlnews.blogspot.com/2007/12/top-10-most-popular-ocaml-programs.html
http://haskell-news.blogspot.com/2008/01/top-10-most-popular-haskell-programs.html

and is much more widely used in industry. There are far more 
practically-minded people in the OCaml community and that is reflected in the 
much larger number of commercial products that use OCaml.

Tangentially, OCaml has a successful relative in F# whereas Haskell's close 
relatives are extinct.

I did extensive research on all of the most popular functional languages last 
year, including Haskell. In case you are trying to do something similar, I'll 
warn you that almost all of the examples of Haskell's use in industry are 
fakes, e.g. companies that have no products, companies that have one product 
that never used Haskell, companies that happen to have two Haskell advocates 
working for them out of 150 developers, companies where one employee once did 
a preliminary Haskell program but nothing since and, finally, plain old spam 
where companies that have never had anything to do with Haskell have hijacked 
the Haskell site to advertise on-line only to be hailed as a "real world" 
example of Haskell in industry by its proponents. I was rather baffled when I 
discovered this and have never seen behaviour like it.

Haskell also has some advantages over OCaml, of course, but you should 
probably ask the Haskell community to explain them. I consider them all to be 
untested because nobody has ever done anything significant using Haskell 
AFAIK.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Haskell vs OCaml

[David Thomas]

--- On Wed, 8/13/08, Jon Harrop <jon@ffconsultancy.com> wrote:

> I consider them all to be untested because nobody has ever done anything 
> significant using Haskell AFAIK.


Besides the window manager I'm currently using... :-P


      

Re: [Caml-list] Haskell vs OCaml

[Erik de Castro Lopo]

David Thomas wrote:

> --- On Wed, 8/13/08, Jon Harrop <jon@ffconsultancy.com> wrote:
> > I consider them all to be untested because nobody has ever done anything 
> > significant using Haskell AFAIK.
> 
> 
> Besides the window manager I'm currently using... :-P

And Darcs the distributed revision control system.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Do I do everything in C++ and teach a course in advanced swearing?"
-- David Beazley at IPC8, on choosing a language for teaching

Re: [Caml-list] Haskell vs OCaml

[Paolo Donadeo]

> And Darcs the distributed revision control system.

Erik, Darcs is so slow, buggy and broken by design (I speak for direct
experience) that even the GHC team decided to switch to GIT or
Mercurial, see [1] and [2].

Consider this: three years ago I decided to study a functional
language and I had to decide between OCaml and Haskell. In that
period, for other reasons, I was searching for a new SCM to replace
CVS and I extensively tested Darcs.

Darcs was so broken that I decided for OCaml when I realized it was
written in Haskell.

So Darcs, IMHO, is definitively not "anything significant".


[1] http://www.reddit.com/comments/6v2nl/ghc_project_switches_to_git/
[2] https://lopsa.org/node/1656


-- 
Ing. Paolo Donadeo
Studio Associato 4Sigma
Website: http://www.4sigma.it
Email: p.donadeo@4sigma.it
~
~
:wq

Re: [Caml-list] Haskell vs OCaml

[Jon Harrop]

On Thursday 14 August 2008 03:46:10 David Thomas wrote:
> --- On Wed, 8/13/08, Jon Harrop <jon@ffconsultancy.com> wrote:
> > I consider them all to be untested because nobody has ever done anything
> > significant using Haskell AFAIK.
>
> Besides the window manager I'm currently using... :-P

Interestingly, the number of registered installs of XMonad has increased a lot 
from only 95 in January to 542 now. However, that is still orders of 
magnitude fewer than the most popular open source software written in OCaml:

Debian and Ubuntu registered installs
-------------------------------------
184,574: FFTW (14,298 lines of OCaml)
 12,866: Unison (23,993 lines of OCaml)
  7,286: MLDonkey (171,332 lines of OCaml)
  4,365: Darcs (3,939 lines of Haskell)
  4,066: FreeTennis (7,419 lines of OCaml)
  4,057: Planets (3,296 lines of OCaml)
  3,465: HPodder (2,225 lines of Haskell)
  2,965: LEdit (2,048 lines of OCaml)
  2,822: Hevea (11,596 lines of OCaml)
  2,657: Polygen (1,331 lines of OCaml)

So:

. 8/10 of the top ten most popular OCaml/Haskell open source projects on 
Debian and Ubuntu were written in OCaml and not Haskell.

. 221,293 installs of popular OCaml software compared to only 7,830 of 
Haskell.

. 235,312 lines of well-tested OCaml code compared to only 6,164 lines of 
well-tested Haskell code.

Some of the Haskell projects (e.g. pugs and srcinst) have even *decreased* 
in popularity over the past 7 months. Indeed, Darcs was only being used to a 
significant extent by the Haskell community and the GHC developers are now 
giving up on it themselves citing awful performance as one of the main 
reasons:

  http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation

Note their own benchmark results:

  Annotate: Darcs is 50x slower than Git.
  Clone: Darcs is 49x slower than Git.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Haskell vs OCaml

[Erik de Castro Lopo]

Jon Harrop wrote:

> 184,574: FFTW (14,298 lines of OCaml)

For FFTW, Ocaml is used the generate C code. Nothing that the final
user of libfftw links to is written in Ocaml. I don't think this one
really counts.

> Some of the Haskell projects (e.g. pugs and srcinst) have even *decreased* 
> in popularity over the past 7 months. Indeed, Darcs was only being used to a 
> significant extent by the Haskell community and the GHC developers are now 
> giving up on it themselves citing awful performance as one of the main 
> reasons:
> 
>   http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation

Darcs with its theory of patches is also far more experimental and is pushing
back the boundaries of how people who write revision control software think
about the field.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Incompetence, like misery, seeks company." -- Erik Naggum

Re: [Caml-list] Haskell vs OCaml

[blue storm]

[-- Attachment #1: Type: text/plain, Size: 3295 bytes --]

So it seems the debate went on anyway. I had written something, but when
just before posting i saw Brian Hurt's post, and decided not to. It now
seems i was wrong, and actually (when reading the others) my post seems
quite balanced after all.

I'm not saying that the other posters are biased in any way. But i have the
point of view of someone trying to learn a language "for fun" and in order
to discover interesting features or novel point of views. It seems Haskell
do much better in that context that in the "use it to do something useful in
the cruel world" context used so far.

So here is my original post :

I'm afraid your question is a bit too general (and it seems strange to ask
that on the mailing-list of one of the projects, while asking for a balanced
answer).

The main differences are :
OCaml is impure (imperative features in the language), Haskell is pure.
OCaml is strict, Haskell is lazy.
Ocaml has modules, Haskell has type classes.

If you're coming from the imperative land, OCaml is, in my opinion, easier
to learn.
It is also a good choice to begin with OCaml because everything you learn
with the OCaml basics can be reused for learning Haskell (the converse is
also true, but then you have to learn lazy evaluation first, wich is a
non-trivial shift, and is vastly less used in OCaml).
Haskell is certainly worth the effort, but my personal opinion is that
learning OCaml first is a good idea. Moreover, for "real world" application,
you may prefer OCaml over Haskell.

The syntax are different, but not so much (before learning haskell, i could
generally understand the purpose of tiny haskell sources). I have heard some
people say they prefer the Haskell syntax, but this is more a matter of
taste (and not very relevant if you want to learn something from the
language semantics). Both have their ugly sides.

Idiomatic OCaml implementations tend to produce more efficient than
Idiomatic Haskell implementations (but Haskell compilers are getting better
and better everyday (for Haskell performances to be good, compilers have to
do lots of clever and not so simple optimizations), and Haskell is faster
than most (scripting) languages used these days anyway).

The Haskell standard library is bigger than the Ocaml one, but this is
probably not an advantage for beginners (because this means more time spent
in browsing the doc, while playing with the language and reimplementing
functions yourself is much more interesting). Haskell program thus tends to
be more terse and "higher-level" (because of reusing a lot of higher-order
combinators in the stdlib): OCaml is also very expressive, but the
simplicity of the stdlib tends to keep people on simpler things.

To the advanced programmer, both languages have interesting advanced
features to offer. Haskell tends to specialize in sophisticated type system
features, whereas OCaml has an interesting object system, and polymorphic
variants. Both languages have very interesting derivatives, specific
languages intended to explore a specific area (concurrency, metaprogramming,
etc...).

Camlp4 is a flexible and powerful Ocaml preprocessor. Haskell has some tools
in that direction, that i have never used (so i'm mostly guessing here), but
they seem to be even less supported and used inside the community.

[-- Attachment #2: Type: text/html, Size: 3466 bytes --]

Re: [Caml-list] Haskell vs OCaml

[David Mitchell]

Thanks - nice summary

Dave M.

On 14/08/2008, blue storm <bluestorm.dylc@gmail.com> wrote:
> So it seems the debate went on anyway. I had written something, but when
> just before posting i saw Brian Hurt's post, and decided not to. It now
> seems i was wrong, and actually (when reading the others) my post seems
> quite balanced after all.
>
> I'm not saying that the other posters are biased in any way. But i have the
> point of view of someone trying to learn a language "for fun" and in order
> to discover interesting features or novel point of views. It seems Haskell
> do much better in that context that in the "use it to do something useful in
> the cruel world" context used so far.
>
> So here is my original post :
>
> I'm afraid your question is a bit too general (and it seems strange to ask
> that on the mailing-list of one of the projects, while asking for a balanced
> answer).
>
> The main differences are :
> OCaml is impure (imperative features in the language), Haskell is pure.
>  OCaml is strict, Haskell is lazy.
> Ocaml has modules, Haskell has type classes.
>
> If you're coming from the imperative land, OCaml is, in my opinion, easier
> to learn.
> It is also a good choice to begin with OCaml because everything you learn
> with the OCaml basics can be reused for learning Haskell (the converse is
> also true, but then you have to learn lazy evaluation first, wich is a
> non-trivial shift, and is vastly less used in OCaml).
>  Haskell is certainly worth the effort, but my personal opinion is that
> learning OCaml first is a good idea. Moreover, for "real world" application,
> you may prefer OCaml over Haskell.
>
> The syntax are different, but not so much (before learning haskell, i could
> generally understand the purpose of tiny haskell sources). I have heard some
> people say they prefer the Haskell syntax, but this is more a matter of
> taste (and not very relevant if you want to learn something from the
> language semantics). Both have their ugly sides.
>
> Idiomatic OCaml implementations tend to produce more efficient than
> Idiomatic Haskell implementations (but Haskell compilers are getting better
> and better everyday (for Haskell performances to be good, compilers have to
> do lots of clever and not so simple optimizations), and Haskell is faster
> than most (scripting) languages used these days anyway).
>
> The Haskell standard library is bigger than the Ocaml one, but this is
> probably not an advantage for beginners (because this means more time spent
> in browsing the doc, while playing with the language and reimplementing
> functions yourself is much more interesting). Haskell program thus tends to
> be more terse and "higher-level" (because of reusing a lot of higher-order
> combinators in the stdlib): OCaml is also very expressive, but the
> simplicity of the stdlib tends to keep people on simpler things.
>
> To the advanced programmer, both languages have interesting advanced
> features to offer. Haskell tends to specialize in sophisticated type system
> features, whereas OCaml has an interesting object system, and polymorphic
> variants. Both languages have very interesting derivatives, specific
> languages intended to explore a specific area (concurrency, metaprogramming,
> etc...).
>
> Camlp4 is a flexible and powerful Ocaml preprocessor. Haskell has some tools
> in that direction, that i have never used (so i'm mostly guessing here), but
> they seem to be even less supported and used inside the community.
>
> _______________________________________________
>  Caml-list mailing list. Subscription management:
>  http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>  Archives: http://caml.inria.fr
>  Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
>  Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: [Caml-list] Haskell vs OCaml

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 14 August 2008 07:50:43 am blue storm wrote:
> The main differences are :
> OCaml is impure (imperative features in the language), Haskell is pure.
> OCaml is strict, Haskell is lazy.
> Ocaml has modules, Haskell has type classes.

I would restate the last as:

  OCaml has an object system, Haskell has type classes.


In Haskell you can write a function that takes anything that is "showable" (a 
type class) and print it out.  The sig would be something like (I'm mixing 
OCaml and Haskell syntax here, but hopefully the point is still clear):

  Showable 'a => 'a -> unit

You can't quite do that with modules/functors.  However with objects you can 
write a function that takes a showable and executes it.  It's sig would look 
like this:

  showable -> unit

where

  class type showable = object
    method print : unit -> unit
    ...
  end


As to Haskell vs. OCaml, they are both great languages.  Haskell is more 
researchy and experimental (although with Haskell Prime they are making a big 
push to make it more friendly to industrial uses).  This is great because you 
get some really cool stuff.  This is also bad because all the cool stuff is 
hard to understand and sometimes you-just-want-to-get-stuff-done.  OCaml is 
great for that and for one other thing that I think few people point out.  
OCaml supports a variety of programming styles: OO, imperative and 
functional.  This means it's easy for anyone to pick up and use.  If you have 
collaborators, OCaml projects have an easier learning curve.  Anyone can feel 
more or less at home using OCaml in a week.  In contrast, Haskell has quite a 
steep initial learning curve (eg. you need to learn monads before you can 
write any interesting real-world application) which can be a big barrier to 
potential collaborators.

Also the ability to switch styles often lets you write faster.  For some 
problems, I just think in one style versus another.  It just comes more 
easily to me in a functional style sometimes, and an OO style other times.  
OCaml let's you write however you think about it.  Haskell makes you think 
about it in *the haskell* way.  Sometimes this is good because it forces you 
to do certain things.  Othertimes it just gets in your way.


Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFIpDMIfIRcEFL/JewRAtN1AKCth4Iep/uNUaFObIcyvAQXS0LmwgCdHQB2
wP8iIzC8YUtOlxmuPPfSKqU=
=g/dJ
-----END PGP SIGNATURE-----

Re: [Caml-list] Haskell vs OCaml

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Thursday 14 August 2008 09:28:34 am Peng Zang wrote:
> OCaml let's you write however you think about it.  Haskell makes you think
> about it in *the haskell* way.  Sometimes this is good because it forces
> you to do certain things.  Othertimes it just gets in your way.
>
>
> Peng


Haha, I have some free time.  So, let me explain more about why sometimes it's 
good that Haskell makes you do things in a certain way.

One is that Haskell forces your program into two parts.  Parts that contain 
side-effects (in monads) and the part that is pure.  This is great because 
the compiler can now do some optimizations not available when you don't know 
if your code is pure.  This is also good because side-effects can be 
confusing and difficult to maintain over time.  By putting all the side 
effects in a box, you can compartmentalize it away.  For lots of changes you 
only have to consider the pure stuff which is easier to think about (no 
worries about state, no worries about the right order of doing things, 
program in a declarative fashion).  The downside is you have to put all the 
side-effect stuff in a corner and box it off.  This can be a little odd 
because it may make you organize your code in a counterintuitive way.  Also 
it makes side-effect creep very obvious (when you realize "oops, that needs 
to be in a monad too... and that... and that ... crap").  You really have to 
sit down and think about the design before you do anything.  Haskell is 
definitely a first-on-paper, then-in-code type of language.  This can be good 
because for complex stuff you probably want to think about the design ahead 
of time anyways.  Haskell forces this discpline on you.  On the other hand, 
if you like to do rapid prototyping type of approach and live on the edge a 
bit, it can be a bummer.

A similar argument follows for lazy (non-strict) evaluation as well.  Allows 
some really cool stuff (eg. infinite lists) and optimizations (eg. 
deforestation).  But has significant overhead (eg. you have to make a thunk 
for everything, if you're going to evaluate it anyways, all that work to make 
the thunk is wasted) and it's hard to reason about speed and memory 
performance (eg. it looks like a tail recursive function that uses constant 
stack space but because the accumulator is thunked, you end up creating O(N) 
thunks).

Anyways, I think Haskell has some really cool ideas and I like it.  It 
definitely expands the mind.  But OCaml is my go-to-swiss-army-knife of 
languages.  It used to be C but that was too low level for me and library 
support was crap (this was before Boost).  Then it was Java but it was waay 
to verbose and you couldn't even return a tuple without creating a class for 
it first.  Then it was Lisp, but it's dynamically typed and I got tired of 
finding bugs from 3 years ago.  Now days it's OCaml.  Maybe one day it'll be 
something else, but in the mean time, I'm enjoying it.

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFIpDq+fIRcEFL/JewRAv3eAJ9L3W43Qfn2bFpLpUiyRt4Dn1dt6gCeNvew
8w6kCN5AKcGJH8WYzJPyKVM=
=6HsO
-----END PGP SIGNATURE-----

Re: [Caml-list] Haskell vs OCaml

[blue storm]

> One is that Haskell forces your program into two parts.  Parts that contain
> side-effects (in monads) and the part that is pure.

You can actually do quite a bit more, using different monads to
compartementalize different aspects of your code. You will, by the
way, have noticed that Haskellers tend to put everything in the IO
monad (when a separate monad would make more sense) because mixing
monads is difficult.

> This is great because
> the compiler can now do some optimizations not available when you don't know
> if your code is pure.

I suppose you could get the same benefits with a "purity inference"
compiler pass, the same way haskell compilers a "strictness
inference".

> it makes side-effect creep very obvious (when you realize "oops, that needs
> to be in a monad too... and that... and that ... crap").

unsafePerformIO to the rescue !

I generally agree with the interest of pure programming in some part
of the language. It is, however, not all as rosy as you say (i've seen
people argue that the "side-effect creep" related to monads cause
composability problems) because they are hard issue (monads mixing for
example) wich have not been quite resolved yet. Haskell is interesting
because of that experimental taste, but i totally agree it "sometimes
gets in your way".

> A similar argument follows for lazy (non-strict) evaluation as well.  Allows
> some really cool stuff (eg. infinite lists) and optimizations (eg.
> deforestation).

Explicit lazy evaluation (as in OCaml) can give you the same cool
stuff, with a saner standard (strict evaluation) and, in my opinion,
increased comprehensibility (by explicitely highlighting the part that
rely on lazy evaluation). Both library and syntaxic support of lazy
values in OCaml could be better that they are now, but they is work
going on (we even have *several* lazy lists librairies these day).


> That's true, but I think Haskell's point of view is to stop that completely.
> They want to remove optimization of code and put it into the hands of the
> compiler.  The ideal is to say to the programmer: "don't worry about
> performance and optimization, just write correct code.  The compiler will
> figure out the rest".

I strongly disagree on that point. You just can't rely on anything
that optimizes "as much as possible" when you don't know precisely
what it does. The idea to "not worry about performance" is, in my
opinion, wrong because you'll always have specific cases wich are not
correctly optimized (see for example the posts on the performance of
high-level automatic differentiation stuff that went on the Haskell
planet a month ago or so). The usual programmer should not need to
know about subtle and implementation-specific stuff (whereas the
requirement of understanding tail-recursion is commonly accepted among
OCaml programmers), but trying to optimize every naive code into
something efficient is a dangerous dream.

Re: [Caml-list] Haskell vs OCaml

[Jon Harrop]

On Thursday 14 August 2008 12:50:43 blue storm wrote:
> It is also a good choice to begin with OCaml because everything you learn
> with the OCaml basics can be reused for learning Haskell (the converse is
> also true, but then you have to learn lazy evaluation first, wich is a
> non-trivial shift, and is vastly less used in OCaml).

Monads and zippers?

> The syntax are different, but not so much (before learning haskell, i could
> generally understand the purpose of tiny haskell sources). I have heard
> some people say they prefer the Haskell syntax, but this is more a matter
> of taste (and not very relevant if you want to learn something from the
> language semantics). Both have their ugly sides.

That reminds me: you can run the same OCaml code in the top-level, in the 
bytecode interpreter and through the native code compiler.

> Idiomatic OCaml implementations tend to produce more efficient than
> Idiomatic Haskell implementations (but Haskell compilers are getting better
> and better everyday (for Haskell performances to be good, compilers have to
> do lots of clever and not so simple optimizations),

Even if Haskell's performance is improved it will remain unpredictable and, 
consequently, it will continue to be impossible to optimize non-trivial 
Haskell programs.

> and Haskell is faster than most (scripting) languages used these days
> anyway). 

Despite being written in Python, Mercurial is orders of magnitude faster than 
Darcs.

> The Haskell standard library is bigger than the Ocaml one,

Does the Haskell stdlib provide a database interface, md5 checksums, 
marshalling, pretty printing, lexer generator, graphics library, regular 
expressions, unix interface and weak references?

> Haskell program thus tends to
> be more terse and "higher-level" (because of reusing a lot of higher-order
> combinators in the stdlib): OCaml is also very expressive, but the
> simplicity of the stdlib tends to keep people on simpler things.

I'm not sure what you mean by "simplicity of the [OCaml] stdlib tends to keep 
people on simpler things" but there is certainly far more non-trivial 
software written in OCaml than Haskell, both open source and commercial.

> Camlp4 is a flexible and powerful Ocaml preprocessor...

And an extensible general-purpose parser generator that is higher-level than 
Parsec. Camlp4 rocks!

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Haskell vs OCaml

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Thursday 14 August 2008 09:57:47 am Jon Harrop wrote:
> Monads and zippers?

They can be useful for the same reasons they are in Haskell.  You can always 
write OCaml code like Haskell code, it's just not always easiest to do it 
that way.

> Even if Haskell's performance is improved it will remain unpredictable and,
> consequently, it will continue to be impossible to optimize non-trivial
> Haskell programs.

That's true, but I think Haskell's point of view is to stop that completely.  
They want to remove optimization of code and put it into the hands of the 
compiler.  The ideal is to say to the programmer: "don't worry about 
performance and optimization, just write correct code.  The compiler will 
figure out the rest".  Clearly we're not at that point, and perhaps that 
ideal is a long ways to become true if possible at all.  But you gotta give 
them props for the idea.  It would be nice to only care about correctness and 
not performance.

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFIpDvifIRcEFL/JewRAvCyAJwNdNYMEx8TKWwwDB1D6X3C5258uwCghlP3
ZaogvTv/CydHsPQ+ETA/+KI=
=eQDx
-----END PGP SIGNATURE-----

Re: [Caml-list] Haskell vs OCaml

[Vincent Hanquez]

On Thu, Aug 14, 2008 at 02:57:47PM +0100, Jon Harrop wrote:
> > and Haskell is faster than most (scripting) languages used these days
> > anyway). 
> 
> Despite being written in Python, Mercurial is orders of magnitude faster than 
> Darcs.

(wow, very funny)

by the same stupid thinking process:

Despite being written in C, CVS is orders of magnitude slower than
mercurial. obviously now, python is faster than C.

-- 
Vincent

Re: [Caml-list] Haskell vs OCaml

[Jon Harrop]

On Thursday 14 August 2008 15:21:40 you wrote:
> On Thu, Aug 14, 2008 at 02:57:47PM +0100, Jon Harrop wrote:
> > > and Haskell is faster than most (scripting) languages used these days
> > > anyway).
> >
> > Despite being written in Python, Mercurial is orders of magnitude faster
> > than Darcs.
>
> (wow, very funny)
>
> by the same stupid thinking process:
>
> Despite being written in C, CVS is orders of magnitude slower than
> mercurial.

Is that based upon any measurements?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Haskell vs OCaml

[Nicolas Pouillard]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Excerpts from Jon Harrop's message of Thu Aug 14 15:57:47 +0200 2008:
> On Thursday 14 August 2008 12:50:43 blue storm wrote:
...
> > and Haskell is faster than most (scripting) languages used these days
> > anyway). 
> 
> Despite being written in Python, Mercurial is orders of magnitude faster than 
> Darcs.

The difference of performances between Darcs and Mercurial is 99% due
differences in algorithms not in the implementation language. So this
comparison does not make sense!

-- 
Nicolas Pouillard aka Ertai

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [Caml-list] Haskell vs OCaml

[Jon Harrop]

On Thursday 14 August 2008 21:57:59 you wrote:
> Excerpts from Jon Harrop's message of Thu Aug 14 15:57:47 +0200 2008:
> > On Thursday 14 August 2008 12:50:43 blue storm wrote:
> > > and Haskell is faster than most (scripting) languages used these days
> > > anyway).
> >
> > Despite being written in Python, Mercurial is orders of magnitude faster
> > than Darcs.
>
> The difference of performances between Darcs and Mercurial is 99% due
> differences in algorithms not in the implementation language. So this
> comparison does not make sense!

Only if the choice of algorithm was independent of the language, which is 
rarely the case.

For example, Fortran programmers use arrays when they are unsuitable and their 
programs can be slower than scripting languages as a consequence. That is 
Fortran's fault.

Does the Darcs implementation overuse singly linked lists because they are 
more accessible? Are the reported stack overflows indicative of this? I don't 
know but I certainly wouldn't rule it out as a possibility.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Haskell vs OCaml

[Nicolas Pouillard]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

Excerpts from Jon Harrop's message of Thu Aug 14 23:16:26 +0200 2008:
> On Thursday 14 August 2008 21:57:59 you wrote:
> > Excerpts from Jon Harrop's message of Thu Aug 14 15:57:47 +0200 2008:
> > > On Thursday 14 August 2008 12:50:43 blue storm wrote:
> > > > and Haskell is faster than most (scripting) languages used these days
> > > > anyway).
> > >
> > > Despite being written in Python, Mercurial is orders of magnitude faster
> > > than Darcs.
> >
> > The difference of performances between Darcs and Mercurial is 99% due
> > differences in algorithms not in the implementation language. So this
> > comparison does not make sense!
> 
> Only if the choice of algorithm was independent of the language, which is 
> rarely the case.
> 
> For example, Fortran programmers use arrays when they are unsuitable and their 
> programs can be slower than scripting languages as a consequence. That is 
> Fortran's fault.
> 
> Does the Darcs implementation overuse singly linked lists because they are 
> more accessible? Are the reported stack overflows indicative of this? I don't 
> know but I certainly wouldn't rule it out as a possibility.

I'm talking about the informal algorithms, their independent of that kind of
things...

-- 
Nicolas Pouillard aka Ertai

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [Caml-list] Haskell vs OCaml

[Jon Harrop]

On Thursday 14 August 2008 22:50:19 you wrote:
> I'm talking about the informal algorithms, their independent of that kind
> of things...

Yes, that may well be true. I think we would need in-depth knowledge of Darcs 
to be able to distinguish between the two.

Do any OCaml projects use Darcs, BTW?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Haskell vs OCaml

[Stéphane Glondu]

Jon Harrop wrote:
> Do any OCaml projects use Darcs, BTW?

Ocsigen¹ does.

¹ http://ocsigen.org/

-- 
Stéphane Glondu

Re: [Caml-list] Haskell vs OCaml

[Luca Saiu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Harrop wrote:
> On Thursday 14 August 2008 22:50:19 you wrote:
>> I'm talking about the informal algorithms, their independent of that kind
>> of things...
> 
> Yes, that may well be true. I think we would need in-depth knowledge of Darcs 
> to be able to distinguish between the two.
> 
> Do any OCaml projects use Darcs, BTW?

We use Darcs as the VCS for Marionnet. See http://darcs.marionnet.org .

Darcs 2 has yet to give us any headache; the "exponential merge" corner
cases of version 1 are apparently gone, and now it's quite a pleasure to
use.

- --
Luca Saiu
http://www-lipn.univ-paris13.fr/~saiu
GNU epsilon: http://www.gnu.org/software/epsilon
Marionnet:   http://www.marionnet.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkineB4ACgkQvzOavibF0oYvqQCeMXMygLIy46MFhFJqmOU8n6qJ
kDwAn3xb+Ezu6Ky/cdZPgKFLNM/0bVBN
=rOZh
-----END PGP SIGNATURE-----

Re: [Caml-list] Haskell vs OCaml

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FWIW, I still use darcs (darcs 2) exclusively. So far, no other  
version control system has gotten the relationships among  
repositories, branching, and merging quite right, although I'm keeping  
a keen eye on Mercurial's forthcoming "rebase" extension.

On Aug 14, 2008, at 5:15 PM, Jon Harrop wrote:

> On Thursday 14 August 2008 22:50:19 you wrote:
>> I'm talking about the informal algorithms, their independent of  
>> that kind
>> of things...
>
> Yes, that may well be true. I think we would need in-depth knowledge  
> of Darcs
> to be able to distinguish between the two.
>
> Do any OCaml projects use Darcs, BTW?
>
> -- 
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiqMqsACgkQIVlHUIJ6Q02suQCgim9bDlna3r0WYl8Qb2DHQDuy
zgEAn1VRvTKhaKIphvp++BJJb3cyASph
=Mq8B
-----END PGP SIGNATURE-----

Re: [Caml-list] Haskell vs OCaml

[Dr. Thomas Fischbacher]

circ ular wrote:

> What are the advantages/disadvantages when comparing OCaml to Haskell?

What are the advantages/disadvantages when comparing a fork to a spoon?

-- 
best regards,
Thomas Fischbacher
t.fischbacher@soton.ac.uk

Re: [Caml-list] Haskell vs OCaml

[DooMeeR]

> What are the advantages/disadvantages when comparing a fork to a spoon?

 From Church's thesis, one can easily answer this question: they are 
equivalent.

The reduction is quite easy. A fork can be reduced to a spoon using a 
fire, an anvil and a hammer, and a spoon can be reduced to a fork using 
a saw.

Hope this helps.

-- 
Romain Bardou

Re: [Caml-list] Haskell vs OCaml

[David Teller]

I'm not sure there's confluence if you factor in the resources required
for such reduction, though.

On Thu, 2008-08-21 at 10:47 +0200, DooMeeR wrote:
> > What are the advantages/disadvantages when comparing a fork to a spoon?
> 
>  From Church's thesis, one can easily answer this question: they are 
> equivalent.
> 
> The reduction is quite easy. A fork can be reduced to a spoon using a 
> fire, an anvil and a hammer, and a spoon can be reduced to a fork using 
> a saw.
> 
> Hope this helps.
> 
-- 
David Teller-Rajchenbach
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] Haskell vs OCaml

[Dr. Thomas Fischbacher]

DooMeeR wrote:

>>What are the advantages/disadvantages when comparing a fork to a spoon?
> 
>  From Church's thesis, one can easily answer this question: they are
> equivalent.
> 
> The reduction is quite easy. A fork can be reduced to a spoon using a
> fire, an anvil and a hammer, and a spoon can be reduced to a fork using
> a saw.

So, why at all bother with OCaml if it's equivalent to Basic anyway, or
machine language, for that matter?

Church's Thesis is often cited for precisely this purpose of cutting off
discussions related to differing aspects of programming languages --
sometimes this may even seem a Pawlowian reflex reaction. However,
I think Church is a red herring here, as the important aspects of
programming languages are not at the language:machine interface, but
at the human:language interface. The design of a milk carton certainly
does not matter a lot for how well it manages to store milk -- pretty
much all of them do that quite well. But it certainly does matter for
the question whether I'll spill milk all over the table when I try to
put some into my tea (as I did this morning).

-- 
best regards,
Thomas Fischbacher
t.fischbacher@soton.ac.uk