# [erlang-questions] Question about reverse list of recursion functions

ok <>
Fri Jan 1 11:48:59 CET 2016

```For what it's worth, I have now benchmarked my code and Andrey
Koleshko's.  My code takes 75% of the time of his.  (Yay! Code
golf! Wow! /sarc)

Yawn.  My version of quicksort is *still* beaten by lists:sort/1.

This just underscores Joe Armstrong's point (at least I think it
was his): for most practical purposes a difference of this order

I think this is one difference between programmers and software
engineers.  I *still* think like a programmer.  I *still* worry
about things like calling reverse/1.  And yet I *KNOW* the
slogan "FIRST make it right, THEN make it fast (IF you need to)."

A real software engineer would feel in his or her very bones
that the time you need to reduce is the time from concept to
testing (so that you can make sure that what you have built
is actually solving the right problem).

Maybe when I grow up I'll be a real software engineer.  Sigh.

But even a real software engineer would concede that
- using reverse/1 is more complex than not using it
- code that is more complex is more likely wrong
(for example, using reverse/1 when you shouldn't,
or not using it when you should).

I suspect that a real software engineer would like

%%  list-based quick-sort taking the first element as pivot.
%%  TODO: profile to see if this needs tuning.

qs([H|T]) ->
qs([X || X<-T, X < H]) ++ [H] ++ qs([X || X<-T, X >= H]);
qs([]) ->
[].

even if it is nearly twice as fast as my code,
because it is so hard to get this version wrong.
(Fusing the two list comprehensions into a single traversal
is not beyond the state of the art in functional language
compilers.  Which is not to say the Erlang compiler does it.)

```