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!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Haskell, anyone?
Date: Wed, 18 Nov 2015 17:06:17 -0600
Organization: JSA Research & Innovation
Message-ID: <n2j09a$pg2$1@loke.gir.dk>
References: <c6ac0d2f-52af-4aa6-ba6f-34f61e3c93e8@googlegroups.com>
 <14533506-4289-4148-b8c4-e970f5778b26@googlegroups.com>
 <87si45msuz.fsf@nightsong.com>
 <35d6dc4f-4f2e-4e75-925c-e4acc7c8f112@googlegroups.com>
 <n2f4q7$eiq$1@dont-email.me>
 <76ea0bc9-537b-4c68-a728-4f634cf6de52@googlegroups.com>
 <87a8qccxj4.fsf@nightsong.com>
 <0ff849e9-11d7-438d-abf9-853f79348640@googlegroups.com>
 <874mgjnctv.fsf@nightsong.com>
 <b6f252a0-1dbe-4b65-b1f3-df591df27567@googlegroups.com>
 <87ziyblkzn.fsf@nightsong.com>
 <937b88b1-66aa-4205-a412-9588d83a3f26@googlegroups.com>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1447887978 26114 24.196.82.226 (18 Nov 2015 23:06:18 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Wed, 18 Nov 2015 23:06:18 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:28446
Date: 2015-11-18T17:06:17-06:00
List-Id: <comp.lang.ada>

"Hadrien Grasland" <hadrien.grasland@gmail.com> wrote in message 
news:937b88b1-66aa-4205-a412-9588d83a3f26@googlegroups.com...
...
>This does not mean that there isn't a benefit to the functional ways. But I 
>don't
> think that we can handwave away their additional complexity with a simple 
> "it
> depends on what you're used to". Functional constructs are, indeed, less 
> intuitive,
>and according to Occam's principle such extra learning complexity deserves 
>a
>good motivation (which I believe most functional programming fans will be
>happy giving anyway).

I agree. In addition, this is an Ada forum, and it would be nice to get back 
to conversation about Ada.

So, let me say that it certainly possible to program in a functional style 
using Ada.

It's always been possible to construct pure functions (those with no 
side-effects) in Ada, and it's likely that Ada 2018 will have a way to 
declare and enforce that.

One can use the advanced data structures in Ada.Containers to program using 
lists, maps, trees, and so on without messing with the ugly details 
(including storage management). It would be easy to use these structures as 
a basis for even higher level operations if one really wanted to hide 
iterators and the like. (You can already use the call-back form of iteration 
to avoid any visible imperative code, if you wanted to do that.)

As Hadrien said, it's useful to have FP techniques available when they work 
well, but one really doesn't want to be fenced into any single programming 
paradyme. Basic imperative programming alone, or ADTs alone, or OOP alone, 
or FP alone, or whatever alone, is almost never the best way to get things 
done. Some problems map naturally into one style or another, and its crazy 
to be fenced into some other style for such problems.

                                    Randy.