Bulat Ziganshin <[EMAIL PROTECTED]> writes: > 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
No. The topic was "A suggestion for the next high profile Haskell project", before that "Mozart vs. Beethoven" and before that "Haskell for Dummies". All of which could be construed to suggest the value of structure and clearness over mere performance. >> 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 't'was your topic: speed. :-) > C sorting array of numbers and Haskell sorting *lazy* list of numbers? :) Sorting lazy lists? I think they would have to be forced ..., wouldn't they? Regards -- Markus _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
