From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.129.157.2 with SMTP id u2mr228186ywg.15.1447836521264; Wed, 18 Nov 2015 00:48:41 -0800 (PST) X-Received: by 10.183.3.106 with SMTP id bv10mr3894obd.17.1447836521224; Wed, 18 Nov 2015 00:48:41 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!f78no537230qge.1!news-out.google.com!f6ni6072igq.0!nntp.google.com!i2no4598236igv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 18 Nov 2015 00:48:40 -0800 (PST) In-Reply-To: <874mgjnctv.fsf@nightsong.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=82.216.245.129; posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr NNTP-Posting-Host: 82.216.245.129 References: <14533506-4289-4148-b8c4-e970f5778b26@googlegroups.com> <87si45msuz.fsf@nightsong.com> <35d6dc4f-4f2e-4e75-925c-e4acc7c8f112@googlegroups.com> <76ea0bc9-537b-4c68-a728-4f634cf6de52@googlegroups.com> <87a8qccxj4.fsf@nightsong.com> <0ff849e9-11d7-438d-abf9-853f79348640@googlegroups.com> <874mgjnctv.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Haskell, anyone? From: Hadrien Grasland Injection-Date: Wed, 18 Nov 2015 08:48:41 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:28437 Date: 2015-11-18T00:48:40-08:00 List-Id: Le mercredi 18 novembre 2015 05:36:32 UTC+1, Paul Rubin a =E9crit=A0: > > 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..." >=20 > 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 som= ewhere in your mental model. Your counterpoint was that recursive code is easy to *write*, and this I wo= n'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 oft= en at odds with each other. I believe they are in the case of loops vs recu= rsion. 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 doe= s 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 b= y using highly sophisticated abstractions even when they are not strictly n= ecessary, if in exchange we can benefit in some other important code design= area such as referential transparency, code reuse, or ease of writing comp= lex algorithms. Much like, for example, garbage collection and lazy evaluat= ion are based on the philosophical viewpoint that it is okay to sacrifice p= erformance 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 the= se complicated programming tradeoffs, and for me exploring this diversity o= f viewpoints is both one of the greatest joys and the greatest pains of lea= rning 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 t= o be had in compromizing on readability sometimes too, depending on the pro= blem you are dealing with. I'm curious about what else I'll discover in my = continued programming language exploration.