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

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.

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