I'm a recovering programmer who has been designing video games since the 1980s, doing things that seem baroquely hardcore in retrospect, like writing Super Nintendo games entirely in assembly language. These days I use whatever tools are the most fun and give me the biggest advantage.
james.hague @ gmail.com
Where are the comments?
Digging Deeper into Sufficiently Smartness(If you haven't read On Being Sufficiently Smart, go ahead and do so, otherwise this short note won't have any context.)
I frequently write Erlang code that builds a list which ends up backward, so I call
lists:reverseat the very end to flip it around. This is a common idiom in functional languages.
lists:reverseis a built-in function in Erlang, meaning it's implemented in C, but for the sake of argument let's say that it's written in Erlang instead. This is super easy, so why not?
reverseat the very end, just before returning:
"1234". And now one more "suppose": suppose that one time we decide that we really need to process the result of
collect_digitsbackward, so we do this:
reversecould be dropped from
collect_digitsin the generated code, and each call to
collect_digitscould be automatically wrapped in a call to
reverse. If there ends up being two calls to
reverse, then get rid of both of them, because it's just wasted effort to double-reverse a list.
lists:reverseas a built-in, this is easy enough. But can it be deduced simply from the raw source code that
reverse(reverse(List))can be replaced with
List? Is that effort easier than simply special-casing the list reversal function?