Go rant

[Andrei Alexandrescu]

Daniel de Kok wrote:
> On 2009-12-19 21:04:32 +0100, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
>> "This code is shown for its elegance rather than its efficiency. Using 
>> ++ in this way is not generally considered good programming practice."
>>
>> So if the code is inefficient and in poor programming practice, how in 
>> this blessed world could it count as elegant?
> 
> Well, it is elegant in that it is very readable, and as such provides 
> educational value.

I disagree. We don't want to educate people to write patently 
inefficient code and in poor programming practice.

When I was doing Windows programming, I noticed that many example in the 
documentation were written in terrible style. I also noticed that much 
of the production code I was working with was often stitched from 
documentation examples.

> There are very many examples in programming text 
> books that may not be efficient, but do show the solution to a problem 
> elegantly.

Yeah, exponential-time Fibonacci and bubble sort come to mind.

In my mind "elegant" and "at a polynomial blowup in complexity" can't be 
reconciled anywhere outside a Turing machine introduction where 
everything is equivalent within a polynomial difference in time and space.

> E.g. consider list reversal in a recursive function or predicate. It is 
> easy to see that to reverse a list, you append the head to the reversed 
> tail. E.g.:
> 
> reverse([],[]).
> reverse([H|T],R) :-
>  reverse(T,RT),
>  append(RT,[H],R).
> 
> Of course, this is very inefficient, since the program is doing (slow) 
> appends all the time, and is not tail-recursive. You can do it a lot 
> faster with an accumulator, but it makes the solution also less 
> understandable, and not something you'd want to present students/readers 
> immediately:
> 
> reverse(List,Reverse) :-
>  reverse_aux(List,Reverse,[]).
> 
> reverse_aux([],List,List).
> reverse_aux([H|T],List,List0) :-
>  reverse_aux(T,List,[H|List0]).

Yah, I understand. But what you're really saying is that reverse offers 
either a simple implementation or an efficient implementation, but not 
both. That's hardly furthering my belief that FP has a crushing 
advantage over pretty much anything else.

In another thread, "retard" wrote in response to the comparison of the 
real quicksort in C and Haskell:

"What is so brilliant? Referential transparency is broken unless single-
threadedness is forced through monadic computation or by some other 
means (uniqueness types comes to mind)."

I think that's a roundabout way of saying that functional programming is 
unable to express certain algorithms easily or at all.

>> I have gathered a fair amount of samples of involuntary humor from 
>> that book. I wouldn't want to go on about that because it could too 
>> easily be interpreted as poor taste competitiveness. Let me say I 
>> don't think the book is well written.
> 
> It seems that currently the time to market is much more important than 
> to provide good material, although I cannot comment on that particular 
> book.

I agree, and I already know of many places in which TDPL has cut quality 
corners to make it on time, but I hope it never transgressed into 
intellectual dishonesty. You are supposed to make it look easy, but you 
can't afford expending the truth in the process.


Andrei