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 -----
Sent: Sunday, July 15, 2007 10:39
PM
Subject: Re: Re[4]: [Haskell-cafe]
In-place modification
On 7/15/07, Sebastian Sylvan <sebastian.sylvan@gmail.com>
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