[Caml-list] Haskell vs OCaml
circ ular
_______________________________________________
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
Brian Hurt
>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
Jon Harrop
> 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
David Thomas
--- On Wed, 8/13/08, Jon Harrop <j...@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
Erik de Castro Lopo
> --- On Wed, 8/13/08, Jon Harrop <j...@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
Paolo Donadeo
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.do...@4sigma.it
~
~
:wq
blue storm
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.
Jon Harrop
> --- On Wed, 8/13/08, Jon Harrop <j...@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
_______________________________________________
David Mitchell
Dave M.
Damien Guichard
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?
>
>
Peng Zang
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-----
Jon Harrop
> 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
_______________________________________________
Peng Zang
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
Vincent Hanquez
> > 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
Jon Harrop
> 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
_______________________________________________
Erik de Castro Lopo
> 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
parnell
> 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.
This is entirely untrue. You can determine when lazy evaluation will
bite you and when it will help you, it is just not intuitive to
someone used to strict evaluation (which is almost everybody).
When code reviews come up short haskell has a decent built in time and
space profiler to help chase down space leaks and slow bits. You can
also use ghc-core to get a good idea of what the compiler is trying to
do with your code an how you can help the compiler optimize it. I
have had very good results with both of these tools and the GHCI
debugger on several non-trivial commercial applications. I would not
say that ghc-core and the heap profiler are easy to use for a beginner
but once you learn to use them they are very helpful indeed.
> Despite being written in Python, Mercurial is orders of magnitude faster than
> Darcs.
>
As with most performance issues the performance problems in Darcs are
mainly due to design issues and have little to do with the performance
of Haskell.
Parnell
Nicolas Pouillard
> 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
Jon Harrop
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.
Nicolas Pouillard
> 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...
Stéphane Glondu
> Do any OCaml projects use Darcs, BTW?
Ocsigen¹ does.
--
Stéphane Glondu
blue storm
> 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.
Paul Snively
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-----
Dr. Thomas Fischbacher
> 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.fisc...@soton.ac.uk
David Teller
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.
Dr. Thomas Fischbacher
>>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).
adrian.ale...@gmail.com
> What are the advantages/disadvantages when comparing OCaml to Haskell?
case you of
man -> haskell
mouse -> ocaml