Tue, 22 Dec 2009 01:43:17 -0800, Walter Bright wrote: > Daniel de Kok wrote: >> I do not mind it, it's ok for explaining a concept clearly. Of course, >> inadequacies should also be discussed. I'd argue that these are also >> the thinking steps normally involved in designing a solution to a >> problem: first try to solve it in the obvious way to understand the >> problem. Then, make a more performant implementation. Of course, >> performant also depends on the context. I have written a lot of C++ >> code that tries to squeeze the last bit of performance out of the >> machine in a single-core world, but it is also difficult to >> parallelize. In a parallel world, the 'slower' solution is sometimes >> better. > > One of the big problems with the presentations of the functional qsort > is that it is presented as a shining success of FP, when it is anything > but. There may be later a footnote or comment that it is not suitable, > but those appear to be written as afterthoughts and do not clearly lay > out what the problems are.
Well, in PL research community the terse functional quicksort code isn't considered that important. The focus is on completely different kinds of systems. I recommend forgetting the whole example for now. The badly performing one liner doesn't mean that all functional programming and all functional programming languages are toys when solving real world problems. There's more diversity in functional languages than in mainstream OOP hybrid languages. You can port the same badly performing code to D and get - surprise, surprise - badly performing qsort in D! The discussion here mostly touts imperative languages with the same old centuries old arguments like "omg functional languages can't do in-place algorithms". "so you need hacks to implement in-place algorithms. that must mean that the elegance of fpl is in fact something that cannot be achieved in real world". I've already repeated this many times: abstractions. Let's assume you have world class in-place implementation of sort in module stdlib.productionquality.collections and a shitty novice implementation of buggy bubble sort in stdlib.crappycrap.collections. Now the only difference on use site is: import sort from stdlib.productionquality.collections sort mycollection vs import sort from stdlib.crappycrap.collections sort mycollection Now how does this prove in any way that functional programming is ugly and broken. With a decent FFI implementation you can even import a C/C++/ D version of the sort function and use that in your functional code. This all works thanks to the universal C ABI. If that C/C++/D code doesn't break referential transparency, it means that the functional code also retains its reliability even if it calls imperative code. > > Furthermore, an introductory FP programming text should be about how to > write useful programs in FP, not about how sorting algorithms work. So all the Haskell/Erlang/ML/Scheme books you've read have been really bad? That only means that there's market for good FPL books, then!
