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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: Haskell, anyone? Date: Wed, 18 Nov 2015 01:23:08 -0800 Organization: A noiseless patient Spider Message-ID: <87ziyblkzn.fsf@nightsong.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="560a36ee31cc4bcf69e115b311f0cc5c"; logging-data="25245"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+VrS5rG14KzRqmGRVMzwL2" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:Msz2qbdt3lVKD0+cePLkmdwk20o= sha1:8ynMcYtexMRKL7Q9sb3jcfA8lgU= Xref: news.eternal-september.org comp.lang.ada:28438 Date: 2015-11-18T01:23:08-08:00 List-Id: Hadrien Grasland writes: > 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... Your counterpoint was that recursive code > is easy to *write*, I don't find the recursive version harder to read. In the goto version, the variable is changing while the thing runs, so at one place it's 5 and at another place it's 4, and I have to keep track of that, and it's potentially exponentially worse when there's more than one variable changing. In the recursive version, the values don't change. Yes you have to be aware of possible stack consumption but that becomes second nature, and there are also tools that can monitor your code for space consumption to catch any problems. > 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. It's probably mostly a matter of what you're used to. If I look at a Swedish web page and can't understand much of it, that's because I don't know the language, not because of the style or ideas in it. > 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. Again it's a matter of what you're used to and what you consider conventional. There are some intro classes being taught with Haskell and ML these days, and SICP back in the day used Scheme in mostly-functional style. If you're writing concurrent programs you should know about those immutable structures anyway. > 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, I'd say Haskell is at the high end of the sophistication scale for general-purpose languages, so that critique applies more to it than to (say) Scheme or ML. But IMO that sophistication also makes it the most enlightening for programmers trying to expand their technical range. Ocaml may be more practical and I want to try using it sometime. > 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. Haskell is pretty readable if you know the language, especially if you write good comments. It's not COBOL but you really probably don't want it to be. One issue though is that the language keeps changing. SML is basically frozen and I guess that has attractions. >"Try to use the simplest abstraction that will work well" is an >important principle for me. Sure, that makes sense.