Go rant

[retard]

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!