[Haskell-cafe] what do you think of haskell ? (yes, it's a bit general ...:)

Udo Stenzel u.stenzel at web.de
Thu Jun 15 18:14:47 EDT 2006

minh thu wrote:
> but i consider to move back to c/c++.

I'm led to believe that you just haven't got the hang of the things that
just aren't there in C, such as Monads and higher order functions.  So
you cannot yet see what you would miss in C.  (And I guess, you're not
feeling at home in C++ either, since there is no language named C/C++.)

Whatever, if you believe a person can only master a single programming
language, it might as well be C for you...

> * array : if i want to write something involving array, i could use
> list, and a lot (too much!) of array types (io/st, mutable/immutable,
> c-friendly (storable).

I've never understood peoples preoccupation with arrays.  You lose all
flexibility just for O(1) lookup and O(1) destructive(!) update.  Most
of the time you're better served with a finite map.

> worst, code involving one type can need to be rewritten for another type.

Huh?  It doesn't, that's the point of the overloaded IArray/MArray

> * laziness / array (again)
> always with array code, i was forced (maybe it's because i dont know enough)
> to use iouarray : if not, performance|memory consumption were low|high.

You're putting unevaluated thunks into your data structure, probably
accumulating them there.  Bringing out the sledge hammer of IOUArray
only obscures the problem.  You should 'seq' data before writeArray'ing

> * randomIO
> but the threading of the randomIO argument is really not explicit for
> me : it just means that the underlying/threaded state in the IO monad
> can encapsulated a lot of things.

Duh, don't use IO if you neither like nor need it.  Most random
functions are no IO actions for a reason.

> e.g. writing myfunction x1 .. xn | x1 `seq` ... False = undefined is
> not declarative

But it isn't all that bad either...

> (and i still have to learn to identify where it helps and where it doesn't)

...while this is the real problem.  You have to understand lazy
evaluation to make beneficial use of 'seq'.  It really helps to
reproduce some reductions on paper.

> the c language take some more time to learn at the beginning but that's it!

Oh come on, you cannot honestly believe that.  If so, please send me
some chunk of nontrivial C code, I send you back at least one location
where it produces undefined behaviour.  Yes, I'm confident that I'll
find some.

> did you had the same feeling ? does it disappear ? how ?

Never had that feeling, because C is just too ugly.  It will disappear
once you really understand lazy evaluation.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org//pipermail/haskell-cafe/attachments/20060616/a84938de/attachment.bin

More information about the Haskell-Cafe mailing list