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

[minh thu]

thanks, brian, udo and the others for your answers

[...]
> 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++.)

although i'm not comfortable with monad and higher-order function, i
use them and i can find it elegant.

a general aspect of haskell programming that resorts from the mails is
"do it nicely, then see after if it' sufficiently ok". in my case,
it's not ok (i always think to the array exemple) : it works well for
really small amount of data but rapidly hits memory limits.
the answer is not increasing this limit since memory consumption does
not have to grow.
so the answer is : try to figure out where it (laziness) hurts and get
rid of it.

> Whatever, if you believe a person can only master a single programming
> language, it might as well be C for you...
well, i think it's better to know some language, but anyway, even for
one, i still have to know which one suits better my need.

> > * 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.

i want to process 4k pictures (and not just one pixel fater one)... for example.
if there is a better solution than array, i'm eager to know it!

> > 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
> interface!
really ? you would use runSTArray with something else than an ST array ?
you would construct (and then design the wole code around) an array
the same way with DiffArray than with another one ?

i had a nice line of code that looks like this :

process valuess = foldr (acc) emptyArray values

where 'emptyArray' means a zero everwhere array and 'acc' updates the
array in multiple cells for each value of 'values'.

indeed it's really nice : a perfectly readable one-liner that does the job.
(but laziness hurts ...)

now, if i want to change the type of my array, i wont use foldr
neither acc (which can be arbitrary hard to (re)code).

> 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
> it.
ok.

> Duh, don't use IO if you neither like nor need it.  Most random
> functions are no IO actions for a reason.
ok, but i was just saying it's weird to provide randomIO.
obviously, given your answer, it's weird for you too.

> > (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.
ok.

> > 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.
you make mistakes, ok, but i never had the feeling to beat myself
against the language.

> > 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.
>
>
> Udo.

thanks again.