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