what do you think of haskell ? (yes, it's a bit general ...:)

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

what do you think of haskell ? (yes, it's a bit general ...:)

Vo Minh Thu
hi all folks,

i'm diving into haskell for more than one year now.
the reason for that is just that i like haskell.
(i'm a computer science student)

but i consider to move back to c/c++.

here are my thoughts.
i've no specific question but i'd like to have your opinion.

here we go:
haskell is really nice : short phrased, declarative, math-feeling, the
type system ensure low bug amount (i surely forget other nice things).

but haskell is quite ugly in some way :

* 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).
worst, code involving one type can need to be rewritten for another type.

* laziness / array (again)
(i am biased since i have no knowledge of haskell profiling /
performance seeking)
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.

but with iouarray, i cant use an array of MyType; i have to use an
array of (say) float (it's ok if i have only float in MyType).

that kind of thing is what i think is *really* low-level.
in c, i can have an array of what-i-want.

* randomIO
side-effect is nicely resolved with monad. and you have to thread your state.
if you're writing your monad or use a transformer, things are quite
explicitly (even if it's implicit in the do notation) threaded.

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.
it feels exactly like a c function. but usually, you cant design a
c-like function in haskell (i.e. a function with state).

* more things i dont remember...

* generally
my general feeling for haskell vs c is:
in haskell i always have to learn new things to get my work done ;
although haskell is really easy to learn in the first step, it's
becoming increasingly hard to get what's the *trick* to do what i
want.

e.g. writing myfunction x1 .. xn | x1 `seq` ... False = undefined is
not declarative
(and i still have to learn to identify where it helps and where it doesn't)

the c language take some more time to learn at the beginning but that's it!
what you can learn by after is better c programming.
there are memory management, pointers, side-effects, but you can do
what you want, it behaves as expected and you dont have to learn (in a
academic paper) how to use an array or how to do io.

:)
please don't tell me "you're stupid, go back to your c and leave this
glorious mailing list"

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

thanks a lot,
vo minh thu
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Neil Mitchell
Hi Minh,

When I write Haskell, its because I want to write the code quickly,
not because I want it to run quickly. GHC is a wonderful compiler and
makes things go fast, but Hugs is faster at compiling, so I always use
Hugs (WinHugs in fact). If your focus is on things going fast, then
with Haskell you have to think harder to get this - but its certainly
possible, see the shootout benchmarks.

> * array
Why do you want to write things with Array's - in C the default type
of everything is an Array, and you occasionally use a Linked List. In
Haskell its the opposite - linked lists are very nice and natural - I
never use arrays.

> * laziness / array (again)
Laziness often makes my code go faster - because I am lazy and
Haskell's laziness means that when I combine things in just "lazy"
ways Haskell drops the things I did that were useless.

> * randomIO
> side-effect is nicely resolved with monad. and you have to thread your state.
> if you're writing your monad or use a transformer, things are quite
> explicitly (even if it's implicit in the do notation) threaded.
Yes, C is nicer for this kind of thing, in my opinion - nicer from a
practical view, even if it is pretty horrid in the end.

> * generally
> my general feeling for haskell vs c is:
> in haskell i always have to learn new things to get my work done ;
> although haskell is really easy to learn in the first step, it's
> becoming increasingly hard to get what's the *trick* to do what i
> want.
I think I know very few tricks, and have never felt the need to know
more. If you stick to simple Haskell it keeps your brain for other
things.

I think what you seem to be saying is that to write fast Haskell
programs requires more effort and more work than C programming?
Exactly what Haskell programs were you trying to write, and did you
try just writing them in a naive way and checking that just "simple
and stupid" doesn't give you the performance you need?

Maybe if you learnt the FFI aspects of Haskell, you could write your
code in Haskell, and then either optimise the Haskell or just give up
and move that portion to C, keeping the rest in Haskell.

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Vo Minh Thu
hi, thanks for your answer.

the kind of thing i want to do : computer graphics programming.
so array is better than list (no ?) to represent images ...

bye
vo minh thu
(hey, my last name is VO, and my first name is Thu, not Minh :)


2006/6/15, Neil Mitchell <[hidden email]>:

> Hi Minh,
>
> When I write Haskell, its because I want to write the code quickly,
> not because I want it to run quickly. GHC is a wonderful compiler and
> makes things go fast, but Hugs is faster at compiling, so I always use
> Hugs (WinHugs in fact). If your focus is on things going fast, then
> with Haskell you have to think harder to get this - but its certainly
> possible, see the shootout benchmarks.
>
> > * array
> Why do you want to write things with Array's - in C the default type
> of everything is an Array, and you occasionally use a Linked List. In
> Haskell its the opposite - linked lists are very nice and natural - I
> never use arrays.
>
> > * laziness / array (again)
> Laziness often makes my code go faster - because I am lazy and
> Haskell's laziness means that when I combine things in just "lazy"
> ways Haskell drops the things I did that were useless.
>
> > * randomIO
> > side-effect is nicely resolved with monad. and you have to thread your state.
> > if you're writing your monad or use a transformer, things are quite
> > explicitly (even if it's implicit in the do notation) threaded.
> Yes, C is nicer for this kind of thing, in my opinion - nicer from a
> practical view, even if it is pretty horrid in the end.
>
> > * generally
> > my general feeling for haskell vs c is:
> > in haskell i always have to learn new things to get my work done ;
> > although haskell is really easy to learn in the first step, it's
> > becoming increasingly hard to get what's the *trick* to do what i
> > want.
> I think I know very few tricks, and have never felt the need to know
> more. If you stick to simple Haskell it keeps your brain for other
> things.
>
> I think what you seem to be saying is that to write fast Haskell
> programs requires more effort and more work than C programming?
> Exactly what Haskell programs were you trying to write, and did you
> try just writing them in a naive way and checking that just "simple
> and stupid" doesn't give you the performance you need?
>
> Maybe if you learnt the FFI aspects of Haskell, you could write your
> code in Haskell, and then either optimise the Haskell or just give up
> and move that portion to C, keeping the rest in Haskell.
>
> Thanks
>
> Neil
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Sebastian Sylvan-2
On 6/15/06, minh thu <[hidden email]> wrote:
> hi, thanks for your answer.
>
> the kind of thing i want to do : computer graphics programming.
> so array is better than list (no ?) to represent images ...
>

This may not be very helpful, but I would say that an Image is neither
a list nor an array - it's a function! :-)


/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Joel Reymont

On Jun 15, 2006, at 6:18 PM, Sebastian Sylvan wrote:

> This may not be very helpful, but I would say that an Image is neither
> a list nor an array - it's a function! :-)

How exactly do you manipulate the bits and bytes of a function?

--
http://wagerlabs.com/





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Vo Minh Thu
In reply to this post by Sebastian Sylvan-2
right :)
i had to say a discrete image ... or a raster, or an *array* of pixels !
sylvan, it must be nice to talk with you (an funny) about haskell and cg :)

mt

2006/6/15, Sebastian Sylvan <[hidden email]>:

> On 6/15/06, minh thu <[hidden email]> wrote:
> > hi, thanks for your answer.
> >
> > the kind of thing i want to do : computer graphics programming.
> > so array is better than list (no ?) to represent images ...
> >
>
> This may not be very helpful, but I would say that an Image is neither
> a list nor an array - it's a function! :-)
>
>
> /S
>
> --
> Sebastian Sylvan
> +46(0)736-818655
> UIN: 44640862
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Sebastian Sylvan-2
In reply to this post by Joel Reymont
On 6/15/06, Joel Reymont <[hidden email]> wrote:
>
> On Jun 15, 2006, at 6:18 PM, Sebastian Sylvan wrote:
>
> > This may not be very helpful, but I would say that an Image is neither
> > a list nor an array - it's a function! :-)
>
> How exactly do you manipulate the bits and bytes of a function?

Well I suppose by returning a new function which produces the required
changes, and perhaps refers back to the old function in certain cases.

It's a neat abstraction, anyway, even if you at the very bottom have
some low level representation using pedestrian concepts such as bytes
and bits :-)


/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Henning Thielemann
In reply to this post by Vo Minh Thu

On Thu, 15 Jun 2006, minh thu wrote:

> * randomIO
> side-effect is nicely resolved with monad. and you have to thread your state.
> if you're writing your monad or use a transformer, things are quite
> explicitly (even if it's implicit in the do notation) threaded.

You know that random generators are not bounded to IO? 'random' and
related functions work just like the random generators in object oriented
designs. In OO languages the random generator is usually an object which
hides a state and there can be several instances of random generators. In
Haskell the random generator can be viewed as a State monad. But you are
right, you have to carry the monad with you all the time. Alternatively it
is sometimes simpler to consume values from a list generated by randomRs.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Vo Minh Thu
hi,
yes i know about that, but i was talking about randomIO which breaks that view;
and i find that quite weird for a 'clean' language.

* another thing i remember now :
binary io. there are some libraries but it's not really standard. and
it's weird to learn all (well, or just one) that libraries just to do
io.

cheers,
mt

2006/6/15, Henning Thielemann <[hidden email]>:

>
> On Thu, 15 Jun 2006, minh thu wrote:
>
> > * randomIO
> > side-effect is nicely resolved with monad. and you have to thread your state.
> > if you're writing your monad or use a transformer, things are quite
> > explicitly (even if it's implicit in the do notation) threaded.
>
> You know that random generators are not bounded to IO? 'random' and
> related functions work just like the random generators in object oriented
> designs. In OO languages the random generator is usually an object which
> hides a state and there can be several instances of random generators. In
> Haskell the random generator can be viewed as a State monad. But you are
> right, you have to carry the monad with you all the time. Alternatively it
> is sometimes simpler to consume values from a list generated by randomRs.
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Udo Stenzel
In reply to this post by Vo Minh Thu
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
interface!

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

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


Udo.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Brian Hulley
In reply to this post by Vo Minh Thu
minh thu wrote:
> hi all folks,
>
> i'm diving into haskell for more than one year now.
> the reason for that is just that i like haskell.
> (i'm a computer science student)
>
> but i consider to move back to c/c++.

There is also OCaml and SML, both of which have freely available compilers
to generate fast native code (SML has MLton - a whole program optimizing
compiler), and which use side effects instead of monads.

>
> here are my thoughts.
> i've no specific question but i'd like to have your opinion.
>
> here we go:
> haskell is really nice : short phrased, declarative, math-feeling, the
> type system ensure low bug amount (i surely forget other nice things).
>
> but haskell is quite ugly in some way :
>
> * array : if i want to write something involving array, i could use

[snip]

Bulat's written a new array library - see
http://www.haskell.org//pipermail/haskell/2006-June/018044.html

>
> but with iouarray, i cant use an array of MyType; i have to use an
> array of (say) float (it's ok if i have only float in MyType).
>
> that kind of thing is what i think is *really* low-level.
> in c, i can have an array of what-i-want.

There is a compromise between using IOArray versus IOUArray. IOArrays might
even be more efficient than unboxed arrays in some situations:
1) When (large) elements are shared between different arrays or different
data structures, since only the pointer needs to be copied
2) Compared to C++ templates, only one piece of code needs to be generated
to handle them, so there might be fewer cache misses at runtime

>
> * randomIO
> side-effect is nicely resolved with monad. and you have to thread
> your state. if you're writing your monad or use a transformer, things
> are quite explicitly (even if it's implicit in the do notation)
> threaded.
> 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.
> it feels exactly like a c function. but usually, you cant design a
> c-like function in haskell (i.e. a function with state).

You can instead write a function that returns an action in whatever monad
you're using. For example using a Reader monad to hold IORefs, you can
easily update the state of these IORefs. Of course this is more work than
just declaring some global variable in C and updating it in the function,
but it gives you more flexibility in the long run - you now have full
control over the environment that the function sees, just by running it in
another Reader containing different IORefs.

>
> * more things i dont remember...
>
> * generally
> my general feeling for haskell vs c is:
> in haskell i always have to learn new things to get my work done ;
> although haskell is really easy to learn in the first step, it's
> becoming increasingly hard to get what's the *trick* to do what i
> want.

Maybe you are expecting too much of your code. A while back I was agonizing
over the perfect way to write something using higher order functions, then a
comment by Bulat (
http://www.haskell.org//pipermail/haskell-cafe/2006-May/015540.html ) helped
me put things in perspective:

    imho, it's typical functional style,
    but without using higher-level functions

So now I just concentrate on getting code to work and leave the highly
obfuscated cleverness for later... ;-)

>
> e.g. writing myfunction x1 .. xn | x1 `seq` ... False = undefined is
> not declarative
> (and i still have to learn to identify where it helps and where it
> doesn't)

Bang patterns would at least make the syntax easier to write. Strictness
annotations work both ways - perhaps the question should be: where does
*lazyness* help? I don't think anyone really has a clear answer to this at
the moment.

>
> the c language take some more time to learn at the beginning but
> that's it! what you can learn by after is better c programming.

I think (as someone who has spent at least 16 years programming in C++) that
there are millions of complicated things there as well. The syntax and
semantics of a language is only the very start. C and C++ have idioms to
learn too, and like anything, it takes a lot of time and experience to know
which "trick" to use in a given situation. Just as the object oriented
community has spent many years slowly trying to understand how to design
object oriented programs and made major mistakes at the beginning (eg using
implementation inheritance instead of interfaces and composition (exactly
what is fully supported in Haskell by classes and instances)).

> there are memory management, pointers, side-effects, but you can do
> what you want, it behaves as expected and you dont have to learn (in a
> academic paper) how to use an array or how to do io.

Haskell has a difficult learning curve. I remember the first few times I
looked at the type signatures for the methods of Data.IArray and it was
certainly not at all clear! :-) In the worst case, you can always use the
FFI to link with some C if there is some especially tricky low level
operation that needs to be very fast.

>
> :)
> please don't tell me "you're stupid, go back to your c and leave this
> glorious mailing list"
>
> did you had the same feeling ? does it disappear ? how ?

I think it just takes time to gradually understand enough to write whatever
program you're writing. There are lots of useful tutorials on the wiki (both
old and new wiki). To understand things like monads and monad transformers,
you can also look at the Haskell source (available from ghc wiki for
example) to see that they are not so complicated as they appear if you only
look at the Haddock documentation which only gives the type signatures.

Regards, Brian.

--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Bulat Ziganshin-2
Hello Brian,

Friday, June 16, 2006, 2:18:24 AM, you wrote:

>> but i consider to move back to c/c++.

> There is also OCaml and SML, both of which have freely available compilers
> to generate fast native code (SML has MLton - a whole program optimizing
> compiler), and which use side effects instead of monads.

i also mentioned that all complaints are really about laziness and
purity of language, so ocaml/sml and may be even Clean will be better
alternative. there was also discussions about strict haskell dialect
(look in archives) and it seems that strictness can be obtained just
by running special preprocessor which generates all those "!" and
"seq". for example, before preprocessor:

data T = C Int Char
f x = x*2

after:

data T = C !Int !Char
f x | x `seq` True = x*2


>> * array : if i want to write something involving array, i could use
> Bulat's written a new array library - see
> http://www.haskell.org//pipermail/haskell/2006-June/018044.html

i just rewrote existing lib and it don't have any differences from
original in areas mentioned by Thu. may be he don't read the
http://haskell.org/haskellwiki/Arrays - in particular, it mention that
array library really has only two interfaces - one for mutable and for
immutable arrays

one thing not yet mentioned there is what GHC has parallel arrays that
are strict but can contain elements of any type

>> e.g. writing myfunction x1 .. xn | x1 `seq` ... False = undefined is
>> not declarative
>> (and i still have to learn to identify where it helps and where it
>> doesn't)

> Bang patterns would at least make the syntax easier to write.

they are already supported in ghc 6.5




--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Bulat Ziganshin-2
In reply to this post by Vo Minh Thu
Hello minh,

Friday, June 16, 2006, 12:14:00 AM, you wrote:

> yes i know about that, but i was talking about randomIO which breaks that view;
> and i find that quite weird for a 'clean' language.

there is also haskell-based language named Clean, look at it too :)

> * another thing i remember now :
> binary io. there are some libraries but it's not really standard. and
> it's weird to learn all (well, or just one) that libraries just to do
> io.

1) most of these libs derived from GHC module Binary and therefore has the
same interface

2) best is my own library (see http://haskell.org/haskellwiki/Library/AltBinary )
what can be simpler than this:

import Data.AltBinary
main = putWord32 stdout (1::Int)

? :)  just download www.haskell.org/library/Streams.tar.gz or
www.haskell.org/library/StreamsBeta.tar.gz



--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Vo Minh Thu
In reply to this post by Udo Stenzel
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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what do you think of haskell ? (yes, it's a bit general ...:)

Donald Bruce Stewart
noteed:
>
> 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!

Try Data.ByteString. 4G can be feasible :)

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Bulat Ziganshin-2
In reply to this post by Vo Minh Thu
Hello minh,

Friday, June 16, 2006, 10:09:47 AM, you wrote:

> it's not ok (i always think to the array exemple) : it works well for

Thu, haskell/ghc is definitely not for fast execution


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Vo Minh Thu
In reply to this post by Bulat Ziganshin-2
[...]
> import Data.AltBinary
> main = putWord32 stdout (1::Int)
>
>  Bulat                            mailto:[hidden email]

well, you're right, i've a bit to overemphased the learning difficulty..
but, last time i tried to use your lib, i missed some other libraries
(win32 for one ? .. i dont remember).

thank you all,
mt
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Vo Minh Thu
In reply to this post by Bulat Ziganshin-2
>
> Thu, haskell/ghc is definitely not for fast execution
>

really, i was not seeking time performance. i try to have a nice to
read kind of prototype.
but the fact that the program doesn't work with quite small test (but
already too big for it) is a problem.

> Best regards,
>  Bulat                            mailto:[hidden email]
>
>
mt
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Bulat Ziganshin-2
In reply to this post by Vo Minh Thu
Hello minh,

Friday, June 16, 2006, 10:20:24 AM, you wrote:

> well, you're right, i've a bit to overemphased the learning difficulty..
> but, last time i tried to use your lib, i missed some other libraries
> (win32 for one ? .. i dont remember).

if it was with Streams 0.1e, just remove "win32" from cabal file

.. or better download www.haskell.org/library/Streams.tar.gz and try
it - i hope that i fixed this problem


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe