They are all good languages and yes, it is a matter of taste.
In the recent ICFP competition ( involved writing a ray tracer that
could handle a functional scene description language as input ), the
first and second prizes went to the Ocaml team. The second and third
prizes went to teams using Haskell.
See:
http://caml.inria.fr/icfp99-contest/
http://caml.inria.fr/icfp00-contest/
for more information on theocaml entries for 1999 and 2000.
and for information on the 2000 winners see:
http://www.cis.upenn.edu/~sumii/icfp/
israel raj thomas <·······@optushome.com.au> writes:
> could handle a functional scene description language as input ), the
> first and second prizes went to the Ocaml team. The second and third
> prizes went to teams using Haskell.
Uh?
> and for information on the 2000 winners see:
> http://www.cis.upenn.edu/~sumii/icfp/
Or:
http://www.cs.cornell.edu/icfp/contest_results.htm
Which shows (corrected for the braindamaged character set):
First Place������� Team PLClub
����������� Second Place�� Camls 'R Us
����������� Third Place������ Team Galois Connections
����������� Fourth Place���� The Merry Mercurians
����������� Judges' Prize��� Team Helikopter -- awarded for the
coolest test image (GML source, image)
First, second used Ocaml, third Haskell, and fourth Mercury.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
israel raj thomas <·······@optushome.com.au> writes:
>They are all good languages and yes, it is a matter of taste.
>In the recent ICFP competition ( involved writing a ray tracer that
>could handle a functional scene description language as input ), the
>first and second prizes went to the Ocaml team. The second and third
>prizes went to teams using Haskell.
So does that mean that the team that got second prize used
both Ocaml _and_ Haskell??
;-)
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
>>They are all good languages and yes, it is a matter of taste.
>>In the recent ICFP competition ( involved writing a ray tracer that
>>could handle a functional scene description language as input ), the
>>first and second prizes went to the Ocaml team. The second and third
>>prizes went to teams using Haskell.
>
>So does that mean that the team that got second prize used
>both Ocaml _and_ Haskell??
Sorry, the _third_ prize went to the Haskell team.
:-)
Mercury won the fourth prize and
finally Team Helikopter using SML won the Judges Prize for the best
image.
"There were 39 entries, with teams ranging from 1 to 13 persons.
Breakdown by language used:
C, C++ 7
Clean 1
Dylan 1
Eiffel 1
Haskell 6
Java 6
Mercury 1
ML 9
Perl 2
Python 1
Scheme 2
Smalltalk 2
"
israel raj thomas <·······@optushome.com.au> writes:
> "There were 39 entries, with teams ranging from 1 to 13 persons.
> Breakdown by language used:
> C, C++ 7
> Clean 1
> Dylan 1
> Eiffel 1
> Haskell 6
> Java 6
> Mercury 1
> ML 9
> Perl 2
> Python 1
> Scheme 2
> Smalltalk 2
I'm confused, since this column adds to 39, but there's no OCaml
there. Am I missing something?
If it interests anyone, there is an OO book out there that compares
the object systems of CL, Haskell, and Eiffel (I think it was those
3). If people are interested in that book, let me know, and I'll try
to get the name.
I do think that it's good for people to know what other programmers
are using in competitions, and which languages win. These languages
are interesting, but it's important to consider the criteria for
winning.
OCaml really does look interesting, considering what people have been
able to do with it. I think the syntax and the feel of it just wasn't
right for me, but it's free, got a supposedly excellent compiler, and
is relatively high-level. Probably worth looking at again.
dave
On 5 Jan 2001, David Bakhash wrote:
> israel raj thomas <·······@optushome.com.au> writes:
>
> > "There were 39 entries, with teams ranging from 1 to 13 persons.
> > Breakdown by language used:
> > C, C++ 7
> > Clean 1
> > Dylan 1
> > Eiffel 1
> > Haskell 6
> > Java 6
> > Mercury 1
> > ML 9
> > Perl 2
> > Python 1
> > Scheme 2
> > Smalltalk 2
>
> I'm confused, since this column adds to 39, but there's no OCaml
> there. Am I missing something?
Yup. OCaml is a variant of ML.
Aaron
Aaron Reichow :: "In essence, Smalltalk is a programming
Twin Ports ACM Vice President :: language focused on human beings rather
http://www.d.umn.edu/~reic0024/ :: than the computer." - Alan Knight
David Bakhash <·····@alum.mit.edu> writes:
> I'm confused, since this column adds to 39, but there's no OCaml
> there. Am I missing something?
OCaml is in the ML family of languages.
> OCaml really does look interesting, considering what people have
> been able to do with it. I think the syntax and the feel of it just
> wasn't right for me, but it's free, got a supposedly excellent
> compiler, and is relatively high-level. Probably worth looking at
> again.
OCaml is actually pretty cool. I used it for one project very good
results. But programming in it is totally different than programming
in Lisp - I spent a great deal of time staring at complex type
inference clashes from the compiler.
Colin Walters <·········@cis.ohio-state.edu> writes:
> OCaml is actually pretty cool. I used it for one project very good
> results. But programming in it is totally different than
> programming in Lisp - I spent a great deal of time staring at
> complex type inference clashes from the compiler.
Yeah. After using Common Lisp for a while, you start to appreciate
the fact that it's loosely-typed, but that you can insert declarations
when appropriate. The fact that OCaml is strictly typed is a minus as
far as I'm concerned, but I can see how that leads to producing fast
code overall.
dave
On Sun, 07 Jan 2001 01:20:44 GMT, David Bakhash <·····@alum.mit.edu> wrote:
> Colin Walters <·········@cis.ohio-state.edu> writes:
>
> > OCaml is actually pretty cool. I used it for one project very good
> > results. But programming in it is totally different than
> > programming in Lisp - I spent a great deal of time staring at
> > complex type inference clashes from the compiler.
>
> Yeah. After using Common Lisp for a while, you start to appreciate
> the fact that it's loosely-typed, but that you can insert declarations
> when appropriate. The fact that OCaml is strictly typed is a minus as
> far as I'm concerned, but I can see how that leads to producing fast
> code overall.
NB "strictly typed" does not necessarily equate with having to put type
declarations all over the shop. Good type inference in strictly typed
languages can mean less type declarations than is commonly needed with many
Lisp implementations (in order to achieve comparable performance). But you
knew that.
__Jason
Jason Trenouth <·····@harlequin.com> writes:
> NB "strictly typed" does not necessarily equate with having to put
> type declarations all over the shop. Good type inference in strictly
> typed languages can mean less type declarations than is commonly
> needed with many Lisp implementations (in order to achieve comparable
> performance). But you knew that.
It's hard to imagine that the strict typing wouldn't get in the way,
regardless of how good the inference engine is. But I don't have any
experience with these kinds of langauges (i.e. OCaml) so I don't know
for sure.
Thanks for making that point, though. Please, however, explain to me
how OCaml would differ from a CL that does lots of type inference,
e.g. CMUCL, both with respect to performance and ease of writing code.
thanks,
dave
From: Andrew Cooke
Subject: Re: Question about CLisp, Dylan, Haskell, Ocaml
Date:
Message-ID: <93mhqm$ufe$1@nnrp1.deja.com>
In article <···············@home-on-the-dome.mit.edu>,
David Bakhash <·····@alum.mit.edu> wrote:
> It's hard to imagine that the strict typing wouldn't get in the way,
> regardless of how good the inference engine is. But I don't have any
> experience with these kinds of langauges (i.e. OCaml) so I don't know
> for sure.
>
> Thanks for making that point, though. Please, however, explain to me
> how OCaml would differ from a CL that does lots of type inference,
> e.g. CMUCL, both with respect to performance and ease of writing code.
It's a trade-off. If you have to add type declarations to CMUCL then
you're doing work that's not necessary in ML(*); similarly you
sometimes have to do more work in ML to pacify the static type
checker. I suspect that the sections of code that you need to
concentrate on for CMUCL (where it can't make inferences from earlier
information itself) are also sections of code where you need to be
careful with static types.
I can think of examples involving ease of writing code that support
either language:
In my (limited) experience it can be tricky remembering exactly what
arguments are needed for complex higher-order functions in Lisp; ML's
type system give a kind of self-documentation that helps here.
On the other hand, in Lisp/Scheme I've used references to null values
that are later replaced by something (ie the type is know later); ML
requires a different approach (options, for example).
Performance wise, there are some comparisons <a
href="http://www.bagley.org/~doug/shootout/">here</a>, but not all CMUCL
examples have type declarations (don't look at the silly "scores" -
choose individual tests).
Static/dynamic typing are not the only differences between ML and CL.
In my opinion what makes Lisp distinctive is the weak separation
between data and code - demonstrated by the reader, macros, and
data-driven programming. ML doesn't have those and is cleaner and
simpler for it.
Andrew
http://www.andrewcooke.free-online.co.uk/index.html
* I hope it's common knowledge that type declarations are inferred from
the code in ML except in very special cases.
Sent via Deja.com
http://www.deja.com/
In article <············@nnrp1.deja.com>, Andrew Cooke
<······@andrewcooke.free-online.co.uk> wrote:
> Performance wise, there are some comparisons <a
> href="http://www.bagley.org/~doug/shootout/">here</a>, but not all CMUCL
> examples have type declarations (don't look at the silly "scores" -
> choose individual tests).
I guess the (CMU)CL examples need some hacking. Better results
should be possible.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <············@nnrp1.deja.com>, Andrew Cooke
> <······@andrewcooke.free-online.co.uk> wrote:
>
> > Performance wise, there are some comparisons <a
> > href="http://www.bagley.org/~doug/shootout/">here</a>, but not all CMUCL
> > examples have type declarations (don't look at the silly "scores" -
> > choose individual tests).
>
> I guess the (CMU)CL examples need some hacking. Better results
> should be possible.
It should also be noted that most (CMU)CL examples have a
(defun main ...)
and then the time is taken taking into account startup time. Not a
thing that is usually otimized in CL systems.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > In article <············@nnrp1.deja.com>, Andrew Cooke
> > <······@andrewcooke.free-online.co.uk> wrote:
> >
> > > Performance wise, there are some comparisons <a
> > > href="http://www.bagley.org/~doug/shootout/">here</a>, but not all CMUCL
> > > examples have type declarations (don't look at the silly "scores" -
> > > choose individual tests).
> >
> > I guess the (CMU)CL examples need some hacking. Better results
> > should be possible.
>
> It should also be noted that most (CMU)CL examples have a
>
> (defun main ...)
>
> and then the time is taken taking into account startup time. Not a
> thing that is usually otimized in CL systems.
But for a lot of these benchmarks it does not really matter.
CMUCL comes up fast enough.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
>>>>> "Rainer" == Rainer Joswig <······@corporate-world.lisp.de> writes:
Rainer> In article <············@nnrp1.deja.com>, Andrew Cooke
Rainer> <······@andrewcooke.free-online.co.uk> wrote:
>> Performance wise, there are some comparisons <a
>> href="http://www.bagley.org/~doug/shootout/">here</a>, but not all CMUCL
>> examples have type declarations (don't look at the silly "scores" -
>> choose individual tests).
Rainer> I guess the (CMU)CL examples need some hacking. Better results
Rainer> should be possible.
Perhaps. At least for the matrix multiplication example, I don't
think CMUCL can get any better. The main problem is that the example
uses a 2-D array and CMUCL doesn't have 2-D simple-arrays. (CMUCL
simple-array's are 1-D). If you change the code to work on 1-D arrays
and compute the indices by hand, I would think the results would be
very close to C speeds.
I did this test once with Fortran versus CMUCL with a matrix addition
using 2-D array in Fortran and 1-D array in CMUCL. The execution
times were indistinguishable.
Ray
Scripsit David Bakhash <·····@alum.mit.edu>
> israel raj thomas <·······@optushome.com.au> writes:
> > "There were 39 entries, with teams ranging from 1 to 13 persons.
> > Breakdown by language used:
> > ML 9
> I'm confused, since this column adds to 39, but there's no OCaml
> there. Am I missing something?
Caml counts as an ML dialect for this breakdown.
--
Henning Makholm "Punctuation, is? fun!"
In article <············@cantaloupe.srv.cs.cmu.edu>, David Bakhash
<·····@alum.mit.edu> wrote:
> israel raj thomas <·······@optushome.com.au> writes:
>
> > "There were 39 entries, with teams ranging from 1 to 13 persons.
> > Breakdown by language used:
> > C, C++ 7
> > Clean 1
> > Dylan 1
> > Eiffel 1
> > Haskell 6
> > Java 6
> > Mercury 1
> > ML 9
> > Perl 2
> > Python 1
> > Scheme 2
> > Smalltalk 2
>
> I'm confused, since this column adds to 39, but there's no OCaml
> there. Am I missing something?
OCaml is counted as a dialect of ML.
-- Bruce
israel raj thomas wrote:
> They are all good languages and yes, it is a matter of taste.
> In the recent ICFP competition ( involved writing a ray tracer that
> could handle a functional scene description language as input ), the
> first and second prizes went to the Ocaml team. The second and third
> prizes went to teams using Haskell.
>
> See:
> http://caml.inria.fr/icfp99-contest/
> http://caml.inria.fr/icfp00-contest/
> for more information on theocaml entries for 1999 and 2000.
> and for information on the 2000 winners see:
> http://www.cis.upenn.edu/~sumii/icfp/
>
And what should us say that?
a) That Ocaml is a better language than others?
b) That Haskell is a better language than others?
c) I've not seen any CommonLisp or Dylan Teams - would that change the
result?
I think this could say that either high-level languages are more mighty
than pseudo-languages like Perl,Java and C++ or that the winning teams
had more experience.
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
>> http://www.cis.upenn.edu/~sumii/icfp/
A fuller recount is available at:
http://www.cs.cornell.edu/icfp/contest_results.htm
> And what should us say that?
> a) That Ocaml is a better language than others?
> b) That Haskell is a better language than others?
Draw your own conclusions. There's more, for instance it appears that
Daniel Wright wrote single-handedly a quite respectable Java entry -
only knocked out in the last round. Ben Lynn did well with Eiffel,
and the Golden Mean, another one-man entry, in C++. Each could have
taken fourth, had they rendered correctly in the final stage.
Sandburst, using a combination of Haskell and C only made it to second
tier, but was apparently the second fastest entry, as far as it went
in the competition.
> c) I've not seen any CommonLisp or Dylan Teams - would that change the
> result?
Check the URL. There was a Dylan team (and some Schemes, and
Smalltalks), but AFAICT, no CL team. All of these were eliminated in
the first round, measuring image correctness, it seems.
> I think this could say that either high-level languages are more mighty
> than pseudo-languages like Perl, Java and C++ or that the winning teams
> had more experience.
The latter is probably very important, IMHO. Certainly, for
efficiency, which was the final criterion, I expect every trick in the
book (and probably every other trick, too) to have been used.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
>> They are all good languages and yes, it is a matter of taste.
>> In the recent ICFP competition ( involved writing a ray tracer that
>> could handle a functional scene description language as input ), the
>> first and second prizes went to the Ocaml team. The third
>> prizes went to teams using Haskell.
>c) I've not seen any CommonLisp or Dylan Teams - would that change the
> result?
There was one Dylan team.
Of course, such a competition does not allow for varying degrees of
experience / ability.