If you are so sure that C# will be better than haskell why not prove it at the
ICFP (http://www.icfpcontest.org/).
That should be as fair as possible with your requests for comparison.
It is running next weekend (20th-23rd of July), so you can prove how superior
your C# is.
If you win, peobably everyone here will recognize it.
So go and register.
----- Original Message -----
From: Hugh Perkins
To: Sebastian Sylvan
Cc: haskell-cafe@haskell.org
Sent: Sunday, July 15, 2007 10:39 PM
Subject: Re: Re[4]: [Haskell-cafe] In-place modification
On 7/15/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote:
[Lots of stuff]
Ok, Sebastian, there's such a thing as analysing products along multiple
orthogonal axes.
At no point have I claimed that C# is better at threading than Haskell, in
fact I'm pretty sure I've mostly suggested that Haskell might have answers for
this?
Nevertheless, threading is not the only point of interest when one analyses a
language. One is also interested in things like:
- how easy is it to check function parameters for type (ok in Haskell) and
name (not ok)
- how fast does a pure computational function actually run. It's fine saying
threading will multiple execution times by the number of cores, but on a
256-core machine, if the underlying code runs 500 times slower, you're actually
going to run 50% slower overall ;-) and use up every processor on that machine
just for that one task
- how easy it to do things that are necessary for one's job. For me this
means things like:
- is it easy to serialize arbitrary objects to/from xml (answer: didnt
used to be, but I managed to implement a good-enough solution)
- create forms/web pages (answer: havent checked yet)
- carry out network rpc (answer: doesnt exist yet, would need to write it
myself)
- use opengl (not for my job, but I enjoy doing things outside of work too
;-) )
- how easy is it for typical developers to use. (answer: not easy; that
means developers will cost lots more money)
So... benchmarking comes into play to find out how fast a pure computational
function actually runs (point 2), and how well opengl runs (point 3.4). I
didnt try opengl yet, I'm not holding my breath, but I'll give it a shot and
see what happens.
For the pure computation, FWIW my personal conclusions at the moment:
- Haskell can get up to C# speeds, by using imperative algorithms
- what does this say about lazy algorithms???
- intuitively written, maintainable Haskell algorithms run at far from C#
speeds
It's ok, I'm not planning on using Haskell today, I'm sure you guys will sort
this stuff out by the time Haskell becomes useful.
Or: the concepts from Haskell that work well will be imported into other
languages. If you can run haskell in imperative-mode, I dont see why C# cant
run in pure mode. In that case, knowing how haskell works will probably make
it easier to understand how C#-puremode works.
------------------------------------------------------------------------------
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
