Hello ajb, Monday, December 18, 2006, 4:12:01 AM, you wrote:
> time. For example, for certain types of problem, Haskell minimises the > amount of time between the point where I start typing and the point where > I have the answer. of course, we can fool any topic by changing the names. no one will say that Haskell is small productive language, the topic was just about speed of code generated > Similarly, I think today that a decent merge sort in Haskell is likely > to outperform most C qsort() implementations TODAY, under reasonable > conditions (reasonably large data set, for example), because C's qsort() > interface simply cannot support good specialisation. is that really important, having cheap calls? how about comparision between C sorting array of numbers and Haskell sorting *lazy* list of numbers? :) -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe