Re: Haskell, anyone?

[Hadrien Grasland <hadrien.grasland@gmail.com>]

Le mercredi 18 novembre 2015 05:36:32 UTC+1, Paul Rubin a écrit :
> > int iterate_recursion(int n) ...
> > int iterate_goto(int n) ...
> >
> > You have to admit that in the end, the basic approach is almost
> > exactly the same, ..."okay, so at the start of the iteration, the input
> > parameter is indeed n, but after that, we'll decrement it..."
> 
> I don't think so.  In the recursive version, n never changes in the
> context of the function being run.  The function is called again with a
> new value.  Anyway it's not a big deal, there may be some times when an
> iterative loop is slightly more natural, but writing it recursively is
> always easy anyway.  There are much bigger issues in FP that take a
> really different approach to deal with.  For example, the entire topic
> of functional data structures.  Another is the programs-as-proofs
> concept in type theory (Haskell doesn't quite reach there seriously, but
> Agda does).  Recursion vs iteration is a tiny step along the way.

Note that here, our focus is different. My message was about the fact that a program with recursion is about as hard to read and understand as an old-fashioned program featuring gotos. Actually harder, I may add, because for any nontrivial use of recursion, you also need to fit an implicit stack somewhere in your mental model.

Your counterpoint was that recursive code is easy to *write*, and this I won't dispute. It also takes me only a couple of minutes to turn a loop which doesn't modify its argument into a recursion.

However, readability and ease of writing are different goals, which are often at odds with each other. I believe they are in the case of loops vs recursion. And I believe there is also such a usability compromise at work when you need to give up on data structures which everyone knows about, and use more sophisticated and obscure ones, because your programming language does not support very well the conventional abstractions.

So far, my impression is that in the philosophy of functional programming, it is okay to sacrifice readability and make the life of newcomers harder by using highly sophisticated abstractions even when they are not strictly necessary, if in exchange we can benefit in some other important code design area such as referential transparency, code reuse, or ease of writing complex algorithms. Much like, for example, garbage collection and lazy evaluation are based on the philosophical viewpoint that it is okay to sacrifice performance and run-time predictability if in exchange, we can express some tricky concepts like infinite lists or shared variables more easily.

Honestly, I find this fascinating. There's no single good answer to all these complicated programming tradeoffs, and for me exploring this diversity of viewpoints is both one of the greatest joys and the greatest pains of learning new programming languages.

Personally, I am quite obsessed with the idea that my code might be read by someone else someday, including the person I'll be in 20 years, so I tend to put readability fairly high on my priority list when I program something. "Try to use the simplest abstraction that will work well" is an important principle for me. But I can certainly agree that there are some benefits to be had in compromizing on readability sometimes too, depending on the problem you are dealing with. I'm curious about what else I'll discover in my continued programming language exploration.