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

I also have to say that the Haskell wiki doesn't exactly reflect the 
views of the whole FPL community. The target audience is probably novice 
to moderately experienced programmers coming from other (mainly 
imperative) languages. There's lot of hype around FPL, and to get a 
better view of the matter, I recommend studying the history of FPLs, 
accompanied by references to constructive logic.

Simon Peyton Jones had in his slides a nice graph of the reliability vs 
performance issues. Functional languages were originally very slow, but 
had the safety aspect. Imperative languages have always been fast, and 
only gradually improved on the reliability front. Pure functional 
languages have never given up the reliability aspect, so it's a bit 
surprising how small amount of people here know what's their biggest 
advantage. Without syntactic sugar functional languages can be terribly 
verbose. Try writing functional code in runtime D or worse, with 
templates, and you'll begin to see just how verbose it really can be.